On 10/14/25 12:08, David Benjamin wrote:
[...]
With respect to the constant-time model, that import process indeed
leaks the byte length of the privateKey field, but this is actually
unavoidable. The encoding itself already leaked the length. The byte
strings themselves weren’t the same size and the constant-time model
assumes the trace of memory accesses (often visible to cache-timing
attacks) is leaked. That means merely constructing a buffer to pass
into the library leaks the length of the buffer.
This means private key formats must have secret-independent lengths.
The privateKey field, by spec, achieves this, but these malformed,
truncated privateKey fields do not. If one passes a truncated
privateKey field to any decoder, leaking the byte length is
unavoidable. Rather, it is up to the encoder to follow the spec, which
will give a fixed-width, secret-independent byte length that can be
safely leaked.
Does the file size of the private key file also leak this information?
The inputs in the test harness use this leaky, truncated encoding. One
can see this in how the test cases have different sizes. The issue is
that “randme.py” calls the Python hex() function on an integer, which
returns the minimal hex encoding. Something like theint.to_bytes(48,
"big").hex() would have constructed the correct, fixed-width private
key representation for P-384.
Ideally, decoders would all reject these invalid inputs, so it would
be immediately apparent when encoders get this wrong, but the
environment of existing private keys makes doing so a compatibility risk.
Perhaps a warning that limited information about the private key has
unavoidably been leaked and the key should be rotated should be emitted
upon loading such an improperly-encoded key? (The warning could include
a URL for a page with a longer explanation of the issue.)
-- Jacob
