Daniel Bleichenbacher is one of the most famous living cryptanalysts. He's famous for a number of attacks on public-key cryptosystems like RSA and ECSDA, and published one of the very first error oracle attacks. Many attacks on SSL/TLS trace, intellectually, back to him. Crypto nerds tend to be surprised to learn that he's been working at Google for years now.
Thai Duong is part of the teams that discovered the TLS BEAST attack, the CRIME attack, and the POODLE attack, in addition to a bunch of other crypto attacks on software (for instance, he and his partner-in-crime Juliano Rizzo discovered the CBC padding oracle attack on .NET, and the SHA length extension attack on the Flickr API).
The most important thing about this work is the crypto knowledge encoded into the unit tests. Relative to the effort it takes to come up with these test cases, it's comparatively easy to port them to other languages.
It's worth reading through the source code on this project just for the comments. For instance: there was apparently a bignum primality flaw in Gnu Crypto that broke SRP --- which I learned only from a comment in the bignum test cases.
This is fascinating (to a non-crypto nerd such as myself). It would be nice to collect some code that will fail all the unit tests to study why I think as well as reading the commentary. Also if theres a way to use this to audit legacy Java apps that would be fun as well.
yeah - I try to encourage/force coworkers to remember that while `git blame` is a fantastic and useful thing, it only tells you what, not why.
It's the whys that cause the most head-scratching later, the whats are usually pretty straightforward (if not, it probably wouldn't make it through code review).
TBF, that large comment precedes 150 lines of arbitrary hex strings without even a variable name to tell them apart. I'm normally someone who prefers the code to speak to itself, rather than have a large prose comment - but if I came across that in a code review without an accompanying fifteen line comment I'd probably flag it as needing some explanation.
Of course! Code should be concise without being cleverly brief, and it should be clear with its intentions. I write software for business though that references back to requirements. In my case, I'm not explaining a bunch of odd values that look arbitrary. I'm indicating a reason for writing something the manner I'm which I wrote, so if it needs to be modified, they're not opening 5 tabs or searching through pages of documents to make sure things are still compatible. Or worse, modifying without caring and updating the test to assertNotNull(obj).
Incidentally: since there are similar concerns for most of the AE cipher constructions, not just EAX and GCM, I wonder if the EAX test suite here is an indication that Google uses a lot of EAX.
Request for crypto review: We've been working on an explainer series for how to build end-to-end encrypted P2P social networks. It was very hard for me to figure out /conceptually/ what pieces needed to go where and fit with others, so we made this series ( http://gun.js.org/explainers/data/security.html ) on how to use Public/Private key pairs, PBKDF2, Proof of Work, AES, and Digital Signatures. Anybody up for reviewing it and telling me if this is the right combo/structure?
Ah good old Wycheproof. They used have a race called the King of the Mount were racers would struggle up the "mountain" carrying a 63kg bag of wheat. They had to shut it down because after the race everybody would get blotto and trash the town, that and insurance costs I believe.
This is a fascinating project. The hardest part of writing crypto software will always be avoiding the little mistakes, and every time we can bottle the understanding needed to detect some of them, we free cognitive labor for finding others. This is a necessary part of the future of crypto development. I tip my hat to the Wycheproof team!
On a related note: how prevalent is Java among the security folk?
Most of the crypto algorithms I've read are done in C. As a person that wants to try rolling my own crypto, I just don't see myself writing it in Java.
Not an expert, but I'm pretty sure that the first rule of crypto is that you should not roll your own, at least not in a place of any actual importance.
Crypto for Java programs tends to be written in Java. Not always: you see OpenSSL used underneath Tomcat via APR for example, but certainly very often the crypto is coded in Java.
21 comments
[ 5.4 ms ] story [ 53.9 ms ] threadDaniel Bleichenbacher is one of the most famous living cryptanalysts. He's famous for a number of attacks on public-key cryptosystems like RSA and ECSDA, and published one of the very first error oracle attacks. Many attacks on SSL/TLS trace, intellectually, back to him. Crypto nerds tend to be surprised to learn that he's been working at Google for years now.
Thai Duong is part of the teams that discovered the TLS BEAST attack, the CRIME attack, and the POODLE attack, in addition to a bunch of other crypto attacks on software (for instance, he and his partner-in-crime Juliano Rizzo discovered the CBC padding oracle attack on .NET, and the SHA length extension attack on the Flickr API).
The most important thing about this work is the crypto knowledge encoded into the unit tests. Relative to the effort it takes to come up with these test cases, it's comparatively easy to port them to other languages.
It's worth reading through the source code on this project just for the comments. For instance: there was apparently a bignum primality flaw in Gnu Crypto that broke SRP --- which I learned only from a comment in the bignum test cases.
I agree, the negative test cases would be good to see.
I wish more people saw comments (and by extension, commit messages) in this same light. Fan-freakin'-tastic.
It's the whys that cause the most head-scratching later, the whats are usually pretty straightforward (if not, it probably wouldn't make it through code review).
// Signatures with special case values for r and s (such as 0 and 1). // Such values often uncover implementation errors.
I liked the diss on GCM in the GCM test suite.
Generally this sounds like a great effort to harden important software.
On a related note: how prevalent is Java among the security folk?
Most of the crypto algorithms I've read are done in C. As a person that wants to try rolling my own crypto, I just don't see myself writing it in Java.