New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dhparam generates insecure groups (non-quadratic generators) #4737

Open
Florianjw opened this Issue Nov 14, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@Florianjw
Copy link

Florianjw commented Nov 14, 2017

The last time I wanted to post this, it didn't work for some reason, but whatever caused the issue seems to have been dealt with. Since nothing really has changed since then, I'll just copy the report that I sent to the libressl-team back then.

It has recently come to my attention that the dhparam-command of both openssl and libressl generates insecure groups: When I request a generator (2 or 5), the library will search for a safe-prime (good) for which this generator is not a square (terrible). Yes, the squares represent a subgroup and therefore reduce the group-size, but it has precisely halve the size and unlike the entire group prime-order. The result of this is that DDH becomes easy to solve, meaning that you cannot use those parameters for things like ElGamal-encryption without enabling distinction-attacks.

This was noticed (apparently without understanding the implications) 15 years ago but the person who did decided to just add the following comment instead of fixing it:

/* Actually there is no reason to insist that 'generator' be a generator.
* It's just as OK (and in some sense better) to use a generator of the
* order-q subgroup.
*/

This is a serious security-issue and I know of at least one serious protocol intended for real-world-usage (with security-proof!) that get's completely broken by this.

@mattcaswell

This comment has been minimized.

Copy link
Member

mattcaswell commented Nov 14, 2017

dhparam is designed for generating parameters for Diffie Hellman. It is not designed for ElGamal! Perhaps a note on the man page to this effect might be worthwhile.

@Florianjw

This comment has been minimized.

Copy link
Author

Florianjw commented Nov 14, 2017

But why shouldn't it be suitable for ElGamal? There are precisely no downsides to doing it right (including performance-wise), and doing so would remove a pointless foot-gun for people who assume that the API is also suitable for general-purpose-use outside of just TLS as it stands.

And if you don't care about the security-aspects of it: Just removing the check entirely would speed up group-generation by a factor of two, since you wouldn't have to throw away halve the safe-primes. So even DH-KX is affected though with regards to performance instead of security.

@mattcaswell

This comment has been minimized.

Copy link
Member

mattcaswell commented Nov 14, 2017

But why shouldn't it be suitable for ElGamal?

Well, that is a different issue - and makes this more of a feature request. My response was more of a comment on whether this is a security issue or not (my opinion: no - because dhparam is not designed to do this). I have no "in principle" objection to a pull request that makes this change (although we should be careful about updating the documentation appropriately to make it clear which. versions are suitable for ElGamal and which not). Of course OpenSSL doesn't actually support ElGamal so the usefulness of this feature is somewhat restricted.

@mattcaswell mattcaswell added the feature label Jan 23, 2018

@mattcaswell mattcaswell added this to the Post 1.1.1 milestone Jan 23, 2018

@richsalz richsalz added after 1.1.1 and removed after 1.1.1 labels May 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment