[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] NIST approved crypto in Tor?
07.09.2013 19:02, Nick Mathewson:
Do not dare to reply again before your weekend is over. Probably don't
even read it.
> On Sat, Sep 7, 2013 at 5:25 AM, Sebastian G. <bastik.tor>
> <bastik.tor@xxxxxxxxxxxxxx> wrote:
>> 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.
That sounds good to me. (Knew that you use 25519, but not if NIST
>> Are other parts of Tor certified by NIST?
> NIST has certified tons of stuff
I thought so.
> including AES and SHA1 and SHA256
I knew that and did not worry back then.
> and SHA3.
I remembered that and wondered why the winner is the winner.
> If you're jumping ship from NIST, you need to jump ship
> from those as well.
That would be the case, then.
> 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)
> * http://cr.yp.to/antiforgery/cachetiming-20050414.pdf (on AES)
Thanks, I'll yet have to read them.
It has been said before that the implementation has to be done
correctly, which is obviously harder if there's more room for failures.
> 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
What seems to be quite difficult. I'm not a cryptographer so I can
> 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
Is that true for signatures of emails as well?
If so, is this weakness the reason that no-one involved in Tor* got a
DSA key for signing?
For example Erinn got an RSA for signing the bundles.
*those I checked.
(DSA = Deep[fried] Sh*t Algorithm)
> 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.)
No authority is to blame for a poor implementation, just the one(s)
implementing it. One can not proof (without leaked material) that a
certifying or consulting party or even an implementing party had an
> 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?
It would be hard to believe that they all collaborating with an
malicious intend. Soooo many people.
(Well I had not believed the scale and depth of the NSA spying, although
I assumed they would spy.)
> And it's not like NIST standards are the only ones that have problems.
I could have imagined that.
TLS 1.0 had (well it should still have it) problems.
I remembered BEAST and CRIME and just looked at it again to confirm my
believe that 1.1 (at least somewhat) and 1.2 resolved those problems,
which is not completely true.
Reading the security section of its Wikipedia entry does not give my
much confidence either.
> 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
I see RC4 for encryption on websites. (https hooray)
> 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.
If just everything had perfect forward secrecy (PFS) built-in, some
situations of the NSA spying would not be as bad as they are.
> Conspiracy, or saboteurs in the (international) TLS working group, or
> international bureaucratic intertia? Who can say?
Bureaucracy has to be spelled bureaucrazy as it is crazy at least at times.
At times you may ask what's the lowest possible common ground and it may
has to be the lowest of all you ask.
But who can say if that is actually always true?!
> 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
Where are the sun-rays that penetrate the cloud(s)?! (Everything looks
bad, there doesn't appear to be something to look forward to, or is
there something to look forward to?)
>> I understand that ECC used for Tor is different from what the essay is
>> 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 )
(I knew I included the question twice.)
I'll added 'everything' after 'nearly' (correct me if I'm wrong). Yes
they recommend a lot of things (to me it seems they would).
>> 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
(Everything is linked. I knew it. ;) )
They are all stupid, then. ;) Well not sure what they are. I see that
just replacing US standards (or whatever) with international standards
(or whatever) does not magically help.
> With any luck, smart cryptographers will start to push non-NIST curves
> and ciphers into prominence.
You use 25519, so I'm confident that others, when they trust you ("we
know where the money comes from"), use it, too.
> 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 targeted ECRYPT
> III some time.
So far I have nothing to make me hope for the EU about anything.
Commercial lobbying is something the EU is influenced by.
When it involves politics the department for fishing (yes, actual
fishes) might decide what cipher is used. (I'm over-saturating here, am I?)
For actual cryptographers I have no clue if your hopes are justified.
Well I hope they are.
> As I said on another mail, I've got a mind to move a lot of our crypto
> for other reasons, as well.
Could be good.
> The elephant in the room here is TLS itself. Frankly, I'm starting to
> think we should cut the Gordian Knot here and start a little
> independent protocol group of our own if the TLS working group can't
> get its act together and have one really good ciphersuite some time
Could be good, too. Well aren't more people better as more brains know
more things and more eyes see more things or "too many people making too
many problems? (and there's not much love to go around. Tell me why this
is a land of confusion")
>> The NSA likes playing around.  (found while searching)
>> Oh and I'm not trying fear-mongering here or try to conspire whenever or
>> not the NSA has subverted cryptographic functions (in one way or another).
> Yeah, I know how it is. I'm seeing conspiracies under every protocol
> and in every patch these days.
I'll write a proposal to improve Tor's random number generator. ;)
(consisting of three dice and Schrödinger's cat with a few mice)
> Gotta stay focused, write the best
> protocols and designs and software I can, and maintain.
I on the other hand have to stay focused, (Firefox: cared, but could not
do anything useful, hate the changes being made and the process, don't
care about it, still use and complain about it. The closer I get, beside
just using the stuff the worser it gets) don't get mad, pissed off or
There have been times where I thought to not care about Tor anymore to
not go insane about the issues you have to deal with. Well I'm still
reading most threads on the mailing-list (excluding those dealing with
ARM or exceeding my knowledge), following the timeline and file tickets,
read papers. I have not been on IRC for quite some time to maintain my
distance, though I have no idea if that's sane.
If I can do something to keep you focused (for example not writing too
long emails) let me know. Or the community in general.
> (And with that in mind I should really start on my weekend soon.)
Happy weekend to all and everyone (including NSA agents)
Same to you and anyone else,
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsusbscribe or change other settings go to