Secure channels over TCP/IP

#1

Post by purak » Tue, Jul 07, 2015, 7:55 PM UTC

Secure channels over TCP/IP
kyleisom.net

Re: Secure channels over TCP/IP

#2

Post by cespare » Tue, Jul 07, 2015, 10:46 PM UTC

Interesting. A couple of questions that come to mind:

- Any rough benchmarks vs. TLS? Or even just back-of-the-envelope math/reasoning behind the claim in the opening paragraph: "without the overhead of TLS".

- Instead of generating 24 PRNG bytes for each message to use as the NaCl nonce, why not use the sequence number each message is assigned anyway?

Re: Secure channels over TCP/IP

#3

Post by 0xEA » Tue, Jul 07, 2015, 11:09 PM UTC

Your message length is sent in plain text and unauthenticated. Does this present a problem?

Re: Secure channels over TCP/IP

#4

Post by tptacek » Tue, Jul 07, 2015, 11:11 PM UTC

0xEA wrote: post #3

Your message length is sent in plain text and unauthenticated. Does this present a problem?

Probably not, because messages are authenticated cryptographically, and the lengths are validated before being passed to libsodium. You can't truncate an authenticated message.

Re: Secure channels over TCP/IP

#5

Post by jallmann » Tue, Jul 07, 2015, 11:14 PM UTC

The public key operations during setup are clearly useful for authentication against a possibly untrusted peer. What mechanism is used for key distribution? Revocation? Is the main advantage over TLS in its use of a limited set of cryptographic primitives (as provided by NaCl), at the expense of flexibility? Any other advantages, such as decreased setup time? What about upgradeability -- does the protocol have the ability to roll in additional keys/exchange algos or ciphers as better ones become available?

Of course, the more of these features you add, the closer you get to TLS. That being said, without these features (eg, if you need to basically upgrade your whole fleet just to update to a newer NaCl or to add keys as opposed to using a signed certificate mechanism), the advantage starts shifting towards even simpler approaches, such as spiped, which omits all the public-key ceremony in favor of a shared secret key.

Re: Secure channels over TCP/IP

#6

Post by 0xEA » Tue, Jul 07, 2015, 11:15 PM UTC

cespare wrote: post #2

Interesting. A couple of questions that come to mind: - Any rough benchmarks vs. TLS? Or even just back-of-the-envelope math/reasoning behind the claim in the opening paragraph: "without the overhead of TLS". - Instead of generating 24 PRNG bytes for each message to use as the NaCl nonce, why not use the sequence number each message is assigned anyway?

nacl says that for security each nonce/key pair must be unique for each message. If you send a "HELO" message, for example first, you've made it possible to build a pretty simple rainbow table if nonce just starts at 0 or 1. That said, it would seem that the first nonce being random and then incremented would likely work well.

Re: Secure channels over TCP/IP

#7

Post by 0xEA » Tue, Jul 07, 2015, 11:19 PM UTC

jallmann wrote: post #5

The public key operations during setup are clearly useful for authentication against a possibly untrusted peer. What mechanism is used for key distribution? Revocation? Is the main advantage over TLS in its use of a limited set of cryptographic primitives (as provided by NaCl), at the expense of flexibility? Any other advantages, such as decreased setup time? What about upgradeability -- does the protocol have the ab…

I agree, you would have to tie IPs->peer keys to make this work.

Re: Secure channels over TCP/IP

#8

Post by diafygi » Tue, Jul 07, 2015, 11:45 PM UTC

What advantage does this have over spiped[1]? Since there's not really a good way to distribute public keys, you really need to just put them on a thumb drive and walk them over to the person that wants them. And if you're doing that, you might as well give the person a shared secret.

[1]: https://www.tarsnap.com/spiped.html

Re: Secure channels over TCP/IP

#9

Post by doomrobo » Tue, Jul 07, 2015, 11:55 PM UTC

The key exchange high-level overview looks like it has some typos.

Firstly, the is being escaped instead of being interpreted as a tag. Also you say that the client and server make a keypair and create a tuple k_(pub,1) || k_(pub,2) || sig. Why would one participant have 2 pubkeys? If you meant it to be one public and one private, why would it include a private key? Is it actually that the client makes k_(pub,1) || client_sig and the server makes k_(pub,2) || server_sig? Also later you reference k_(peer,1) and k_(priv,1) which weren't mentioned previously at any point.

Sorry if I'm misunderstanding anything. I'm gonna read through the Go code to see if I can understand better, this looks really interesting!

Re: Secure channels over TCP/IP

#10

Post by doomrobo » Wed, Jul 08, 2015, 12:21 AM UTC

doomrobo wrote: post #9

The key exchange high-level overview looks like it has some typos. Firstly, the is being escaped instead of being interpreted as a tag. Also you say that the client and server make a keypair and create a tuple k_(pub,1) || k_(pub,2) || sig. Why would one participant have 2 pubkeys? If you meant it to be one public and one private, why would it include a private key? Is it actually that the client makes k_(pub,1) || c…

Update

Looking at the source, it seems like the initial key exchange keys are sent as a k_(pub,x) || sig tuple where x is 1 for the sender and 2 for the receiver. Similarly, it looks like the shared keys are derived from subslices of k_(pub,x) and k_(priv,3-x).

Is there a particular reason there isn't a single read/write symmetric key that's derived from the entirety of the public and private keys?