We don't plan enabling this algorithm in Fedora, it's a deliberate decision. It is not NIST approved.

I would consider backporting OpenSSH 9.9 containing MLKEM to F41.

Why would it be a deliberate decision to disable an *additional* layer of security? Even if it is not NIST approved and let's assume it adds no extra security at all - it would still not be worse than disabling it, so there really is no point in disabling it other than e.g. the NSA asking Red Hat not to enable it?

Let's not tinfoil-hat this discussion.

The reason we did not enable NTRU is that these algorithms historically had very little cryptanalysis and the openssh implementation had even less verification or proof of correctness.
It is "probably" fine, but could also be terminally broken for all we know.

The NIST algorithms have received a lot more scrutiny and we feel a lot more confident about the algorithm themselves and the implementations.

We'll take under consideration this request, but we rather provide MLKEM over SNTRUP.

I understand that NTRU is new and for all we know might be completely broken and add zero extra security. But even if that is the case, there is still no downside to enabling it, as it is purely in addition. If NTRU is broken, the security is exactly the same as when not using it. I'm fine with adding MLKEM, that seems to also be where upstream is gooing, but adding NTRU would still make sense when connecting to older servers / having older clients connect. Maybe I'm being naive here, but I really see no downside of using NTRU instead of nothing, as it's purely an additional layer. So from a cryptographic point of view, there is no downside. Are you worried from a software engineering perspective of having more complex code that could theoretically result in RCE?

Maintenance was a consideration when we disabled it at the time.

On the more philosophical questions raised in #0:

> Please fix this ASAP and do a post mortem on how it was possible that a crypto policy that significantly weakens security was added

It really comes off like you're accusing me or some other maintainer
of introducing a conscious sabotaging change
to disable previously enabled sntrup761x25519-sha512(@openssh.com).
Since all development happens in the open, you can easily verify for yourself
that no such change has ever taken place and neither
sntrup761x25519-sha512 nor sntrup761x25519-sha512 have ever been enabled in DEFAULT.
While I have provided all the necessary controls to toggle them through crypto-policies,
I have not audited their implementations in openssh
to be strictly superior to ones already enabled by default,
be it for cryptanalysis, performance etc
so the strongest you can really accuse me of is erring on the safe side
of not enabling the shiny new thing in DEFAULT with the highest possible priority,
something that upstream didn't do either yet at the time crypto-policies added support for it.
(https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/17914f1b995ed5f233f61f4cc79415f94d2eb834)

Generalizing this idea comes out even more awkward to me,
since, generally, enabling extra algorithms weakens security.
If upstream adds algorithm X tomorrow, crypto-policies won't have it enabled for openssh
until consciously added to the policy, DEFAULT or other,
which I personally consider a valuable property,
one that I have no interest in revising unless you make your case more clear.
In fact, I've poured large amount of efforts into attaining this property for other back-ends,
see, e.g., https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting

For now, PQ algorithms are available through TEST-PQ subpolicy
for those willing to risk enabling them in addition to classical ones.
We're not yet at the point of being able to offer a generally usable purely-PQ policy.
Custom policies should allow you to conveniently enable it for, like,
two years already, with any priority you want.

> as this entirely defeats the purpose of overriding upstream security policies - if anything, it should make it better, but never worse.

Not only the second part of the sentence does not follow the first one,
I have no idea where it comes from at all.
The goals of crypto-policies include modifying what's enabled both ways, for better or worse,
on forward-looking distros like RHEL and conservative ones like Fedora.

> It really comes off like you're accusing me or some other maintainer
> of introducing a conscious sabotaging change
> to disable previously enabled sntrup761x25519-sha512(@openssh.com).

No. I'm saying that upstream increased security and the policy is now making it weaker.

> I have not audited their implementations in openssh
> to be strictly superior to ones already enabled by default,

They add an *additional* layer, so in the worst case scenario, they add no additional security, but also don't make anything worse. In the best case scenario, they fully prevent a "collect now and decrypt later" attack.

> so the strongest you can really accuse me of is erring on the safe side
> of not enabling the shiny new thing in DEFAULT with the highest possible priority,

This this is that NTRU is not used *instead* of something else, it is used *in addition* to x25519.

> enabling extra algorithms weakens security

There seems to be a fundamental misunderstanding what sntrup761x25519 is. This is duing NTRU and x25519. It's a hybrid approach, only adding an additional layer, as x25519 is already in the list. To quote from the draft:

> To hedge against attacks on either of sntrup761 or X25519 a hybrid construction may be used, with the intention that the hybrid would be secure if either of the involved algorithms are flawed.

