What is the maximum message size when using ECDSA (specifically secp256k1?

Question

I'm guessing that the message must conform to 256 bits but I was not able to find documentation of any message length limits.

Answer 1

The first message-related step of ECDSA (and most signature mechanisms in actual use) is hashing the message, both in signature production and verification. The result of this hash is then truncated to the number of bits in the group size; that's truncated to 256-bit for secp256k1.

Hence what limits the size of the message to be signed is the limit built into the hash, typically due to a fixed-size counter. That limit is usually $2^{64}-1$ bit (e.g. for SHA-256, typically used for secp256k1) or more (e.g. $2^{128}-1$ bit for SHA-512 or SHA-512/256, which would be usable as a substitute for SHA-256 with secp256k1).

$2^{64}-1$ bit is just shy of 2 exbibyte and >2.3 exabyte (several days worth of the current mobile traffic worldwide per this source). This is not a practical issue with usual hashes, which are sequential: hashing that at a rate of $10^9$ blocks of 512-bit per second (much more than anything a single sequential device currently achieves) would require more than a year. For hashing real large messages, we need a parallelizable hash, typically a hash tree. It would also be a good idea to sign subtrees of manageable size, to avoid storing exabytes of data only to find afterwards that it does not check.

---

Some APIs to ECDSA expect the hash to be done externally, and typically start at the truncation step. Technically, they do not fully implement ECDSA. For secp256k1, such API would probably process the low-order 256-bit of their pre-hashed message input. For signature production at least, it is important (prudent and perhaps essential) to only allow a hash (PRF secure in the ROM) to be fed there, as it is necessary for conformance, is an assumption in ECSDA security proofs/arguments, and doing otherwise at least allows existential forgery (perhaps worse).

^{Further, some APIs to ECDSA signature production take as input the random they use to sign (or the generator they use to generate that). It is then essential to only allow that input to be (or yield, for a generator) a random secret exclusively used for that purpose and a single signature; doing otherwise would jeopardize the confidentiality of the private key.}

Answer 2

According to FIPS 186-5, the hash tag is truncated to the bit length of the group order, len(n). For secp256k1, this is 256 bits. This is relevant, say, when using NONEwithECDSA in Java.