cloudflare-specific hybrid kyber768 support

[baentsch]

As per discussion in open-quantum-safe/openssl#388 this is to create "minimally invasive" support for cloudflare's hybrid choice of x25519_kyber768.

To activate, set #define CLOUDFLARE in oqs_prov.h.

Tested to run successfully against cloudflare infrastructure & code point:

OQS_CODEPOINT_X448_KYBER768=65073  ./openssl/apps/openssl s_client -groups x25519_kyber768 -connect cloudflare.com:443 -provider-path _build/oqsprov -provider oqsprovider -provider default
[...]
read R BLOCK
HTTP/1.1 200 OK
Date: Wed, 19 Oct 2022 09:19:03 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive
Access-Control-Allow-Origin: *
Server: cloudflare
CF-RAY: 75c86e05a8c1cc62-ZRH
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Cache-Control: no-cache

e5
fl=64f31
h=cloudflare.com
ip=2a01:2ac:51dd:d483:3c5f:d979:73f5:bdfa
ts=1666171143.48
visit_scheme=https
uag=
colo=ZRH
sliver=010-tier1
http=http/1.1
loc=CH
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
kex=X25519Kyber768Draft00

[songlingatpan]

@baentsch
Two questions:

1. OQS_CODEPOINT_X448_KYBER768=65073
   Is it on purpose to use OQS_CODEPOINT_X448_KYBER768 for x25519_kyber768?

In RFC draft, https://www.rfc-editor.org/rfc/rfc8446, it mentioned 4 hybrid examples
/* Hybrid Key Exchange Methods */
x25519_kyber768(TBD), secp384r1_kyber768(TBD),
x25519_kyber512(TBD), secp256r1_kyber512(TBD), ...,
Can we add secp384r1_kyber768 and secp256r1_kyber512 as well?

Thanks

[baentsch]

@baentsch Two questions:

1. OQS_CODEPOINT_X448_KYBER768=65073
   Is it on purpose to use OQS_CODEPOINT_X448_KYBER768 for x25519_kyber768?

Yes, absolutely: Check the code changes for the "CLOUDFLARE" define: As Cloudflare chose to mix the (cryptographically too weak) X25519 with Kyber768, the PR just changes the assignment --for this particularly weird/unlogical choice-- of X25519 to/with Kyber768. OQS in contrast recommends the use of combining classic and PQ algorithms of the same cryptographic strength. So, for a Kyber768 hybrid that is X448, hence the use of that define to change the codepoint of the Kyber768 hybrid. It may be confusing, but I wanted to add as little code as possible to support an unlogical and proprietary hybrid algorithm choice.

In RFC draft, https://www.rfc-editor.org/rfc/rfc8446, it mentioned 4 hybrid examples /* Hybrid Key Exchange Methods */ x25519_kyber768(TBD), secp384r1_kyber768(TBD), x25519_kyber512(TBD), secp256r1_kyber512(TBD), ..., Can we add secp384r1_kyber768 and secp256r1_kyber512 as well?

Thanks
I'm confused: The referenced RFC draft does not mention any of these algorithms. Besides, why should "secp384r1_kyber768 and secp256r1_kyber512" be added as they are already on the list you mention before?

[songlingatpan]

Thanks for your quick answers. p256_kyber512 and p384_kyber768 works well.

[bwesterb]

for this particularly weird/unlogical choice-- of X25519 to/with Kyber768

We aim for "128 bit" security. The current consensus is that Kyber512 reaches that, but there is not a lot of margin. The designers of Kyber recommend Kyber768, even for "128 bit" applications, to hedge against big, but not catastrophic, advances in cryptanalysis. Hence our choice to mix X25519 with Kyber768.

[baentsch]

for this particularly weird/unlogical choice-- of X25519 to/with Kyber768

We aim for "128 bit" security. The current consensus is that Kyber512 reaches that, but there is not a lot of margin. The designers of Kyber recommend Kyber768, even for "128 bit" applications, to hedge against big, but not catastrophic, advances in cryptanalysis. Hence our choice to mix X25519 with Kyber768.

Thanks for the background. After the above we added support to OQSprovider to enable all kinds of combinations beyond purely "bit-security-compatible" ones we supported in the old openssl111 code base. So feel free to suggest any further alternatives :)