> one that I have no interest in revising unless you make your case more clear.

This makes a lot of sense in an either-or scenario. But here it is literally about adding an additional layer to future-proof things. Even if that additional layer turns out to be broken, there is no decrease in security.

> We're not yet at the point of being able to offer a generally usable purely-PQ policy.

Nobody ever asked for a purely-PQ policy. That would indeed be a downgrade in security.

Jonathan,
we are aware of how things work, your posts keeps insinuating that the people you are talking to are stupid, uninformed, unprofessional or malicious.

This is not a useful way to conduct a discussion and is not conducive to achieve your goal or any consensus.

We have simply different opinions on the topic of how and when to introduce new critical security algorithms.

You are welcome to ask questions about how we approach policies and perhaps advocate for a change.

You are NOT welcome to lay implicit accusations and be unnecessarily confrontational.

First of all, if anybody feels I accused them of malice, I apologize, as that was not my intention. Whenever cryptography is weakened for no (to the outside) discernable reason, it irks me and that got the better of me - I'm sorry. With Red Hat being a US company and there being no externally discernable reason to weaken cryptography, it raised the question for me if Red Hat is just following NSA guidance, as the NSA has been caught doing exactly that in the past - and in this particular case, the NSA would benefit greatly from being able to decrypt past communication in the future, while nobody else other than spy agenceis would profit from it (after all, you need to have all the old data collected). Even if this were the case (I am not implying it is, it was a genuine question), this does not mean any of the individuals on Red Hat's side have any bad intentions. Cryptographic standards have been weakened by the NSA in the past when everybody on the standards committe had good intentions and none of them is to blame. Similarly, nobody at Red Hat would be to blame. But again, that is a big if, there was no implication this is the case, it was merely a question on whether Red Hat might have not enabled NTRU on the NSA's advise.

But I agree, the current discussion isn't going anywhere, so let's try it from a different perspective:

It seems some people at Red Hat have objections against using NTRU in combination with the already existing Curve25519 as they think that would weaken security. It would be helpful if those people could explain how they came to this conclusion. Maybe they have a different thread model, maybe they have information people outside of Red Hat are lacking. Explaining they came to this conclusion might help understand each other's perspectives.

What would be also useful for mutual understanding: Is this a Red Hat decision or a Fedora decision (as it seems only people from Red Hat have commented so far)? I personally am not interested in what Red Hat does, but I would really like to improve the situation for Fedora. Backporting 9.9 was mentioned - could this be a compromise for Fedora at least?

>  Explaining *how* they came to this conclusion might help understand each other's perspectives.

Sorry, I missed a word.

Thank you, that's... somewhat less accusatory and conspiratorial indeed.


> in the worst case scenario, they add no additional security, but also don't make anything worse.

In theory. In practice,
the worst case scenario is that the implementation messes up,
and a fresh new combined kex renders everything insecure.
Now, that's not a likely scenario by a wide margin, especially in 2025, but
I'd like to remind that c-p knob for it has landed in March 2022,
when the implementation was, like a month old.


> it raised the question for me if Red Hat is just following NSA guidance

I can confidently say I was not following any NSA guidance,
neither when I've introduced support for sntrup761x25519-sha512 in c-p,
back when it wasn't the highest priority openssh upstream default yet,
nor when I've simply never revised that since.

Now, two years later, when the implementation has seen real-world use
and has been battle-tested enough,
I'm not really against turning it on for Fedora.
But I'm merely a crypto-policies maintainer and no openssh maintainer,
and it seems like Dmitry and Simo
put more trust / willingness to maintain into ML-KEM,
which (as I understand) is more rigorously studied, NIST-approved,
used in TLS as well and implemented outside of openssh,
all of which do sound like good things to me.


ML-KEM hybrid kex, by the way, is in a rather similar position
to what sntrup761x25519-sha512 was mid-2022:
openssh rawhide has support for it, rawhide c-p supports enabling it,
but so far it's not on by default, and it's not highest-priority either.

If I flip ML-KEM on in Fedora DEFAULT in rawhide now,
that'd mean it'll go released DEFAULT in ~April.
Perhaps, that would be what makes everyone happy?

Do we know what the upstream plans are wrt its place in upstream default priority?
Say, if upstream makes mlkem768x25519-sha256 their top default tomorrow,
I don't see why shouldn't we follow suit in Fedora with a reasonable lag.

Let me clarify some points in addition to what Alex already wrote.

