learn.equalit.ie - User contributions [en]

Np1sec/Specification

2014-09-19T21:38:01Z

Infinity0: add category

== 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 [[mpCAT#VIII.3_Joining|VIII.3]], as they enter the chat. Algorithm [[mpCAT#Chatroom_setup|1]] describes the chat room setup protocol.

====Chatroom setup====

{{algorithm-begin|name=Chatroom Init}}
Input: <math>newRoomName</math>,<math>participantNick</math>
'''global''' <math>myId := 1</math>
'''global''' <math>Nick_{myId} := participantNick</math>
'''global''' <math>roomName := newRoomName</math>
'''global''' <math>x_{myId}, y_{myId} :=</math> '''Generate Initial Paramters'''(<math>myId</math>)
'''global''' <math>signatureKey_{myId} := (x_{myId},y_{myId})</math>
<math>participantList := [Nick_{myId}]</math>
<math>ephemeralPublicPointList := [y_{myId}, y_{other}]</math>
{{algorithm-end}}

=== Joining ===

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

When a new participant <math>U_{n+1}</math> joins the chat, current participants can still use their established authenticated ephemeral public key (to derive the <math>sessionKey_{new}</math> and as their signature verification key). Confidentiality of <math>sessionKey_{old}</math> 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 <math>sessionKey_{old}</math>. 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====

{{algorithm-begin|name=Join}}
Input: <math>newRoomName</math>, <math>Nickname_{myId}</math>, <math>participantId</math>
'''global''' <math>myId := participantId</math>
'''global''' <math>roomName := newRoomName</math>
<math>x_{myId}, y_{myId} := </math>'''Generate Initial Paramters'''(<math>myId</math>)
'''global''' <math>signatureKey_{myId} := (x_{myId},y_{myId})</math>
'''Broadcast'''(":3mpCAT:3Join:3", <math>myId</math>, <math>Nickname_{myId}</math>, <math>y_{myId}</math>)
'''global''' <math>participantList, ephemeralPublicPointList :=</math> '''Receive'''()
'''global''' <math>sessionId := </math> '''Compute Session Id'''(<math>roomName</math>, <math>participantList</math>, <math>ephemeralPublicPointList</math>)
'''Sign and Send Key Confirmation and Shares'''()
'''Wait On Receive'''(":3mpCAT:3KeyConfirmationShare:3")
'''global''' <math>keyShareList, keyConfirmationList, signatureList :=</math> '''Receive'''()
'''Verify Key Confirmations and Signatures'''(<math>keyConfirmationList</math>, <math>signatureList</math>)
'''Update Session Key'''()
{{algorithm-end}}

{{algorithm-begin|name=Receive Session Digest}}
Input: <math>currentSessionHistoryDigest</math>
'''global''' <math>sessionDigest := currentSessionHistoryDigest</math>
{{algorithm-end}}

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


{{algorithm-begin|name=Accept}}
Input: <math>newParticipant</math>
'''Broadcast'''(":3mpCAT:3Join:3", <math>myId</math>, <math>Nickname_{myId}</math>, <math>y_{myId}</math>)
'''Wait On Receive'''(":3mpCAT:3Join:3")
'''global''' <math>nick_{NewParticipant}</math>, <math>ephemeralPublicPoint_{NewParticipant} := </math> '''Receive'''()
'''Update Lists'''(<math>nick_{NewParticipant}</math>, <math>ephemeralPublicPoint_{NewParticipant}</math>)
'''global''' <math>sessionId := </math> '''Compute Session Id'''(<math>roomName</math>, <math>participantList</math>, <math>ephemeralPublicPointList</math>)
'''Sign and Send Key Confirmation and Shares'''()
'''Wait On Receive'''(":3mpCAT:3KeyConfirmationShare:3")
'''global''' <math>keyShareList, keyConfirmationList, signatureList :=</math> '''Receive'''()
'''Verify Key Confirmations and Signatures'''(<math>keyConfirmationList</math>, <math>signatureList</math>)
'''Update Session Key'''()
'''Send'''(<math>sessionDigest</math>)
{{algorithm-end}}

=== 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 [[mpCAT#Farewell|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 [[mpCAT#Farewell|4]] excluding users which did not update their key.

====Farewell====

{{algorithm-begin|name=Shrink on Leave}}
Input: <math>leaverId</math>
'''remove''' <math>leaverId</math> from <math>participantIdList</math>
'''global''' <math>sessionId :=</math> '''Compute Session Id'''()
'''if''' <math>|participantList| > 1</math>''', then'''
'''Sign and Send Key Shares'''()
'''Wait On Receive'''(":3mpCAT:3KeyShare:3")
<math>keyShareList</math> := '''Receive'''()
'''Update Session Key'''(<math>keyShareList</math>)
{{algorithm-end}}

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

=== Secure Send and Receive ===

After the session key is established, participants will use Algorithms [[mpCAT#Send|5]] and [[mpCAT#Receive|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====

{{algorithm-begin|name=Send}}
----

Input: <math>metaMessage</math>, <math>message</math>
<math>keyShareMessage</math> = '''NewKeyShareMessage'''(<math>metaMessage</math>)
<math>cryptMessage</math> := '''AES CTR Encrypt'''(<math>sessionKey</math>,<math>message | keyShareMessage</math>)
<math>originAuthSignature</math> := '''ED25519Sign'''(<math>SignatureKey</math>, <math>sessionId</math> || <math>cryptMetatMessage</math>)
<math>sessionDigest</math> := '''Compute Session Digest'''(<math>lastMessage</math>)
'''Broadcast'''(":3mpCAT:3", <math>sessionId</math>, <math>cryptMessage</math>, <math>sessionDigest</math>, <math>originAuthSignature</math>,":3")
{{algorithm-end}}

====Receive====

{{algorithm-begin|name=Receive}}
Input: <math>sender</math>, <math>encryptedMessage</math>, <math>originAuthSignature</math>, <math>sessionDigest</math>
<math>v := </math> '''ED25519VerifySignature'''(<math>ephemeralPublicKeyList[Sender]</math>, <math>sessionId || encryptedMessage</math>, <math>originAuthSignature</math>)
'''Assert'''(<math>v</math>) or '''return''' Reject
<math>message, keyShareMessage :=</math> '''AES CTR Decrypt'''(<math>sessionKey</math>, <math>encryptedMessage</math>){}
<math>isMetaMessage = </math>'''UpdateNewKeyStatus'''(<math>keyShareMessage</math>)
'''Verify Digests'''(<math>sessionDiges</math>)
'''return'''{<math>isMetaMessage, message</math>} # isMetaMessage is true if the message is purely meta message and there is nothing to display
{{algorithm-end}}

=== Common functions ===

====Common functions used by other procedures in different stages====

{{algorithm-begin|name=Generate Initial Paramters}}
Input: <math>myId</math>
<math>signaturePrivateKey := </math> '''RandomBits'''(256)
<math>x_{myId} :=</math> '''Ed25519 Scalar'''(<math>signaturePrivateKey</math>)) #{This is both Diffie-Hellman secret and ephemeral signature private key}
<math>y_{myId} := x_{myId}P</math>
'''return''' <math>x,y</math>
{{algorithm-end}}

{{algorithm-begin|name=Verify Key Confirmation and Signatures}}
Input: <math>signatureList</math>, <math>keyConfirmationList</math>
'''for each''' <math>participant \in participantList</math>, '''do'''
'''if''' <math>keyConfirmationList[participant][myId] \neq Hash(k_{myId,participant} , U_{myId} )</math>''', then'''
'''Halt'''()
'''else''' '''if''' '''ED25519VerifySignature'''(<math>ephemeralPublicKeyList[particicpant]</math>, <math>sessionId | keyShares[myId]</math>, <math>originAuthSignature</math>) = Fail ''', then'''
'''Halt'''()
{{algorithm-end}}

{{algorithm-begin|name=Compute Session Id}}
Input: <math>participantList</math>, <math>ephemeralPublicPointList</math>
'''return''' <math>Hash(roomName, zip(participantList, ephemeralPublicPointList))</math> # <math>zip([a,b],[c,d]):=[(a,c),(b,d)]</math>
{{algorithm-end}}

{{algorithm-begin|name=Verify Signatures}}
Input: <math>longPublicList</math>,<math>schnorrRandomPointList</math>,
# standard signature verification
{{algorithm-end}}

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

{{algorithm-begin|name=Update Session Key}}
Input: <math>keyShareList</math>
<math>i := myId</math>
'''for each''' <math>{j \in [i,...,i+n-1]}</math>, '''do'''
<math>z_{j,j+1} := z_{j-1,j} \oplus keyShareListe[j+1]</math>
# recovered <math>z_{i-1,i}</math> should be equal to its original value
'''global''' <math>sessionKey := Hash(z_{j,j+1} | j \in [1...n])</math>
{{algorithm-end}}

{{algorithm-begin|name=Sign Params Update Session Key}}
Input: <math>toBeSigned</math>, <math>signatureList</math>,<math>keyShareList</math>
'''Update Session Key'''()
<math>toBeSigned := Hash(sessionId, ||Hash(verifierList, ephemeralPublicPointList, keyShareList)))</math>
<math>signature_{myId} := </math>'''Sign Session and Send'''(<math>toBeSigned</math>)
'''Broadcast'''(":3mpCAT:3SignedSessionParameters:3",<math>signature_{myId}</math>)
{{algorithm-end}}

{{algorithm-begin|name=ComputeSessionDigest}}
Input: <math>lastMessage</math>
'''for each''' <math>message</math> in Messages Received from <math>lastDigestedMessage</math>+1 till <math>lastMessage</math>, '''do'''
<math>sesionDigest := Hass(sessionDigest, message)</math>
'''LRU Cache Store Digest'''(<math>sessionDigest</math>, <math>message</math>)
'''return''' <math>sessionDigest</math>,<math>lastMessageId</math>
{{algorithm-end}}

{{algorithm-begin|name=NewKeyShareMessage}}
Input: <math>metaMessage</math>
# Based on metaMessage Determines what type of keyshare needs to be send (Ephemeral point or Group key share) and returen it.
{{algorithm-end}}

{{algorithm-begin|name=UpdateNewKeyStatus}}
Input: <math>keyShareMessage</math>
# Update the table of which participant has sent its new ephemeral point or its new group key share
{{algorithm-end}}

{{algorithm-begin|name=Hash}}
Input: <math>message</math>
'''return''' '''SHA-512'''(<math>message</math>)
{{algorithm-end}}

[[Category: mpOTR]]

Main Page

2014-09-19T21:37:30Z

Infinity0: relink to landing page

'''eQualit.ie's whitepapers, documentation and training guides. Free to use and share'''

* [[Curricula|a Digital Security Trainer's Curricula]]
* Online manual on [http://equalit.ie/esecman/index.html Digital Security for Human Rights Defenders]
* [[Secure hosting guide]]
* [[Online Learning|Digital Security lessons]]
* [[MpOTR|mpOTR: multi-party OTR protocol]]

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

MpOTRPages

2014-09-19T21:37:11Z

Infinity0: ask to delete

obsolete, sysops please delete

[[Category: Delete]]

Np1sec/Sept9

2014-09-19T21:32:59Z

Infinity0: Infinity0 moved page MpOTRSept9 to MpOTR/Meetings/Sept9

Preliminary agenda for the September 9th meeting in DC.

*Transport assumptions:
**Investigating properties offered by XMMP-MUC (and cost of considering other protocols)
**Offering reliable transport (deciding if its part of this protocol or part of the transport layer and implications over transcript consistency)

*Transcript consistency:
**Choice between simple consistency for globally order messages or incremental for less reliable transport.
**Figuring out if mpOTR is only responsible for announcing inconsistency or it is also need to try to recover from inconsistency.

*Consistence view:
**mpOTR require that member of each session has the same view of the room before the session starts and all see the same text.
**The DoS attacks that can be applied to consistence room view scenario and its mitigation.
**The benefit of having a shared key or each individual manages their own key.

By the end of the meeting, final protocol specification should be decided, specifically:

*Simple consistency vs incremental consistency
*Requiring a consistent view of the room
*Shared key or independent key

[[Category: mpOTR]]

MpOTRSept9

2014-09-19T21:32:59Z

Infinity0: Infinity0 moved page MpOTRSept9 to MpOTR/Meetings/Sept9

#REDIRECT [[MpOTR/Meetings/Sept9]]

Talk:MpOTR/Overview

2014-09-19T21:29:45Z

Infinity0: Infinity0 moved page Talk:MpOTR to Talk:MpOTR/Overview: splitting doc into Overview/Specification

This is a threaded discussion list to collate all discourse on protocol creation, adversarial models, et al. Should you wish to contact us directly by email, please use http://equalit.ie/#contact

Talk:MpOTR

2014-09-19T21:29:45Z

Infinity0: Infinity0 moved page Talk:MpOTR to Talk:MpOTR/Overview: splitting doc into Overview/Specification

#REDIRECT [[Talk:MpOTR/Overview]]

TransportAssumptions

2014-09-19T21:28:57Z

Infinity0: content is redundant, repeated elsewhere

obsolete, sysops please delete

[[Category: Delete]]

Np1sec/SenderKeys

2014-09-19T21:26:12Z

Infinity0: /* General concepts */ move ordering/consistency stuff to main page

2014-08-04T15:58:41Z

Infinity0: Reply to Transport reliability

''> In my opinion mpCAT should be like SSL and IPSEC, the messaging transport control protocol (MTCP) should act like TCP... ''

We are working on end-to-end security principles, which applies for reliability too. TCP reliability is on the transport layer, not end-to-end between clients working on separate TCP connections. XMPP MUC reliability helps, but is not general enough: as I noted in the other thread, typically public services do not have the incentive, and cannot afford (due to threat of DoS) to offer ''unconditional'' reliability - they can only offer ''limited'' reliability, i.e. finite-time buffer or finite-message buffer, as experienced on real-world MUC servers.

As I explain in msg-notes, consistency is closely related to reliability; therefore it's best done ''within'' the end-to-end reliability layer. For example, your proposed scheme ''fails badly'' in the general case where the server cannot provide end-to-end reliability.

I agree that deniable authenticity and forward-secure confidentiality is best done in a separate layer, though. The idea of separation is good, but I disagree with how you're choosing to separate things, based on my research into the consistency problem.

''> I think assuming extra ordinary config/storage/abilities for the server, defeat the purpose of end-to-endness. If some participants are malicious...''

Context for others: this is for a server-dictated order that supports end-to-end reliability.

Participants might innocently drop for longer periods than the server is willing to buffer (due to potential maliciousness). However, you as the end client implicitly trusts your friend, so you are happy to buffer your own messages for them. ''Large public servers cannot make this assumption for all their users.''

The server adding a sequence number, is zero-cost and (not considering migration costs) should be easy and reasonable to implement. It will ''enable'' end-to-end reliability, not guarantee it - the actual recovery behaviour would be implemented on the clients.

''> .. we are restarting consistency check so you all are consistence after message y.". (an easily implementable compromise is to reset consistency digest at each group key exchange, I'll add that if nobody objects).''

I think it would be better to just automatically re-run the GKE when inconsistency is detected. Why wait until the next group key exchange?

But I think this sort of solution is not ideal, and results much greater overal complexity; consistency and reliability should be done as part of the same layer, because it is simpler and more natural that way.

''> .. Again, in my opinion the MTCP should run in a lower layer than mpCat like TCP, that is how we can be transport-agnostic. However, I think there is a general consensus that async is off the table for now.''

To explain why this viewpoint is naive and narrow: your layer mpCAT, makes assumptions that ''do not apply'' in the more general case. The way you calculate consistency, assumes global-totally-ordered (linear) reliable delivery; it ''cannot work'' in a less strict scenario such as serverless broadcast, even though theoretically we can achieve consistency in those scenarios (e.g. via causal ordering). So, general (i.e. transport-agnostic) reliability systems ''do not try'' to achieve this property, so you will not be able to "layer" mpCat on top of it.

The only way a reliability layer can achieve this property (i.e. to ensure your assumption holds), is to ''require'' the server changes I mentioned (global explicit sequence numbers) ''and'' implement end-to-end recovery in the clients based on this information. '''This is a fine path to go down''', but '''no reasonable person should call this "transport-agnostic"''', since it requires server changes which other protocols may not want to adopt (if the protocol even has servers).

TL;DR: the currently-proposed protocol is '''not transport-agnostic''' due to an assumption that is fundamentally transport-specific (global total-ordering). No "layering" strategy will enable the protocol to be transport-agnostic; only changes to the protocol itself that ''don't make this assumption'' will enable it to achieve this.

Thread:Talk:MpOTR/Rename "broadcast scheme"

2014-08-02T15:53:01Z

Infinity0:

By "broadcast scheme", this refers collectively to the peer-to-peer pairwise broadcast, or the "sender keys" optimisation on top of it. I think "broadcast scheme" is too generic and confusing. How about "p2p-broadcast", "full-broadcast", "sender-broadcast", or "member-broadcast"?

I also disagree with ''"Each participant will have its own different $plist_i$ which is able to broadcast too."''. In all schemes, every member should eventually reach the same plist as everyone else. In all schemes, there will be a period where different members have different plists - e.g. even in the GKE case, some members will receive the final round of the GKE earlier than others, so switch to the new plist earlier than those others.

The key difference is that in the p2p-broadcast case, (optionally) members are able to *provisionally send* to the new plist earlier than some other members do, without receiving a key confirmation (and with a forward secrecy penalty if there was an active attack).

Thread:Talk:MpOTR/Rename "broadcast scheme"

2014-08-02T15:50:19Z

Infinity0: New thread: Rename "broadcast scheme"

Thread:Talk:MpOTR/Protocol name/reply

2014-08-02T15:42:44Z

Infinity0: Reply to Protocol name

I'm hesitant about "mpOTR". 2-party OTR works well on IRC, even though messages may be dropped. But in the group setting, in order to ensure transcript consistency, you basically require reliability which IRC does not do. So the current proposal can only work for XMPP.