Chapter 6: Digital signatures reconsidered

A signature scheme is secure if an adversary who has seen signatures on any messages of its choice still cannot produce a valid signature on a fresh one. The security goal is called EUF-CMA, short for existential unforgeability under adaptive chosen-message attack (Goldwasser et al., 1988). Every digital signature scheme in the book targets this game or a strengthening of it. Textbook RSA fails it structurally, by a one-line algebraic forgery. ECDSA illustrates a different failure mode: its security depends critically on the per-message secret nonce $k$. Reusing $k$ across two signatures under the same private key recovers the key outright from those two signatures alone. Biased or partially leaked nonces also lead to key recovery, but through a lattice attack on many signatures (the hidden number problem), not the closed-form derivation on two (Boneh & Venkatesan, 1996; Nguyen & Shparlinski, 2003). A few lines of Python make the two-signature case concrete.

A textbook forgery

Textbook RSA signing raises the message to the private exponent modulo the public modulus and calls that the signature (Rivest et al., 1978). The verification check is $s^e \equiv m \pmod{n}$, which reverses the signing map. Raw modular exponentiation is a group homomorphism on the unit group $(\mathbb{Z}/n\mathbb{Z})^\times$. If $s_1 = m_1^d \bmod n$ and $s_2 = m_2^d \bmod n$, then $s_1 s_2 \equiv (m_1 m_2)^d \pmod{n}$ by a single line of algebra. Anyone who has seen two valid signatures can multiply them and recover a valid signature on $(m_1 m_2) \bmod n$, without knowing $d$ or factoring $n$.

The snippet below runs the forgery on the same 64-bit modulus Chapter 5 used for the toy RSA-KEM:

# Textbook RSA signing on the 64-bit modulus from Chapter 5.
# Raw modular exponentiation is a group homomorphism on (Z/nZ)^*:
# s1 * s2 = (m1 * m2)^d mod n, which verifies as a signature on (m1 * m2) mod n.
p = 3184935163
q = 3199286161
n = p * q
e = 65537
d = pow(e, -1, (p - 1) * (q - 1))

# Honest signer produces two legitimate signatures.
m1 = 0x1111222233334444
m2 = 0x5555666677778888
s1 = pow(m1, d, n)
s2 = pow(m2, d, n)

# Attacker sees (m1, s1) and (m2, s2) and multiplies them.
s_forged = (s1 * s2) % n
m_forged = (m1 * m2) % n

# The forged pair verifies under the textbook rule s^e == m mod n,
# and m_forged is a fresh message the signer never signed.
assert m_forged not in {m1, m2}
assert pow(s_forged, e, n) == m_forged
print(pow(s_forged, e, n) == m_forged)
# ==> True

Every Python block this chapter prints is also a standalone file in the companion repository, under chapter-code/ch06/, one file per block. Appendix C covers the clone and the environment they run on.

Raw RSA signing preserves a homomorphic relation between signatures and messages, and any useful definition of signature security has to rule out forgeries of this shape. The pedagogical repair is full-domain hash RSA (FDH-RSA): hash the message into the full RSA domain and sign the representative, so a scheme outputs $\sigma = H(m)^d \bmod n$ instead of $m^d \bmod n$.

RSA exponentiation is still multiplicative, so the attacker can still compute $\sigma_1 \sigma_2 \bmod n$. That product, however, only verifies as a signature on a message $m^*$ with $H(m^*) \equiv H(m_1) H(m_2) \pmod{n}$. In the random-oracle model, finding such an $m^*$ requires inverting the random oracle at a value the attacker chose, which succeeds only with negligible probability (Bellare & Rogaway, 1996; Boneh & Shoup, 2023). What full-domain hashing removes is the message-level homomorphism, not the multiplicativity of the exponentiation. Real deployed RSA signature schemes use standardized encodings such as RSA-PSS (the probabilistic signature scheme) rather than the literal hash-and-exponentiate construction.

EUF-CMA as a game

