Weave is kinda slow • Hacker News Board

Re: Weave is kinda slow

#161

Post by weavenetwork » Sat, May 09, 2015, 9:30 AM UTC

takeda wrote: post #160

weavenetwork wrote: post #157

Earlier quoted context omitted.

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/

Re: Weave is kinda slow

#162

Post by heavenlyhash » Wed, May 13, 2015, 1:12 AM UTC

msackman wrote: post #145

heavenlyhash wrote: post #144

Earlier quoted context omitted.

What you're looking for here is usually referred to as "PBE" (Password Based Encryption) or "KDF" (Key Derivation Function). There's a couple extra concerns for transforming a human-readable password into a symmetric key. Hashing is the start, so it's great that your project already has that, but there's more to do, and this is a well-studied topic with lots of literature and pre-existing solutions. "PBKDF2", "HDKF",…

DH is used to ensure that every connection between every pair of weave router nodes that ever gets established uses a unique session key. Yes, the public key is exchanged in the clear, and yes, that is MITMable. But as you say, the subsequent combination of the result of the DH with the non-exchanged password solves that. What is the weakness with this approach? Is your point that there's nothing gained from doing th…

So the DH does give you some degree of ephemerality, yes... but as used, only if you're not already being MITM'd. (If you are subject to MITM, then it degenerates to the case you describe where peers are just picking a random number and exchanging it in the clear.) You could upgrade this to not have that weakness under MITM at all by doing the DH after the KDF: use the KDF to key an HMAC, thus preventing MITMs by someone lacking the password at the time of the DH exchange. I don't think there are any additional expenses or drawbacks associated with doing this.

Re: Weave is kinda slow

#163

Post by mradestock » Thu, May 14, 2015, 1:08 PM UTC

heavenlyhash wrote: post #162

msackman wrote: post #145

Earlier quoted context omitted.

DH is used to ensure that every connection between every pair of weave router nodes that ever gets established uses a unique session key. Yes, the public key is exchanged in the clear, and yes, that is MITMable. But as you say, the subsequent combination of the result of the DH with the non-exchanged password solves that. What is the weakness with this approach? Is your point that there's nothing gained from doing th…

So the DH does give you some degree of ephemerality, yes... but as used, only if you're not already being MITM'd. (If you are subject to MITM, then it degenerates to the case you describe where peers are just picking a random number and exchanging it in the clear.) You could upgrade this to not have that weakness under MITM at all by doing the DH after the KDF: use the KDF to key an HMAC, thus preventing MITMs by som…

Just to clarify, the attack you want to protect against is that of an adversary being able to conclude the DH public key exchange with a bona fide weave peer, despite having no knowledge of the password. Correct?

But what can an adversary learn from doing so? All subsequent messages on the connection are encrypted with the secret key, which has the password mixed in.

Re: Weave is kinda slow

#164

Post by theptip » Thu, May 14, 2015, 6:12 PM UTC

Confusion wrote: post #121

otterley wrote: post #102

Earlier quoted context omitted.

Is GRE inadequate? A single solution that solves most cases, is codified in an RFC, and has mature, reliable, performant implementations sounds like a winner to me.

I don't know if GRE is inadequate: if I knew that, I wouldn't need to ask these questions. The author doesn't disapprove of VXlan, so there must be something insufficient in GRE. Look, I'm just trying to understand the playing field here, for when the moment comes that I need that knowledge. I don't currently have a need for funky networking between Docker containers, but I do have Docker containers and can imagine a…

L3 routing protocols like BGP are one solution to the network connectivity problem which have been around for decades. BGP powers the internet, so we know it can scale to millions of endpoints.