
Disco: Modern Session Encryption [pdf] - lainon
https://eprint.iacr.org/2019/180.pdf
======
haarts
This doesn't appear to be only a research project, there are two
implementations already. One in Go
([https://www.discocrypto.com/](https://www.discocrypto.com/)) and one in C
([https://github.com/mimoo/disco-c](https://github.com/mimoo/disco-c)).

~~~
baby
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).

------
eadmund
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.

~~~
pvg
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.

------
feb
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](https://www.youtube.com/watch?v=bTGLO4obxco)

------
tatersolid
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.

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

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

~~~
tptacek
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.

