Wycheproof – Tests that check cryptographic software for known weaknesses | Hacker News Reader

Wycheproof – Tests that check cryptographic software for known weaknesses

security.googleblog.com

226 pointsrincebrain21 comments

For anyone who isn't a crypto nerd:

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.

Some of these are in the cryptopals challenges, at http://cryptopals.com/.

I agree, the negative test cases would be good to see.

They did an amazing job at commenting the code. Example: https://github.com/google/wycheproof/blob/master/java/com/go...

And when I comment code like this, I'm being needlessly verbose such that my time could be better spend doing something else.

I wish more people saw comments (and by extension, commit messages) in this same light. Fan-freakin'-tastic.

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).

You have one comment for them. I think this is enough, unless you have no idea about what they're doing.

// Signatures with special case values for r and s (such as 0 and 1). // Such values often uncover implementation errors.

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.

And the train line running up the middle of the main street.

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!

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.

I liked the diss on GCM in the GCM test suite.

It would be awesome if they port this to c/c++.

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.

Too bad there aren't good standards in C++ for security APIs and architectures unlike Java.

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.

Unfortunately a bunch of stuff uses java. Like Android.

So this would be something one could throw the arq backups at? I find very little about whether those are actually secure.

Generally this sounds like a great effort to harden important software.

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?

Don't post things like this in a largely unrelated thread. Put up an Ask HN instead.

Reply on news.ycombinator.com