Streaming encryption protocol based on libsodium's box primitive | Hacker News Reader

Streaming encryption protocol based on libsodium's box primitive

github.com

29 pointsc-rack13 comments

The protocol uses symmetric crypto primitive from Sodium, leaves key distribution - arguably the most difficult part - beyond the scope.

I'm not a cryptographer, but I do know, that cryptographic protocols are damn hard and their design should be left to professionals.

regards to professional cryptographers, here are two quotes:

First, from Matthew Green:

> A while ago on Twitter somebody asked why I spend so much time criticizing things that are old and broken, rather than making things new and shiny. When I finished sputtering, I realized that the answer is simple: I'm lazy.

(from this blogpost: http://blog.cryptographyengineering.com/2012/12/the-anatomy-... )

and the second from Diffie & Helman's classic paper, _New Directions in Cryptography_

> The last characteristic which we note in the history of cryptography is the division between amateur and professional cryptographers. Skill in production cryptanalysis has always been heavily on the side of the professionals, but innovation, particularly in the design of new types of cryptographic systems, has come primarily from the amateurs.

(from: http://www.cs.jhu.edu/~rubin/courses/sp03/papers/diffie.hell...)

(note that "cryptanalysis" means _breaking cryptographic systems_)

Hi I am the author of this protocol (but I did not post it to hacker news)

To clarify: this is not a substitute for TLS, DTLS, Curvecp, or Noise-Pipes -- because there is no key agreement handshake.

You could use this with a suitable handshake protocol to encrypt the rest of the session, or you could encrypt a file.

Do not use this protocol on it's own to encrypt a tcp connection. I have updated the protocols documentation to make this more clear.

This is a bit weird. Why not use an AEAD construction? Libsodium provides ChaCha20Poly1305, conform to RFC 7539.

The code is also confusing. "box" is actually the "secretbox_easy" operation, but rewritten using "secretbox". Which intentionally doesn't exist in libsodium.js because it only makes sense in C code.

Hi I am the author of this protocol (though I do not know who posted it to hacker news)

You ask a good question, but I would much rather discuss it on github, since then that discussion will be tied to the project not a hacker news thread.

https://github.com/dominictarr/pull-box-stream/issues/5

Any idea how it compares to CurveCP [http://curvecp.org/] and Noise [https://github.com/trevp/noise/wiki]?

As far as I recall CurveCP is based upon public key encryption NaCl primitives. This protocol uses symmetric encryption from Sodium. While it is also based on NaCl, that's all they have in common. I'm not familiar with Noise.

This protocol has no forward security; so, poorly by comparison.

This protocol assumes there's already a shared secret. So you need another one for the key exchange. Which can provide forward security. Or not.

This protocol does not include a handshake, so it's not comparable to either of those protocols.

(Also, I was not aware of noise so thank you for bringing that to my attention!)

You could use this protocol for the rest of the tcp connection, once a forward secure key has been agreed upon.

What are some uses people are thinking of after reading the README?

Here are some of mine:

* Encrypted live communication (video, voip, IM) via a web browser

* Could something like this be added to the SSL/TLS security in HTTP?

Why should I ever use this instead of DTLS?

This would be great as a obfsproxy plugin if I understand it correctly

Reply on news.ycombinator.com