(In reply to Jonathan S. from comment #9)
> With Red Hat being a US company and there being no externally
> discernable reason to weaken cryptography, it raised the question for me if
> Red Hat is just following NSA guidance, as the NSA has been caught doing
> exactly that in the past - and in this particular case, the NSA would
> benefit greatly from being able to decrypt past communication in the future,
> while nobody else other than spy agencies would profit from it (after all,
> you need to have all the old data collected).

Only two people on the RHEL crypto team are US citizens, the rest lives in Europe or Asia. I can't speak for everybody else, but personally, I don't have a lot of sympathy for the NSA, and we do not trust what they publish. It is also not in Red Hat's corporate interest to purposely weaken cryptography, as both US and non-US customers would likely and rightfully be very upset if they found out we had intentionally done such a thing.

In fact, the RHEL crypto team thinks quite a few things the NSA has recently published in their CNSA 2.0 guidelines do not pass the smell test and we are discussing ways to comply with these guidelines for the customers that need it while keeping everybody else safe and secure even if one of the algorithms recommended by CNSA 2.0 turn out to be broken. For example, we may end up signing packages not just with ML-DSA, but SLH-DSA in addition, and we want to avoid stateful hash-based signature algorithms due to their failure modes.


> But again, that is a big if,
> there was no implication this is the case, it was merely a question on
> whether Red Hat might have not enabled NTRU on the NSA's advise.

I think if *anybody* had standardized NTRU (IETF, NIST, BSI, ANSII, …) we might have enabled it. To my knowledge, we're not aware of any standardization organizations that recommend NTRU. Are there any that we've missed?


> What would be also useful for mutual understanding: Is this a Red Hat
> decision or a Fedora decision (as it seems only people from Red Hat have
> commented so far)?

The Fedora crypto team is the Red Hat crypto team. All major cryptographic packages in Fedora are maintained by Red Hatters.

FEDORA-2025-800d4e4a95 (openssh-9.9p1-1.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-800d4e4a95

I built OpenSSH 9.9p1 for F41. It has MLKEM768-based KEX on board, please test it

FEDORA-2025-800d4e4a95 has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-800d4e4a95`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-800d4e4a95

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

To the best of my understanding of the original request,
this is about the highest-priority algorithm in DEFAULT policy,
not about there availability per se.
Moving back from ON_QA.

FEDORA-2025-800d4e4a95 (openssh-9.9p1-1.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

(oh, that's why I can't find it, silly automation has closed this ticket)

Dear Jonathan, you might be interested to learn that
I've now promoted Dmitry's preferred hybrid kex, mlkem768x25519-sha256
to the most preferred priority in DEFAULT starting from
crypto-policies-20250324-1.git3714354.fc43.
That decision has been made ~half a year after upstream openssh
first shipped with mlkem768x25519-sha256
and immediately considered it good enough to be offered by default,
but without waiting for it
to become the upstream's highest-priority choice of a kex.

This change will not be backported to Fedora <43,
meaning it'd reach released Fedora no earlier than by ~November 2025,
easily another half a year later. I consider this timeline to be reasonable,
given how the current implementation comes from a fresh pre-release openssl 3.5,
which, as far as I know, is different from the one offered in Fedora 42
(where the implementation comes from liboqs instead).
Moreover, while mlkem768x25519-sha256 seems to operate fine in my testing,
I consider it a good idea to wait out at least one more Fedora cycle
to give it more time for potential problems to surface.
I reserve the right to revert this change in case any serious breakage would ensue.
Though I hope that'll go smoothly and I won't have to revisit this decision.

Writing post-mortems on me not enabling any hybrid kexes at topmost priority
because nobody asked me to are left as an exercise for the reader.
Should anyone ever indulge in such curious pastime activities,
please portray me as a perpetually grumpy young professional
with tired blue eyes and animesquely-bright orange hair.

Sorry for the late response - I kinda lost track of the ticket, too.

Thanks for the change! It's really appreciated and I'm looking forward for it to make its way into a release!

Also, sorry, the initial post was under the assumption that it has been explicitly disabled rather than just not gotten to being enabled.

As OpenSSH still supports NTRU and older clients/servers *only* support NTRU, is there any plan to enable NTRU at all?

I had no such plans.

Enabling it at the end of the list sounds a bit pointless to me,
since any openssh modern enough to have NTRU enabled
will have ample higher-priority kex overlap with f43 openssh,
so the only scenario that it'd have any effect on
would be interop with hosts that disabled everything but NTRU, wouldn't it?
I don't see many administrators/deployments being that PQ-impatient in 2025,
and I guess, my answer for those who are is apply a custom policy now,
use ML-KEM later.

10.0> the hybrid post-quantum algorithm mlkem768x25519-sha256 is now used by default for key agreement

Awesome, so we'll be in alignment with upstream now.