search

open-quantum-safe / openssl

UNSUPPORTED Fork of OpenSSL 1.1.1 that includes prototype quantum-resistant algorithms and ciphersuites based on liboqs PLEASE SWITCH TO OQS-Provider for OpenSSL 3
https://openquantumsafe.org/
Other
289 stars 125 forks source link

Collect input to discuss/ease upstream uptake #233

Closed baentsch closed 3 years ago

baentsch commented 4 years ago

The goal of this fork is to eventually enable/ease QSC uptake into OpenSSL. This issue should serve as a focus/collection point for "challenge areas" we see in the design/APIs/data structures, e.g., along the lines of issues #59 or #214 that we may want to bring up with upstream maintainers.

romen commented 3 years ago

I think this issue might also benefit from including the same update I posted on #59 :

https://github.com/openssl/openssl/pull/13018 is extending the work done in changes recently merged for OpenSSL 3.0:

https://github.com/openssl/openssl/pull/13018 would extend https://github.com/openssl/openssl/pull/11914 to:

  • add an extra capability to allow providers to optionally signal that a "plugged-in" group behaves as a KEM (key encapsulation method),
  • include minimal changes in libssl to act on this optional capability:
    • handling of the Key Share extension on the client and the server checks the new capability so that, if set to true, the API introduced in https://github.com/openssl/openssl/pull/12750 is called, as an alternative to the traditional "DH-like scheme", that remains unchanged.

The combination of these 2 items would allow OpenSSL Providers to model the "plugged-in" groups either under the key exchange scheme (both sides do a Diffie-Hellman-like exchange) or the key encapsulation method scheme (client sends KEM pubkey in Key Share, server encapsulates under given pubkey and send back the ciphertext as its Key Share, client decapsulates the received ciphertext using the paired privkey). Given that a key exchange scheme can trivially be described as a KEM scheme, this also allows the authors of OpenSSL Providers to optionally describe DH-like primitives in terms of KEM, which also simplifies the design and deployment of hybrid schemes composing traditional-computing-resistant and quantum-computing-resistant primitives.

https://github.com/openssl/openssl/pull/13018 is currently held back, because it is coming quite late in the development cycle of the OpenSSL 3.0 release and because we all want to avoid "feature creep".

I presented my argument for inclusion nonetheless and I am looking for endorsement by members of the community to build support for it: please consider participating in the https://github.com/openssl/openssl/pull/13018 discussion if you want to show your support on the matter, caution against inclusion, or share any relevant feedback.

baentsch commented 3 years ago

@romen Thanks very much for your work, the PR and involving all of us: If I see it right acceptance of PR#13018 would go a very long way of resolving our issue here -- certainly when OpenSSL 3.x fully replaces OpenSSL 1.1.1. Thus, fully supporting the positive voices from @dstebila and @christianpaquin already voiced in the OpenSSL discussion or the PR, I can only add the suggestion to do interop testing between your functionality (using suitable Providers) and the test server we set up for this purpose at https://test.openquantumsafe.org. Time permitting I may give this a go -- it looks like the time has come for me to look more deeply into OpenSSL 3.x (build & integration) concepts...

dstebila commented 3 years ago

Closing this issue and cross referencing in a new task to follow OpenSSL 3.0 development