Difference between revisions of "Np1sec/SenderKeys"
m (Dmitri moved page SenderKeys to Np1sec/SenderKeys) |
|||
| (15 intermediate revisions by 2 users not shown) | |||
| Line 22: | Line 22: | ||
When a new user joins, she generates a new AES256 key (her "sender key") and Ed25519 key (her "signing key"). She then sends these keys to existing members, encrypted under the "pairwise keys" from pairwise key agreements. This allows subsequent messages to be encrypted-and-signed once, instead of N times with pairwise keys. | When a new user joins, she generates a new AES256 key (her "sender key") and Ed25519 key (her "signing key"). She then sends these keys to existing members, encrypted under the "pairwise keys" from pairwise key agreements. This allows subsequent messages to be encrypted-and-signed once, instead of N times with pairwise keys. | ||
| − | Every time a message is encrypted or decrypted with a sender key, the key is updated to provide forward secrecy: | + | Every time a message is encrypted or decrypted with a sender key, the key is afterwards updated to provide forward secrecy: |
sender_key = HMAC-SHA256(prev_sender_key, "0") | sender_key = HMAC-SHA256(prev_sender_key, "0") | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Timing == | == Timing == | ||
| Line 83: | Line 63: | ||
=== JOIN === | === JOIN === | ||
* Contains a certificate for the new member | * Contains a certificate for the new member | ||
| + | * Contains the sequence number of the MEMBER_LIST it's responding to | ||
=== CONFIRM === | === CONFIRM === | ||
| Line 93: | Line 74: | ||
=== DATA === | === DATA === | ||
* Encrypted under the sender's "sender key" | * Encrypted under the sender's "sender key" | ||
| − | * Ed25519 signature from the sender's | + | * Ed25519 signature from the sender's signing key |
* Contains the sequence number for its parent | * Contains the sequence number for its parent | ||
* The transcript hash and membership of its parent is included as "additional authenticated data" | * The transcript hash and membership of its parent is included as "additional authenticated data" | ||
Latest revision as of 18:48, 2 December 2014
Security Goals
Transcript consistency
- Recipients are informed of the correct causal order of messages
- Excessively delayed messages are detected
Nonblocking join
- Join and leave are treated as messages, so transcript consistency applies (causal order, delays are detected).
- New users have to "confirm" to existing users to join.
- Existing users have to "confirm" to the new user shortly after the new user joins (e.g. 1 minute).
General concepts
Room membership
Users can enter and leave the room, as signalled by presence messages from the server (USER_ENTERED, USER_LEFT).
Users can join the room's conversation by sending a JOIN message.
Users can only leave the conversation if the server says they left the room.
Sender keys and Signing keys
When a new user joins, she generates a new AES256 key (her "sender key") and Ed25519 key (her "signing key"). She then sends these keys to existing members, encrypted under the "pairwise keys" from pairwise key agreements. This allows subsequent messages to be encrypted-and-signed once, instead of N times with pairwise keys.
Every time a message is encrypted or decrypted with a sender key, the key is afterwards updated to provide forward secrecy:
sender_key = HMAC-SHA256(prev_sender_key, "0")
Timing
Timing rules can trigger errors based on some assumed constants:
- MAX_RTT - this is the maximum time it should take for a sent message to arrive at all parties. If you send a message and haven't received it back within MAX_RTT, something is wrong.
- MAX_RTD - this is the maximum difference in time when a message arrives at all parties. If you receive a message that's not a successor of a message (X) you received more than MAX_RTD + MAX_RTT time ago, something is wrong. (This is because message X might have arrived at the other party more than MAX_RTD after you saw it, and the other party's message might have taken MAX_RTT to reach you. But after MAX_RTD + MAX_RTT, there's no excuse for the other party not to have seen X).
- MAX_CONFIRM - this is the maximum time an existing member may spend after receiving a new user's JOIN message before sending a CONFIRM message in response. If the new user hasn't received CONFIRM messages from existing membership within 2*MAX_RTT + MAX_CONFIRM, something is wrong.
Messages
Generic structures
Certificate
- The user's Curve25519 identity public key
- The user's Curve25519 ephemeral public key
- An Ed25519 signature from the identity key over the ephemeral key
(Ed25519 signatures can be produced from Curve25519 keys)
Server messages
USER_ENTERED, USER_LEFT
- "Presence" messages sent in clear by the server to indicate a user has entered or left the room
User messages
QUERY
- Contains a nonce
- Requests a MEMBER_LIST
MEMBER_LIST
- Contains the sequence number and nonce of the QUERY it's responding to
- Contains the transcript hash for the QUERY
- Contains a certificate for each member as of the QUERY
JOIN
- Contains a certificate for the new member
- Contains the sequence number of the MEMBER_LIST it's responding to
CONFIRM
- Encrypts-and-confirms an AES256 "sender key" and Ed25519 "signing key" from one member to another
- Uses pairwise TripleDH between sender and recipient keys, i.e.
HASH( DH(A_id, B_eph) || DH(A_eph, B_id) || DH(A_eph, B_eph) )
- Contains the sequence number for its parent
- The transcript hash and membership of its parent is included as "additional authenticated data"
DATA
- Encrypted under the sender's "sender key"
- Ed25519 signature from the sender's signing key
- Contains the sequence number for its parent
- The transcript hash and membership of its parent is included as "additional authenticated data"
Algorithms
Blocking Join
On entering a room, a user sends a QUERY. Someone will respond with a MEMBER_LIST. If two users try to join simultaneously, the second QUERY will not be responded to until the first user has finished joining.
On receiving a MEMBER_LIST, the new user learns the membership, transcript hash, and sequence number for the QUERY message. To finish joining, the new user sends a JOIN, including a CONFIRM for each existing member. Each member will respond to her JOIN message with a CONFIRM, containing a new sender key.
Until the new user has finished joining, existing members continue exchanging DATA with their old sender keys. Once the last confirmation has been received, existing users switch to their new sender keys.
Once the new user has received all CONFIRM messages from the existing membership, she is successfully joined. If other users sent a QUERY in the meantime, the next one will be responded to with a MEMBER_LIST.
Nonblocking Join
On entering a room, a user sends a QUERY. Someone will respond with a MEMBER_LIST. If multiple users try to join simultaneously, they will all be responded to immediately.
On receiving a MEMBER_LIST, the new user learns the membership, transcript hash, and sequence number for the QUERY message. To finish joining, the new user sends a JOIN, including a CONFIRM for each existing member. Each member will respond to her JOIN message with a CONFIRM, containing their current sender key.
The new user is part of the group once her JOIN message is received. This means that DATA can be sent between group members who have not yet confirmed each other.
