Hacker News Reader

Comment by api | Hacker News Reader

"demonstrably safe" -- this is another issue I have with this crypto conservative FUD.

"Use SSL, don't roll your own!"

Then we get BEAST, CRIME, Heartbleed, etc., and we discover that the dominant SSL/TLS implementation is a rat's nest of comically awful code:

http://opensslrampage.org

Look at the older posts for LuLz like: http://opensslrampage.org/post/83007010531/well-even-if-time...

I wonder just how much scrutiny IPSec implementations have gotten, especially since it's such a usability nightmare that nobody uses it.

View on HN

indeed. at the risk of entering tinfoil hat land, note the following http://blog.cryptographyengineering.com/2014/12/on-new-snowd... ..although also the not 100% reassuring https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-...

What about other libraries? GnuTLS, NSS, PolarSSL, wolfSSL?

What about them? Would you recommend one of them over the others?

Yes, any of them is better than rolling your own.

Even if they have bugs (it is unlikely they don't), they'll still have less bugs than own implementation.

If you are still not convinced, at least give user option what to use.

curl[1] is a good example of giving freedom to the user.

[1] http://curl.haxx.se/docs/ssl-compared.html

Thanks @takeda.

Are you aware that we did not roll our own crypto? Instead we used the NaCl crypto libs[1]. Weave adds about 300 LOC to integrate NaCl.

You can read about it here - http://docs.weave.works/weave/latest_release/how-it-works.ht... You can also read a bit about weave crypto in the comments from mradestock and msackman elsewhere on this page.

I would be extremely grateful if you could provide actionable advice (or help) on which other crypto libraries could fit our requirements for weave. Please note that in addition to functional requirements, any library must be open source, hard to misuse, easy to package, and demonstrably safe.

alexis

[1] http://nacl.cr.yp.to/

Reply on news.ycombinator.com