Hacker News new | ask | show | jobs
by tedunangst 4302 days ago
The briar patch of OpenSSL is more in the high level protocol code, and not the asm crypto (the perl obfuscation layer makes it fun, but isn't a major source of bugs). I would not want to write a robust asn.1 parser in assembly. Lots of other cruft works around the presence or absence of various #define values in header files. Rewriting in assembly is not going to solve the problem of deciding how big socklen_t is.
1 comments
AlyssaRowan 4302 days ago
Mm, true: the long grass of the libcrypto part pales in comparison to the thorny nightmare that is the rest of it. Thank you to OpenBSD's LibReSSL for beginning to clear away the worst of the bramble (and uncovering the occasional juicy blackberry in the Valhalla rampage process).

There's a crypto library, and then there's a protocol library. And TLS, to put it politely, has lots of hairy bits, and I hope and pray TLS 1.3 makes a positive impact on that, but I'm not yet sure if it will.

If one were developing from scratch (and I am not) I'd wonder if a reasonable approach would be a ridiculously low-level approach for the primitives, but a ridiculously high-level approach for the protocol. I might consider writing the first in assembly, but the second? If it involved an ASN.1 parser? I would prefer to do something else, anything but that! :-) At the very least, if someone did do it, we'd be able to see exactly how. We just might not want to! I would suggest perhaps instead, maybe something involving formal correctness proofs and then converting those to assembly, because miTLS indicates that this can be an enlightening approach, and seL4 proves that it's possible to actually make use of? (For someone else. I think it is outwith my expertise!)

link
tedunangst 4302 days ago
In light of the current discussion, it's hard to make such a clean distinction. Your private key is going to be stored in a file that goes through the PEM and ASN.1 parsers. It's going to hang around for a bit while you sign stuff (using some sweet asm code), but now you need to dispose of it. The object lifetime is often much longer than we'd like even with perfect zeroing, and there are some ways to address that, but it casts a long "shadow" on the call graph, not all of which can be made minimal.

In short: imperfect buffer zeroing probably reduces risk enough that it drops below several other concerns.

link