- Forwarded message from Nick Mathewson ni...@alum.mit.edu -
Date: Sat, 7 Sep 2013 13:02:04 -0400
From: Nick Mathewson ni...@alum.mit.edu
To: tor-t...@lists.torproject.org tor-t...@lists.torproject.org
Subject: Re: [tor-talk] NIST approved crypto in Tor?
Reply-To: tor-t...@lists.torproject.org
On Sat, Sep 7, 2013 at 5:25 AM, Sebastian G. bastik.tor
bastik@googlemail.com wrote:
Hi,
Tor switches over to ECC what's a reasonable step.
I'm unable to find the blog post (or maybe it was an official comment on
the blog) [With DDG and StartPage] where someone said that if the NIST
(I guess) is not lying ECC is safe.
Is the ECC used by Tor in some way certified by NIST?
The TLS ECDH groups P-256 and P-224 are NIST-certified. For circuit
extension, we use Dan Bernstein's non-NIST-certified curve25519 group.
Are other parts of Tor certified by NIST?
NIST has certified tons of stuff, including AES and SHA1 and SHA256
and SHA3. If you're jumping ship from NIST, you need to jump ship
from those as well.
Of all the NIST stuff above, my suspicion is not that they are
cryptographically broken, but that they are deliberately hard to
implement correctly: see
* http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf
(on the P groups)
and
* http://cr.yp.to/antiforgery/cachetiming-20050414.pdf (on AES)
Also, we're not using DSA, but DSA (as recommended by NIST) fits into
this pattern: DSA (as recommended by NIST) requires a strong random
number generator to be used when signing, and fails terribly in a way
that exposes the private key if the random number generator is the
least bit week or predictable. (see
https://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Sensitivity)
To me, this suggests a trend of certifying strong cryptographic
algorithms while at the same time ensuring that most implementations
will be of poor quality. That's just speculation, though.
(And I'm probably falling to the fallacy where you assume that
whatever results somebody gets are the ones they wanted.)
Of course, the deliberately in deliberately hard to implement
correctly is almost impossible to prove. Is it nearly impossible to
write a fast side-channel-free AES implemenation in C because because
of a nefarious conspiracy, or simply because cryptographers in 2000
didn't appreciate how multiplication in GF(2^8) wasn't as
software-friendly a primitive? (Looking at the other AES finalists, I
see a bunch of other hard-to-do-right-in-fast-software stuff like
GF(2^8) multiplication and table-based s-boxes.) Are the ECC P
groups shaped that way for nefarious reasons, or simply because the
standards committee didn't have an adequate appreciation of the
software issues?
And it's not like NIST standards are the only ones that have problems.
TLS is an IETF standard, but TLS implementations today have three
basic kinds of ciphersuirte: a fraught-with-peril CBC-based
pad-MAC-then-encrypt kind where somebody finds a new active attack
every year or so; a stream-cipher-based kind where the only supported
stream cipher is the ridiculously bad RC4, and an authenticated
encryption kind where the the AEAD mode uses GCM, which is also hard
to do in a side-channel-free way in software.
Conspiracy, or saboteurs in the (international) TLS working group, or
international bureaucratic intertia? Who can say?
And let's not mention X.509. Let's just not, okay? X.509 is
byzantine in a way that would make any reasonable implementor's head
spin, *and* the X.509 CA infrastructure is without a doubt one of the
very worst things in web security today. And it's an international
standard.
[...]
I understand that ECC used for Tor is different from what the essay is
about.
However the NSA may found something it can exploit in ECC and made NIST
(maybe unknowingly) standardize the curve (or whatever) that is most
vulnerable or recommends for a weak one, or for too short keys.
Does Tor use stuff certified or recommended by NIST?
Yes; see above. Also, there were once NIST recommendations for using
TLS; I have no idea whether we're following them or not. (There are
NIST recommendations for nearly )
If so would it be reasonable to move to international standards
(whatsoever) without the involvement of NIST and NSA 'consultation'?
(Completely unrelated to what might be going on, just as defense-in-depth.)
I'm not sure that there *are* international-standards recommendations
for ECC groups or for ciphers that diverge from NIST's. The IETF is
an international body, after all, and TLS standards have been happily
recommending SHA1, SHA256, AES, DSA, and the P groups for ages. (See
also notes above about the not-much-betterness of international
stuff.)
With any luck, smart cryptographers will start to push non-NIST curves
and ciphers into prominence. I've got some hopes for the EU here;
ECRYPT and ECRYPT II produced some exceptionally worthwhile results; I
hope that whoever makes funding decisions funds a nice
