encryption???

[GallagherCommaJack]

basic premise: users have associated public signing and KEM keys

the basic API of KEM is that you can, from a public key p, create a random shared secret, ss, alongside a ciphertext cs, which when combined with a secret key s can reconstruct the shared secret.

message format:

• random new ciphertext cs from KEM public key
• message encrypted using AES+padding or a stream cipher (I don't know enough to know which of these makes more sense)
• message metadata for the server

proposed KEM: ntruhps4096821 proposed sig: falcon-1024

[GallagherCommaJack]

This would have worked but actually misses a lot of the nice security properties of double ratchet.

The current plan is to implement double ratchet sessions, with sender keys for groups. We'll also be using crypto primitives from libsodium for symmetric key operations (e.g. kdf, mac, stream encryption), and we'll probably use it for signatures as well (though I'm open to the suggestion of using e.g. falcon for signing, lattice signature schemes seem less mature than encryption schemes so I'm inclined to stick with EdDSA from libsodium).

[GallagherCommaJack]

New message format is actually server metadata + xsalsa20poly1305 encrypted message body.

[GallagherCommaJack]

Closing this - we'll be using libsodium primitives, through the bindings provided by sodiumoxide. Implementation is in the chainmail repo, I'll probably give the protocol a more thorough write-up once it's had a few weeks to stabilize.