[Cryptography] a question on consensus over algorithmic agility

Stephen Farrell stephen.farrell at cs.tcd.ie
Wed Jun 25 11:06:45 EDT 2014


Just two clarifications...

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

s/Algorithms/protocols/ in the above I think.

> 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.

There's no claim to date about consensus on the tcpcrypt list.
There is a general consensus in the IETF that algorithm agility
in protocols is desirable. And s/algorithms/protocols/ again:-)

S


>  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.
> 
> 
>      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.
> 
> 
> 
> 
> iang
> 
> 
> 
> [0] https://www.ietf.org/mailman/listinfo/tcpcrypt
> 
> [1] agility:  TLS has a config string selecting algorithms at the
> server;  SSH has an ability to handle different ones by selecting
> command line switches.
> 
>     non-agility:  DJB and Tanja Lange have presented protocols in which
> you get one choice only:  one EC curve + Poly + Salsa.  DJB calls it a
> cryptobox.  Bitcoin has one suite: SecP256K1 ECDSA over double SHA256,
> RIPEMD-160 fingerprint.  Etc.
> 
> I'm explicitly handwaving over the level issue of cipher v. small suite
> v. combined PK large suite.  Which distinction is important in TLS.
> 
> 


More information about the cryptography mailing list