Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Logjam TLS attack

weakdh.org

Post reply on HN
Print view View original

71–80 of 103 posts

Re: Logjam TLS attack

#71

Post by agwa »

AlyssaRowan wrote: post #31
pbsd wrote: post #5

This is not at all surprising; even I had pointed out the looming DH problem in an earlier thread: https://news.ycombinator.com/item?id=8810316 One small nit with the paper: it is claimed that there had been technical difficulties with the individual logarithm step of the NFS applied to discrete logarithms, making individual logs asymptotically as expensive as the precomputation. Commeine and Semaev [1] deserve the c…

It's not particularly surprising to the IETF TLS Working Group either, which is at least partially why https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe... exists. Minimum 2048 bits, please note. 1024 is not safe - and has not been for quite some time. GCHQ and NSA can definitely eat 1024-bit RSA/DH for breakfast at this point (although it does still take them until lunch). (Those of you still using DSA-10…

What do you (and pbsd) think of the site's recommendation to use custom 2048-bit parameters as opposed to a well-known 2048-bit group such as group 14 from RFC3526? Is it really that likely a nation-level adversary could break 2048-bit FFDHE the same way they've probably broken the 1024-bit group 2? How does that weigh against the risk of implementation errors generating your own parameters, or the risk of choosing a group with a currently-unknown weakness?

Re: Logjam TLS attack

#72

Post by ceequof »

ericcholis wrote: post #56

Seen many nginx tutorials omit a pretty critical (IMO) command before applying/reloading config changes: nginx -t. nginx -t will quickly tell you if you've screwed something up before actually trying to apply changes.

`service nginx configtest` does the same thing.

Re: Logjam TLS attack

#73

Post by kerio »

wtracz wrote: post #46
yuhong wrote: post #22

Earlier quoted context omitted.

I suggest a 768 bit minimum for now, because of Java. As a side note, the latest IcedTea 6/7 release allow 1024-bit DHE but it is not enabled by default.

This was fun to find at the end of two days last week when a third-party system was trying to connect via SSL. Java 8 is the first to allow above 1024-bit Diffie-Hellman parameter values.

And it still doesn't allow >2048-bit parameters

Re: Logjam TLS attack

#74

Post by garethsaxby »

ceequof wrote: post #72
ericcholis wrote: post #56

Seen many nginx tutorials omit a pretty critical (IMO) command before applying/reloading config changes: nginx -t. nginx -t will quickly tell you if you've screwed something up before actually trying to apply changes.

`service nginx configtest` does the same thing.

That's good to know too, yes, but using the nginx binary itself to test is always available, whilst a service command normally involves an init script, systemd config file or similar to be available, and they can vary between packages and distributions.

Re: Logjam TLS attack

#75

Post by tedunangst »

sarciszewski wrote: post #68
mc_hammer wrote: post #67

Earlier quoted context omitted.

TLS implementation has already had 2 serious show-stopping bugs if i remember. and heartbleed on top of that. they were beginner crypto mistakes like reusing nonce/null nonce... and the new logjam bug keep downvoting guys the government needs you!

I suspect you're being downvoted for linking to 8chan.

And/or people aren't much interested in reading about variable names.

Re: Logjam TLS attack

#76

Post by pbsd »

agwa wrote: post #71
AlyssaRowan wrote: post #31

Earlier quoted context omitted.

It's not particularly surprising to the IETF TLS Working Group either, which is at least partially why https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe... exists. Minimum 2048 bits, please note. 1024 is not safe - and has not been for quite some time. GCHQ and NSA can definitely eat 1024-bit RSA/DH for breakfast at this point (although it does still take them until lunch). (Those of you still using DSA-10…

What do you (and pbsd) think of the site's recommendation to use custom 2048-bit parameters as opposed to a well-known 2048-bit group such as group 14 from RFC3526? Is it really that likely a nation-level adversary could break 2048-bit FFDHE the same way they've probably broken the 1024-bit group 2? How does that weigh against the risk of implementation errors generating your own parameters, or the risk of choosing a…

Group 14 is fine. You might as well also tell people to use custom block ciphers, since a precomputation of roughly the same magnitude---compute a common plaintext under many possible keys---would break AES-128 pretty quickly as well.

I would say use a custom group if you must stick with 1024-bit groups for some reason. Otherwise, use a vetted 2048+-bit group. If---or when---2048-bit discrete logs over a prime field are broken (and by broken I mean once, regardless of precomputation), it will likely be due to some algorithmic advance, in which case DHE is essentially done for. If nation states have been able to pull that off already, then it's pointless to even recommend anything related to DHE in the first place.

Re: Logjam TLS attack

#77

Post by r1ch »

mdewinter wrote: post #29

My side project tries to give secure default settings for all major webservers and other software (like haproxy, mysql, mailservers etc): https://cipherli.st/ From the start it has listed the suggestion to set up >2048 DH keys. If you want to test your site for export ciphers, you can try my other side project: https://tls.so/ - you can also use the SSL labs test but mine is faster for just testing ciphersuite. (And…

Any chance of adding STARTTLS support to tls.so? I've found a lack of decent tools to scan FTP servers, SMTP servers, etc.

Re: Logjam TLS attack

#79

Post by tptacek »

sarciszewski wrote: post #65
tptacek wrote: post #59

Earlier quoted context omitted.

Depends on what we mean by "at scale", right? That's why the shared parameter aspect of this attack is so meaningful: they probably can't solve 1024 bit DH problems "on demand".

If they can solve the 1024-bit DH problem "on demand" we should probably be eying 2048-bit DH with some suspicion. (I'm agreeing with your point.)

Attacks don't really scale like that. If 2048 bit prime field discrete logs fail, all of prime field discrete logs (and with it probably RSA) will probably be done for.

There is, as I understand it, a huge performance penalty for using keys larger than 2048 bits. People should just use 2048 bit keys, or stop using conventional prime field public key algorithms altogether, is what I think.

Post reply on HN