Skip to content

Conversation

@alexw91
Copy link
Contributor

@alexw91 alexw91 commented Jan 15, 2026

Goal

Removes any reference that Kyber ever existed from s2n-tls's codebase.

Why

  1. Kyber was a draft standard that predates MLKEM.
  2. AWS-LC about to delete their Kyber implementation code.
  3. Now that MLKEM is standardized and supported everywhere that Kyber was previously supported, we no longer need Kyber, and can delete any references to it.

How

  • Did a bunch of grep -ni kyber -r . in the s2n-tls directory and deleted everything I could find.
  • Where it was trivial, tests were updated in place to use MLKEM. Otherwise Kyber tests were deleted entirely.
  • PQ TLS Policies that only had Kyber (and did not have MLKEM) were deleted and marked as deprecated.
  • PQ TLS Policies that contained both MLKEM and Kyber, were updated in place to have Kyber removed from the bottom of the preference list.
  • All references or usages of LibOQS is removed (since it was only used to test Kyber interoperability)

Callouts

  1. There is still a lot of dead PQ TLS 1.2 code paths that are never used. Those still need to be removed eventually.
  2. This PR deletes the s2n TLS Policy 20240730 which was previously pointed to by default_pq. I don't think that will cause any issues, but wanted to call that out for others to confirm.
  3. test_all_fips was updated to add all MLKEM KeyShares since kem_preferences_all is now FIPS compliant.
  4. Updated crypto/s2n_fips_rules.c so that pure ML-KEM-1024 would be detected as FIPS.
  5. Note: As a rule of thumb, any PQ TLS Policy with the year "2023" or earlier in the name only contained Kyber and is now deprecated. PQ TLS Policies with the year "2024" or newer in the name contained both MLKEM and Kyber and are still supported by s2n (just with Kyber support removed).

Testing

Unit Testing on M4 Mac.

Related

Related to:

release summary: Delete all code that references Kyber

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@alexw91 alexw91 requested a review from dougch as a code owner January 15, 2026 23:49
@alexw91 alexw91 marked this pull request as draft January 15, 2026 23:50
@alexw91 alexw91 force-pushed the delete-kyber branch 5 times, most recently from 7b38a03 to 7820197 Compare January 16, 2026 00:48
@alexw91 alexw91 marked this pull request as ready for review January 16, 2026 01:16
Copy link
Contributor

@dougch dougch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! it might also be worth calling out dropping OQS...

} else {
RESULT_GUARD(s2n_fips_validate_kem(hybrid_group->kem, valid));

if ((hybrid_group->curve != &s2n_ecc_curve_none) && !hybrid_group->send_kem_first) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I keep staring at this and I have no idea why this change in necessary. Please explain 😢.

Copy link
Contributor Author

@alexw91 alexw91 Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. With the removal of Kyber, kem_preferences_all is now FIPS compliant. (Because every KEM preference now contains MLKEM, which is FIPS approved).
  2. Since kem_preferences_all is now FIPS compliant, I thought that the TLS Policy test_all_fips should be updated to use kem_preferences_all.
  3. test_all_fips has the FIPS rule check enforced on it.
  4. The existing FIPS rule checks didn't properly handle pure MLKEM1024, so I updated this file s2n_fips_rules.c to correctly handle pure MLKEM1024

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm interested in this logic about the send_kem_first field. Previously, if the kem was first, we validated it. Otherwise we validated the ecc curve. Now we are always validating the kem, and only validating the ecc curve if it exists and comes first. Is that correct? I get that in pure MLKEM, the ecc curve may not exist, but the ordering of groups logic is now really confusing.

@alexw91 alexw91 requested a review from maddeleine January 27, 2026 20:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants