search

atek-cloud / spork

[CLI app] Peer-to-peer socket magic in the air
https://spork.sh
MIT License
289 stars 9 forks source link

Encryption #1

Closed guybedford closed 2 years ago

guybedford commented 2 years ago

My knowledge of these layers is very limited so I'm probably getting this all wrong, but I'm under the impression hyperswarm uses the same Hyper concept of the public key being the address, but then assume you're also not currently encrypting any packets either so this key isn't actually used for anything apart from the addressing right?

In theory you could get a fast DH handshake since you know the key you can just perform the other half of it and get bi-directional encryption on low-level packets right? But then it's not clear to me why IP didn't just implement encryption at this layer anyway instead of applying it at the TCP layer... Surely there aren't such huge benefits to encrypting larger chunks over it being per-packet?

Or do I just need to go back to learning networking 101?

pfrazee commented 2 years ago

Or do I just need to go back to learning networking 101?

Not at all -- you've got an accurate mental model of the PREVIOUS version of Hyperswarm.

The NEW Hyperswarm now encrypts all traffic using the NOISE framework.

guybedford commented 2 years ago

Ah perfect! So this is encrypted by default!? Perhaps state that first...!

guybedford commented 2 years ago

So the new Hyperswarm uses the NOISE framework for Diffie-Hellman exchange?

pfrazee commented 2 years ago

Perhaps state that first...!

Lol good call, I'll do that.

So the new Hyperswarm uses the NOISE framework for Diffie-Hellman exchange?

I'd have to ask (not my specialty)

guybedford commented 2 years ago

For it to be truly bi-directional, the client must be generating a diffie-helman keypair on its side as a one-way handshake component but that could be sent in the first packet so no three way handshake per usual TCP requirements. If it is fully bi-directional that's definitely a huge selling point.

pfrazee commented 2 years ago

It is bi-directional. Both peers set a keypair

Here’s the module: https://github.com/emilbayes/noise-peer

On Oct 17, 2021, at 3:54 PM, Guy Bedford @.***> wrote:

 For it to be truly bi-directional, the client must be generating a diffie-helman keypair on its side as a one-way handshake component but that could be sent in the first packet so no three handshake way per usual TCP requirements. If it is fully bi-directional that's definitely a huge selling point.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.