Closed soatok closed 2 months ago
If we go ahead with ML-DSA-65, all parties should (as @FiloSottile suggests for ML-KEM) only use a 32-byte "seed" as the private key, rather than storing/validating the whole private key.
Unlike the Chromium team, I'm not shy about FALCON (soon to be called FN-DSA by NIST, when they standardize it later this year or early next year).
We just need a good implementation. PQClean / OpenQuantumSafe have C implementations, but I'm aware of work going into Rust PQ implementations, so I'll probably hold out on that.
Luckily, this isn't a v0.1.0 milestone target, so no urgency.
(This is just a mental core dump.)
Given that we're at the application-layer, not working with the limitations of network packets, I'm okay with larger public keys and/or signatures. However, I do want it to be fast.
Based on that, I think I'm going to prioritize hybrid post-quantum before we tag v1.
Although deferring the adoption of post-quantum cryptography until later allows us to flex our migration muscles, I'd rather not find out that some clients cannot migrate due to memory or bandwidth constraints later. Let's swallow the bitter pill now instead.
After much research and discussion, I think we should punt on PQ signatures entirely for the immediate future. When we revisit this, I will file a new issue and link to this one.
https://soatok.blog/2024/09/13/e2ee-for-the-fediverse-update-were-going-post-quantum/
At some point in the future, we should migrate to using post-quantum cryptography.
This means the following:
This won't be tenable until SigSum releases a PQ variant, and doing PQ KEMs for E2EE is a higher priority due to store now, decrypt later attacks.