Ephemeral Diffie-Hellman?
After reading the Logjam paper from Daniel Bernstein et al. it seems likely to me that Ephemeral Diffie-Hellman is broken for Oakley Group 2 and several other well known primes. Your white paper mentions elliptic curves but it is unclear whether the product uses Ephemeral (broken) or ECDHE (not broken).
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:logjam
Comments
-
Hi @CloseAtHand,
Your question touches on a number of things, so I will try to touch upon them (though in no particular order).
You seem to be asking a number of different questions, though I'm not entirely sure
We mention elliptic curves as a possibility for the future, but we aren't actually using it for anything at this point.
The bulk of our public key encryption uses RSA, but we do use a Diffie-Hellman construction in our SRP authentication. We use the 4096 group from RFC 3526. Because we control development of both the client and the server, we don't have to support weak groups, so there is no scope for downgrade attacks, like Logjam.ope
I'm not entirely sure whether I have succeeded in answering your question; so please let me know if I can clarify anything.
0 -
@jpgoldberg Thanks. The basic question was "Are you using DHE with a 1024-bit key?" and the answer is "No". The reference to LOGJAM is not to the MITM attack that downgrades to Export Grade, but to the final section of that paper, which tells me 1024-bit should now be considered weak. 4096-bit is not weak :)
0 -
Excellent. I'm glad to hear jpgoldberg's answer was helpful. :)
Ben
0 -
Exactly @CloseAtHand!
What you describe played a big role in our choice of DH group.
1024 bit DH keys have been advised against for quite some time. And this advice took on extra urgency after Bruce Schneier's comments in September 2013 that we should consider the very plausible possibility that 1024 DH groups are in reach of the NSA
We’re already trying to phase out 1024-bit RSA keys in favor of 2048-bit keys. Perhaps we need to jump even further ahead and consider 3072-bit keys.
(I recall reading something else around from some cryptographer who looked at the Snowden releases and saying something to the effect of "it is past time to retire 1024 bit DH keys", but I can't find that at the moment.)
By the time we were settling on our parameters, the outlines of plausible attacks on common 1024 groups were already becoming clear. Because the attacks depend on a lot of pre-computation about the group, there were some questions about using a commonly used group or whether we should construct our own. We opted to go with a common group, but agreed that we would not go below 3072 bits. At the time, we didn't see a notable performance difference between 3072 and 4096 (we only perform these exponentiations during authentication) and so went with the rounder number. We might drop down to 3072 bits if we find we face a price with the overkill of 4096.
Our server and clients only accept the 4096 group, but that isn't all. We have actually removed any knowledge of any group under 2048 bits from the server itself. This would make it much harder for us to either accidentally (or through trickery) find ourselves using 1024 bit DH groups.
0
