4 ms·

I strongly believe in 'Audi alteram partem', and like to understand rather than believe. Hence my question. For all I know, a few extra bits parameter length c

by syzzer 11y ago

I strongly believe in 'Audi alteram partem', and like to understand rather than believe. Hence my question. For all I know, a few extra bits parameter length can make the NFS just as infeasible as generating own parameters. Edit: re-reading my earlier comment I understand your reply better. I've expanded my question to 'even with larger group sizes', as it indeed is clear that it is a problem with smaller groups.

acqq 11y ago
The newly disclosed research clearly demonstrates that the common parameters enable "precompute just once, attack fast everywhere" whereas when everybody simply generates their own values that approach becomes impossible. The difference is between the days of computation versus the seconds in their example. The difference is many orders of magnitude, it is if everybody everywhere can be attacked anytime or just somebody sometimes somewhere. Moreover, the main reason why it should be done is that the expected browser updates won't block the sites with 1024 bits. So all the sites which for whatever reason still use 1024 bits won't be so vulnerable if they had their own parameters. The practice of using the common parameters already now worsens the current state. The bad effects of the really bad move already exist. The common parameters are now provably bad and it won't change in the future. Just don't use the common parameters. Generate the new ones everywhere. And, of course, "minimum 2048 bits, please." Edit: audi alteram... means "listen to the other side." Which side is the other side here? The stale information is not "the other side" it's just stale.
- syzzer 11y ago
  Thanks for elaborating. The 'other side' are the people currently working on the negotiated-ffdhe draft (which I assume are bright people too). The draft was last updated a week ago (12 May 2015), so their considerations must be quite recent. I'm just trying to get a sense of pros and cons. Iirc, generating own groups has its problems too. For example, the Triple Handshake attack (https://www.secure-resumption.com/ https://www.secure-resumption.com/) could break TLS because implementations did not properly validate DH params. Allowing only some (set of) pre-defined (known good) params would have stopped that attack. To be clear, I'm certainly not arguing for or against using common groups. Just trying to get a complete picture. (And yes, based on current information I think too that using unique groups is the right approach.)
  - schoen 11y ago
    The folks working on that draft have definitely become aware of this research. Soon we'll see what they have to say about it.

by syzzer 11y ago

acqq 11y ago

The newly disclosed research clearly demonstrates that the common parameters enable "precompute just once, attack fast everywhere" whereas when everybody simply generates their own values that approach becomes impossible. The difference is between the days of computation versus the seconds in their example. The difference is many orders of magnitude, it is if everybody everywhere can be attacked anytime or just somebody sometimes somewhere. Moreover, the main reason why it should be done is that the expected browser updates won't block the sites with 1024 bits. So all the sites which for whatever reason still use 1024 bits won't be so vulnerable if they had their own parameters. The practice of using the common parameters already now worsens the current state. The bad effects of the really bad move already exist. The common parameters are now provably bad and it won't change in the future. Just don't use the common parameters. Generate the new ones everywhere. And, of course, "minimum 2048 bits, please." Edit: audi alteram... means "listen to the other side." Which side is the other side here? The stale information is not "the other side" it's just stale.

syzzer 11y ago
Thanks for elaborating. The 'other side' are the people currently working on the negotiated-ffdhe draft (which I assume are bright people too). The draft was last updated a week ago (12 May 2015), so their considerations must be quite recent. I'm just trying to get a sense of pros and cons. Iirc, generating own groups has its problems too. For example, the Triple Handshake attack (https://www.secure-resumption.com/ https://www.secure-resumption.com/) could break TLS because implementations did not properly validate DH params. Allowing only some (set of) pre-defined (known good) params would have stopped that attack. To be clear, I'm certainly not arguing for or against using common groups. Just trying to get a complete picture. (And yes, based on current information I think too that using unique groups is the right approach.)
- schoen 11y ago
  The folks working on that draft have definitely become aware of this research. Soon we'll see what they have to say about it.