6 ms·

If I had written a book on implementing cryptography I've been throwing $20 bills at my monitor so that your book will start downloading, but it doesn't seem t

If I had written a book on implementing cryptography 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.

tptacek 13y ago
No, I'm not even close to qualified to write that book.
- yukichan 13y ago
  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?
  - tptacek 13y ago
    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.
    - sillysaurus3 13y ago
      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. TextSecure's crypto is implemented in Java, which is of course garbage collected. Some cursory Googling suggests that Java's GC will suspend the main execution thread during each GC op: http://javabook.compuware.com/content/memory/reduce-garbage-collection-pause-time.aspx http://javabook.compuware.com/content/memory/reduce-garbage-... 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=PA122&source=bl&ots=wXzpiGWeB9&sig=sEwidDoCFSP09CYMZw1MvMg_shk&hl=en&sa=X&ei=KahOU-bgItakyAS5w4GwCQ&ved=0CEgQ6AEwBQ#v=onepage&q&f=false 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.)
      - tptacek 13y ago
        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.
      - swordswinger12 13y ago
        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.
      - xenophonf 13y ago
        "Some cursory Googling suggests that Java's GC will suspend the main execution thread during each GC op" The (non-default) CMS and G1 GCs will do as much as they can in background threads before they have to stop the world. For more information see http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html http://www.oracle.com/webfolder/technetwork/tutorials/obe/ja... and http://www.cubrid.org/blog/dev-platform/understanding-java-garbage-collection/ http://www.cubrid.org/blog/dev-platform/understanding-java-g.... I only know about this because I kept encountering long, GC-related pauses on my Minecraft server that went away when I switched to the concurrent mark-sweep collector. :)
      - bdamm 13y ago
        In my opinion having sensitive keys in Java, or pretty much any software stack, is not the correct way to go. We should turn to hardware solutions for access to raw keys. Let the software stacks do what they do well, which is accelerate users and engineers.
      - bmm6o 13y ago
        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.securestring%28v=vs.110%29.aspx 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].
  - higherpurpose 13y ago
    This might help: > 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. http://tstarling.com/blog/2014/04/ssl-implementations-compared/ http://tstarling.com/blog/2014/04/ssl-implementations-compar...
- chm 13y ago
  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.
  - tptacek 13y ago
    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.
    - chm 13y ago
      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.

tptacek 13y ago

No, I'm not even close to qualified to write that book.

yukichan 13y ago
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?
- tptacek 13y ago
  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.
  - sillysaurus3 13y ago
    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. TextSecure's crypto is implemented in Java, which is of course garbage collected. Some cursory Googling suggests that Java's GC will suspend the main execution thread during each GC op: http://javabook.compuware.com/content/memory/reduce-garbage-collection-pause-time.aspx http://javabook.compuware.com/content/memory/reduce-garbage-... 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=PA122&source=bl&ots=wXzpiGWeB9&sig=sEwidDoCFSP09CYMZw1MvMg_shk&hl=en&sa=X&ei=KahOU-bgItakyAS5w4GwCQ&ved=0CEgQ6AEwBQ#v=onepage&q&f=false 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.)
    - tptacek 13y ago
      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.
    - swordswinger12 13y ago
      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.
    - xenophonf 13y ago
      "Some cursory Googling suggests that Java's GC will suspend the main execution thread during each GC op" The (non-default) CMS and G1 GCs will do as much as they can in background threads before they have to stop the world. For more information see http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html http://www.oracle.com/webfolder/technetwork/tutorials/obe/ja... and http://www.cubrid.org/blog/dev-platform/understanding-java-garbage-collection/ http://www.cubrid.org/blog/dev-platform/understanding-java-g.... I only know about this because I kept encountering long, GC-related pauses on my Minecraft server that went away when I switched to the concurrent mark-sweep collector. :)
    - bdamm 13y ago
      In my opinion having sensitive keys in Java, or pretty much any software stack, is not the correct way to go. We should turn to hardware solutions for access to raw keys. Let the software stacks do what they do well, which is accelerate users and engineers.
    - bmm6o 13y ago
      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.securestring%28v=vs.110%29.aspx 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].
- higherpurpose 13y ago
  This might help: > 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. http://tstarling.com/blog/2014/04/ssl-implementations-compared/ http://tstarling.com/blog/2014/04/ssl-implementations-compar...
chm 13y ago
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.
- tptacek 13y ago
  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.
  - chm 13y ago
    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.