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

From: Fedor Brunner <[email-masked]>
Date: Tue, 01 Jul 2014 10:36:37 +0200

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 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 1 Jul 2014 14:36:07 +0000

Fedor Brunner <[email-masked]> writes:

>Also Adam Langley thinks that NIST continually pick algorithms that aren't
>suited to software implementations.

Another problem with the NIST standards is that, once you go beyond basics
like AES, SHA-2, and so on, you have a neverending stream of oddball modes and
mechanisms that no standard protocol ever uses, or arguably needs.  However
since it's specified by NIST, standards groups, who are often heavily stacked
with US contributors, feel the need to force them into all manner of standards
because they feel they need USG approval for them.  

This applies particularly to things like TLS, less so for protocols like SSH
(if I had a penny for every time I've heard "we can't do <straightforward
common-sense approach> because there's no NIST-approved way to do it" or "we
need to do <some boneheaded silly-walk> because that's what the NIST standard
says"...).  In other words while the SSH effort is driven by purely technical
considerations, things like TLS are driven by a combination of technical
considerations and "what NIST has standardised so we can get it FIPS certified
for our USG customers".

This dual technical+political approach is not a good way to design a standard.

Peter.