mimoo / disco Goto Github PK

Disco could benefit from an NN pattern that enforces verification of a fingerprint post-handshake in order to "unlock" the session.

you can use disco via:

• plug-and-play Dial/Listen+Accept for TCP
• same thing for UDP
• framing messages yourself (you need to call WriteMessage and ReadMessage yourself)

None of these are documented. Perhaps it's better to only document the first two and leave the third one for knowledgeable people.

We've seemed to have settled on schnorr signatures over ristretto22519. (See this PR #45)

Other choices were:

• qDSA. Too new.
• EdDSA. Makes use of SHA-512.
• ECDSA. Why not, but not really specified for Curve25519.
• schnorr over P-256. We already use Curve25519, so we should leverage this.

My two concerns are:

• ristretto. Too new, and not well-supported.
• schnorr signatures are not specified anywhere.

What references are there out there? I think we should follow the scheme defined by a proof:

https://crypto.stackexchange.com/questions/48616/prove-the-security-of-schnorrs-signature-scheme

I think a whitepaper containing:

• the rational behind Disco
• benchmark and codesize results in different implementations (especially in C)
• some tamarin symbolic proof

would be great. If anyone wants to collaborate :)

what are the secrets to delete?

• psk
• ephemeral keys
• long-term keys

when to delete? Probably when Split() is called? Although GetHandshakeState() might still require some stuff?

There is a clear() function to clear secrets btw.

Also note that it doesn't seem possible to completely wipe secrets in Go

I just added benchmarks in 8b2bf93

It's not pretty compared to crypto/tls

the main reason I believe is that I am not using the block hack that they use. It shouldn't be too hard to implement.

In the spec, GetHandshakeHash is quite different from the one in the Noise spec:

1. it changes the state
2. it will give out a different result depending when it is called

so we need to add some more information in the spec? fix:

1. perhaps we should clone the state before calling it?
2. both peers need to call it at the same time to obtain the same result

Because the fix in 2. also fixes 1., perhaps we should just keep fix 2.

I'll reference this issue for security or breaking changes

We don't check in checkRequirements or elsewhere that handshake patterns have the correct keys set during initialization. Probably this should be done when calling Initialize on the handshakeState?

For example Noise_N should have the rs set for the initiator and the s set for the responder.

On the other hand, maybe we do check that when we have to send them? In any case it should be checked somewhere.

Right now one needs to read both the Noise and the Disco spec.

One could create a Self-contained Disco spec that would be much smaller than the Noise spec. I think this would be a good thing to facilitate implementation of Disco.

What's the license for library as well as other code in this repo? Would be nice to have explicit license/copying file and SPDX tags inside source files.

There are several APIs that need to be documented:

• isRemoteAuthenticated()
• remotePublicKey()
• ListenDisco() & AcceptDisco()

more info

The documentation also needs to update the APIs of GenerateKeyPair and LoadKeyPair that now take a passphrase.

this page is cool, we should link to it.

I think balloon hashing is probably the best algorithm to implement here due to its compactness.

Currently, handshake patterns with I and X (key is transmitted as part of the handshake) seem to enforce signatures and a PKI. For example NX:

Noise_NX is a handshake pattern similar to a typical browser ↔ HTTPS server scenario where the client does not authenticate itself and the server authenticates its public key via a signature from an authoritative signing key.

This is not at all the only way of using this handshake patterns. TOFU (trust on first use) or (a whitelist of) key pinning are also possibilities.

How to do it? Your StaticPublicKeyProof() function can return an empty string and your PublicKeyVerifier() can always return true or match public keys against a whitelist.

Furthermore, to obtain the public key received from the connection, one must either use the Disco functions directly (and they are currently not exported) or must use the ListenDisco/AcceptDisco() functions that return a libdisco.Conn instead of a net.Conn; giving access to extra functions like RemotePublicKey().

I am also trying to think of a way a net.Conn could be used to retrieve that public key. The problem is that its interface is limited to modifying its RemoteAddr() function (which is supposed to return the ip:port tuple of the peer). Perhaps, a flag in the configuration of Disco could tweak this to return a publickey:ip:port tuple instead?

It would be interesting to see if Tamarin or ProVerif could be used to prove this design :)

have a main website showcasing all the implementations, like this: https://miscreant.io/

What's wrong

http://www.discocrypto.com/

How it should be

https://www.discocrypto.com/by default

Why?

Obviously, it is not really good for a crypto lib not to force the use of HTTPS on their website. See also: HSTS. 😉

in handshake patterns with X or I when the key needs to be signed: we also need to sign the server "identity name" which the client needs to know in advance.

• Apache
• Nginx
• ?

We need benchmarks, possibly taken from crypto/tls

(Of course benchmarks in a C implementation would be better)

Looks like int return value can be either the number of output bytes, written to output buffer, or in case of exception, number of input bytes, read from socket, including length.

