A byte-level comparison of RSA, elliptic-curve, pairing-based and post-quantum signatures shows when recurring signature traffic overtakes key provisioning and storage.

When a protocol team asks how much space a signing algorithm needs, three different quantities often collapse into one answer: public-key size, private-key size and signature size. They do not scale together. RSA has large key material and a signature exactly as wide as its modulus. Ed25519 has a 32-byte public key and a 64-byte signature. ML-DSA signatures are larger than its already substantial public keys. SLH-DSA reverses the visual intuition entirely: its keys are tiny and its signatures occupy thousands or tens of thousands of bytes.

The distinction changes engineering decisions. Public keys may be installed once during enrollment, cached for months or carried in every certificate chain. Private keys may never leave a secure element. Signatures may cross a radio link many times each day. A useful comparison must keep those paths separate.

What the matrix measures

The tables below compare binary cryptographic objects, not complete certificates or protocol messages. The following assumptions make every number reproducible:

1. No X.509, SubjectPublicKeyInfo, PKCS #8, CMS, COSE, CBOR, ASN.1 DER, PEM or Base64 wrapper is included.
2. No algorithm identifier, message, hash, certificate chain, transport header or length prefix is included.
3. RSA uses a two-prime key, a modulus of exactly 2,048 or 4,096 bits and public exponent 65,537. The public column is fixed-width n || e. The private column is the fixed-width CRT tuple n || e || d || p || q || dP || dQ || qInv. These are accounting records, not interoperable encodings. An actual DER object varies because INTEGER values can require sign padding.
4. ECDSA P-256 uses a compressed SEC 1 point, a 32-byte scalar and a fixed-width r || s signature. An uncompressed public point is 65 bytes. A DER ECDSA signature is variable-length and is deliberately excluded.
5. Ed25519 uses the raw 32-byte seed, 32-byte public key and 64-byte signature defined by RFC 8032. APIs that store the expanded secret or concatenate seed and public key will report 64 bytes instead of 32 for private storage.
6. BLS12-381 uses compressed group elements. Both standardized draft variants are shown because moving the public key from G1 to G2 exchanges 48 bytes for 96 bytes and reverses the signature size. The secret scalar is represented in 32 bytes.
7. ML-DSA and SLH-DSA use the exact byte strings specified by FIPS 204 and FIPS 205.
8. Falcon uses the Round 3 submission’s serialized keys and fixed padded signature format. Those rows are measurements of Falcon, not final FN-DSA wire commitments.

This is not a table of equivalent security strengths. RSA-2048, P-256, BLS12-381 and the NIST post-quantum categories do not express security with the same model. The table answers a spatial question after a security policy has selected acceptable candidates.

Classical, Edwards and pairing-based objects

Scheme and representation	Family	Public key (bytes)	Private key (bytes)	Signature (bytes)	Signature / public key
RSA-2048, fixed fields	Integer factorization	259	1,155	256	0.99
RSA-4096, fixed fields	Integer factorization	515	2,307	512	0.99
ECDSA P-256, compressed point, raw signature	Elliptic curve	33	32	64	1.94
Ed25519, RFC 8032 raw objects	Edwards curve	32	32	64	2.00
BLS12-381, minimal public key	Pairing-friendly curve	48	32	96	2.00
BLS12-381, minimal signature	Pairing-friendly curve	96	32	48	0.50

RFC 8017 makes the central RSA relationship exact: an RSA signature is an octet string with the length of the modulus. Changing the hash or choosing PSS instead of PKCS #1 v1.5 does not turn a 2,048-bit RSA signature into a smaller object. It remains 256 bytes. The apparent 259-byte public-key entry is only the 256-byte modulus plus the assumed three-byte exponent. A deployable ASN.1 structure needs tags and lengths as well.

For P-256, the signature contains two values modulo the group order. Fixed-width transport gives each value 32 bytes. DER instead encodes two signed INTEGER values, so length changes with their high bits and leading zeroes. A system with fixed records should not budget from one observed DER sample. It should choose a canonical fixed-width format where its protocol permits one or reserve for the DER maximum required by that profile.

Ed25519 removes this variance. RFC 8032 defines a 32-octet public key and forms a signature from two 32-octet halves. This predictability is operationally valuable even when the difference between 64 and 70 bytes is not.

BLS12-381 exposes a different trade. The current CFRG BLS draft defines a minimal-public-key variant with a 48-byte public key and 96-byte signature, and a minimal-signature variant with a 96-byte public key and 48-byte signature. Aggregation can hold the signature size constant across multiple signers or messages under the scheme’s verification rules. Part 2 treats that behavior separately. BLS12-381 is still elliptic-curve cryptography and is not post-quantum.

Standardized post-quantum objects

Scheme	Security category	Public key (bytes)	Private key (bytes)	Signature (bytes)	Signature / public key
ML-DSA-44	2	1,312	2,560	2,420	1.84
ML-DSA-65	3	1,952	4,032	3,309	1.70
ML-DSA-87	5	2,592	4,896	4,627	1.79
SLH-DSA-128s, SHA2 or SHAKE	1	32	64	7,856	245.50
SLH-DSA-128f, SHA2 or SHAKE	1	32	64	17,088	534.00
SLH-DSA-192s, SHA2 or SHAKE	3	48	96	16,224	338.00
SLH-DSA-192f, SHA2 or SHAKE	3	48	96	35,664	743.00
SLH-DSA-256s, SHA2 or SHAKE	5	64	128	29,792	465.50
SLH-DSA-256f, SHA2 or SHAKE	5	64	128	49,856	779.00

