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.
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_attackNot 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.
Newer versions of OpenSSL silently modify these keys at runtime, but ofc that is not persisted
$ cat priv_128_0.pem -----BEGIN PRIVATE KEY----- MC4CAQAwEAYHKoZIzj0CAQYFK4EEACIEFzAVAgEBBBCneCRP4EljgOADB0hiscbz -----END PRIVATE KEY----- $ openssl pkey -in priv_128_0.pem -----BEGIN PRIVATE KEY----- ME4CAQAwEAYHKoZIzj0CAQYFK4EEACIENzA1AgEBBDAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAKd4JE/gSWOA4AMHSGKxxvM= -----END PRIVATE KEY-----For the young eager security researchers on the list, if you want to find some non-constant-time code to point at for your paper: script "git bisect" on the above openssl command, and it'll lead you to an OpenSSL commit where that's happening. (And my gut tells me it's very likely that correction is not constant time in the traditional model.)
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.
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/garciaWe 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 EXPLOITBut 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. Cheers, BBB -- Dr. Billy B. Brumley, D.Sc. (Tech.) Director of Research, 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/[email protected] S/MIME public key: https://people.rit.edu/bbbics/[email protected] https://www.rit.edu/directory/bbbics-billy-brumley https://www.rit.edu/cybersecurity/
smime.p7s
Description: S/MIME Cryptographic Signature
