search

Argyle-Software / kyber

A rust implementation of the Kyber post-quantum KEM
https://docs.rs/pqc_kyber/
Apache License 2.0
167 stars 37 forks source link

Add a Misuse Resistant Hybrid API #12

Closed mberry closed 1 year ago

mberry commented 2 years ago

Kyber should not be used by itself currently[1][2] in most cases. There's notes in the readme about this but always a chance of misuse with shiny new thing. We should have an easy to use/ hard to fuckup hybrid[3] mechanism.

The IETF TLS 1.3 draft proposal uses a simple concatenation[4]. OpenSSH currently uses concatenation then hashing for its sntrup761x25519 kem[5]. The other alternative here is xor'ing the shared secrets assuming they are the same size (a fair assumption).

I'd suggest Kyber768x25519 as an opinionated default, though it should be pluggable with other kem's as curve25519 isn't accepted by some companies/clouds/governments/standards bodies today and probably never will be.

[1] https://www.ietf.org/archive/id/draft-campagna-tls-bike-sike-hybrid-07.html

BIKE, Kyber and SIKE are post-quantum candidates which were submitted to the NIST Call for Proposals for Post-Quantum Cryptographic Schemes. While these schemes are still being analyzed as part of that process, there is already a need to protect the confidentiality of today's TLS connections against a future adversary with a quantum computer. Hybrid key exchanges are designed to provide two parallel key exchanges: one which is classical (e.g., ECDHE) and the other which is quantum-safe (e.g., SIKE). The hybrid schemes we propose are at least as secure as ECDH against a classical adversary, and at least as secure as the PQ KEM against a quantum adversary. This strategy is emerging as a method to speculatively provide additional security to existing protocols.

[2] https://eprint.iacr.org/2022/975.pdf

Our Magma implementation breaks the instantiation SIKEp434, which aims at security level 1 of the Post-Quantum Cryptography standardization process currently ran by NIST, in about one hour on a single core.

[3] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-04.html#section-1.2

"Hybrid" key exchange, in this context, means the use of two (or more) key exchange algorithms based on different cryptographic assumptions, e.g., one traditional algorithm and one next-gen algorithm, with the purpose of the final session key being secure as long as at least one of the component key exchange algorithms remains unbroken.

[4] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-04.html#section-3

[5] https://github.com/openssh/openssh-portable/blob/master/kexsntrup761x25519.c#L103

mberry commented 1 year ago

This functionality deserves to be separated out into another crate so I am going to close the issue.

Ideally, we will have some opinionated plug and play hybrid options such as kyber764x25519 and kyber1024x448, though personally I'm coming around to the idea that a post-quantum threat model would benefit more from inverting those two ie. kyber764x448 and kyber1024x25519. That's an interesting discussion for another day though.