A digital signature scheme is a triple $(\mathrm{Gen}, \mathrm{Sign}, \mathrm{Verify})$. Gen() samples a keypair $(\mathrm{pk}, \mathrm{sk})$. Sign(sk, m) outputs a signature $\sigma$. Verify(pk, m, sigma) returns accept or reject. The scheme is correct if a signature produced by Sign always verifies: for every keypair and every message, Verify(pk, m, Sign(sk, m)) = 1 with probability one over the randomness of Gen and Sign. The security game fixes what it means for Verify to reject forgeries.

The EUF-CMA game against a signature scheme $\Pi$ runs like this (Goldwasser et al., 1988). The challenger generates $(\mathrm{pk}, \mathrm{sk}) \gets \mathrm{Gen}()$ and gives $\mathrm{pk}$ to the adversary $\mathcal{A}$. $\mathcal{A}$ may query a signing oracle on any message $m$ of its choice. The oracle returns $\sigma = \mathrm{Sign}(\mathrm{sk}, m)$. At any point $\mathcal{A}$ outputs a forgery attempt $(m^*, \sigma^*)$. The adversary wins if $\mathrm{Verify}(\mathrm{pk}, m^*, \sigma^*) = 1$ and $m^*$ was never queried to the signing oracle. The advantage is

$$\mathrm{Adv}^{\text{EUF-CMA}}_{\Pi}(\mathcal{A}) = \Pr[\mathrm{Forge}^{\mathcal{A}}_{\Pi} = 1].$$

A signature scheme is EUF-CMA-secure if every polynomial-time adversary’s advantage is negligible in the security parameter (Boneh & Shoup, 2023).

Figure 6.1. EUF-CMA. The challenger holds the keypair; the adversary queries Sign and forges on a message it never queried. The figure is the security game, not a deployment protocol: Sign in real systems is not a public oracle.

It is useful to separate the goal (existential forgery on a fresh message) from the attack model (what the adversary gets to see). The game admits two weakenings and one strengthening worth naming. Every model hands the adversary the public key. They differ in what else it sees, and in what counts as a win.

Notion	Also gets	Wins with
Key-only	Nothing	Any valid $(m^*, \sigma^*)$
EUF-KMA	Pairs on challenger-chosen messages	Valid $(m^*, \sigma^*)$, $m^*$ outside that set
EUF-CMA	A signing oracle on adversary-chosen messages	Valid $(m^*, \sigma^*)$, $m^*$ never queried
sEUF-CMA	The same as EUF-CMA	Any new valid pair, including a second $\sigma$ on a queried $m$

Key-only and known-message (EUF-KMA, existential unforgeability under known-message attack) are the two weakenings. A scheme that fails EUF-CMA can still pass either of them, which is why neither is an adequate security target. The strengthening is sEUF-CMA (strong existential unforgeability), which denies the adversary even a fresh signature on a message the oracle already signed. The two standards this book builds sit on either side of that line: FIPS 205 states the SLH-DSA parameter-set security categories with respect to EUF-CMA (National Institute of Standards and Technology, 2024), while FIPS 204 designs ML-DSA for the stronger notion, which it writes SUF-CMA (National Institute of Standards and Technology, 2024a).

The full-domain hash RSA construction turns textbook RSA into an EUF-CMA-secure signature scheme in the random-oracle model (Bellare & Rogaway, 1993, 1996). The construction is direct. Sign(sk, m) outputs $\sigma = H(m)^d \bmod n$, where $H$ is a hash function whose output range covers $\mathbb{Z}/n\mathbb{Z}$. Verify(pk, m, sigma) accepts if $\sigma^e \equiv H(m) \pmod{n}$. The security proof reduces EUF-CMA to the RSA assumption by answering the adversary’s hash queries itself. It plants the RSA challenge as the answer to one guessed query. Every other query gets a value whose $e$-th root the reduction picked first and therefore knows, which is what lets it sign those messages on demand. If the forgery is built on the guessed query, the reduction reads the RSA inverse straight off it, and EUF-CMA is what guarantees that message was never sent to the signing oracle. The textbook treatment is in Boneh-Shoup (Boneh & Shoup, 2023).

The FDH reduction is not tight

The exact-security treatment is in the Bellare-Rogaway 1996 paper, which also introduced PSS as a tighter alternative (Bellare & Rogaway, 1996). Their reduction loses a factor of the forger’s total query count, hash queries plus signing queries. Coron later sharpened that to roughly the number of signing queries alone, by including the challenge in many hash answers at a tuned probability rather than planting it at one guessed query (Coron, 2000). Neither reduction ever holds the private exponent; all it holds are $e$-th roots it chose itself. Signing queries are normally far fewer than hash queries, so the bound improves, but a loss remains: FDH is not tight even after Coron.

Lattice-based signatures take a different route. ML-DSA is a Fiat-Shamir-with-aborts construction, and FIPS 204 bases its SUF-CMA security on MLWE (Module-LWE) over the ring $R_q$ and a nonstandard variant of MSIS (Module-SIS) called SelfTargetMSIS, in the random-oracle model (National Institute of Standards and Technology, 2024a). Chapter 9 defines $R_q$ and both module problems. Rejection sampling on the signer’s side prevents the signature distribution from leaking the secret.

Nonce reuse recovers the key

ECDSA signatures carry an independent random scalar $k$ called the nonce. If the same $k$ is ever used for two different signatures under the same private key, the attacker recovers the key from the two signatures alone (National Institute of Standards and Technology, 2023). The derivation is elementary and relies on the fact that the scalar order $N$ is prime.

Recall the ECDSA signing equation from Chapter 4. Given a private key $d$, a message hash $z$ reduced modulo the scalar order $N$, and a nonce $k \in [1, N-1]$, the signer computes $R = kG$ and takes $r = R_x \bmod N$. The signature is $s = k^{-1}(z + rd) \bmod N$.

Suppose the signer produces two signatures $(r, s_1)$ on $z_1$ and $(r, s_2)$ on $z_2$ under the same $k$. Because $k$ is fixed, $r$ is the same in both signatures, so a repeated $r$ is the signal the attacker watches for. The two signature equations are

$$s_1 = k^{-1}(z_1 + rd) \bmod N, \qquad s_2 = k^{-1}(z_2 + rd) \bmod N.$$

Subtract the second from the first. The $rd$ terms cancel:

$$s_1 - s_2 \equiv k^{-1}(z_1 - z_2) \pmod{N}.$$

Multiply by $k$ and divide by $s_1 - s_2$ to recover the nonce:

$$k \equiv (z_1 - z_2)(s_1 - s_2)^{-1} \pmod{N}.$$

Because $N$ is prime, the inversion is well-defined iff $s_1 \not\equiv s_2 \pmod{N}$, which in turn holds iff $z_1 \not\equiv z_2 \pmod{N}$. Substitute $k$ back into the first signature equation and solve for $d$:

$$d \equiv (s_1 k - z_1) r^{-1} \pmod{N}.$$

This step also assumes $r \not\equiv 0 \pmod{N}$. Real ECDSA rejects a signature with $r = 0$ or $s = 0$, so a correctly implemented signer never emits one. What it does instead depends on how the nonce was produced. FIPS 186-5 sends a randomized signer back to draw a fresh $k$, and makes a deterministic signer output failure, because re-deriving $k$ from the same key and message would reproduce the same $r$ and $s$ (National Institute of Standards and Technology, 2023). The recovery formula itself uses only the two signatures, the two message hashes, and the group order $N$; it does not use the generator $G$ or the public key $Q = dG$. A real attacker still uses the public key to identify which signatures belong to the same signer; the formula above just no longer needs it once that pairing is known.

FIPS 186-5 therefore requires a per-message secret number $k$ for each signature. The standard allows $k$ to be generated randomly or deterministically from the message hash and the private key; in either case $k$ must remain secret and must not repeat across distinct message hashes under the same private key (National Institute of Standards and Technology, 2023).

A repeated $r$ is a signal, not a proof

$r$ is the $x$-coordinate of $kG$ reduced modulo $N$, and $(N-k)G$ is the reflection of $kG$ across the $x$-axis, so $k$ and $N-k$ always produce the same $r$ (National Institute of Standards and Technology, 2023). A shared $r$ is compatible with at least $k$ and $N-k$, and rarely with more. The reduction modulo $N$ can fold two distinct curve $x$-coordinates onto one $r$. On secp256k1 that happens at $r = 2$, where four nonces share the value. The negated case is still fatal, with the same algebra and one sign flipped: $k \equiv (z_1 - z_2)(s_1 + s_2)^{-1} \pmod{N}$. Either way the attacker settles it the same cheap way, by checking the recovered $d$ against the public key. The toy group below has collisions of its own on top of that, because it reduces the group element instead of an $x$-coordinate. There, $k = 6$ and $k = 9$ both give $r = 2$.

The attack is mechanical on a toy prime-order group. The snippet below uses the order-$11$ subgroup of $(\mathbb{Z}/23\mathbb{Z})^\times$ generated by $g = 4$, a private key $d = 7$, and the same nonce $k = 6$ for two different message hashes $z_1 = 3$ and $z_2 = 5$. Group exponentiation stands in for scalar multiplication, and $r$ is the integer $R$ reduced modulo $N$. In real ECDSA, $R = kG$ is an elliptic-curve point and $r$ is its $x$-coordinate reduced modulo $N$. The toy compresses that to R mod N because a multiplicative-group element has no coordinate pair. The attack is insensitive to how $r$ is derived, so the toy algebra and the secp256k1 algebra are identical.

# Toy ECDSA nonce-reuse attack on the order-11 subgroup of (Z/23)^*.
# g = 4 has order 11 modulo 23 (check: 4 = 2^2, and (Z/23)^* has order 22).
# The attacker sees two signatures (r, s1) and (r, s2) under the same nonce k
# and recovers the private key d from the two signatures alone.
p = 23
N = 11
g = 4

# Confirm that g has order N in (Z/p)^*.
assert pow(g, N, p) == 1

# Signer's keypair.
d = 7
y = pow(g, d, p)  # y = g^d mod p is the public "point"

# Two signatures under the SAME nonce on different message hashes.
k = 6
z1 = 3
z2 = 5

R = pow(g, k, p)          # "scalar multiplication" kG in the subgroup
r = R % N
s1 = (pow(k, -1, N) * (z1 + r * d)) % N
s2 = (pow(k, -1, N) * (z2 + r * d)) % N

# Real ECDSA rejects r = 0 and the recovery needs s1 != s2.
assert r != 0
assert s1 != s2

# Attacker sees (r, s1, z1) and (r, s2, z2). Recover k, then d.
k_rec = ((z1 - z2) * pow(s1 - s2, -1, N)) % N
d_rec = ((s1 * k_rec - z1) * pow(r, -1, N)) % N

print(d, d_rec, d == d_rec)
# ==> 7 7 True

The recovered $d$ matches the original, as the marker shows. The algebraic fix is straightforward: use a correct per-message secret number as specified in FIPS 186-5, and never reuse the same $k$ under the same private key (National Institute of Standards and Technology, 2023). The engineering fix still requires care: the nonce path has to be protected against RNG failure, side channels, and fault injection, since any of those can leak $k$ or force a repeat without the signer noticing.

The attack has been run in the field. Sony’s PS3 code-signing key fell in 2010, after fail0verflow showed the console’s ECDSA signer used a fixed value in place of a per-signature nonce (fail0verflow, 2010). On the Bitcoin chain the same mistake is measurable: Bos and colleagues found 158 public keys that had signed more than once under the same nonce (Bos et al., 2014). One address appears to have collected over 59 bitcoin from ten of them between March and October 2013. Both cases were spotted the way the attacker spots them here, by a repeated $r$.

Why textbook shortcuts fail EUF-CMA

• Textbook RSA. The multiplicative forgery in the opening snippet shows that an EUF-CMA adversary who obtains any two signatures can forge a third on their product. The fix is full-domain hash RSA: sign $H(m)^d$ instead of $m^d$, which removes the message-level relation the attacker exploited, even though RSA exponentiation itself stays multiplicative.

• ECDSA with broken nonce generation. The nonce-reuse derivation above recovers the private key from two signatures under the same $k$. The fix is strict per-message nonce discipline: either generate $k$ uniformly with explicit rejection at the boundary, or derive $k$ deterministically from the private key and message hash via an approved deterministic procedure such as RFC 6979 (National Institute of Standards and Technology, 2023). Deterministic generation eliminates dependence on fresh randomness for each signature; it does not eliminate the requirement for side-channel and fault-injection hardening, since either route still has to keep $k$ secret at runtime.

• Nonces biased in any predictable way. Even without reuse, nonces sampled from a distribution biased toward a fixed bit pattern, a short bit length, or any other structured subset leak the private key through a lattice attack on the hidden number problem (Boneh & Venkatesan, 1996; Nguyen & Shparlinski, 2003). The fix is uniform sampling with explicit rejection at the boundary, or deterministic derivation from the message and the key.

EUF-CMA is stricter than keeping the private key secret. The signer loses the game if any computed quantity gives the adversary a path to forge. A product of signatures does that without revealing $d$ at all. A reused or biased nonce does it the other way, by letting the adversary compute $d$ from published signatures, even though the signer never transmits it.

Tradeoffs across post-quantum signature families

Post-quantum signature schemes in the book target at least the EUF-CMA game, and make different tradeoffs on key size, signature size, and verification cost.

Family	Scheme (NIST level)	Verification key	Signature
Lattice	ML-DSA-44 (2)	1,312 B	2,420 B
Hash	SLH-DSA-128s (1)	32 B	7,856 B
Hash	SLH-DSA-256f (5)	64 B	49,856 B
Isogeny	SQIsign (1)	83 B	200 B

Sizes are from FIPS 204 (National Institute of Standards and Technology, 2024a), FIPS 205 (National Institute of Standards and Technology, 2024b), and the SQIsign round-3 specification (The SQIsign Team, 2026). The two SLH-DSA rows are its extremes: verification keys are 32, 48, or 64 bytes as the security level rises, and no parameter set signs longer than SLH-DSA-256f.

• Lattice-based. ML-DSA (FIPS 204) is NIST’s standardized general-purpose lattice-based signature scheme. Chapter 12 builds it from scratch against the FIPS 204 vectors, and Part V deploys it. FN-DSA (Fast-Fourier lattice-based digital signature algorithm, in development as FIPS 206 (Perlner, 2025)), derived from the pre-standard construction Falcon, is the smaller-signature lattice alternative at the cost of a more delicate signer. This edition discusses it but does not build it.

• Hash-based. SLH-DSA (FIPS 205) has the largest signatures in the table. Its security rests on hash-function, extendable-output-function (XOF), and pseudorandom-function (PRF) assumptions rather than algebraic assumptions such as factoring, discrete log, or structured lattices. FIPS 205 assigns its EUF-CMA security categories under the bound that each key pair signs at most $2^{64}$ messages (National Institute of Standards and Technology, 2024b). Chapter 17 builds SLH-DSA.

• Isogeny-based. SQIsign advanced to Round 3 of NIST’s Additional Digital Signatures process in May 2026 (National Institute of Standards and Technology, 2026) and is not yet a FIPS standard. Its size advantage is the exceptionally small combined public-key-plus-signature footprint. This is not strictly the smallest signature alone among the on-ramp candidates (UOV’s Round 2 spec lists shorter level-I signatures), but it is the smallest combined size. The tradeoff is a more complex and slower implementation profile than ML-DSA or FN-DSA. Chapter 23 builds SQIsign.

None of the three treats the raw message as the algebraic object being signed. Each hashes or encodes the message into a digest, a Fiat-Shamir challenge, or a transcript before the scheme-specific signing relation is checked, and each targets EUF-CMA or the stronger sEUF-CMA rather than a weaker unforgeability game.

Hash-based signatures sit outside the factoring and discrete-log families entirely. Their security rests on the working-level hash-function assumptions Chapter 3 treated as quantum attack targets, with no algebraic trapdoor. The historical problem is that the earliest hash-based constructions were stateful: the signer had to track which one-time keys had been used. That makes backup, restore, and multi-machine signing dangerous unless the state is coordinated so that one-time keys are never reused. Stateful schemes XMSS and LMS, standardized by NIST in SP 800-208, still exist for constrained environments where state management is feasible (Cooper et al., 2020). The stateless hash-based standard is SLH-DSA from FIPS 205, which eliminates state at the cost of larger signatures (National Institute of Standards and Technology, 2024b). Chapter 14 builds Lamport’s one-time signature and the Merkle tree that turns it into a many-time scheme, Chapter 15 builds the XMSS family, and Chapter 17 builds SLH-DSA.

Where Part I ends and Part II picks up

Part I has been a survey of what breaks and why. Chapter 1 set the timeline, Chapter 2 and Chapter 3 the algebra and the hard problems, Chapter 4 the two classical schemes Shor’s algorithm breaks, and Chapter 5 the key-establishment side of the replacement. This chapter closed the other side: the security definition every signature scheme in the book targets, and two ways a scheme can miss it. Textbook RSA lets an adversary forge without ever learning the private key. ECDSA with a repeated nonce is worse, and hands the key over from published signatures alone.

Part II builds the first replacement family from the ground up. Chapter 7 introduces lattices, Chapter 8 the LWE problem, and Chapter 9 its ring and module variants. Chapter 10 assembles Regev encryption and Chapter 11 ML-KEM against the FIPS 203 vectors. Chapter 12 builds ML-DSA, where the Fiat-Shamir-with-aborts construction and the SelfTargetMSIS assumption named above become code. Chapter 13 closes the Part with what it would cost an attacker to break any of it.

Exercises

1. Forge under textbook RSA by hand. Using the 64-bit modulus from the opening snippet, pick two 64-bit integers $m_1$ and $m_2$ and verify numerically that $(s_1 s_2) \bmod n$ equals $(m_1 m_2)^d \bmod n$. Then state in one sentence why, in the random-oracle model, an FDH-RSA adversary cannot efficiently find a fresh $m^*$ whose full-domain hash satisfies $H(m^*) \equiv H(m_1) H(m_2) \pmod{n}$.

2. Recover $d$ from nonce reuse. Using the nonce-reuse snippet as a template, pick a different private key $d \in [1, 10]$ and a different nonce $k \in [1, 10]$. Produce two signatures on two distinct message hashes and run the recovery formula. Confirm that the recovered $d$ matches the original. Then set $z_1 = z_2$ and explain in one sentence why the attack fails when the two message hashes are equal.

3. State EUF-CMA in your own words. Write a four-sentence statement of the EUF-CMA game that another student could use to look up the original paper. The statement must name the challenger, the signing oracle, the win condition on the forgery, and the advantage function.

4. Stateful versus stateless by counterexample. Explain in two sentences why a stateful hash-based signature scheme cannot be safely backed up across two machines without coordination. Name one NIST-approved stateful hash-based scheme (from SP 800-208) and one NIST stateless hash-based standard (from FIPS 205).

5. Schnorr on secp256k1 under long-lived key exposure. Restate the chapter’s EUF-CMA game against Schnorr on secp256k1 (Wuille et al., 2020) in the deployment setting where the verification key $\mathrm{pk}$ was published on a public ledger in year $Y_\text{first}$ and never rotated. An adversary reads $\mathrm{pk}$ from the ledger at $Y_\text{first}$ and waits. At year $Y_\text{CRQC}$ a cryptographically relevant quantum computer becomes available. The adversary runs Shor’s algorithm (Shor, 1994) on $\mathrm{pk}$ and recovers the secret scalar $d$. State the EUF-CMA win condition the adversary now satisfies on a fresh message $m^*$. Then derive the key-exposure window length as a function of $Y_\text{first}$ and $Y_\text{CRQC}$. Evaluate it at $Y_\text{first} = 2021$ and $Y_\text{CRQC} = 2031$. The first is a Taproot-era P2TR output, in which BIP-341 places the public key directly in the output script (Wuille, Nick, & Towns, 2020). The second is CNSSP 15’s CNSA 2.0 deadline, which is a migration target rather than a CRQC arrival forecast.

Worked solutions and editorial notes for these exercises are in Appendix D, Chapter 6. A separate track, for rebuilding rather than reading: the package exercises/ch06-signature-attacks has every function the chapter teaches replaced by a stub. Run PQC_IMPL=exercises pytest tests/ch06 to grade your version against the suite that proves the reference one.

References

Bellare, M., & Rogaway, P. (1993). Random oracles are practical: A paradigm for designing efficient protocols. Proceedings of the 1st ACM Conference on Computer and Communications Security (CCS 1993), 62–73. https://doi.org/10.1145/168588.168596

Bellare, M., & Rogaway, P. (1996). The exact security of digital signatures: How to sign with RSA and Rabin. Advances in Cryptology – EUROCRYPT 1996, 1070, 399–416. https://doi.org/10.1007/3-540-68339-9_34

Boneh, D., & Shoup, V. (2023). A Graduate Course in Applied Cryptography (v0.6). Free online textbook. https://toc.cryptobook.us/

Boneh, D., & Venkatesan, R. (1996). Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes. Advances in Cryptology – CRYPTO 1996, 129–142. https://doi.org/10.1007/3-540-68697-5_11

Bos, J. W., Halderman, J. A., Heninger, N., Moore, J., Naehrig, M., & Wustrow, E. (2014). Elliptic Curve Cryptography in Practice. Financial Cryptography and Data Security (FC 2014), 8437. https://doi.org/10.1007/978-3-662-45472-5_11

Cooper, D., Apon, D., Dang, Q., Davidson, M., Dworkin, M., & Miller, C. (2020). Recommendation for Stateful Hash-Based Signature Schemes. NIST Special Publication 800-208. https://doi.org/10.6028/nist.sp.800-208

Coron, J.-S. (2000). On the exact security of full domain hash. Advances in Cryptology – CRYPTO 2000, 1880, 229–235. https://doi.org/10.1007/3-540-44598-6_14

fail0verflow. (2010). Console Hacking 2010: PS3 Epic Fail. 27th Chaos Communication Congress (27C3), Berlin. https://media.ccc.de/v/27c3-4087-en-console_hacking_2010

Goldwasser, S., Micali, S., & Rivest, R. L. (1988). A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on Computing, 17(2), 281–308. https://doi.org/10.1137/0217017

National Institute of Standards and Technology. (2023). Digital Signature Standard (DSS). FIPS Publication 186-5. https://doi.org/10.6028/NIST.FIPS.186-5

National Institute of Standards and Technology. (2024a). FIPS 204: Module-Lattice-Based Digital Signature Standard. Federal Information Processing Standards Publication. https://doi.org/10.6028/NIST.FIPS.204

National Institute of Standards and Technology. (2024b). FIPS 205: Stateless Hash-Based Digital Signature Standard. Federal Information Processing Standards Publication. https://doi.org/10.6028/NIST.FIPS.205

National Institute of Standards and Technology. (2026). Status Report on the Second Round of the Additional Digital Signature Schemes for the NIST Post-Quantum Cryptography Standardization Process (Internal Report NIST IR 8610). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.IR.8610

Nguyen, P. Q., & Shparlinski, I. E. (2003). The insecurity of the elliptic curve digital signature algorithm with partially known nonces. Designs, Codes and Cryptography, 30(2), 201–217. https://doi.org/10.1023/A:1025436905711

Perlner, R. (2025). FIPS 206 Status Update: Fast-Fourier Lattice-Based Digital Signature Standard (FN-DSA, Falcon). NIST Computer Security Resource Center status presentation. https://csrc.nist.gov/presentations/2025/fips-206-fn-dsa-falcon

Rivest, R. L., Shamir, A., & Adleman, L. (1978). A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2), 120–126. https://doi.org/10.1145/359340.359342

Shor, P. W. (1994). Algorithms for quantum computation: discrete logarithms and factoring. Proceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS), 124–134. https://doi.org/10.1109/SFCS.1994.365700

The SQIsign Team. (2026). SQIsign: Algorithm Specifications and Supporting Documentation (Version 3.0). NIST Post-Quantum Cryptography Additional Signatures, Round 3 submission. https://sqisign.org/spec/sqisign-20260901.pdf

Wuille, P., Nick, J., & Ruffing, T. (2020). BIP-340: Schnorr Signatures for secp256k1. Bitcoin Improvement Proposal. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

Wuille, P., Nick, J., & Towns, A. (2020). BIP-341: Taproot: SegWit version 1 spending rules. Bitcoin Improvement Proposal. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki