WIP Implement post-quantum security #1842

1. 
   real-or-random commented at 4:02 pm on April 1, 2026: contributor

   In light of recent advancements in the area of quantum computing that reduce the number of qubits¹² and Toffoli gates² necessary to solve the discrete logarithm problem on secp256k1, I believe it’s time to take action and secure this library against quantum attacks.

   Implementation plan:

   • 60892c97f660fbb4835661ecc75e9e823e162c33 ecmult_(gen/const): Implement post-quantum mode
   • 9b9eb401fc9b2b9400f56c8fe4b0dbe1a1f9488a configure: Add –enable-post-quantum option
   • Port configure option to CMake
   • 9e2e6e7515896e2504ca04214475d5cf6dddd912 Double major version number (BIG breaking change)
   • Reevaluate functionality
   • Fix CI
   • Add Changelog entry

   ---

   1. Clémence Chevignard, Pierre-Alain Fouque, André Schrottenloher. Reducing the Number of Qubits in Quantum Discrete Logarithms on Elliptic Curves, EUROCRYPT 2026, https://eprint.iacr.org/2026/280, ↩︎

   2. Ryan Babbush, Adam Zalcman, Craig Gidney, Michael Broughton, Tanuj Khattar, Hartmut Neven, Thiago Bergamaschi, Justin Drake, Dan Boneh. Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations, preprint, https://arxiv.org/pdf/2603.28846 ↩︎ ↩︎

2. ecmult_(gen/const): Implement post-quantum mode 60892c97f6
3. configure: Add --enable-post-quantum option 9b9eb401fc
4. Double major version number to indicate BIG breaking change 9e2e6e7515
5. real-or-random added the label assurance on Apr 1, 2026
6. real-or-random added the label feature on Apr 1, 2026
7. real-or-random added the label needs-changelog on Apr 1, 2026
8. 
   sipa commented at 5:20 pm on April 1, 2026: contributor

   Hmm, I would expect PQC mode to just be a “return false;” in all signature verification functions, but they seem unaffected here?
9. 
   hebasto commented at 5:46 pm on April 1, 2026: member

   I believe it’s time to take action and secure this library against quantum attacks.

   Indeed.

10. 
    theStack commented at 5:49 pm on April 1, 2026: contributor

    For better marketing, I’d recommend quadrupling the major version number instead of only doubling (implying an EVEN BIGGER breaking change). Happy to re-review the diff thoroughly if you want to follow that suggestion.
11. in src/util.h:164 in 9e2e6e7515

    158@@ -159,6 +159,11 @@ static const secp256k1_callback default_error_callback = {
    159 #define VERIFY_CHECK(cond)
    160 #endif
    161 
    162+#define POST_QUANTUM_CHECK(ctx) do { \
    163+    fprintf(stderr, "Forbes a day before 01/Apr/2026 Google Finds Quantum Computers Could Break Bitcoin Sooner Than Expected\n"); \
    164+    abort(); \
    

    ---

    ---

    

    furszy commented at 5:53 pm on April 1, 2026:

    tiny nit for the future:

    Execute a GPT/Claude/Gemini prompt here.

12. 
    furszy commented at 5:53 pm on April 1, 2026: member

    Change is too complex. Should be divided across multiple PRs. The more, the better.
13. 
    real-or-random commented at 6:12 pm on April 1, 2026: contributor

    Hmm, I would expect PQC mode to just be a “return false;” in all signature verification functions, but they seem unaffected here?

    That’s a fair point, and I’ve considered this as well, but it’s orthogonal to this PR. Changing the signature verification functions would entail a softfork in Bitcoin, and so this will need more discussion. What we could do is add new API calls such as secp256k1_schorrsig_verify_pq which just return 0 when post-quantum mode is enabled and fall back to ordinary verification otherwise. However, based on @furszy’s feedback, I suggest that this is done in another PR.

    I should have made this clearer in the initial comment, but the purpose of this PR to ensure that any keys created in post-quantum mode are safe (and the same for any ECDH secrets derived in post-quantum mode). This will also make the library secure for new applications adopting libsecp256k1 in the future, e.g., in 50 years from now.

14. 
    real-or-random commented at 6:12 pm on April 1, 2026: contributor

    For better marketing, I’d recommend quadrupling the major version number instead of only doubling (implying an EVEN BIGGER breaking change). Happy to re-review the diff thoroughly if you want to follow that suggestion.

    I think that’s overkill for now, but we could do if @sipa’s suggestion is implemented.

15. 
    real-or-random commented at 6:13 pm on April 1, 2026: contributor

    Change is too complex. Should be divided across multiple PRs. The more, the better.

    Agreed. I had a hard time splitting 9e2e6e7515896e2504ca04214475d5cf6dddd912, but I’m happy to move it to a follow-up PR.

16. 
    sipa commented at 6:15 pm on April 1, 2026: contributor

    It is quite impressive how this PR manages to create public keys that reveal nothing about the corresponding private keys, even in a CRQC setting!
17. real-or-random closed this on Apr 8, 2026

    ---

18. real-or-random removed the label assurance on Apr 8, 2026
19. real-or-random removed the label feature on Apr 8, 2026
20. real-or-random removed the label needs-changelog on Apr 8, 2026
21. real-or-random added the label invalid on Apr 8, 2026

Contributors
real-or-random sipa hebasto theStack furszy

Labels
invalid