Understanding Signal Protocol Notes
Understanding Signal Protocol Notes
Notes
Security Services
~~~~~~~~~~~~~~~~~
# Encryption
AES, RSA
# Digital Signature
RSA
# Key Exchange
DFKE, ECDH, X3DH
Alice Bob
Alice and Bob uses AES with kAB to exchange messages between them
RSA Encryption
~~~~~~~~~~~~~~~
# Ref:
Book: Understanding Cryptography, Chapter 7, The RSA Cryptosystem
https://www.dropbox.com/s/rrwtm3k0tcoxfau/2010_Book_UnderstandingCryp
tography.pdf?dl=0
# Bob's parameters:
Large Prime = p
Large Prime = q
n = p.q
Phi(n) = (p-1).(q-1)
e = {1,2,...,Phi(n)-1}
e and Phi(n) are coprime: GCD(e,Phi(n)) = 1
d = Inverse(e)
d.e = 1 mod Phi(n)
# Bob's Keys:
Private Key (1024+ bits) = d = PrkB
Public Key = (n,e) = PkB
# Bob's DH Keys:
Private Key {2,3,...,p-2} = PrkB
Public Key = g^PrkB mod p = PkB
# Alice downloads Bob’s published IPkB from the server, to use for
signature verification
# Alice and Bob uses AES with kAB to exchange messages between them
P = (x1,y1)
Q = (x2,y2)
R = P + Q = (x1,y1) + (x2,y2) = (x3,y3)
# Point Addition:
R = P + Q
Draw a line through P and Q and obtain a third point of intersection
between the elliptic curve and the line. Mirror this
third intersection point along the x-axis. This mirrored point is, by
definition, the point R.
# Point Doubling:
P = Q
R = P + P = 2P
# Equation:
P + Q = (x1,y1) + (x2,y2) = (x3,y3)
Alice Bob
Domain parameters:
Large Prime (1024 or 2048 bits) = p
Primitive element = (xP,yP) = P
Coefficients a and b of Elliptic Curve E: y^2 ≡ x^3 + a.x + b mod p
Keys: Keys:
Private Key {2,3,...,#E-1} = PrkA Private Key {2,3,…,#E-1} = PrkB
Public Key = P o PrkA = (xA,yA) = Public Key = P o PrkB = (xB,yB)
PkA = PkB
Alice and Bob uses AES with HkAB to exchange messages between them
# Scenario:
Alice wants to send initial message to Bob.
All keys used for generating Shared Secret Keys are Elliptic Curve
Diffie Hellman keys.
# Parameters:
Elliptic Curve = X25519 or X448
Hash Function = SHA512
Digital Signature = XEdDSA
Key Derivation Function (KDF) = HKDF
Alice Bob
Prekey Signature
= Sign(hash(SPkB),IPrkB)
= SigB
Bob will also upload a new signed prekey and prekey signature at
some interval (e.g. once a week, or once a month). The new signed
prekey SPkB and corresponding signature SigB will replace the
previous values.
Bob may keep the private key corresponding to the previous signed
prekey around for some period of time, to handle messages using it
that have been delayed in transit. Eventually, Bob should delete
this private key for forward secrecy.
Calculate Diffie-Helmans:
Shared Secret Key 1 =
DH(SPkB,IPrkA) = kAB1
Shared Secret Key 2 =
DH(IPkB,EPrkA) = kAB2
Shared Secret Key 3 =
DH(SPkB,EPrkA) = kAB3
Shared Secret Key 4 =
DH(OPkB3,EPrkA) = kAB4
(if no OPkB3, then kAB4 is not
computed)
Calculate Diffie-Helmans:
Shared Secret Key 1 =
DH(IPkA,SPrkB) = kAB1
Shared Secret Key 2 =
DH(EPkA,IPrkB) = kAB2
Shared Secret Key 3 =
DH(EPkA,SPrkB) = kAB3
Shared Secret Key 4 =
DH(EPkA,OPrkB3) = kAB4
(if no OPkB3 ID was sent by
Alice, then kAB4 is not
computed)
If decryption succeeds,
Bob deletes his one-time
private key (OPrkB3) used by
Alice, for forward secrecy.
Bob will periodically generate and upload new signed prekey SPkB
and corresponding signature SigB. He will eventually delete the old
SPrkB to provide perfect forward secrecy.
For authentication, Bob and Alice can compare their identity public
keys IPkA and IPkB by comparing public key fingerprints manually or
by scanning a QR code. This is not part of X3DH protocol.
# KDF Chains:
A KDF chain has the following properties:
1. The output keys appear random to an adversary without knowledge of
the KDF keys. This is true even if the adversary can control the KDF
inputs.
2. Output keys from the past appear random to an adversary who learns
the KDF key at some point in time.
3. Future output keys appear random to an adversary who learns the
KDF key at some point in time, provided that future inputs have added
sufficient entropy.
In a Double Ratchet session between Alice and Bob each party stores a
KDF key for three chains: a root chain, a sending chain, and a
receiving chain (Alice's sending chain matches Bob's receiving chain,
and vice versa).
# Symmetric-key ratchet:
Every message sent or received is encrypted with a unique message
key. The message keys are output keys from the sending and receiving
KDF chains.
The KDF inputs for the sending and receiving chains are constant. The
sending and receiving chains just ensure that each message is
encrypted with a unique key that can be deleted after encryption or
decryption. Because message keys aren't used to derive any other
keys, message keys may be stored without affecting the security of
other message keys.
# Diffie-Hellman ratchet:
If an attacker steals one party's sending and receiving chain keys,
the attacker can compute all future message keys and decrypt all
future messages. To prevent this, the Double Ratchet combines the
symmetric-key ratchet with a DH ratchet which updates chain keys
based on Diffie-Hellman outputs.
Alice Bob
Delete keys:
Root Chain Key 1 = kAB1
Delete keys:
Sending Chain Key 1 = SkA1
Sender Alice's Message Key 1 =
A1
Delete keys:
Root Chain Key 1 = kAB1
Delete keys:
Receiving Chain Key 1 = RkB1
Receiver Bob's Message Key 1 = A1
Delete keys:
Root Chain Key 2 = kAB2
Delete keys:
Sending Chain Key 1 = SkB1
Sender Bob's Message Key 1 = B1
Since Alice received a new Ratchet Public Key from Bob, she must:
1. Step up the Root Chain Ratchet.
2. If encrypted message exists, reset the Receiving Chain Ratchet.
3. If encrypted message exists, step up the Receiving Chain
Ratchet.
4. Generate a new pair of Diffie-Hellman Ratchet keys.
5. Step up the Root Chain Ratchet again.
6. Reset the Sending Chain Ratchet.
RkA1 = SkB1
Delete keys:
Root Chain Key 2 = kAB2
Delete keys:
Receiving Chain Key 1 = RkA1
Receiver Alice's Message Key 1 =
B1
Delete keys:
Root Chain Key 3 = kAB3
Since Alice and Bob are both using their existing Ratchet Key, they
must:
1. For every encrypted message received, step up the Receiving
Chain Ratchet.
2. For every message to send, step up the Sending Chain Ratchet.
Alice received messages B3 and B4 with the Bob's new ratchet public
key
and sends a message A5.
Since Alice received message B3 with a new Ratchet Public Key from
Bob, she must:
1. Step up the Root Chain Ratchet.
2. If encrypted message exists, reset the Receiving Chain Ratchet.
3. If encrypted message exists, step up the Receiving Chain
Ratchet.
4. Generate a new pair of Diffie-Hellman Ratchet keys.
5. Step up the Root Chain Ratchet again.
6. Reset the Sending Chain Ratchet.
Since Bob received message A5 with a new Ratchet Public Key from
Alice, he must:
1. Step up the Root Chain Ratchet.
2. If encrypted message exists, reset the Receiving Chain Ratchet.
3. If encrypted message exists, step up the Receiving Chain
Ratchet.
4. Generate a new pair of Diffie-Hellman Ratchet keys.
5. Step up the Root Chain Ratchet again.
6. Reset the Sending Chain Ratchet.
# Out-of-order messages:
The Double Ratchet handles lost or out-of-order messages by including
in each message header the message's number in the sending chain
(N=0,1,2,...) and the length (number of message keys) in the previous
sending chain (PN). This enables the recipient to advance to the
relevant message key while storing skipped message keys in case the
skipped messages arrive later.
For example, consider the message sequence from the previous section
when messages B2 and B3 are skipped. Message B4 will trigger Alice's
DH ratchet step (instead of B3). Message B4 will have PN=2 and N=1.
On receiving B4 Alice will have a receiving chain of length 1 (B1),
so Alice will store message keys for B2 and B3 so they can be
decrypted if they arrive later:
Sesame Algorithm
~~~~~~~~~~~~~~~~~
Ref:
The Sesame Algorithm: Session Management for Asynchronous Message
Encryption
https://signal.org/docs/specifications/sesame/
# Scenarios:
1. Alice and Bob might each have several devices, so encrypting a
message from Alice to Bob might require creating sessions from
Alice's sending device to all of Bob's devices, and also to Alice's
other devices (so they receive a copy of the message).
2. Alice and Bob might add and remove devices, so they will have to
add and delete sessions to handle these changes.
3. Alice and Bob might simultaneously initiate a new session with
each other, so that two new sessions are created. For the Double
Ratchet to be maximally effective Alice and Bob must send and receive
messages using matching sessions, so they must agree on which
matching sessions to use.
4. Alice might choose to erase her device's session state, or restore
from a backup, thus causing either her or Bob to possess orphaned
sessions which no longer match one of the other party's sessions.
# Assumptions:
1. Each user has a UserID (a username or phone number).
1. Users can add or delete devices at any time.
2. Each device has a DeviceID which is unique for the UserID.
3. Each device has an identity key pair.
3. The server stores a mailbox for each device.
4. Devices send messages to other devices' mailboxes. Server stores
the sending device's UserID and DeviceID alongside the message.
5. Devices fetch messages from their own mailbox. Recipient device
fetches the message and the sender's UserID and DeviceID from the
server.
6. Messages can be encrypted and decrypted using a session, which is
some secret data stored by a device.
7. SessionID uniquely identifies each session.
8. A device can create a new initiating session at any time.
# Device States:
1. Each device stores a set of UserIDs, and corresponding DeviceIDs.
Enables enables a device to send a copy of each outbound message to
the user's other devices.
2. Sesame supports two different models for key pairs: With per-user
identity keys, all devices under a user share the same key pair. With
per-device identity keys, each device may have a different key pair.