2 ms·
An identity is a public key. An address is a hash of that public key. Key agreement is just SHA512(Curve25519(my secret + your public)). Public keys are looked
by api 8y ago
An identity is a public key. An address is a hash of that public key. Key agreement is just SHA512(Curve25519(my secret + your public)). Public keys are looked up from addresses via "upstream" nodes by the sender. An upstream node is typically one of our root servers unless someone has added their own.
Crypto here is fairly dirt simple as I said. It's just ECDH with two Curve25519 keys and then go.
The moons/worlds stuff is just some odd terminology for how to define upstream nodes. We are dumping that in favor of something more straightforward in the future. Most users don't need to care about it.
I'd like to avoid GCM but we also may have a need for FIPS compliance in the future. Yes I know that FIPS basically mandates weaker crypto... or at least crypto that is easier to implement wrong... but if it's not FIPS it isn't "enterprise" to some (clueless) people. Then you have organizations mandated to use FIPS crypto by forces beyond their control.
- tptacek 8y agoThere are no ephemeral keys at all? It's just static-static DH?
- api 8y agoNot in 1.2. This is planned for 1.4. It's fairly prominent in the manual. It was left out of the original design since ephemeral negotiation means state and therefore latency and stalls if packets are dropped. The present design leaves it out as part of a design that prioritizes instantaneous connectivity. When we do add it we will probably add a network level config option to select whether forward secrecy is required. If it's off it will work instantly and then lazily upgrade. If this option is on it will wait. As I said though I don't see network level (L2/L3) encryption as being worth much more than whole disk encryption. Each really secure thing should have it's own secure authenticated session that would be secure enough over the open Internet. That way a network compromise or trojan is not instantly fatal. We pretty much tell everyone this.
- tptacek 8y agoHave you considered just, you know, adopting the WireGuard protocol and then building something on top of it to coordinate connections? I built something like this (in C++, no less!) back in 2000. After the company failed, I always felt like we had made a mistake not just shipping the absolute simplest possible message forwarder, and then implementing the control plane for it in a reasonable high-level language. (In fact: an early team member pushed us to do that, and I shot them down.)
- monkeywork 8y agoThis may come off as rude ... but tptacek there is a fine line between being enthusiastic and aggressively dickish. All over this thread you have been PUSHING hard... way harder than you should have to if your product is as good as you are touting. It's one thing to promote, but what I've read all over this post (not just this thread) is someone whose personality REFUSES to allow them to even give a small inch in a debate -- feels a drive to be right no matter the cost. That makes me question how likely you are to take input from people who can / want to help ... Friendly advice -- roll yourself back down to an 8 or 9.
- tptacek 8y agoWireGuard isn't "my" project. I have no formal relationship with the developer, other than that we like his work so much we've contributed a bit to its development (less than others). You're not being rude. But I have no plans to give an inch on this discussion. If that's problematic for you, you're welcome to use the HN votey-buttons as you see fit.
- monkeywork 8y agoJust letting you know that your comments/attitude/etc are likely hurting the cause you are championing. Your volume of replies, the tone you take in them, and the way you react makes it seem like you ARE deeply part of the project... Thus I (and likely many others) associate you with it. I don't care what you comment - be a dick to the fullest if that's your thing - I was simply letting you know the impression you are leaving out there.