[Cryptography] a question on consensus over algorithmic agility

[Peter Fairbrother]

On 25/06/14 16:01, ianG wrote:
> Hi all on the crypto group,
>
>
>
> over on TCPcrypt [0] it is being debated whether Algorithms should be
> Agile [1] for a future extension of TCP that includes opportunistic
> encryption.
>
> It has been claimed that the consensus is that algorithms MUST be agile.
>   And, ditto for TCPcrypt, being a lightweight MITMable protocol.
>
> My question in 2 parts, purely to measure *consensus in this group* as
> opposed to the IETF group:
>
>
>       1.  Do you believe that in general case for the security for the
> net, (a) security protocols MUST be agile w.r.t cryptography ciphers ?
> OR, in the negative, no, protocols may set one cipher and stick with it.



No. Not only no, but - we have a language problem here. You seem to be 
using the word protocol for something other than a defined single way in 
which cryptographic items interact.

Of course, for loosely-defined use of the word "protocols", that 
"defined single way" may frequently involve eg a choice of ciphers, a 
choice of key exchange mechanisms, a choice of encryption and/ or 
authentication methods and/or methodologies, even a choice of whether to 
encrypt or not -


So first of all, TCPcrypt is not a protocol, in the strict sense of a 
defined single way in which cryptographic items interact.



Second, it is my belief that we as cryptographers have a duty to ensure 
that even the luser know-nothing know-it-all annoying helpline clogging 
masturbating useless bastards' communications are actually secure. All 
of them. Always.

So we should have a strict protocol called simply eg Alice. Which 
defines the cipher to be used, the key establishment mechanism, the 
authentication methods etc - as the best we can do.

And if it gets broken, even a little, we say so, and say sorry, and 
replace it with Bob. Alice is broken, sigh, long live Bob!



BTW, I'm not suggesting only one such strict protocol. But each of them 
should have names, and absolutely *everything* should be strictly 
defined, no alternatives, before the name is first used.


I can't see any better, on indeed any other, way for us to perform our duty.

Which includes confirming the expectation of those lusers that we will 
actually provide them with a secure cryptographic solution. A solution 
which is always secure, against everything, from kid sisters to the 
NSA-2500-AD.

And that if we don't, if we messed up, we will say so - and try to do 
better next time.



>       2.  Do you believe in the specific case of an opportunistic,
> dynamic, transparent upgrade inside TCP to an (e.g.,) anonymous DH
> protected secret key protocol, that, the ciphers must be agile?  OR, in
> the negative, no, that particular protocol can insist on only one and be
> done with it.


As I think you might guess, no. Agile because the server might enforce a 
better cipher? but maybe the server is pwned ..

Or maybe so the server can just enforce the use of a worse cipher?

We don't, and can't expect the luser to make the right choice -- beyond 
occasionally perhaps choosing to use our software.




-- Peter Fairbrother