-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Kyber-768: differing shared secrets after decapsulation between bc and liboqs #1578
Comments
@Chratho Bouncy Castle currently implements Kyber as specified in the NIST FIPS 203 draft, whereas OQS implements Kyber as specified in the earlier round three submission to NIST. NIST has made some changes to Kyber which has resulted in changing the output of the algorithm before standardizing it (perhaps it is now best called ML-KEM), though note that FIPS 203 is still in draft stage. Particularly: If you open the FIPS 203 draft and go to versus Note that NIST has removed the additional hash ("Do not send output of system RNG" -- doesn't impact output) and the additional KDF invocation (which does impact the output and ability to interoperate with older specs). BouncyCastle has updated to match NIST's changes as of c8eb894, but no similar commit has been made to OQS or their upstream reference implementation (in Presumably when the ink is dry on the final version of FIPS 203, we might be in sync again. :-) Ah, here we are: open-quantum-safe/liboqs#1521 -- looks like they're working on it! :-) HTH! |
Wow, thank you very much for this detailed explanation - I wasn't aware of these differences. Is there any known schedule of when FIPS 203 will become final? Or can you make an educated guess? Can I somehome force bc to use the round 3 submission version of Kyber? At least I think I won't be able to simply downgrade bc to some specific version, right? Because I think I've seen shared secrets of unexpected length in |
This recent blog article by Filippo might be insightful: https://words.filippo.io/dispatches/mlkem768/#bonus-track-using-a-ml-kem-implementation-as-kyber-v3 I haven't verified the result myself, but you might get away with what's noted there, namely: shared, ciphertext := ML-KEM-Encapsulate(...)
shared = SHAKE-256(shared || ciphertext)[:32] (or the same on the decapsulate side -- decapsulate OQS's value here in BC and then re-apply this transform). And maybe that will give you interop with OQS, without downgrading BC? |
Thanks for this hint. I was indeed able to reproduce the "original" hash by applying two additional hashes (one on the ciphertext alone, and the already mentioned SHAKE-256 hash). |
Hi,
I currently try to perform a KEM key derivation using Kyber-768. The client is written in C with liboqs [1] and the server uses Java/Kotlin with bc. However, the derived shared secrets between both applications do not match.
I have used the Kyber reference implementation [2] to generate a set of hex-dumps (notably the sk and ct as required for the last decapsulation round plus the resulting secret). Based on these dumps, I was able to derive the same secret using liboqs, but not with bc.
The following code should make the issue clear. Am I doing something wrong when performing the decapsulation using bc?
[1] https://github.com/open-quantum-safe/liboqs
[2] https://github.com/pq-crystals/kyber/
The text was updated successfully, but these errors were encountered: