Digital Signatures

A digital signature answers two questions at once: did this exact content arrive unchanged, and did it really come from the holder of a specific private key? That is how your OS trusts a software update, how Git can verify commits, and how TLS certificates prove a server’s identity. It is the authenticity half of asymmetric cryptography, complementing the confidentiality half from the sibling Diffie-Hellman.

Sign with private, verify with public

The roles are the mirror image of encryption. The signer hashes the message and transforms that hash with their private key to produce a signature. Anyone with the matching public key can verify that the signature corresponds to both the message and that key.

This proves three things:

• Integrity: any change to the message, even one bit, breaks verification.
• Authenticity: only the private-key holder could have produced a valid signature.
• Non-repudiation: the signer cannot plausibly deny signing, since no one else has the key.

It does not provide confidentiality. A signature protects a message; it does not hide it.

Scheme	Underlying key	Notes
RSA-PSS	RSA (>= 3072-bit)	Use PSS, not PKCS#1 v1.5, for new work
ECDSA	EC (P-256/P-384)	Compact and fast, but nonce handling is fragile
Ed25519	Edwards curve	Deterministic, misuse-resistant, the safe default

ECDSA nonce reuse: the PlayStation 3 failure

ECDSA needs a fresh random secret number, the nonce k, for every single signature. The math has a lethal property: if you ever reuse the same k for two different messages, anyone can solve two equations for the one unknown and recover your entire private key from the two public signatures.

Sony learned this the hard way. The PlayStation 3 signed its firmware with ECDSA but used a constant k for every signature. Researchers collected two signed messages, did the algebra, and extracted Sony’s master signing key. That let anyone sign code the console would treat as genuine Sony firmware. The curve was fine; the implementation reused the nonce, and that was game over.

The modern fix is deterministic nonces (RFC 6979), which derive k from the private key and the message hash so it is unique per message and never comes from a weak random source.

Ed25519 as the safe modern default

Ed25519 was designed to make the PlayStation 3 mistake impossible. Its nonce is deterministic by construction, its implementations are constant-time, and it exposes no fragile parameters to get wrong. It is also fast and produces compact 64-byte signatures. For new signing work, it is the recommended default (see the sibling Elliptic Curves).

Hands-on: sign and verify with Ed25519

cd ~/crypto-lab
openssl genpkey -algorithm ed25519 -out signer.pem
openssl pkey -in signer.pem -pubout -out signer.pub.pem

echo -n "deploy artifact sha256:abc123" > release.txt
# Ed25519 signs the message directly (no separate -sha256 digest step)
openssl pkeyutl -sign -inkey signer.pem -rawin -in release.txt -out release.sig

# Verify with the public key
openssl pkeyutl -verify -pubin -inkey signer.pub.pem \
  -rawin -in release.txt -sigfile release.sig

Expected output:

Signature Verified Successfully

Now confirm that tampering breaks verification:

echo -n "deploy artifact sha256:EVIL99" > tampered.txt
openssl pkeyutl -verify -pubin -inkey signer.pub.pem \
  -rawin -in tampered.txt -sigfile release.sig

Expected output:

Signature Verification Failure

One changed byte and verification fails, which is exactly the integrity guarantee you want.

Practical Guidance

1. Default to Ed25519 for new signing. It removes the nonce-handling footgun entirely.
2. If you use ECDSA, ensure the library uses deterministic nonces (RFC 6979) and never a home-grown or reused k.
3. For RSA signatures use PSS padding, not PKCS#1 v1.5, and keys of at least 3072 bits (see the sibling RSA).
4. Sign the content you actually care about, and verify before acting on any signed artifact; never trust an unverified signature.
5. Distribute public verification keys through a trusted channel so an attacker cannot substitute their own key.
6. Protect signing private keys in an HSM or KMS where feasible, and rotate them (see the Key Management group).