Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

[Michael StJohns <[e-mail]>]

On 6/30/2014 3:16 PM, Nigel Smart wrote:
> What's the difference between defining a cryptographic protocol (i.e. 
> TLS 1.3)
> which could have lots of problems/be cracked/have a back door; and 
> defining
> a cryptographic algorithm which could have lots of problems/be 
> cracked/have
> a back door? Experience shows us that defining cryptographic protocols
> (key agreement/secure channels) is more prone to problems than defining
> cryptographic primtives (AES, ECC). 

If the math is insecure then the cryptographic standard is insecure as 
is everything that depends on it.

If the cryptographic standard is insecure then the cryptographic 
protocols are insecure (but hopefully you can plug in something else - 
e.g. DES vs AES).

If the cryptographic protocol is insecure then the applications are 
insecure (but hopefully you can plug in something else e.g.  TLS1.0 vs 
TLS1.1 vs TLS1.2 vs ??).

Oh yeah - if the implementation is insecure, it doesn't really matter 
whether or not you got everything else right.

So the difference is really about what depends on the protocol vs the 
standard vs the math, and you get more dependencies the closer you are 
to the math.

I tend to agree with you about the problems with defining crypto 
protocols, but at least they are*protocols* which is somewhat within the 
IETF's scope of expertise.  They're also a lot easier for the 
non-crypto-math people to get their heads around.  Crafting a 
cryptographic protocol is still a specialty expertise though.  At least 
TLS13 will have *lots* of eyes on it.  Given the huge set of plugin 
cryptography in TLS, hopefully at least some of it will be secure enough.

Mike