Np1sec/Specification - learn.equalit.ie

Procedures

Chat setup

In almost any practical case, participants join the chat sequentially. It is assumed that multiple participants cannot join simultaneously. For the sake of efficiency one can tweak the implementation to have a threshold to wait and start a chat with more participants. However, this makes the implementation significantly more complicated without an evident efficiency benefit.

Therefore, our assumption is that a secure chat is always set up when a participant starts the chat room. Additional participants would be added sequentially using Algorithm VIII.3, as they enter the chat. Algorithm 1 describes the chat room setup protocol.

Chatroom setup

Procedure Chatroom Init
Input:  $newRoomName$ , $participantNick$ 
  global  $myId:=1$ 
  global  $Nick_{{myId}}:=participantNick$ 
  global  $roomName:=newRoomName$ 
  global  $x_{{myId}},y_{{myId}}:=$  Generate Initial Paramters( $myId$ )
  global  $signatureKey_{{myId}}:=(x_{{myId}},y_{{myId}})$ 
   $participantList:=[Nick_{{myId}}]$ 
   $ephemeralPublicPointList:=[y_{{myId}},y_{{other}}]$

Joining

Joining a chat involves two different procedures: the Join procedure, described in Algorithm 2, which runs on the new participant’s instance, and an Accept New Participant Procedure, described in Algorithm 3, which runs on the clients of participants that are already in the chat.

When a new participant $U_{{n+1}}$ joins the chat, current participants can still use their established authenticated ephemeral public key (to derive the $sessionKey_{{new}}$ and as their signature verification key). Confidentiality of $sessionKey_{{old}}$ is guarded against the new participant by Diffie-Hellman key shares hashed alongside the session id (which is dependent on the list of participants). The new participant cannot combine the old and new shares to recover $sessionKey_{{old}}$ . The fact that old participants do not need to compute new ephemeral keys (and re-verify their ephemeral identities) decreases the computational complexity of the protocol.

Join

Procedure Join
Input:  $newRoomName$ ,  $Nickname_{{myId}}$ ,  $participantId$ 
  global  $myId:=participantId$ 
  global  $roomName:=newRoomName$ 
   $x_{{myId}},y_{{myId}}:=$ Generate Initial Paramters( $myId$ )
  global  $signatureKey_{{myId}}:=(x_{{myId}},y_{{myId}})$ 
  Broadcast(":3mpCAT:3Join:3",  $myId$ ,  $Nickname_{{myId}}$ ,  $y_{{myId}}$ )
  global  $participantList,ephemeralPublicPointList:=$  Receive()
  global  $sessionId:=$  Compute Session Id( $roomName$ ,  $participantList$ ,  $ephemeralPublicPointList$ )
  Sign and Send Key Confirmation and Shares()
  Wait On Receive(":3mpCAT:3KeyConfirmationShare:3")
  global  $keyShareList,keyConfirmationList,signatureList:=$  Receive()
  Verify Key Confirmations and Signatures( $keyConfirmationList$ ,  $signatureList$ )
  Update Session Key()

Procedure Receive Session Digest
Input:  $currentSessionHistoryDigest$ 
  global  $sessionDigest:=currentSessionHistoryDigest$

Protocol for other participants already in the chat to accept the newcomer

Procedure Accept
Input:  $newParticipant$ 
  Broadcast(":3mpCAT:3Join:3",  $myId$ ,  $Nickname_{{myId}}$ ,  $y_{{myId}}$ )
  Wait On Receive(":3mpCAT:3Join:3")
  global  $nick_{{NewParticipant}}$ ,  $ephemeralPublicPoint_{{NewParticipant}}:=$  Receive()
  Update Lists( $nick_{{NewParticipant}}$ ,  $ephemeralPublicPoint_{{NewParticipant}}$ )
  global  $sessionId:=$  Compute Session Id( $roomName$ ,  $participantList$ ,  $ephemeralPublicPointList$ )
  Sign and Send Key Confirmation and Shares()
  Wait On Receive(":3mpCAT:3KeyConfirmationShare:3")
  global  $keyShareList,keyConfirmationList,signatureList:=$  Receive()
  Verify Key Confirmations and Signatures( $keyConfirmationList$ ,  $signatureList$ )
  Update Session Key()
  Send( $sessionDigest$ )

Sending and receiving messages while joining is in progress

In situations where a prolonged joining process (due to connection problems or malicious activities) has an adverse effect on the user experience, it might be desirable to enable the joining users to communicate with the parties in the room, while maintaining minimum assurances of authenticity, confidentiality, forward secrecy, as well as consistency only among participants.

