_Secure_ Messaging

[4meta5]

Signal's Double Ratchet Algorithm

used by two parties to exchange encrypted messages based on a shared secret key

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

https://github.com/claucece/useful-crypto-resources

• https://eprint.iacr.org/2017/239.pdf
• https://www.cypherpunks.ca/~iang/pubs/mpotr.pdf
• https://www-users.cs.umn.edu/~hoppernj/gotr.pdf

[4meta5]

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)

[4meta5]

Keybase Key Exchange Protocol

https://keybase.io/docs/crypto/key-exchange

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.

[4meta5]

MLS

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

High Level Service Architecture

The Messaging Service (MS) presents as two abstract services that allow clients to prepare for sending and receiving messages securely:

1. An Authentication Service (AS) which is responsible for maintaining user long term identities, issuing credentials which allow them to authenticate each other, and potentially allowing users to discover each others long-term identity keys.
2. A Delivery Service (DS) which is responsible for receiving and redistributing messages between group members. In the case of group messaging, the delivery service may also be responsible for acting as a "broadcaster" where the sender sends a single message to a group which is then forwarded to each recipient in the group by the DS. The DS is also responsible for storing and delivering initial public key material required by clients in order to proceed with the group secret key establishment process.

TreeKEM: Continuous Group Key Agreement

https://eprint.iacr.org/2019/1189.pdf

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.

[4meta5]

Secure Scuttlebutt

https://scuttlebot.io/more/protocols/shs.pdf

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

claims to improve on noise and TextSecure, but sacrifices handshake latency

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