[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <df34c8da-9514-4f55-ae41-45e1a6bffe94@gmail.com>
Date: Mon, 20 Oct 2025 22:21:15 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com, Billy Brumley <bbb@....fi>
Subject: Re: BoringSSL private key loading is not constant time
On 10/18/25 02:47, Billy Brumley wrote:
> Howdy Folks,
>
> A lot of questions piled up directed at David Benjamin. I was
> patiently waiting for on-list responses, but I'm not seeing any, so
> I'll jump in.
There have been no on-list responses because the discussion has been
driven off-list.
>> Applications could emit warnings when loading such keys
>
> They could certainly do that, Hanno. I know you're aware of this but
> just for general knowledge, there's Vaudenay's seminal work on padding
> oracle attacks
>
> https://en.wikipedia.org/wiki/Padding_oracle_attack
>
> Not that that maps directly here -- I'm just pointing out, even the
> act of emitting a warning / error can be leaky, too and cause -- in
> general -- security issues.
I have been informed that there are two major problems here:
(1) Invoking write(2) will greatly amplify the timing side channel.
(2) Many (most?) applications using BoringSSL run in environments
where stderr is effectively (or even directly) sent to /dev/null.
> [...]
>
>> Does the file size of the private key file also leak this information?
>
> At first glance it might seem so, Jacob. But the ECPrivateKey OID
> encoding format contains lots of optional fields, and you don't know
> if those fields are present until you decode it :shrug:
>
> So when you see varying file sizes with these keys, it could be for
> many different reasons, unfortunately.
The side channel is most likely to leak that the top octet of the
private key is zero. It does so by making the file *shorter*.
Do any of the optional fields contribute, in total, an odd length to the
file? If none of the optional fields are used, does the incorrect
encoding still leak by reducing the minimal size of the private key file?
>> This appears to be a misunderstanding of the ECPrivateKey format
>
> No, David, there is no misunderstanding at all. We studied tons of
> different formats and wrote about it in 2019 (but you know that, already)
>
> https://www.usenix.org/conference/usenixsecurity20/presentation/garcia
>
> We even discussed with the BoringSSL security team in 2019, and you
> dismissed us. If you would've taken the time to read the paper and
> understand our contribution to the security community, you'd know that.
>
>> The issue is that “randme.py” calls the Python hex() function on an
> integer
>
> No, David, rofl.
>
> ROFL.
>
> For those still reading, this would be like when you submit a PoC
> exploit for an OOB write vulnerability, and you'd get a response like
>
> "The issue is in your harness, you're sending unexpected inputs"
>
> NO THAT'S NOT AN ISSUE OR BUG, IT'S THE WHOLE GOSH DARN EXPLOIT
>
> But ofc David knows it, he knows I'm encoding the keys deliberately
> like that, he's just trolling me on-list, and spreading misinformation
> in public in an attempt to wipe the egg from his face.
>
> Still waiting for the "sorry, we screwed up, we'll fix it" from
> BoringSSL.
>
> David, mea culpa is free, you can stop digging the hole any time you want.
These personal attacks are the reason that most of the discussion for
this issue has been driven from the list.
Please take a few steps back, look in a mirror, and ask yourself if
these attacks have really been helpful.
-- Jacob
Content of type "text/html" skipped
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.