In case of correct decryption this output helps user truncate the buffer and get correct output,
But in case of exception I don't see any useful ways to utilize this integer return value.

So, is this ambiguity intended, and if so why user need it? Maybe it will be better just return 0 for all exceptions?

Ideally the website should cover the protocol + all the implementations in different languages, so it'd be good to have it live in a different repository

https://goreportcard.com/report/github.com/mimoo/disco

Dear Santa,

I am a very good boy, and I don't like 3D array based sponge functions that much.
Can I have a 2D array based cryptographic library? NORX already exists so I want that.

• Go https://github.com/Daeinar/norx-go
• JS https://github.com/kaepora/norx.js
• Python https://github.com/Daeinar/norx-py
• Python + NumPy https://github.com/therealmik/norxpy
• C https://github.com/ctz/cifra
• Java https://github.com/c-rack/norx-java
• Ruby https://github.com/gazay/norxrb

Please I would like this Rave abstraction for experimentation.

Love,
D

(For serious though, Disco's model can be used to fit ANY sufficiently sized sponge function, maybe Fugue or Luffa for SHA3 candidates? pi-cipher or ICEPOLE for CAESAR parallelization candidates? Ascon or PRIMATEs or STRIBOB for non parallelization candidates? SPONGENT or PHOTON or QUARK for a more modern twist?)

To become useful, Disco needs to be widely supported. This means a libdisco needs to exist in:

• C for embedded devices (disco-c).
• Rust (disco)
• C# (DiscoNet)
• python (PyDisco)
• Swift (GDisco)
• Java
• Javascript
• Erlang
• etc.

For now, no interop tests have been done. If people are interested we could have a date setup to plan for that.

There's also Xisco which doesn't use Strobe but Xoodyak

Furthermore, it needs to be integrated in load balancers and proxies:

• HAProxy
• Apache
• Nginx

While I might not want to document them all, especially as some are insecure, it would be nice for protocol builders to support all the handshake patterns. I could also just implement them as they are requested here.

http://discocrypto.com/disco.html#out-of-order-transport-messages

EncryptWithAd should authenticate the ad

Hello!
Nice project, i love the code.

I am reading here :
func GenerateKeypair(privateKey *[32]byte) *KeyPair

that it reads from crypto/rand and returns a random result for the private key.

but, i am also reading here: https://cr.yp.to/ecdh.html

Computing secret keys. Inside your program, to generate a 32-byte Curve25519 secret key, start by generating 32 secret random bytes from a cryptographically safe source: mysecret[0], mysecret[1], ..., mysecret[31]. Then do

     mysecret[0] &= 248;
     mysecret[31] &= 127;
     mysecret[31] |= 64;

is this byte manipulation required?

https://github.com/mimoo/disco/blob/master/libdisco/disco.go#L85

I'm not sure we need to send a tag after sending a static key, this is because the whole message pattern is authenticated at the end by the payload (empty or not)

Here's Initialize():

func Initialize(handshakeType noiseHandshakeType, initiator bool, prologue []byte, s, e, rs, re *KeyPair)

It doesn't make sense to take *KeyPair for rs and re. We should just accept []byte (which can be set to nil as well).

• the noise part has a spec (https://discocrypto.com/disco.html)
• the non-noise part doesn't. How does one implement that? For example we want to use schnorr over ristretto for signatures, but there is no real schnorr spec. We also don't take an IV for encryption and generate it ourselves. etc.

make sure that signing keys can't be re-used as X25519 keys

one additional argument for disco is that static keys that are sent not encrypted in Noise, are sent obfuscated in Disco. This is good against passive observing of middle boxes or others.

What happens if you call Dial("udp", ...) instead of "tcp"?

(it should not work!)

Disco should really shine with embedded devices, and there it should make sense to use keccak-f[400] instead of keccak-f[1600] (which we currently use).

The Strobe version also doesn't include what permutation is used, I think it should be but my suggestions on the list didn't go too far.

Split() clones the Strobe state and creates two different Strobe state at the end of the handshake.
At this point they are differentiated and one is used for the client to encrypt, the other is used for the server to encrypt.
But both will have the initiator=true value set on their Strobe objects!
It doesn't matter much I think, but to be cleaner, shouldn't we set their initiator value according to their role vis-a-vis of each Strobe object?

libdisco still doesn't have releases or a version. How to do that with SemVer and github and Go?

(also this)

Would be good to have an internet draft/RFC for disco at some point

I think I made many mistakes when designing the www.discocrypto.com webpage:

• too much jargon on the landing page
• too many keys to understand

Ideally:

• get to the point: the technical stuff should be either further down the page or on a different page
• technical terms: things should be renamed with what normal users understand, for example "long-term keys" can be renamed "identities"
• to many options: remove things like "half duplex" that are probably not going to be useful to most people.

should MixKeyAndHash set isKeyed in the spec (and implementation)?

right now the library is just a plug-n-play library. It'd be better if it could also be used as a pure disco library.