usnistgov
ACVP Testing of approved X25519MLKEM768
Now that X25519MLKEM768 is approved by SP 800-227 it would be useful to add X25519MLKEM768 ACVP testing.
Will X25519MLKEM768 be added to ACVP?
Possibly related to https://github.com/usnistgov/ACVP/issues/1486 by @jvdsn
This is more pressing as all FIPS implementations released in all languages/ecosystems enable X25519MLKEM768 by default in FIPS mode (golang, java 25, openssl 3.5, boringcrypto, aws-lc, apple crypto and more).
I agree. It's on our agenda. I appreciate you pointing out the immediate need. I can move it up on our to-do list.
For all new submissions, it will likely be the default in practice KEM, thus yes, it is quite critical to support ACVP testing of this. If funding is required, please let me know and I can start fundraiser for this and any other things that are needed to get there.
One clarification. X25519MLKEM768 is not directly approved by SP 800-227. As a technique, the combination is allowed, but the specific protocol uses a non-approved key combiner via SHAKE rather than a KDF in SP 800-108 or SP 800-56C. I believe the cryptographic authors have stated their intention to update one of those documents to enable X25519MLKEM768 to be FIPS-approved, and that is in progress, but not immediately available.
One non-clarification but is helpful to point out... There is a distinction between ACVTS offering testing for an algorithm and CAVP offering testing for validations for an algorithm. We may add tests for an algorithm we think is interesting or useful for the community. If the algorithm is not (at that moment) FIPS-approved, we may not offer the testing for validation certificates on CSRC and keep the algorithm on our Demo server for the community.
We have it on our near-term agenda to add tests for X25519MLKEM768 to the Demo server. Beyond that, we don't know yet.
One clarification. X25519MLKEM768 is not directly approved by SP 800-227. As a technique, the combination is allowed, but the specific protocol uses a non-approved key combiner via SHAKE rather than a KDF in SP 800-108 or SP 800-56C. I believe the cryptographic authors have stated their intention to update one of those documents to enable X25519MLKEM768 to be FIPS-approved, and that is in progress, but not immediately available.
One non-clarification but is helpful to point out... There is a distinction between ACVTS offering testing for an algorithm and CAVP offering testing for validations for an algorithm. We may add tests for an algorithm we think is interesting or useful for the community. If the algorithm is not (at that moment) FIPS-approved, we may not offer the testing for validation certificates on CSRC and keep the algorithm on our Demo server for the community.
We have it on our near-term agenda to add tests for X25519MLKEM768 to the Demo server. Beyond that, we don't know yet.
The D.S. IG (?) update approves X25519MLKEM768 as an approved service with MLKEM768 security claim.
It is useful to have ACVP for approved services. And CAVP.
Hi @xnox, can you link the draft D.S IG you're referring to? The draft @celic and I consulted states that an approved key combiner is required per SP 800-227. Our understanding is that X25519MLKEM768 does not use an approved key combiner.
Best,
Ben
Draft IG D.S - Key Encapsulation Mechanisms[Oct 14 25].pdf
Was posted on CMUF forum for comments.
Maybe there is conflicting interpretation, or further caveats needed.
The industry is deploying TLS Hybrid KEM, and that's the only context here. The preferred hybrid is based on X25519MLKEM768. The MLKEM secret is first. Majority of FIPS vendors keep TLS outside of the module boundary, but portions of TLS cryptography inside the module boundary. It is widely believed that SP 800-227 approves it given that it mentions and uses X25519 as an example multiple times, and uses and references well designed protocols that use concatenation. Many cryptographic modules have implemented TLS specific X25519MLKEM768 service and are in the queue. I do not know for sure, but it seems they all claim it as allowed service with MLKEM security claim. It is used as part of TLS only, and thus it is used as interim value, which later is fed into TLS KDF - the values are passed to/from the boundary multiple times. Similar to TLS KDF testing available in ACVP it would be very useful to test this portion of hybrid TLS as well. Please see AWS-LC, BoringCrypto, and OpenSSL modules in the queue, where ACVP certs have ML-KEM, there are at least 6 modules in the queue now that do this. Furthermore, some vendors claim that in progress full submissions with new algorithms are "update stream" in FedRAMP cryptographic modules selection terms. I cannot be sure, but it seems quiche envoy cilium may already use X25519MLKEM768 as approved service for TLS with deployments in production protecting data in transit.
Given our discussion here, I guess I should submit comment to the proposed IG update. It seems the language used in the SP and IG are overly convoluted. Which is leading to divergent interpretation. I did submit memes as comments to proposed updates. Because there is urgent need to simply the guidance. Documents published by IETF and OWASP are much easier to read, understand.
It would be very helpful to have explicit statement about higher level protocols such as "draft TLS Hybrid X25519MLKEM768 is disallowed" or "draft TLS Hybrid x25519mlkem is approved". The language has to be simple enough for LLMs to give correct answers.
Also, why is X25519 and concatenation used extensively as an example throughout IG. D.S. and SP 800-227 - if such combination is not approved?!
Note the CMVP/CAVP have not been able to talk to the cryptographic authors for the past month. SP 800-227 was published 13 days before the shutdown. The authors are not working during the shutdown.
The goal the authors have stated is to enable X25519MLKEM768. One more Special Publication update is needed for that to happen. My understanding of the issue here is the key combiner using SHA-3 is not yet approved. The expectation from SP 800-227 is that an approved KDF from SP 800-56C would be used (SP 800-227 Section 4.6.2). It's an unfortunate gap in the standards, impacted by the delay in the author's ability to close it.
Concatenation is an allowed key combiner if all elements of the hybrid scheme are approved. This would not apply to X25519.
I have asked the CMVP to update the draft IG D.S with a more direct statement of the status.
We're still going to work on the testing for ACVTS.
Concatenation is an allowed key combiner if all elements of the hybrid scheme are approved. This would not apply to X25519.
Many people are trying to ship hybrid schemes for TLS where one half comes from an existing validated module, and the other one doesn't or comes from in process one. Specifically SecP256r1MLKEM768 - if both implementations have to come from validated implementations, it will set back FIPS PQC transition back by multiple years.
@celic , I wanted to chime in since this is relevant to us as well and I've been trying to collect related guidance.
My understanding is that TLS 1.3 can be used for a SP 800-227-conformant ML-KEM/X25519 hybrid with the rationale that the TLS 1.3 KDF uses HKDF, which falls under SP 800-56C (and is CAVP testable under SP 800-56C). I know SP 800-227 still needs to be included in SP 800-140D, and the updated IG D.S still needs to be published, but I believe these are the only blockers for this hybrid implementation.
Related comments from NIST CT:
- One of my team passed on a secondhand response to this question from Andrew Regenscheid during the PQC standardization conference in September: 'TLS 1.3 KDF is HKDF which is already allowed by both 800-227 and SP 800-56C. If we use SHAKE there may be some more to specify, but do expect it to be allowed as well.'
- We also noted a conference in September where Lily Chen affirmed that TLS 1.3 can be used for a ML-KEM and X25519 hybrid in FIPS. The related question is at 7:30: https://events.zoom.us/ejl/Agj8sq0s31QOVcJTanbI6lRNj-tlSN5z2fvt_sGTYpn-RSIBqVJ5~Axgxca42DkWG402n-EuoqtZUnLnd-oc78-7hCVjqhv3uQDtiRX-SZ2DST7gnGIISiXh-ApQsjHXqRPddLeEb-a_IDph51yzzNSgQ5-bFmtWnC8uXz-Gp64-IirxpErk0nG-W2wJ-ZnYYcuhmcz8/aoEoEfIkRdiOoD0eXsVs6w/video/74D_V8-aSYyohC86z4iKbQ
The timing of the discussion is unfortunate when the CT group is not working. The CAVP/CMVP does not set policy here, we rely on the standards authors.
I reviewed the RFC draft 09 (https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/) with Andy Regenscheid. The key combiner looks like it meets the requirements in SP 800-227... using an approved hash as a one-step KDF from SP 800-56C.
The seed expansion using SHAKE to generate the key pairs is not currently in SP 800-133. That document is actively (to the extent possible...) being revised. I would expect this to be in there when a draft of that revision is published.
I'm working with the author of IG D.S to stay in sync as well. When Andy spoke at the PQC conference in September, it seems the topic of the key combiner and the seed expansion got mixed up.
To clarify, I'm not looking for a final answer here - I just want to add the context we've picked to the CAVP/CMVP discussions around hybrid guidance. I plan to include a comment on the draft IGs as well. And strongly agreed that it's unfortunate the CT group isn't available currently. I really hope they'll be back to clarify by the time the CMVP is reviewing the IG D.S comments.
Also agreed on X-wing. My understanding from recent NIST workshops is that X-wing cannot be used in FIPS until SP 800-133 is updated to allow seed generation with this method. And per section 5.7 of that RFC, I see that it's possible to use X-wing in TLS 1.3, which would raise the SP 800-133 issue above.
But there's also the IETF draft for hybrid key exchange in TLS 1.3 (https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/), which is widely deployed. For this RFC - provided that the seed is generated by an approved RBG instead of the X-wing method - I believe combining ML-KEM with X25519 (etc.) using the TLS 1.3 KDF (which includes the SP 800-56C HKDF) should align with the existing NIST standards.
I reviewed the RFC draft 09 ( https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/) with Andy Regenscheid. The key combiner looks like it meets the requirements in SP 800-227... using an approved hash as a one-step KDF from SP 800-56C.
The use of SHA3? Great!
The seed expansion using SHAKE to generate the key pairs is not currently in SP 800-133. That document is actively (to the extent possible...) being revised. I would expect this to be in there when a draft of that revision is published.
This would be great to see! 🤞
Support for both of these also means the constructions in the CFRG Hybrid KEMs document will also meet the requirements: https://www.ietf.org/archive/id/draft-irtf-cfrg-concrete-hybrid-kems-01.html
On Wed, Nov 5, 2025, 12:02 PM Chris Celi @.***> wrote:
celic left a comment (usnistgov/ACVP#1611) https://github.com/usnistgov/ACVP/issues/1611#issuecomment-3492336595
The timing of the discussion is unfortunate when the CT group is not working. The CAVP/CMVP does not set policy here, we rely on the standards authors.
I reviewed the RFC draft 09 ( https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/) with Andy Regenscheid. The key combiner looks like it meets the requirements in SP 800-227... using an approved hash as a one-step KDF from SP 800-56C.
The seed expansion using SHAKE to generate the key pairs is not currently in SP 800-133. That document is actively (to the extent possible...) being revised. I would expect this to be in there when a draft of that revision is published.
I'm working with the author of IG D.S to stay in sync as well. When Andy spoke at the PQC conference in September, it seems the topic of the key combiner and the seed expansion got mixed up.
— Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/1611#issuecomment-3492336595, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHAAI74LSJ4SNMN5IMUD333IUTBAVCNFSM6AAAAACIWUCRJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIOJSGMZTMNJZGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
And per section 5.7 of that RFC, I see that it's possible to use X-wing in TLS 1.3, which would raise the SP 800-133 issue above.
But there's also the IETF draft for hybrid key exchange in TLS 1.3 ( https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/), which is widely deployed. For this RFC - provided that the seed is generated by an approved RBG instead of the X-wing method - I believe combining ML-KEM with X25519 (etc.) using the TLS 1.3 KDF (which includes the SP 800-56C HKDF) should align with the existing NIST standards.
X-Wing as a Supported Group in TLS 1.3 has not been registered in IANA¹. The mentioned X25519MLKEM768 instance of -tls-hybrid-design gives you everything you need cryptographically without the overhead of extra redundant hashing, and has already seen wide adoption. X-Wing may see more use in Encrypted Client Hello in the future, and is showing adoption in other non-TLS settings.
¹ https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
On Wed, Nov 5, 2025, 9:20 PM aryeharcher @.***> wrote:
aryeharcher left a comment (usnistgov/ACVP#1611) https://github.com/usnistgov/ACVP/issues/1611#issuecomment-3494559793
To clarify, I'm not looking for a final answer here - I just want to add the context we've picked to the CAVP/CMVP discussions around hybrid guidance. I plan to include a comment on the draft IGs as well. And strongly agreed that it's unfortunate the CT group isn't available currently. I really hope they'll be back to clarify by the time the CMVP is reviewing the IG D.S comments.
Also agreed on X-wing. My understanding from recent NIST workshops is that X-wing cannot be used in FIPS until SP 800-133 is updated to allow seed generation with this method. And per section 5.7 of that RFC, I see that it's possible to use X-wing in TLS 1.3, which would raise the SP 800-133 issue above.
But there's also the IETF draft for hybrid key exchange in TLS 1.3 ( https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/), which is widely deployed. For this RFC - provided that the seed is generated by an approved RBG instead of the X-wing method - I believe combining ML-KEM with X25519 (etc.) using the TLS 1.3 KDF (which includes the SP 800-56C HKDF) should align with the existing NIST standards.
— Reply to this email directly, view it on GitHub https://github.com/usnistgov/ACVP/issues/1611#issuecomment-3494559793, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEHAANCTMDVLA22TTKBCXD33KV7HAVCNFSM6AAAAACIWUCRJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIOJUGU2TSNZZGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
@aryeharcher
I believe combining ML-KEM with X25519 (etc.) using the TLS 1.3 KDF (which includes the SP 800-56C HKDF) should align with the existing NIST standards.
Yes I would expect it as well. The application of SP 800-227 Section 3.1 is a tad ambiguous. It is unclear if the seed requirements apply to the non-approved components of a hybrid scheme. Logically if you have access to an approved DRBG (or RBG) you should use it.
A few follow-up notes:
I believe the only 3 registered IANA parameter sets from @dconnolly's link (thanks!) that can be used for TLS 1.3 hybrid key exchange (https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) are SecP256r1MLKEM768, X25519MLKEM768, SecP384r1MLKEM1024.
Yes I would expect it as well. The application of SP 800-227 Section 3.1 is a tad ambiguous. It is unclear if the seed requirements apply to the non-approved components of a hybrid scheme. Logically if you have access to an approved DRBG (or RBG) you should use it.
That's fair. I read the Section 3.1 requirements as specific to approved KEMs, but I think X25519MLKEM768 for TLS 1.3 hybrid key exchange is still aligned with this requirement. If I followed correctly, the X25519MLKEM768 group is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/, which references https://www.rfc-editor.org/rfc/rfc7748 for X25519 key generation. Then section 6.1 of RFC7748 specifies that Alice and Bob each generate 32 random bytes for X25519 key generation.
I'm also including a link to this issue in the IG D.S comments I'm submitting. The relevant comment requests that the IG include the FIPS conformance status for popular industry hybrids.