Disco – A plug-and-play secure protocol and a cryptographic library in Golang | Hacker News Reader

Disco – A plug-and-play secure protocol and a cryptographic library in Golang

discocrypto.com

93 pointsbaby21 comments

This is interesting.

David Wong is a cryptographer at NCC Crypto. I like David. I added that because I know he's reading this.

Noise is Trevor Perrin's transport protocol framework (it's a "framework" because it's parameterized, and defines several different protocols with different cryptographic tradeoffs). Noise is used by Signal, and the WireGuard VPN uses a variant protocol inspired by it.

Strobe is Mike Hamburg's framework for building encrypted transports out of a sponge function --- sponges are the cryptographic kernels of newer hashes like Keccak. I think it works in a similar fashion to Keccak's promise of getting an entire cryptosystem out of a single crypto primitive, which is something David likes a lot.

In a sense, you'd have Noise doing the handshake and key establishment, and Strobe doing the actual encryption. Noise + Strobe = Disco. Cute.

What's the CSS framework this is done it? It's very clean.

(Corrections: it's WhatsApp that uses Noise, not Signal; Wireguard uses a variant of Noise directly).

CSS Framework == Bulma (https://bulma.io)

>Noise is used by Signal

Are you sure?

Yeah, see correction: I got WhatsApp and Signal confused. (WhatsApp uses Signal Protocol and Noise).

Am I understanding this correctly that the main value proposition here is further simplification of Noise protocol by replacing the existing symmetric parts with parts from STROBE protocol?

While its good to push the envelope further, I'm not sure how much practical impact this will have (compared to vanilla Noise). Especially if some of the gained simplicity is countered by sheer novelty of this construction.

The way I'm thinking about it is that it's an instantiation of Noise where, except for the curves, all the crypto primitives are derived from Keccak.

Apart from just being a cool thing to design, Hamburg's rationale for STROBE was for microcontroller environments, where being able to derive everything from a single sponge function saves on text space.

If you don't have that very specific problem, there's not really a good reason to use STROBE (or Disco) --- it's subtantially slower than "vanilla" Noise, which uses primitives either designed to be fast on modern hardware (Chapoly) or that have hardware acceleration (AES-GCM).

> ... except for the curves, all the crypto primitives are derived from Keccak.

This sounds intriguing. Could you share some keywords helpful in searching for more precise descriptions of deriving various crypto primitives from Keccak? I can image generating keys using hash functions but not the primitives themselves.

Quick search yielded only this: https://csrc.nist.gov/CSRC/media/Presentations/FIPS-202-and-...

https://en.wikipedia.org/wiki/Sponge_function

Search for [hamburg strobe], read the STROBE paper, and follow the links. :)

Excellent, thank you!

"In other words, you can use libdisco to securely connect peers together," - any idea as to best practise in terms of using Golang library for next step: connecting the peers through firewalls..etc.? Bittorrent clients have become masters when it comes to automating UDP protocol use along with selective hole punching of firewalls on Win/OSX but they are complex beasts to learn from!

I'd say it depends on required speed and use cases. See libp2p's ifaces for swarm, routing, etc. Heck, you could use Tor, make onion services for your peers, and add the names to Bittorrent's mainline DHT for discovery (of course Tor is slower...a price you pay for anonymity)

I can't comment on the protocol itself, but including an interactive quiz directing the user to a documentation page is a brilliant idea.

Looking forward to a review from tptacek.

David knows more about this stuff than I do, for whatever that's worth.

Congratulations on the release David; I will be watching this one closely!

> libdisco is experimental. It has not been thoroughly reviewed and relies on an unstable specification. It should not be used in production.

Have you seen production lately?

More details here:

https://www.cryptologie.net/article/432/disco/

He broke rule #1: don't implement your own crypto

No this doesn't apply because David is a cryptographer. Clue. He is exactly the kind of cat I want to be writing crypto.

It's more accurate to say "don't implement your own crypto to use in production" - IMO everyone should implement some crypto to understand the basic principles, but there are a lot of possible failure modes which aren't immediately visible (e.g. timing attacks).

Reply on news.ycombinator.com