add dh

[dvc94ch]

Seems like dh could be easily added [0] and there seems to be precedent for using the same keys for both signing and encryption [1].

• [0] https://github.com/ZcashFoundation/ristretto255-dh
• [1] https://signal.org/docs/specifications/xeddsa/

[burdges]

There is a simplistic version already in https://github.com/w3f/schnorrkel/blob/master/src/aead.rs but..

We should make it compliant with https://github.com/ZcashFoundation/ristretto255-dh before telling folks it exists. ;) We should also think about 2DH, etc. for this, which maybe that crate does.

ref. https://github.com/w3f/schnorrkel/issues/4

[dvc94ch]

They just do a multiplication between a scalar and a ristretto point, like what you implemented. Interesting aead32_unauthenticated is exactly what I was looking for.

[burdges]

I'd expect aead32_unauthenticated would stay. We should encourage using forward secure key exchanges instead somehow, but.. I'd prefer to avoid doing a full noise implementation however. lol

[dvc94ch]

Noise should be generic over the crypto. At the moment we're using a file based keystore. I haven't found a nice way to interact with the TPM, but I think new Intel cpu's support generating a key in hardware. The down side of forward secrecy is you can't decrypt your own messages (after the session expired), so it's not very suitable for asynchronous communication. (I guess hardware based solutions don't work if a device is shared by multiple users, but I guess most aren't?)

[dvc94ch]

Are you planning on making a release soon? It's not in the crates.io version so we won't be able to publish until you do. Also it would be good to reexport the aead traits you're using (or dump the aead dependency all together)

[burdges]

I'll do one soon, sorry. We've been kinda busy with stuff lately. :)

I just should sort out what else should go into a release, if anything. In particular, I'm tempted to remove the deterministic batch verification until I've thought slightly more about all the consequences.

[burdges]

Actually the aead module exists already in 9.1, but hidden behind the aead feature gate.

How stable do you want this? And how soon? We could consider removing the feature gate bit-by-bit, but I do not currently have the time to dig through all the details quite carefully enough to feel good about removing the feature gate on everything there.

[dvc94ch]

Yes indeed, I guess I didn't find the feature gate, updated to using git and then forgot to try 0.9.1 . In that case I guess this issue is resolved.

In case you're curious how we're using it [0][1].

• [0] https://github.com/sunshine-protocol/sunshine-core/blob/master/crypto/src/dh.rs
• [1] https://github.com/sunshine-protocol/sunshine-core/blob/master/crypto/src/secret_box.rs

[burdges]

We should maybe add some test for agreement with ristretto255-dh I guess. I'm comfortable promising that much stability.