Re: BoringSSL private key loading is not constant time

[Jacob Bachmeyer <jcb62281 () gmail com>]

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