Changes

Np1sec/SenderKeys

1,153 bytes removed, 11 years ago
Dmitri moved page [[SenderKeys]] to [[Np1sec/SenderKeys]]
Users can only leave the conversation if the server says they left the room.
== Sender keys and Ephemeral signing 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")
 
== Server order ==
All clients see the same message order from the server. All messages are sent to all users. Aside from the presence messages sent by the server, messages are sent by users.
 
All messages in a room have a unique sequence number (0, 1, ...). Sequence numbers are implicit, as the server may not be aware of them (e.g. XMPP MUC).
 
A new user synchronizes his view of sequence numbers via the QUERY / MEMBER_LIST messages (see below).
 
== Causal order ==
Every user-sent message specifies a "parent" sequence number which is the last message the user received before sending it. Note:
* If Alice sends messages (A,B) in a row, A will not be B's parent unless Alice waits till A is received back from the server.
* The parent of a message is different from the "previous" message in the server's ordering, e.g. in a "simultaneous send" case two messages will have the same parent.
 
Due to server ordering, the sender of message i must have seen all
messages from 0...i's parent. Thus, every user-sent message i has a membership set, determined by the JOIN / USER_LEFT messages from 0...i's parent.
 
== Transcript hashes ==
Every message specifies its parent's sequence number. Some messages also specify a transcript hash of that parent and all prior messages. The hash also covers the sender_key for each message (set to zeros for cleartext messages):
 
H(parent) = SHA256(sender_key[parent] || ciphertext[parent] || H(parent-1))
== Timing ==
* "Presence" messages sent in clear by the server to indicate a user has entered or left the room
== Cleartext User messages from users ==
=== QUERY ===
* Contains a nonce
* Requests anyone to send a MEMBER_LIST
=== MEMBER_LIST ===
* Lists Contains the sequence number and nonce of the QUERY it's responding to * Lists Contains the transcript hash for the QUERY* Contains a certificate for each member as of its parentthe QUERY
=== JOIN ===
* Lists the Contains a certificate for the new member* Contains CONFIRM messages for each member the sequence number of its parent == Encrypted messages ==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 a the sequence number for its parent* The transcript hashand membership of its parent is included as "additional authenticated data"
=== DATA ===
* Encrypted under the sender's "sender key"
* Contains a transcript hash* Ed25519 signature from the sender's ephemeral public signing key* Contains the sequence number for its parent* The transcript hash and membership of its parent is included as "additional authenticated data"
= Algorithms =
== Nonblocking Blocking Join ==On entering a room, a user sends a QUERY. She is present in the room but hasn't yet joined the conversation. Someone (or multiple parties) 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, a present the new user learns the room's membership , transcript hash, and sequence numbersnumber for the QUERY message. To finish joining, and can keep track of the membership by observing subsequent new user sends a JOIN / USER_LEFT messages, including a CONFIRM for each existing member. Each member will respond to her JOIN message with a CONFIRM, containing a new sender key.
To join a room, a present Until the new user sends a JOINhas finished joining, including a CONFIRM for each member in its parentexisting members continue exchanging DATA with their old sender keys. Once the last confirmation has been received, and expects existing users switch to receive a CONFIRM from each member shortlytheir new sender keys.
After sending the JOIN, Once the new user considers herself part of has received all CONFIRM messages from the conversation and can send DATA messages and respond to QUERY messages. She responds to any subsequent JOINs with a CONFIRMexisting membership, she is successfully joined. If the subsequent JOIN doesn't include other users sent a CONFIRM for QUERY in the user (simultaneous join)meantime, then she expects the next one will be responded to receive one shortlywith a MEMBER_LIST.
== Blocking Nonblocking Join ==As aboveOn entering a room, except:* A a user is only added sends a QUERY. Someone will respond with a MEMBER_LIST. If multiple users try to group membership once all CONFIRMs from her JOIN, and any subsequent CONFIRMS (due to simultaneous join) have been simultaneously, they will all be responded to with CONFIRMsimmediately.* In On receiving a simultaneous JOIN caseMEMBER_LIST, the JOINs are handled based on new user learns the server ordering (earliest first)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.
Example: Alice and Bob are existing members. Charlie and Dave send simultaneous JOINs, but the server places Charlie's first. Alice and Bob send CONFIRM messages to both Charlie and Dave. Charlie and Dave send CONFIRM messages to each other. Once Charlie receive Alice and Bob's CONFIRMs, he's The new user is part of the group and can send DATAonce her JOIN message is received. Once Dave receives Alice, Bob, and Charlie's CONFIRMs, he's part of the This means that DATA can be sent between group and can send DATAmembers who have not yet confirmed each other.
[[Category: mpOTR]]
Dmitri
Bureaucrat, emailconfirmed, administrator, translator
662
edits
Retrieved from "https://learn.equalit.ie/wiki/Special:MobileDiff/773...1568"