Isn't this the problem, then? People here seem to think you are, and by reading you I get the impression that they're right. I don't believe that you won't write a book because you're not qualified: you just don't want to write one. And that's a good enough reason.
I think the community in general is very harsh towards anything related to cryptography. It's as if you shouldn't bother writing code unless you have mastery of the underlying mathematics while at the same time not bother with the maths unless you're an expert very-low-level-language programmer.
There is certainly a need to put forward blatant errors and potential flaws. But the general harshness is misguided I think. Tptacek, you simply said out loud what many thought, I'm sure. You'd make a lot of people happy if you wrote a book. Because you're still learning doesn't mean others can't learn from you.
Very subtly broken cryptography software is better than no cryptography software. And together we will learn to make it better.
I don't know how to say this other than directly: you're wrong. I shouldn't write a book on how to design cryptosystems, because I'm not qualified to do it, and I'll get things wrong. I can barely write an HN comment on crypto without being corrected by 'pbsd and 'cperciva.
I am an odd duck, even for my odd little field: I'm a software security person who has spent a couple years getting decent at breaking crypto, and (weirdly) few people in my field do that, so I sound like more of an expert than I actually am.
I am an odd duck, even for my odd little field: I'm a software security person who has spent a couple years getting decent at breaking crypto, and (weirdly) few people in my field do that, so I sound like more of an expert than I actually am.
Interesting. When I worked at Entrust, our cryptology team consisted of both cryptographers and cryptanalysts. The former were math PhDs who spent their entire graduate careers designing cryptosystems, so by the time they came to us, they knew what they were about. The latter - well, there was only one when we got started - was a B.Eng. who got interested in crypto at BNR, taught himself the basics, and became one of the top cryptanalysts in the world.
You and he probably have much in common - including not being qualified to design cryptosystems! Like you, he would have said to leave that to the experts.
Then he would have quite happily spent weeks and months figuring out what those experts missed, thereby advancing the field.
It puzzles me to this day that so few in the security field appreciate the difference between the two types of cryptologists.
Maybe I was not clear. I'm not forcing you to write a book, nor saying you absolutely should.
My point is that if people like you, who are definitely more knowledgable than most in this area (most is very important here), communicate their experience, then everyone benefits. If nobody wants to write about crypto because nobody feels qualified, we're at a dead end.
When a person does write content, someone somewhere will tear it apart, for pretty good reasons: getting it right is very difficult, as you say. But that's precisely the point: to learn from our mistakes. We're not dealing with raw science, but real life implementations of theory, and this is where things usually break, as shown by your critique. The value of the book is pedagogical, not necessarily scientific.
If you have anything to say about crypto (and you clearly do), then say it. We're all the better for it! And contributions like the ones you gave here are needed. I just find the general attitude a little tiring, I'm not trying to force you into writing :)
Lastly, the most important thing, to me, is that I, as a chemist, can get on the internet and learn about these concepts from someone who understands them better than I do. Having a discussion about such topics is essential. Your contribution might not be in the deep theorems of academic cryptography, but they sure are appreciated by others like me. So if you ever want to write a book/pamphlet, go ahead, I'll buy it.
I understand. I'm making a distinction you don't care about, between books about designing crypto and books about breaking crypto. We're working on a book (it would be more accurate to say that I am cheerleading Sean and Alex on to write a book). It's just not a book that would teach developers how to build crypto.
You trumpet NaCl's crypto_box and mentioned other language runtimes are deficient in one way or another, but what do you think about security of crypto in the Java standard library?
The JCA provides primitives, not whole designs. Primitives are rarely broken; even PHP mcrypt manages to successfully provide low-level crypto primitives. Most of the things that go wrong in cryptography happen at the points where two primitives join to form a more elaborate construction. The JCA isn't much help there.
If you have the option to use NaCl, use NaCl. A Java-specific alternative to NaCl is Keyczar.
Speaking of Java crypto, I have a question. Is it possible a garbage collector might be dangerous to crypto code? I've seen it mentioned on HN that maybe we should be worried about implementing crypto code in a language with a non-deterministic GC, but sadly I can't find those comments right now.
I'm guessing the concern is that an attacker might somehow discover a way to use the GC to recover sensitive info. It seems like having a GC might cause some other trouble, like making it hard to wipe sensitive data from memory once it's no longer needed: http://books.google.com/books?id=43pcI3in1DcC&pg=PA122&lpg=P...
Since TextSecure is currently believed to be secure and high-quality, then it must be true GCs aren't fundamentally dangerous to crypto code, right? (Or at least that Java's GC on Android isn't dangerous to crypto.) If a GC is dangerous to crypto code, then TextSecure would be vulnerable to those dangers.
Do you happen to know whether cryptographers as of 2014 generally believe GCs are/aren't/might be dangerous to crypto code? Are there any known attack vectors or proofs of concept? (It would be awesome if anyone could point out any whitepapers on the subject.)
I don't buy the argument about GC being a hindrance. If you have sensitive data (e.g. a key) that you don't want sitting around in your process memory, you should wipe it as soon as you are done with it (e.g. zero out the byte array). Just because there is a GC doesn't mean that it's the only way to clean up a resource. String is immutable in both Java and C#, so if you are holding a password in an instance of one it can be difficult to overwrite the backing memory, but this is a separate argument from GC causing problems. This is the problem that SecureString is meant to solve http://msdn.microsoft.com/en-us/library/system.security.secu....
Regarding GC performance, maybe there's an avenue for attack there. You could potentially infer the amount of garbage being generated by an implementation, which seems like it could be variable in a PK implementation. I can't really think of a way to generate variable amounts of garbage without doing variable amounts of computation, so I think you're already leaking timing information. [Actually I can, but not in a way that seems natural].
I think that the concern crypto engineers have with garbage collected runtimes is held in tension by the equal and opposite force of their concern about memory corruption bugs in C. It's a concern, but an inchoate concern.
Typed a whole long comment about the relevant section of Cryptography Engineering, but it seems you already read it :) I'd also be interested in an in-depth study of GC's effect on secret material.
I suspect that constant factor memory usage should go hand in hand with the criticality of constant factor cpu usage.
If a constant time cpu algorithm was not also constant factor memory, then the timing of cache misses (or gc, alike) would certainly be subject to side channel attacks.
If constant factor memory usage is attained, I cannot easily think of a way that a garbage collector could cause an interference that leaks information. (Though by all means, one ought think harder than I have.)
> I reviewed several SSL implementations for coding style: OpenSSL, NSS, GnuTLS, JSSE, Botan, MatrixSSL and PolarSSL. I looked at how buffers are handled in parsers and writers. Of all of them, I think only JSSE, i.e. pure Java, can be trusted to be free of buffer overflows. It suggests that a good webserver for security-critical applications would be Tomcat, without native extensions.
I've been throwing $20 bills at my monitor so that your book will start downloading, but it doesn't seem to be working.
But really, you should write one.