Hacker News .hnnew | past | comments | ask | show | jobs | submit | weavenetwork's commentslogin

We did not roll our own crypto. We used NaCl. The rationale is explained here - http://weaveworks.github.io/weave/how-it-works.html#crypto We agree that other approaches are possible, but this is the one we picked for our first version.


Complaining on twitter is not the same as finding an issue! Criticism has value, but not all commentary deserves equal weight or time before it is reasonable to request reciprocal effort.



Tony, the team recently updated the crypto docs to clarify the rationale etc etc - http://weaveworks.github.io/weave/how-it-works.html#crypto ... Moreover the entire crypto code for weave is about 300 lines. Please please please if you are an expert then a thorough review would not only be welcome but also acted upon. Thank-you. Alexis.


True. We did try ipsec, and couldn't find an implementation that was oss, demonstrably safe, and easy enough to pull into a first release. As weave matures, we'd love to work with experts to implement standard solutions, even if they are costly to put in place.


"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.


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/


OpenBSD's implementation checks off at least the first two boxes, though the third would be a bit difficult in the GNU/Linux world.


We are open to recommendations, help and overall insight from expert contributors in security. As many people on this thread have pointed out, it is a big and complex world..


I don't think anyone meant, or said, "fuck you". Why are you even implying such a thing?

Ultimately we can't work on even a fraction of the features that every person wants, and Laurie said his idea was simple to implement... so why not show how it's done? Honestly, it's not that sinister and it is certainly not rude.


To put it simply, if @monadic were receptive to @lclarkmichalek's ideas, why did he end the conversation?

But let's look at the Tweet in question:

"@lclarkmichalek @weavenetwork please, if it is so simple and robust you are very welcome to contribute a patch."

1. He says "please", which in this case is sarcastic.

2. Then he says "if it is so simple," which is a dismissive way of saying "you think that it's simple, but you're wrong – it's actually very complicated."

3. And also "if it so so ... robust," which is a dismissive way of saying "you think that it's (more) robust, but you're wrong – it isn't."

4. And finally "you are very welcome to contribute a patch," which, first, does not need to be said as presumably anybody knows that they are welcome to submit a patch to an open source project, and second, basically amounts to "so, I'm going to make my problem your problem."

This case is different from a feature request from a user, where "feel free to do it yourself" is slightly less inappropriate. There, what is meant is "this feature is not important enough to warrant our endorsement or any allocation of resources, but if you were to take on the burden entirely yourself, we would consider it."

In this case, what is meant is something more like "we believe that your charge that there is a fundamental issue with our software is false and we are not interested in discussing until you have actually done the work for us," or in other words "fuck you."

I admit, "fuck you" is quite strong for the general case, but the tone of the Tweet warrants that translation.


I'm sorry but I find your interpretations of 1-4 completely uncharitable and unreasonable.


What you meant is clear to you. It's not clear to other people. You can chose to ignore them - maybe the people who misread the tweet are a small minority. Or you can chose to think about communication style and whether more people had the same "uncharitable" interpretation.

For what it's worth I lean more to the uncharitable reading of the tweet, although I'm not as firm about that reading as others appear to be.

Tweets for communication are hard so it's not particularly suprising when what you say and what you think you say doesn't match what other people think you said.


I don't; if anything, I personally find them too charitable and reasonable.

Just admit that you (if you're the one who wrote that response; it's not exactly clear who's who in this discussion...) were being a bit of a twit and move on. We all do it; I do it, the girl next door does it, my grandma even does it and she's the nicest person I know. There's no shame in being honest about it.


No, for example it is 100% uncharitable and unreasonble to assert that "please" is sarcastic. The truth is quite the opposite.


I think we'll have to agree to disagree on that one, then, though thanks for the clarification nonetheless.

Typically (at least in American English vernacular), "please" is very frequently used in a sarcastic manner (e.g. "You think you can jump from the top of that building and not get hurt? Bitch, please." or "Oh please, like you know the difference between a grape and a grapefruit."). While this sarcastic usage is usually accompanied by some other word prefixing it ("Oh please" or "Bitch please" or "Nigga please" or somesuch), it's not uncommon to see a lone "please" used in this sense as well, and the tweet in question very closely resembled that usage.


I'll have to stop saying please when in the US then ;-) But seriously, thanks for taking the time to explain your point of view. alexis.


> To put it simply, if @monadic were receptive to @lclarkmichalek's ideas, why did he end the conversation?

It was actually @lclarkmichalek who ended the conversation.


That does not appear to be the case to me :/


Also, agree with above post that you should use your own name as here I am awkwardly talking to you in the 3rd person.


as laurie mentions in his article, you can easily use off the shelf security solutions with weave... the point of the current crypto is to provide something basic that works. we chose nacl for ease of implementation primarily. happy to add more types of security in the future. help would be welcomed!


You can of course use etcd with weave... indeed weave can be run with no dependencies, so it may make sense as a way to bootstrap etcd ;-)


I haven't seen those used in the wild yet, but fwiw, weave is working on a 'fast data path' that uses the same kernel path as ovs


yes, microseconds surely - we estimate that the cost of switching from kernel to user space, and back again, several times, adds up to 2-300 microseconds. in return for this, you gain a lot of flexibility and ease of use. for apps that need lower latency, weave is currently working on implementing a fast data path option..


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: