3 ms·

While I don't believe Atwood should have anything to do with educating developers about how to build crypto, the fact is that the available libraries are remark

While I don't believe Atwood should have anything to do with educating developers about how to build crypto, the fact is that the available libraries are remarkably poor, and as a developer I've been placed in the unfortunate position of "building crypto", with my OpenSSL reference and Applied Cryptography in-hand. Until we developers have books that better elucidate the pitfalls of implementation, or better libraries that avoid the pitfalls on our behalf, we'll be stuck "building crypto", somewhat blindly. I've seen you recommend GPGME previously. It's practice of executing the GPG command line tool is just not workable in many implementation environments. In my most recent use-case (several years ago), if there had been a decent portable, liberally licensed stream-supporting implementation of CMS (RFC3852), I would have gladly, readily used it.

tptacek 17y ago
What did you implement crypto for? Can I see it?
brl 17y ago
> Until we developers have books that better elucidate the pitfalls of implementation, or better libraries that avoid the pitfalls on our behalf, we'll be stuck "building crypto", somewhat blindly. There are a lot of really good books about cryptography now. This book is the best one that I've seen for coverage of the pitfalls of implementation. http://www.amazon.com/Modern-Cryptography-Practice-Hewlett-Packard-Professional/dp/0130669431/ http://www.amazon.com/Modern-Cryptography-Practice-Hewlett-P... > I've seen you recommend GPGME previously. I missed the context in which tptacek was recommending GPGME, but if your problem is something other than authenticating downloaded packages or signing and encrypting email, designing with GPG as a 'primitive' is probably not such a great idea. I have seen some attempts to repurpose GPG into new applications and every time these protocols have been badly flawed because the authors don't even realize that they are inventing a brand new protocol.
- tptacek 17y ago
  I haven't recommended GPGME, but one of my standard recommendations is, "TLS in motion, GPG at rest". A lot of common problems devolve to "encrypted signed blob" and "encrypted mail". I agree with you that building a protocol based on GPG is a bad idea. Building a crypto protocol of any sort is a bad idea.

tptacek 17y ago

What did you implement crypto for? Can I see it?

brl 17y ago

> Until we developers have books that better elucidate the pitfalls of implementation, or better libraries that avoid the pitfalls on our behalf, we'll be stuck "building crypto", somewhat blindly. There are a lot of really good books about cryptography now. This book is the best one that I've seen for coverage of the pitfalls of implementation. http://www.amazon.com/Modern-Cryptography-Practice-Hewlett-Packard-Professional/dp/0130669431/ http://www.amazon.com/Modern-Cryptography-Practice-Hewlett-P... > I've seen you recommend GPGME previously. I missed the context in which tptacek was recommending GPGME, but if your problem is something other than authenticating downloaded packages or signing and encrypting email, designing with GPG as a 'primitive' is probably not such a great idea. I have seen some attempts to repurpose GPG into new applications and every time these protocols have been badly flawed because the authors don't even realize that they are inventing a brand new protocol.

tptacek 17y ago
I haven't recommended GPGME, but one of my standard recommendations is, "TLS in motion, GPG at rest". A lot of common problems devolve to "encrypted signed blob" and "encrypted mail". I agree with you that building a protocol based on GPG is a bad idea. Building a crypto protocol of any sort is a bad idea.