Consistency aspects of mpCat, both for the room view (plist) and for the transcript, are reached through group agreement. However, there are times when group agreement may be hard or impossible to reach either due to latency in a single participant connection or due to a single participant broadcasting incorrect confirmation data (such as wrong plist, sid, key share, etc).

We offer an extension to the mpCat protocol to tackle this problem during the joining process. When a new participant joins the room, they send their DH key shares to the other participants. The other participants send their ephemeral key in return. They then send their key confirmation and key share. If this extension is to be considered, as soon as each user receives a key confirmation from another user, who is not currently part of the session, mpCat displays a message highlighting the fact that although the user is not part of the session, the conversation is being shared with them (through P2P encryption using the key derived from DH Key). The protocol, however, does not honour their input into the consistency check, until a new session including the new user is set up. Each client can decide whether to disable this option.

The user remains in the list of those not part of the current session, but receives the session messages until a new session is set up. Similarly, when a user receives a message from a user who is not part of the session, mpCat will decrypt the message and display it with a disclaimer that the user is not yet part of the session and that some participants may not receive the same message.

In this model, a room is a forwardly secure authenticated communication channel while a session is a subset of the room, which additionally offers a consistent view of the room and consistent messages among participants.

Leave

Leaving a chatroom involves only one procedure for those who are staying in the chatroom (Procedure Farewell) which is described in Algorithm 4. The remaining participants only need a notice from the server that the user is leaving to re-run the one round key update algorithm. Also, failure to receive a heartbeat from a user will result in executing Algorithm 4 excluding users which did not update their key.

Farewell

Procedure Shrink on Leave
Input:  $leaverId$ 
  remove  $leaverId$  from  $participantIdList$ 
  global  $sessionId:=$  Compute Session Id()
  if  $|participantList|>1$ , then
    Sign and Send Key Shares()
    Wait On Receive(":3mpCAT:3KeyShare:3")
     $keyShareList$  := Receive()
    Update Session Key( $keyShareList$ )

Procedure Sign and Send Key Shares
Input: 
  global  $z_{{myId-1,myId}}:=Hash(k_{{myId,myId-1}},sessionId)$ 
  global  $z_{{myId,myId+1}}:=Hash(k_{{myId,myId+1}},sessionId)$ 
   $keyShare_{{myId}}:=z_{{myId-1,myId}}\oplus z_{{myId,myId+1}}$ 
   $originAuthSignature:=$  ED25519Sign( $SignatureKey$ ,  $sessionId$  ||  $z_{{myId}}$ )
  Broadcast(":3mpCAT:3KeyShare:3",  $myId$ ,  $keyShare_{{myId}}$ ,  $originAuthSignature$ )  # we can send this encrypted but leaving person can read it, hence theoretically it is the same as sending it unencrypted.

Secure Send and Receive

After the session key is established, participants will use Algorithms 5 and 6 to communicate securely.

On Send, the protocol checks the status of the new ephemeral Diffie-Hellman and key share using messages it receives from participants. It (re)sends any missing pieces. It also informs other participants which part of the key share is received by that user. The metadata flag indicates if the message being sent only contains meta data (e.g. heartbeat) or actual user communication.

On Receive, the protocol updates who has which pieces of the key shares. The protocol also generates a new group key if the new key shares have been received from all participants or those who have not updated their key shares time out on their heartbeat interval.

Send

Procedure Send

Input:  $metaMessage$ ,  $message$ 
   $keyShareMessage$  = NewKeyShareMessage( $metaMessage$ )
   $cryptMessage$  := AES CTR Encrypt( $sessionKey$ , $message|keyShareMessage$ )
   $originAuthSignature$  := ED25519Sign( $SignatureKey$ ,  $sessionId$  ||  $cryptMetatMessage$ )
   $sessionDigest$  := Compute Session Digest( $lastMessage$ )
  Broadcast(":3mpCAT:3",  $sessionId$ ,  $cryptMessage$ ,  $sessionDigest$ ,  $originAuthSignature$ ,":3")

Receive

Procedure Receive

Input: $sender$ , $encryptedMessage$ , $originAuthSignature$ , $sessionDigest$

   $v:=$  ED25519VerifySignature( $ephemeralPublicKeyList[Sender]$ ,  $sessionId||encryptedMessage$ ,  $originAuthSignature$ )
  Assert( $v$ ) or return Reject
   $message,keyShareMessage:=$  AES CTR Decrypt( $sessionKey$ ,  $encryptedMessage$ ){}
   $isMetaMessage=$ UpdateNewKeyStatus( $keyShareMessage$ )
  Verify Digests( $sessionDiges$ )
  return{ $isMetaMessage,message$ }  # isMetaMessage is true if the message is purely meta message and there is nothing to display

