Disco: Modern Session Encryption [pdf] | Hacker News Reader

Disco: Modern Session Encryption [pdf]

eprint.iacr.org

47 pointslainon10 comments

This doesn't appear to be only a research project, there are two implementations already. One in Go (https://www.discocrypto.com/) and one in C (https://github.com/mimoo/disco-c).

Author here, there is also one in python, one in C# and one in rust. And today I learned that there is one in swift (but based in gimli).

This is really, really cool: using a single construction to provide … everything. It does feel a bit like putting all of one's eggs in one basket, but I guess as long as it's one really great basket that's okay.

It makes sense, too, given the assumptions we make about security of PRFs: if a PRF is secure enough to generate keys with PRF(state || 001), PRF(state || 002), … then intuitively (which isn't a proof!) everything else follows.

All in all, a really neat result!

As an aside:

> Disco is the natural merge of the two projects

I've gotten used to seeing the verb 'ask' used as a noun instead of 'request,' and just within the last week saw the verb 'solve' used as a noun instead of 'solution'; this is the first time I've seen the verb 'merge' used instead of the noun 'merger' in this context (although I'm familiar with it from version control).

American English has already lost its adverbs; I wonder if we'll start to lose a lot of our nouns (!) too.

I don't think the 'merge' thing is that unusual or new, think 'MailMerge' as a feature of 80s word processors. OED has some early examples:

merge, n. rare.

(mɜːdʒ)

[f. the vb.]

An act or instance of merging.

1805 Foster Ess. i. vii. (1806) 101 In him it was no debility of reason, it was at the utmost but a merge of it. 1905 Pall Mall G. 24 Apr. 3/2 The first barony of Pelham‥merged in the Dukedom of Newcastle.‥ The ‘merges’ of the 1611 baronetcy, Pelham of Laughton, have been many.

I think 'merge' is just a typo.

Very cool approach which relies on the sponge construction of Keccak/SHA-3 fame.

The presentation at Blackhat 2017 explains well the core ideas as well as the context:

https://www.youtube.com/watch?v=bTGLO4obxco

This looks really promising, except for the “variety of handshake patterns from which the developer can choose”. Few details in the paper, but hopefully the choices are limited to just “we share a secret” or “use a pinned public key” or possibly “use PKI” choices. We don’t need non-specialist developers trying to decide what form of mutual authentication they should use; the library should make safe choices for the developer.

I also hope the wire protocol is strictly versioned with zero options. You want a new cipher suite, rev the whole protocol.

The design is based on Noise, which doesn't have negotiation.

Aren’t the “fallback” modifiers in Noise a form of negotiation? http://noiseprotocol.org/noise.html#handshake-pattern-name-s...

Not the way we normally think of negotiation, I don't think? Like: you don't use fallback patterns to switch ciphersuites.

Another way to think about it, and maybe I'm misapprehending something about Noise, is that whatever you're falling back "to" in a handshake is also a documented part of the same protocol. The fallback patterns would presumably (all things being equal) "survive" a versioning of the whole protocol.

Reply on news.ycombinator.com