FIPS 204 defines all three ML-DSA sizes as fixed byte strings. It also notes that an implementation may retain only the 32-byte seed and regenerate a private key. That optimization changes at-rest storage and load time, but it does not change the standardized private-key object shown here. It must therefore be documented as an implementation strategy, not silently substituted into a protocol matrix.

FIPS 205 makes the opposite storage trade. An SLH-DSA public key contains two n-byte values and its private key contains four. The signature carries the randomizer, a FORS signature and a hypertree authentication structure. The public key can be 32 bytes while the smallest approved signature is 7,856 bytes. Selecting the f profile for faster signing increases the category 1 signature to 17,088 bytes.

Those numbers invalidate the shorthand that post-quantum migration simply makes keys larger. ML-DSA enlarges both public keys and signatures. SLH-DSA keeps keys compact but moves the burden decisively into every signed object.

Falcon is a candidate row, not a finalized FN-DSA row

Submission format	Public key (bytes)	Private key (bytes)	Fixed padded signature (bytes)	Signature / public key
Falcon-512	897	1,281	666	0.74
Falcon-1024	1,793	2,305	1,280	0.71

The Falcon submission specification fixes public keys at 897 and 1,793 bytes and padded signatures at 666 and 1,280 bytes. The project’s reference API fixes the corresponding serialized private keys at 1,281 and 2,305 bytes.

NIST selected Falcon for a future standard named FN-DSA, but a selected algorithm and a final wire format are not the same artifact. At this article’s 10 September 2026 cutoff, the latest located public reply from a NIST author, dated 13 April 2026 in the NIST PQC forum status thread, said that the FIPS 206 initial public draft had no concrete release date. Protocol designers can test Falcon-sized envelopes. They should version the encoding and avoid treating these byte counts as immutable FN-DSA constants.

The transport crossover

Let P be public-key bytes, S signature bytes and N the number of signatures transported after one public-key delivery. Ignoring other fields, total cryptographic transport is:

T(N) = P + N × S

Signature traffic exceeds the one-time public-key traffic when N × S > P. The first whole-number crossover is floor(P / S) + 1.

Scheme	First N where signatures exceed one key	Signature share when key and one signature travel together
RSA-2048	2	49.7%
ECDSA P-256	1	66.0%
Ed25519	1	66.7%
BLS12-381, minimal public key	1	66.7%
BLS12-381, minimal signature	3	33.3%
ML-DSA-44	1	64.8%
Falcon-512 submission	2	42.6%
SLH-DSA-128s	1	99.6%

This small calculation identifies three deployment regimes.

First, a provision-once system should optimize recurring signatures. Its public key may live in a verifier registry, certificate cache or device manifest. Ed25519 then costs 64 bytes per assertion, ML-DSA-44 costs 2,420 and SLH-DSA-128s costs 7,856 before framing.

Second, a self-contained object that carries its public key every time should optimize P + S. BLS variant choice matters here. Minimal-public-key BLS produces a 144-byte pair, exactly the same total as minimal-signature BLS, although their behavior differs when many keys or signatures are present.

Third, a frequently rotated or ephemeral-key design must amortize provisioning over the rotation interval K. Public-key cost per signed item becomes P / K. Once K grows beyond P / S, signature bytes dominate. For almost every row in this matrix that happens immediately or after the second signed item.

What is not in this comparison

The requested framing mentioned signatures based on lattices and isogenies. None of the listed schemes is isogeny-based. RSA relies on integer factorization. ECDSA, Ed25519 and BLS use elliptic curves, with BLS adding pairings. ML-DSA and Falcon use lattices. SLH-DSA uses hash-based trees. Adding an “isogeny” label to this matrix would create a category with no matching row and would misstate the algorithms actually evaluated.

The practical conclusion is narrower and more useful. Key length does not predict signature length. Storage pressure does not predict radio pressure. A protocol budget should record public key, private key and signature as separate fields, name the exact encoding for each, and state how often each field crosses the constrained boundary. Only then does an algorithm comparison describe the system that will be deployed.

Context and scope

This analysis abstracts a field evaluation of cryptographic object sizes. The commissioning organisation, product identifiers and deployment details are omitted. Every byte count is tied to the named native encoding; it is not presented as a measurement from an undisclosed production system.

References

1. RFC 8017: PKCS #1 v2.2
2. NIST FIPS 186-5: Digital Signature Standard
3. RFC 5480: Elliptic Curve Cryptography Subject Public Key Information
4. RFC 5915: Elliptic Curve Private Key Structure
5. RFC 8032: EdDSA, Ed25519 and Ed448
6. CFRG Internet-Draft: BLS Signatures, revision 07
7. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
8. NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
9. Falcon specification, version 1.2
10. Falcon reference implementation API
11. NIST PQC Forum: FIPS 206 status update