External-size accounting for the published performance tables

The timing records measure computation, not a network serialization format. The tables therefore take KEM public-key/ciphertext and signature public-key/ signature sizes from the separate external_sizes.csv catalog (394 measured KEM/signature instances), and KEX message/public-key sizes from kex_bandwidth.csv (57 measured instances). These catalogs were reconciled with the frozen submissions' size tables, serialization descriptions and the per-candidate pseudocode.md comparisons; the benchmark API size fields are comparison checks, not the source of the published external-size values.

encoded means the size of the submitted external encoding. For signatures whose size varies, maximum-variable means the submitted encoding's maximum, while nominal-variable means a representative size stated in the frozen specification, not a guarantee for each signature. We use that basis only where the specification supplies a concrete nominal length and the submitted serializer returns variable lengths (Rhyme and Sigurd). Otherwise the submitted encoding's maximum is the conservative available figure (Aigis, Phoenix and Tins). These different bases are visible on the candidate pages; the ordered pages mark nominal values with ≈. Secret-key and shared-secret sizes are not ordering metrics.

Specification versus submitted external encoding

The catalog uses the submitted encoding when a size table describes a different format. The per-candidate analyses provide the source details:

Three other cases matter when reading the table, without changing its external size: Aigis-Sig+, Phoenix and Tins have variable-length signatures represented by their submitted encoding's maxima. The ATLAS signer reports an incorrect output length after writing the specified signature bytes; the catalog counts the encoded signature, not that erroneous returned length. VDOO prints rounded public-key sizes in its specification; the catalog uses exact encoded byte counts.

Key exchange

Protocol-message bytes omit separately delivered public keys. Bandwidth counts both the messages and the required public keys once each. Public keys are transmitted bytes in this KEX model. KEM encapsulation instead assumes the recipient's public key is available and lists its size separately. Certificates, identities supplied out of band and transport framing are excluded. ADKEX and MAMBA-NIKE use only the responder's long-term public key; CreTAKE's KEM/signature combinations use different key lengths on the two sides. These responder-only cases do not authenticate the initiator and are not directly comparable to mutually authenticated exchanges. NIIKE has no separate protocol message, but requires both public keys. Its specification lists 4,030/8,943-byte public keys, whereas the submitted encoding uses 4,160/8,960 bytes; the catalog counts the latter.

AFS-KEX has two accounting differences. Figure 3 sends fresh composite public keys in the first two passes; its protocol-message totals are 3,136/6,080/12,288 bytes. The submitted API instead pre-distributes each composite key alongside its long-term base key and sends only 1,568/2,944/6,016 bytes as protocol messages. Counting the base public keys once, bandwidth is identical under either arrangement: 4,704/9,216/18,560 bytes. The catalog shows the specification's protocol-message totals. Separately, the submitted pass-4 function emits no message but leaves its output-length parameter unchanged. The benchmark initialized that parameter to its buffer capacity, producing phantom traffic; the submitted KAT initializes it to zero. The original raw timing and metadata files remain unchanged.