[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5948a82-c85b-443c-9adb-9d6985359828@gmail.com>
Date: Tue, 14 Oct 2025 19:51:06 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com, David Benjamin <davidben@...gle.com>
Subject: Re: BoringSSL private key loading is not constant time
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
