diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki index 001664ffb3..8ba5884d9f 100644 --- a/bip-0360.mediawiki +++ b/bip-0360.mediawiki @@ -622,47 +622,41 @@ using P2QRH outputs. == Security == {| class="wikitable" -|+ Candidate quantum-resistant signature algorithms ordered by largest to smallest NIST Level V signature size +|+ Candidate quantum-resistant signature algorithms ordered by largest to smallest |- -! Signature Algorithm !! Year First Introduced !! Signature Size !! Public Key Size !! Cryptographic Assumptions +! Algorithm !! Year Introduced !! NIST Level !! Signature Size !! Public Key Size !! Cryptographic Assumptions |- -| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || 8,192 bytes || 16,384 bytes || +| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || - || 8,192 bytesCalculated assuming a 256-bit hash function which results in a public key of 2*256*256/8=16,384 bytes and a signature of 256*256/8=8,192 bytes. || 16,384 bytes || Hash-based cryptography |- -| [https://eprint.iacr.org/2011/191.pdf Winternitz signature] || 1982 || 2,368 bytesWinternitz -signatures are much smaller than Lamport signatures due to efficient chunking, but computation is much higher, -especially with high values for w. Winternitz values are for w of 4. It's worth noting that Winternitz signatures can -only safely be used one time per public key. If addresses are reused, private key information might be leaked, allowing -attackers to spend future outputs assigned to the same address. || 2,368 bytes || Hash-based cryptography +| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA - SHAKE-128s)] || 2015 || 1 || 32 bytes || 7,856 bytes || Hash-based cryptography |- -| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 29,792 -bytes || 64 bytes || Hash-based cryptography +| [https://eprint.iacr.org/2011/191.pdf Winternitz OTS] || 1982 || - || 2,144 bytesWinternitz OTS requires signing both the message digest and a checksum on the message. Assuming a 256-bit hash function and w=16 (chunk size), we get a signature on the message digest consisting of 256/log2(16) = 64 hashes and a signature on the checksum consisting log2(256/log2(16)*log2(16-1))/log2(16)+1=2.99 which rounded up is 3 hashes. This results in a combined signature size of (64+3)*256/8 = 2144-bytes. The WOTS public key is the same size as the signature. || 2,144 bytes || Hash-based cryptography |- | [https://eprint.iacr.org/2011/484.pdf XMSS]XMSS, which is based on Winternitz, uses a value of 108 for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin -network, which take place only inside of wallets one time. || 2011 || 15,384 bytes || 13,568 bytes || +network, which take place only inside of wallets one time. || 2011 || - || 15,384 bytes || 13,568 bytes || Hash-based cryptography (Winternitz OTS) |- -| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4,595 bytes || 2,592 bytes || +| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 2 || 1,312 bytes || 2,420 bytes || Lattice cryptography |- -| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || 1,814 bytes || 1,927 bytes || Lattice cryptography (NTRU) +| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || - || 1,814 bytes || 1,927 bytes || Lattice cryptography (NTRU) |- -| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1,280 bytes || 1,793 bytes || Lattice cryptography +| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1 || 897 bytes || 666 bytes || Lattice cryptography (NTRU) |- -| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 1,261 bytes || 2,329 bytes || Lattice cryptography +| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 1 || 1,024 bytes || 555 bytes || Lattice cryptography |- -| [https://sqisign.org SQIsign] || 2023 || 335 bytes || 128 bytes || Supersingular Elliptic Curve Isogeny +| [https://sqisign.org SQIsign] || 2023 || 1 || 65 bytes || 148 bytes || Supersingular Elliptic Curve Isogeny |- -| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic -Curve Isogeny -|- -| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided || -Supersingular Elliptic Curve Isogeny |} +Lamport and Winternitz OTS signatures can only securely be used one time per public key. If a one time signature scheme is +used more than once, an attacker can forge a signature for a different message. Winternitz signatures have smaller +public keys and signatures than Lamport signatures but require more computation to sign and verify. + As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major constraints. This makes inclusion of SQIsign attractive, however its performance is roughly 100,000 times slower than ECC, @@ -714,6 +708,7 @@ seeds to act as the authoritative secret when signing. These measures are deemed To help implementors understand updates to this BIP, we keep a list of substantial changes. +* 2025-07-20 - Updates PQ Signature Table * 2025-03-18 - Correct inconsistencies in commitment and attestation structure. Switch from merkle tree commitment to sorted vector hash commitment. Update descriptor format. * 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics. * 2025-02-23 - More points of clarification from review. Update dead link.