9 ms·

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 J

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 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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...

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 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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...