Add Post Quantum key agreement #2002
Conversation
|
I think this would be better if added as a configurable option, just like the cipher list, instead of overwriting the default. |
|
I can understand why a configurable option might be wanted, but I still think overriding the default is the correct way to go. Here is the default list of groups: As you can see, the list of groups that I have set has many groups in common with the default group list. The groups that are shared are X25519, P-521, and P-256. These seem to be the most common common groups. The groups that are not shared are the post quantum groups, x448, secp384r1 (P-384), and all the ffdhe groups. The openssl blog says this about ffdhe groups:
Following this advice, I disabled the ffdhe groups completely, because I thought there was no need (Most other groups are shared anyway), but ffdhe2048 and ffdhe3072 can be added back if necessary of course. Given that the current default is vulnerable to the attack described, I think it's worth managing which groups are set even if the post quantum groups aren't available. |
|
I might have misinterpreted your comment. I thought you were suggesting a toggle between post quantum groups and the default. If you were suggesting a way for users to select a group for themselves, I would say that the user shouldn't have to configure something like that because the groups are negotiated between client and server, and there isn't simply one group that is used. This means that the list of groups should be as long as possible while keeping in mind security and performance. |
|
as far as I understand, showing curves in SSL Server HELO message does not obey to anything, |
|
@siddharth-narayan , your change failed on FreeBSD please note that OpenSSL may be built without "provider" support |
|
Sorry, that line was left in from testing I was doing before. Yes, you are right. Setting post quantum curves in the ClientHello does not necessarily mean that the key exchange will be post quantum safe. However, if both the client and server support post quantum curves, (with high enough priority), then they will connect on the highest priority shared curve, which will be post quantum. For someone who wants to enable this functionality, they will not only have to build with OpenSSL 3.0 or greater, but they will also have to have oqsprovider installed for their OpenSSL. If this is done for both the client and server, only then will the connection have a post quantum key exchange. Otherwise, everything will work exactly as it did before. |
|
can you please update a branch ? particularly this commit ebe52af |
|
can you please guard all variables with |
|
Done. This does leave open the denial of service attack described here, because the TLS groups aren't managed for OpenSSL versions less than 3.0. For instance, the Firefox TLS groups look like this: |
|
let's keep that in separate issue. |
|
yes, if you have enough details, please open an issue |
|
thank you for contribution! |
Post Quantum key agreement for TLS 1.3
Adds the ability to load the oqsprovider OpenSSL Provider if present.
Adds a call to SSL_set1_groups_list to set the correct groups in StartSSLEx3. If this fails, the default groups will be used. The extra groups are provided by oqsprovider, if installed.
Will only work for OpenSSL 3.0 or greater, where oqsprovider is installed and on TLS1.3
In order of highest priority, here is the list of groups:
I created this order following the guidance from the openssl blog. It is in order of most secure but also most resource heavy, which I'm not sure is ideal. However, because this is just a key exchange, it only happens once, at the beginning of communication.