Common functions

Common functions used by other procedures in different stages

Procedure Generate Initial Paramters
Input:  $myId$ 
   $signaturePrivateKey:=$  RandomBits(256)
   $x_{{myId}}:=$  Ed25519 Scalar( $signaturePrivateKey$ )) #{This is both Diffie-Hellman secret and ephemeral signature private key}
   $y_{{myId}}:=x_{{myId}}P$ 
  return  $x,y$

Procedure Verify Key Confirmation and Signatures
Input:  $signatureList$ ,  $keyConfirmationList$ 
  for each  $participant\in participantList$ , do
    if  $keyConfirmationList[participant][myId]\neq Hash(k_{{myId,participant}},U_{{myId}})$ , then
      Halt()
    else if ED25519VerifySignature( $ephemeralPublicKeyList[particicpant]$ ,  $sessionId|keyShares[myId]$ ,  $originAuthSignature$ ) = Fail , then
      Halt()

Procedure Compute Session Id
Input:  $participantList$ ,  $ephemeralPublicPointList$ 
  return  $Hash(roomName,zip(participantList,ephemeralPublicPointList))$   #  $zip([a,b],[c,d]):=[(a,c),(b,d)]$

Procedure Verify Signatures
Input:  $longPublicList$ , $schnorrRandomPointList$ , 
# standard signature verification

Procedure Sign and Send Key Confirmation and Share
Input:  $schnorrRandomPointList$ 
  for each  $participant\in participantList$ , do
     $k_{{myId,participant}}:=Hash(x_{{myId}}LP_{{participant}}|lp_{{myId}}y_{{participant}}|x_{{myId}}y_{{participant}})$   # Triple DH
     $kc_{{myId}}:=kc_{{myId}}|Hash(k_{{myId,participant}},U_{{participant}})$ 
  global  $z_{{myId-1,myId}}:=Hash(k_{{myId,myId-1}},sessionId)$ 
  global  $z_{{myId,myId+1}}:=Hash(k_{{myId,myId+1}},sessionId)$ 
   $keyShare_{{myId}}:=z_{{myId-1,myId}}\oplus z_{{myId,myId+1}}$ 
   $originAuthSignature:=$  ED25519Sign( $SignatureKey$ ,  $sessionId$  ||  $z_{{myId}}$ )
  Broadcast(":3mpCAT:3KeyConfirmationAndShare:3",  $myId$ ,  $keyShare_{{myId}}$ ,  $originAuthSignature$ ,  $kc_{{myId}}$ )

Procedure Update Session Key
Input:  $keyShareList$ 
   $i:=myId$ 
  for each  ${j\in [i,...,i+n-1]}$ , do
      $z_{{j,j+1}}:=z_{{j-1,j}}\oplus keyShareListe[j+1]$ 
    # recovered  $z_{{i-1,i}}$  should be equal to its original value
   global  $sessionKey:=Hash(z_{{j,j+1}}|j\in [1...n])$

Procedure Sign Params Update Session Key
Input:  $toBeSigned$ ,  $signatureList$ , $keyShareList$ 
  Update Session Key()
   $toBeSigned:=Hash(sessionId,||Hash(verifierList,ephemeralPublicPointList,keyShareList)))$ 
   $signature_{{myId}}:=$ Sign Session and Send( $toBeSigned$ )
  Broadcast(":3mpCAT:3SignedSessionParameters:3", $signature_{{myId}}$ )

Procedure ComputeSessionDigest
Input:  $lastMessage$ 
  for each  $message$  in Messages Received from  $lastDigestedMessage$ +1 till  $lastMessage$ , do
      $sesionDigest:=Hass(sessionDigest,message)$  
     LRU Cache Store Digest( $sessionDigest$ ,  $message$ )
  return  $sessionDigest$ , $lastMessageId$

Procedure NewKeyShareMessage
Input:  $metaMessage$ 
# Based on metaMessage Determines what type of keyshare needs to be send (Ephemeral point or Group key share) and returen it.

Procedure UpdateNewKeyStatus
Input:  $keyShareMessage$ 
# Update the table of which participant has sent its new ephemeral point or its new group key share

Procedure Hash
Input:  $message$ 
   return SHA-512( $message$ )

Last modified on 19 September 2014, at 21:38