# Comparing XMSS Parameters (conservative vs subMTU) *Author*. Benedikt Wagner. Thanks to George, Thomas, Justin, Emile, Dmitry for discussion. *Context*. There is a discussion for using more aggressive XMSS parameters that yield signature sizes below MTU. Here, we compare the two proposed parameter sets (conservative vs subMTU). Parameters (as well as the hash function) need to be decided before we can register validator keys. We assume Poseidon over the Koalabear field for the comparison here. Minor changes to the parameter sets would be needed when we switch to a different hash function or a different field. # Resources - [Initial Paper on XMSS for Ethereum Consensus (the "055 paper")](https://eprint.iacr.org/2025/055.pdf) - [Paper that improved encoding efficiency](https://eprint.iacr.org/2025/1332.pdf) - [Another improvement on encoding efficiency](https://eprint.iacr.org/2026/016.pdf) - [Signature Library](https://github.com/leanEthereum/leanSig) - [Sketch of a tighter analysis by Emile (WIP)](https://github.com/TomWambsgans/tight-xmss) # Conservative Parameters - https://github.com/leanEthereum/leanSig/blob/main/src/signature/generalized_xmss/instantiations_aborting.rs ``` FIELD = Koalabear; LOG_LIFETIME = 32; TWEAK_LEN_FE = 2; DIMENSION = 46; BASE = 8; TARGET_SUM = 200; PARAMETER_LEN = 5; MSG_LEN_FE = 9; RAND_LEN_FE = 7; HASH_LEN_FE = 8; CAPACITY = 9; ``` # Sub-MTU Parameters - https://github.com/leanEthereum/leanVM/blob/main/crates/xmss/src/lib.rs ``` FIELD = Koalabear; LOG_LIFETIME = 32; TWEAK_LEN_FE = 2; DIMENSION = 42; // DIFF BASE = 8; TARGET_SUM = 184; // DIFF PARAMETER_LEN = 4; // DIFF MSG_LEN_FE = 8; // DIFF RAND_LEN_FE = 6; // DIFF HASH_LEN_FE = 4; // DIFF CAPACITY = ? ``` # Security - [055 security proof](https://eprint.iacr.org/2025/055.pdf) (in combination with the improvements from [here](https://eprint.iacr.org/2026/016.pdf)): * standard model properties of hash => security of signature scheme * then analyze standard model properties of hash in ROM / QROM * bound has a security loss of `L * v * w * w` wrt UD, and `L * v * w` wrt PRE (see Theorem 1) - Optimistically, we can hope for a tighter proof if we use more contrived properties or a monolithic ROM proof * we would go via non-adaptive security first * the bound would stay the same, but we would get rid of the `L * v * w` loss, just a `w` loss for the UD * then to make it adaptive, we add another reprogramming step of the aborting RO * would maybe require a second salted message hash, or just a new analysis - Code here: https://gist.github.com/b-wagn/9292b5f203e4fbd37c3317f43d982e0c | Parameters | Security (Proven) [classical / quantum] | Security (Optimistic) [classical/quantum] | Signature Size (without path) [KiB] | Size Merkle Path [KiB] | |--------------|-------------------------------------------|---------------------------------------------|---------------------------------------|--------------------------| | Conservative | 134.68 / 64.18 | 136.77 / 66.41 | 1.42 | 0.97 | | Sub-MTU | 78.29 / 12.70 | 119.87 / 54.15 | 0.66 | 0.48 | # Arguments for Sub-MTU Parameters - efficiency: only one packet for a signature, slightly less computation - SPHINCS also ignores some minor security losses (few bits here and there, especially in QROM bound) - that's why NIST PQ does not talk about a *provable* level of bit security, but about security levels - more easy to just use one width of Poseidon (i.e., just Poseidon16, no Poseidon24) # Arguments against Sub-MTU Parameters - we should be conservative about security of a critical part of the protocol - we need a security margin, because: - *main argument:* the hash function is far from an RO! It is a structured hash function. - *less relevant:* we verify pqSNARKs, not signatures. This introduces another (small) security loss from the extractors (see Theorem 2). - even with the tighter ROM/QROM proof: below 128/64 security level ! - this more optimistic proof is not written down (with our optimizations) - 055-proof gives concrete targets for cryptanalysis - unclear if being below MTU really makes networking that much easier - we may need Poseidon24 anyways in other parts of the protocol (e.g., if we have a Merkle tree of public keys to reduce CL state), and if not we could implement the conservative parameters with Poseidon16 (a bit more complex) # More thoughts - if we use Sub-MTU parameters, we have to use the narrative *"estimated security comparable to NIST Level 1"* and not *"provable 128 bit security"* - if we manage to make something like Blake3 work instead of Poseidon, Sub-MTU would be more reasonable