"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:
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.
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.
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
If they did it competently, there is no reason they couldn't implement their own crypto encapsulation.
As far as why they rolled their own... have you ever actually tried to use IPSec? It's a usability nightmare. It's also problematic in containers due to container permission issues. I suppose they could have used DSSL (datagram SSL) but that'd probably add more overhead than what they did.
I see little real world evidence that this "let the pros handle it" attitude toward crypto is helping.