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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 30.06.2014 23:20, Michael StJohns wrote:
> 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.
> 

Because some algorithms have been published as cryptographic standard
doesn't mean the algorithm is without a backdoor. For example:

1. ANSI X3.92, NIST SP 800-67 and ISO/IEC 18033-3, DES cipher
 The key was shortened to 56-bit
https://web.archive.org/web/20140423082937/http://cryptome.org/0001/nsa-meyer.htm

2. ANSI X9.82  NIST SP 800-90A, ISO/IEC 18031:2005, Dual_EC_DRBG
https://projectbullrun.org/dual-ec/vulnerability.html
https://eprint.iacr.org/2006/117

D.J.Bernstein writes: In the past decade NIST has been rushing so many
cryptographic standards out the door that the quality of review has
obviously been compromised.
http://blog.cr.yp.to/20140411-nist.html

Because of possible backdoors some companies are moving away from NIST
cryptographic standards
https://blog.silentcircle.com/nncs/

Also Adam Langley thinks that NIST continually pick algorithms that
aren't suited to software implementations.
https://www.imperialviolet.org/2012/10/21/nist.html

> 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
> 
> 
> 
> _______________________________________________ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTsnMVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2
RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOtXMIQAKD9hmWHVflit4tAukqaJ9tz
FHUoTAThAwnf1DxjkacVfddiX7Q42DUAsPruadc1xmdiux35foz9oGFLo1rVqLNZ
XFCvoMzkLK9IvXyf/RiE4vtfXBQSx+bgKLQlRa/TlkC5vqC0U8NMgiSqT41M6xd3
u5ar2O0S9VrEFLXzxPwIQEphn9x+ixu2gJAsu0c7EWshpY1M0a8acSSxk1AQqRJm
KmN+TIYMsOpnJShTmulB5EoHoszEzH1bfzFl5wcK15RFPEhsWf2Bps0q+V1E5mX3
RWIyT2Xctbj6ISMcpbd7sAh3eC9Sdf8pmDzhBd5qvwzMPip+tkIbQsH0BZYdfvCb
PaXj3LqeXIpQVMYDdjIR9M77AmREkw0JucZXBpeY4ncOYESu/JvgiOwJW1cmhgaq
DsSJFBDBsTB6yPpCfrOHaIB0hKZ81qBAAJihE15E3pBTI9FDExnOYMXCUHtjJIfH
qNLLmHcjAjceTcUSrwzdOoHfVO0mWRqd8tmuGaQNiK1o4AmThzXM5HuPoRZwZJqN
a63tvtaNl2DQGjBhk+26YhsrzzOLo4QZpDay6+3mUSvXEKcp2497Ng9lRztjsVh6
ZJbPGn8SKCTg166xrH2FQdfJ0Ay4BVDWZavPPxVIFA2HAiqf8WpieuaicuaRf5df
wERmz00efrw6ar4+9rMp
=Rmfy
-----END PGP SIGNATURE-----