[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8673595-762e-f05b-884c-ae4123239775@iki.fi>
Date: Tue, 14 Oct 2025 16:33:04 -0400 (EDT)
From: Billy Brumley <bbb@....fi>
To: oss-security@...ts.openwall.com
Subject: Re: BoringSSL private key loading is not constant
time
Before I start, I've been a member of this list since c. 2010 when I was a
PhD student.
Unfortunately David Benjamin is not being genuine in his reply, and is
playing the cat-and-mouse misinformation game.
And extra bonus, being super rude to up-and-coming security professionals
is the modus operandi for Google security engineers. (Not me, I have thick
skin. But for all the gen avo kids out there.)
Because a student (and I) reported this issue in 2019 to his company
Digging the 2019 reply then:
"""
In order to avoid cross-thread synchronization overhead later, we cache
the public part of the key at load time as you've noted. The second
recomputation is inefficient and due to the way that the code is
structured. We haven't optimised it away as key-loading is typically not a
hot spot.
We intend that operations on the private key be constant time with the
usual definition. (I.e. the trace of instructions executed and memory
locations accessed does not depend on the contents of the secret.) We
don't aim to defend against physical side-channel analysis.
On those grounds, doing extra private-key operations is not a security
concern because, if we're not leaking any information, two times nothing
is still nothing. If you find that our implementation isn't constant-time,
we would consider that to be a security concern. """
I'm sure those of you listening closely, and that are capable of critical
thinking, understand the statement
"If you find that our implementation isn't constant-time, we would
consider that to be a security concern"
directly conflicts with what David said.
There's some transparancy for you.
A hint to Google security folks: the correct reply, at this stage, is
"Sorry about that. We screwed up, we understand, you're right, you've
dedicated your life to this and we're just humble engineers. Thanks so
much for donating your time and a shit-ton of European tax-payer money to
a $350b company. We'll fix it."
Cheers,
BBB
--
Dr. Billy B. Brumley, D.Sc. (Tech.)
Research Director, ESL Global Cybersecurity Institute (GCI)
Kevin O'Sullivan Endowed Professor, Department of Cybersecurity (CSEC)
Director, Platform Security Laboratory (PLATSEC)
Rochester Institute of Technology
Cybersecurity Hall 70-1770
100 Lomb Memorial Drive
Rochester, NY, 14623-5608, USA
S/MIME public key: https://people.rit.edu/bbbics/bbbics@rit.edu.crt
S/MIME public key: https://people.rit.edu/bbbics/bbb@iki.fi.crt
https://www.rit.edu/directory/bbbics-billy-brumley
https://www.rit.edu/cybersecurity/
Download attachment "smime.p7s" of type "application/pkcs7-signature" (1537 bytes)
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.
