Open 4meta5 opened 4 years ago
This should follow #5 as a newsletter topic. It builds nicely upon the primitives that would be covered in that section (basically, the meat of Serious Cryptography)
The high-level design for the KEX protocol is that two devices want to speak over an encrypted, authenticated channel, to communicate a few important pieces of information:
Provisionee → Provisioner
The provisionee's new device-specific EdDSA public key
The provisionee's new device-specific ephemeral Curve25519 DH public key
Provisioner → provisionee
Data derived from the user's passphrase, used to locally lock secret keys.
A signature of the provisionee's new device-specific EdDSA with the provisioner's existing device-specific EdDSA key
A session token so that the provisionee gets an active session with the server without having to directly login. The provisionee will need a session to post new signatures to the user's sigchain.
The user's latest per-user key (PUK) seed. These keys are always shared among the users devices and can be used by any of them.
The user's latest per-user ephemeral key (userEK) seed. These keys are always shared among the users devices and can be used by any of them while active.
The passphrase information and per-user key seed need to be encrypted for secrecy, and the key-exchanges need to be MAC'ed to make sure an adversary who controls the communication channel isn't MITM-ing the exchange. Both properties are achieved via authenticated-encryption of the exchange. Therefore, the endpoints share an offline secret (W described below) before communication can start.
Though many device-to-device channels exist, we're going to do the simple and naive thing, which is bounce messages off of the Keybase servers. Thus, the Keybase server can control the channel, but with the end-hosts authenticating and encrypting, this design decision does not present a security risk.
https://github.com/mlswg/mls-architecture/blob/master/draft-ietf-mls-architecture.md
This explores E2E encryption and authentication for a group messaging. It achieves security under the RFC3552 Internet Threat Model (implying that the attacker has complete control of the network and still can't violate the protocol's invariants).
The Messaging Service (MS) presents as two abstract services that allow clients to prepare for sending and receiving messages securely:
TreeKEM continuously generates fresh,shared, and secret randomness used by the participating parties to evolve the group key material. Each newgroup key is used to initiate a fresh symmetric hash ratchet that defines a stream of nonce/key pairs used tosymmetrically encrypt/decrypt higher-level application messages (such as texts in a chat) using an AEAD. Astream is used until the next evolution of the group key at which point a new stream is initiated.
Capability Based Security is a conceptual framework for designing decentralized access control systems, yet there is no widely implemented protocol for establishing secure two-way communication that also forms a capability system. (this changes that...)
a highly private 4 pass handshake protocol that is suitable for capability systems. It does not suffer from replay, eavesdropping, man in the middle, or key compromise impersonation
Signal's Double Ratchet Algorithm
The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones. The parties also send Diffie-Hellman public values attached to their messages. The results of Diffie-Hellman calculations are mixed into the derived keys so that later keys cannot be calculated from earlier ones. These properties gives some protection to earlier or later encrypted messages in case of a compromise of a party's keys.
https://signal.org/docs/specifications/doubleratchet/
https://eprint.iacr.org/2016/1013.pdf
https://github.com/sebastianv89/double-ratchet (rust impl)
Private Contact Discovery
Off The Record Messaging
encrypted and authenticated
deniability: The messages you send do not have digital signatures that are checkable by a third party. Anyone can forge messages after a conversation to make them look like they came from you. However, during a conversation, your correspondent is assured the messages he sees are authentic and unmodified.
perfect forward secrecy: If you lose control of your private keys, no previous conversation is compromised.
https://otr.cypherpunks.ca/
https://github.com/otrv4/otrv4/blob/master/otrv4.md
more