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
