Libsodium roadmap inquiry

[B3K7]

With regards to the projected resource reqiurements to break Elliptic Curve Diffie-Hellman (ECDH) and the Elliptic Curve Digital Signature Algorithm (ECDSA).

Given that

• OpenSSH swittched to hybrid key exchange in 2022.
• Libsodium added ML-KEM to the roadmap in 2024.
• Signal Messager deployed their Sparse Post Quantum Ratchet in October.

Has libsodium considered adding ML-DSA to their roadmap?

[B3K7]

This ties in with item #1275

[jedisct1]

ML-DSA is meant for digital signatures, not for key exchange.

Even if you are convinced that large-scale quantum computers are coming, there is no reason to rush into post-quantum signature schemes, especially not ML-DSA.

We are still very far from any realistic quantum attack that could break ECC or RSA. If practical progress ever happens, there will still be plenty of time to update software to use another algorithm. By that point, we will likely have much better options than ML-DSA anyway.

The only situation where early adoption makes sense is in hardware that can never be updated. That concern does not apply to software implementations like libsodium.

[quickcrypt-security]

I am also wrestling with concerns about rushing into PQC standards that are likely to change, but it does not seem correct that because software can be easily updated that we can wait. Specifically, I am using libsodium to create long-term artifacts that depend on key exchange strength (keys must be regenerated in the future). So although libsodium could be updated 15 years from now, the artifacts created with it today could be exposed in a PQ world.

After SIKE, just using ML-KEM today seems risky. Many important projects seem to be concluding that the best choice right now is a hybrid protocol like XWing that is in the RFC process. I created a scenario table to help think about this. My conclusion is that many people believe (or perhaps want) Scenario 1 to become the steady state, but are highly concerned it could be Scenario 4 for a long while.

Scenario	DH Broken (aka workable QC) later	ML-KEM Broken later	DH only now secure later	ML-KEM only now secure later	Hybrid now secure later
1	yes	no	no	yes	yes
2	yes	yes	no	no	no
3	no	no	yes	yes	yes
4	no	yes	yes	no	yes

The time to "later" is of course important. The existence of hybrid indicates many think we're living either scenario 1 or 4 and that "later" could be soon (so ML-KEM and DH only are out). Interestingly if you think hybrid is important today because scenario 4 is likely true for a while, but you don't completely disregard QC, then scenario 2 should be highly concerning for any long-term artifacts created today.

Overall it looks like the anti-negative strategy is increasingly common... which is that hybrid is not broken in 3 of the 4 laters.

[quickcrypt-security]

Realize my comment may be in the wrong thread since was about signing rather than key exchange.... but key exchange is on my mind and ML-KEM is on the roadmap but hybrid KX like XWing is not.

[B3K7]

There are software systems which we depend on which get refreshed say once every twenty+ years. Are you betting that Bells theorem is wrong or are you betting that when our physists succeed, they can loudly advertise their success?

[B3K7]

Agreed. I was just about to suggest XWing.

…

On Sun, Dec 14, 2025, 3:22 p.m. Quick Crypt Security Account < ***@***.***> wrote: I am also wrestling with concerns about rushing into PQC standards that are likely to change, but it does not seem correct that because software can be easily updated that we can wait. Specifically, I am using libsodium to create long-term artifacts that depend on key exchange strength (keys must be regenerated in the future). So although libsodium could be updated 15 years from now, the artifacts created with it today could be exposed in a PQ world. After SIKE, just using ML-KEM today seems risky. Many important projects seem to be concluding that the best choice right now is a hybrid protocol like XWing that is in the RFC process. I created a scenario table to help think about this. My conclusion is that many people believe (or perhaps want) *Scenario 1* to be the steady state, but are highly concerned it could be *Scenario 4*. *Scenario* *DH Broken (aka workable QC)* *ML-KEM Broken* *DH only now secure later* *ML-KEM only now secure later* *Hybrid now secure later* 1 yes no no yes yes 2 yes yes no no no 3 no no yes yes yes 4 no yes yes no yes There is a time element not well represented here. AFAIK we are living scenarios 3 today but many are concerned we'll be in scenario 4 soon, so ML-KEM only is out. Opinions vary widely about the time to 1 or 2, but just in case we get there in the not-to-distant future the anti-negative strategy seem to be increasingly common, which is that hybrid remains secure in 3 of the 4 future scenarios. For hardware or long-term storage... *scenario 2* is concerning. — Reply to this email directly, view it on GitHub <#1494 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS36C3MVZPOPALFQHFYYJV34BXBIDAVCNFSM6AAAAACOUL3P6OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMRVGMZDKNI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[B3K7]

@jedisct1 From a minisign-pqc perspective, should FIPS 204 be implemented in libsodium, or better yet, should it be implemented in a separate package such as libSodalite? i.e. Na8(Al6Si6O24)Cl2