diff --git a/doc/dos-mitigation.pdf b/doc/dos-mitigation.pdf index a6c236c..87994ea 100644 Binary files a/doc/dos-mitigation.pdf and b/doc/dos-mitigation.pdf differ diff --git a/doc/dos-mitigation.tex b/doc/dos-mitigation.tex index b3ddd17..9fb0cbd 100644 --- a/doc/dos-mitigation.tex +++ b/doc/dos-mitigation.tex @@ -108,10 +108,10 @@ \subsubsection{The joiner DOSing} \label{sec-1-1-4} \begin{itemize} \item As a result, the joiner cannot leave the session before joining, so she cannot -invoke NEW$_{\text{PRIORITY}}$$_{\text{SESSION}}$. +invoke NEW$_{\text{PRIORITY}}$$_{\text{SESSION}}$. \begin{itemize} \item PRESUME$_{\text{HEIR}}$ is only called when group$_{\text{dec}}$ is successful: if the group dec is not correct, then the user will not drop the other sessions. -\item If the joiner sends a correct message to some users and a bad message to others, she can force some of the participants to drop the session and some not. Therefore, whenever a user is dropping a session, she should announce it if it is because of: +\item If the joiner sends a correct message to some users and a bad message to others, she can force some of the participants to drop the session and some not. Therefore, whenever a user is dropping a session, she should announce it if it is because of: \begin{itemize} \item timeout \item auth error @@ -134,7 +134,7 @@ \subsubsection{The joiner DOSing} \begin{itemize} \item You request drop in the grace period and wait for the period to pass. \item You accept drop if the grace period has passed. -\item If you received the messages of the party being dropped, you keep them. Drop the +\item If you received the messages of the party being dropped, you keep them. Drop the dropper. \end{itemize} @@ -190,7 +190,7 @@ \section{How to detect} \label{sec-4} \begin{itemize} \item When a participant concludes that another participant is malicious -because of one of the above reasons, she request that participant to be +because of one of the above reasons, she request that participant to be kicked out of the participant list, and includes the reason for the kick. \item How to detect DoS: \begin{itemize} @@ -206,7 +206,7 @@ \section{How to detect} \section{How to react after detection} \label{sec-5} \begin{itemize} -\item If DoS happens during a join process, +\item If DoS happens during a join process, If it is the joiner who is malicious: The maliciousness is happening in session confirmation phase: \begin{itemize} @@ -226,7 +226,7 @@ \section{How to react after detection} \item Authentication failure is a reason for barring join but not DoS. -\item When someone gets kicked out due to DoS reasons, she should become the +\item When someone gets kicked out due to DoS reasons, she should become the last person to join after all the other joiners already in line. \end{itemize} @@ -235,7 +235,7 @@ \section{Concerns:} \begin{itemize} \item Timing problems. There should be an acceptable delay. The messages arrived within an \end{itemize} -acceptable delay period should be ordered in their hash order. But we +acceptable delay period should be ordered in their hash order. But we assume global ordering on messages for now. \begin{itemize} @@ -249,7 +249,7 @@ \section{Proof of DoS protection} \begin{itemize} \item Theorem: Suppose $U_1,...,U_n$ are sets of participants. $I_h \cap I_m = \{1,...,n\}$. \end{itemize} -where $I_o$ is the set of honest and $I_m$ the set of malcious participants, then, after running the above algorithm, each participant gets a list of $plist_i$. If the transport is honestly and consistently delivering messages in timely manner, then for $i,j \in I_h$ +where $I_o$ is the set of honest and $I_m$ the set of malicious participants, then, after running the above algorithm, each participant gets a list of $plist_i$. If the transport is honestly and consistently delivering messages in timely manner, then for $i,j \in I_h$ we have $U_i \in plist_j$. Proof: TBD. @@ -260,20 +260,20 @@ \section{New Algorithm:} \item Badly signed messages are dropped and treated as undelivered. \item If someone fails to contribute any message we are waiting for, we wait for the grace$_{\text{period}}$ and then we just assume they left. -\item If key generation or confirmation fails, then we need to re-session with the session +\item If key generation or confirmation fails, then we need to re-session with the session tagged as DoS detection. Users only can do this by sharing the evidence of cheating. \item If we fail key generation or confirmation with Dos detection tag, then we publish all private key encrypted by p2p keys signed by non-DoS-tagged authenticated private key. The cheater will be detected and kicked out. -\item If U$_{\text{i}}$ kicks U$_{\text{j}}$ out (that is starting session S while U$_{\text{j}}$ is not in the -new session) without cheating evidence signed by alleged cheater U$_{\text{j}}$, then U$_{\text{k}}$ simply ignore the request +\item If U$_{\text{i}}$ kicks U$_{\text{j}}$ out (that is starting session S while U$_{\text{j}}$ is not in the +new session) without cheating evidence signed by alleged cheater U$_{\text{j}}$, then U$_{\text{k}}$ simply ignore the request for the new session. \end{itemize} \subsection{Sub protocol for unresponsiveness on join or re-session or any other part of the key agreement protocol.} \label{sec-8-1} If U$_{\text{i}}$ fails to reply, U$_{\text{j}}$ sends a kick request (for failure to reply) after the grace period has passed. -Other participants either should agree with the kick and respond by participant-info message or re-broadcast the failed message (if they have received it despite the fact that U$_{\text{j}}$ has not). When +Other participants either should agree with the kick and respond by participant-info message or re-broadcast the failed message (if they have received it despite the fact that U$_{\text{j}}$ has not). When you get the message for failed delivery, you \textbf{have to} agree or rebroadcast. If you fail to do so, you will be dropped as well. \begin{itemize} @@ -283,7 +283,7 @@ \subsection{Sub protocol for unresponsiveness on join or re-session or any other A replies after timer 2 but B does not ask to kickout A => ask to kickout A. \end{itemize} --- Current users start a timer as soon as they get a join request for +-- Current users start a timer as soon as they get a join request for all users in the room to respond with authentication. Note: Authentication failed should be an acceptable response. @@ -305,7 +305,7 @@ \subsection{Sub protocol for unresponsiveness on join or re-session or any other has replied in time for the first timer, they drop the requesting user. (We should because the receiving user and the requesting user have different views of the room.) -The users will play the second round, set up timers and follow the same +The users will play the second round, set up timers and follow the same rules. -- Conflict of circles: @@ -317,7 +317,7 @@ \subsection{Sub protocol for unresponsiveness on join or re-session or any other \begin{itemize} \item In the end only users whose views are completely in agreement will stay in the same session. The room might be -divided into different mutually exclusive sessions. (View agreement is an equivalence relationship.) +divided into different mutually exclusive sessions. (View agreement is an equivalence relationship.) The new joiner will be presented the option of choosing which session to join. \end{itemize} @@ -346,7 +346,7 @@ \subsection{Sub protocol for generating wrong keyshare or confirming wrong sessi -- If someone fails to reply, then run sub-protocol for unresponsive user. -The failed message has the share for the new subgroup, so finally the responsive +The failed message has the share for the new subgroup, so finally the responsive parties will make a successful subgroup. So we break the protocol into sections: @@ -354,7 +354,7 @@ \subsection{Sub protocol for generating wrong keyshare or confirming wrong sessi \subsubsection{Cheater detection protocol:} \label{sec-8-2-1} - If the key fails to recover or the session confirmation does not match, then a special session with new ephemeral keys will be distributed and session establishment will be attempted. If the cheater detection session fails + If the key fails to recover or the session confirmation does not match, then a special session with new ephemeral keys will be distributed and session establishment will be attempted. If the cheater detection session fails at the same stages, then the participants will reveal their private key signed by their old key and the cheater will be detected and kicked out. \begin{itemize} diff --git a/doc/high-level-api.pdf b/doc/high-level-api.pdf index e4b3c4c..0b3d602 100644 Binary files a/doc/high-level-api.pdf and b/doc/high-level-api.pdf differ diff --git a/doc/high-level-api.tex b/doc/high-level-api.tex index 1a7fbe1..42f5abc 100644 --- a/doc/high-level-api.tex +++ b/doc/high-level-api.tex @@ -50,7 +50,7 @@ \section{Carrier chat model} The (n+1)sec protocol does not rely on any of the requirements above to ensure any security guarantees; in particular, the security properties described in Section~\ref{sec:np1sec-chat-model} still hold when the carrier chat system does not satisfy these requirements. Instead, in such a situation, the (n+1)sec library will not be able to establish secure chat sessions at all; any attempts to use the (n+1)sec system on such a carrier chat system will result in reported error situations such as network timeouts, protocol errors, et cetera. -As a special case of this general point, per requirement \ref{enum:carrier-chat-model/chat-event-order}, the (n+1)sec system assumes that users have a connection to the carrier chat system that is free from interference, in which attackers cannot interfere with the communication between user and carrier chat system; this can be easily accomplished by the application of proper transport security, as implented by systems such as TLS, to the connection between the user and the carrier chat system. +As a special case of this general point, per requirement \ref{enum:carrier-chat-model/chat-event-order}, the (n+1)sec system assumes that users have a connection to the carrier chat system that is free from interference, in which attackers cannot interfere with the communication between user and carrier chat system; this can be easily accomplished by the application of proper transport security, as implemented by systems such as TLS, to the connection between the user and the carrier chat system. If this assumption is violated ---which can happen, for example, when a user uses a plaintext connection to connect to a carrier chat system, and an attacker modifies the message stream sent to or by the user--- then the security properties described in Section~\ref{sec:np1sec-chat-model} still hold, but the user will not be able to successfully join any (n+1)sec sessions. To perform secure communications, (n+1)sec needs to perform actions in the role of a member of a carrier chat room. @@ -104,7 +104,7 @@ \section{(n+1)sec chat model} Internally, (n+1)sec channels are constructed out of a multitude of cryptographic constructions which we call (n+1)sec \emph{sessions}. A session is an agreement between the active participants of a channel to use a particular shared key for encrypting chat messages. -Unlike channels, sessions cannot be joined or left; when participants join or leave a channel, the channel spawns a new session to accomodate the changed set of participants, and the old session is eventually replaced. +Unlike channels, sessions cannot be joined or left; when participants join or leave a channel, the channel spawns a new session to accommodate the changed set of participants, and the old session is eventually replaced. New sessions are also created periodically in order to refresh short-term keys, as part of the effort to limit the damage done by the compromise of a short-term private key. As the interface to (n+1)sec channels, the (n+1)sec library provides an object representing a channel of which the user is a participant. @@ -146,11 +146,11 @@ \subsection{Channel consistency} An (n+1)sec channel is a distributed cooperation between a set of participants, who are in agreement about such things as the list of authenticated participants, and the active cryptographic session. There is no such thing as a central authoritative version of the state of the channel; instead, the system relies entirely on the proposition that the participants are in agreement with each other, and stay that way. If, for whatever reason, the participants of a channel find themselves in unexpected disagreement about the state of a channel ---for example, if one subset of a channel is of the opinion that user Alice has been authenticated by the entire channel and is therefore promoted to a \emph{joining} participant, whereas the remainder of the channel is of the opinion that Bob has yet to authenticate Alice--- then the coherence of the channel has broken down, and the channel cannot continue in its present form. -This situation can arise if the carrier chat system manipulates the contents of the carrier chat, such as by not informing part of the channel that Bob has authenticated Alice; a malicient user might also try to arrange this situation as a denial of service attack. +This situation can arise if the carrier chat system manipulates the contents of the carrier chat, such as by not informing part of the channel that Bob has authenticated Alice; a malicious user might also try to arrange this situation as a denial of service attack. When this happens, the (n+1)sec system responds by performing a procedure that ultimately leads to the disagreeing segments of the channel each continuing as separate, independent channels. Each (n+1)sec client, when noticing that part of the channel is in disagreement with the client about the channel status, decides to unilaterally drop all participants from the channel with whom they are in disagreement. -Because client agreement is an equivalence relation, the consequence of this procedure is that each ``side'' of the disagreement has constructed an internally consistent descendent channel; effectively, the original disagreeing channel has split itself into independent component channels that are once again in agreement. +Because client agreement is an equivalence relation, the consequence of this procedure is that each ``side'' of the disagreement has constructed an internally consistent descendant channel; effectively, the original disagreeing channel has split itself into independent component channels that are once again in agreement. From the point of view of any particular participant of the disintegrating channel, this splitting procedure is asymmetric: all participants on the other side of the split have simply been kicked from the channel because of a protocol violation. Only from the point of view of an outsider watching the channel does the breakdown of a channel look like a symmetric split. @@ -219,7 +219,7 @@ \section{Joining and constructing (n+1)sec channels} The process of searching for (n+1)sec channels to join in a given carrier chat room consists of a model in which the (n+1)sec library maintains a list of available channels for the user to join, which is continuously updated until the user chooses a channel to join. This list is represented as an initially empty set of \emph{channel} objects as described in Section~\ref{sec:np1sec-chat-model}, which can be displayed in a user interface. -During the channel-search procedure, the following events can happen that change the concents of the available channel list: +During the channel-search procedure, the following events can happen that change the contents of the available channel list: \begin{itemize} \item The search process can report the existence of a newly identified channel; \item A channel on the list can change its set of users, which happens when a user joins or leaves the channel, or a user in the channel becomes authenticated; diff --git a/doc/protocol.pdf b/doc/protocol.pdf index a0be39b..3cb1d26 100644 Binary files a/doc/protocol.pdf and b/doc/protocol.pdf differ diff --git a/doc/protocol.tex b/doc/protocol.tex index 2deaae0..9da3e47 100644 --- a/doc/protocol.tex +++ b/doc/protocol.tex @@ -118,7 +118,7 @@ \section{Chat Model} Secure communications in (n+1)sec take place in chat sessions called \emph{conversations}. An (n+1)sec conversation is a construction similar to a traditional chat room, such as an IRC channel or a Jabber multi-user-chat room. A conversation consists of a set of \emph{participants}, which can send text messages to the group as a whole. -Participants can furthermore leave a conversation, and new participants can join it; together with the history of messages exchangesd, this makes up the main modes of interaction of a conversation. +Participants can furthermore leave a conversation, and new participants can join it; together with the history of messages exchanged, this makes up the main modes of interaction of a conversation. A conversation is a construction that implements the behavior of a chat room while also guaranteeing a collection of security properties, such as the property that the content of exchanged messages is confidential to everyone other than the conversation's participants. The combination of the modes of interaction supported by a conversation, and the security properties it achieves, makes up the conceptual interface of the notion of a conversation; that is, it functions as a specification of the role a conversation can play in constructing a secure chat system. @@ -134,7 +134,7 @@ \subsection{Rooms} Carrier chat rooms are an abstract formalization of a general-purpose chat room system, used by (n+1)sec to transport cryptographic messages to a group of users. The exact behavior and properties (n+1)sec requires carrier chat rooms to have are detailed in Section~\ref{sec:carrier-chat-rooms}. -Each (n+1)sec conversation takes place inside a particilar carrier chat room, which carries the cryptographic messages that make up the conversation. +Each (n+1)sec conversation takes place inside a particular carrier chat room, which carries the cryptographic messages that make up the conversation. The participants of a conversation are restricted to some subset of the members of the carrier chat room, which may be invited to conversations taking place inside that carrier chat room. A carrier chat room can host multiple independent (n+1)sec conversations at the same time, and members of the carrier chat room can be part of any number of these conversations. @@ -176,7 +176,7 @@ \subsection{Joining and leaving} Chat messages in an (n+1)sec conversation are encrypted using a symmetric key known to all of the conversation's participants. This forms the basis of the mechanisms ensuring confidentiality of chat content. -When a participant leaves a conversation, the remaining participants negiotiate a new symmetric key to which the former participant does not have access. +When a participant leaves a conversation, the remaining participants negotiate a new symmetric key to which the former participant does not have access. Once this procedure finishes, the participants switch over to the new symmetric key. However, until this key negotiation is finished, messages are exchanged that are encrypted using the old key, to which the former member has access; as a consequence, the former member can still decrypt these messages if they have access to the encrypted messages, despite having nominally left the conversation. While this process of negotiating a new key after a participant leaves the conversation takes a fairly short time under normal circumstances, it may take a substantial time to finish when conditions are less fortunate. @@ -291,7 +291,7 @@ \subsection{Carrier model and limitations} If these properties are not satisfied, this will not compromise the security properties delineated in Section~\ref{sec:chat-model/cryptographic-assurances}; however, it will make it impossible to create, or maintain, (n+1)sec conversations in the room. The carrier chat room needs to satisfy the following properties in order to support (n+1)sec conversations: \begin{itemize} -\item Chat events occurring in the chat room ---which include at least chat messages, joining members, and leaving members--- have a strict and consistent order enforced by the carrier chat system. Different members of the chat room receive the same chat events in the same order. This include schat events originated by the receiving member; for example, if a member sends a chat message, it should be aware of the timing at which it is received by the chat room, relative to other chat events in the same room. +\item Chat events occurring in the chat room ---which include at least chat messages, joining members, and leaving members--- have a strict and consistent order enforced by the carrier chat system. Different members of the chat room receive the same chat events in the same order. This includes chat events originated by the receiving member; for example, if a member sends a chat message, it should be aware of the timing at which it is received by the chat room, relative to other chat events in the same room. \todo[inline]{Could we lift this restriction, without turning (n+1)sec into Byzantine Paxos and then some?} \item The recognizable unique identifier that identifies a particular member of a chat room corresponds to a particular instantiation of an (n+1)sec client. In particular, multiple (n+1)sec-capable user agents must not share a unique user identifier. \todo[inline]{Could we lift this? It seems more of an annoyance than a fundamental restriction.} @@ -405,7 +405,7 @@ \subsubsection{Authentication} The (n+1)sec protocol implements this scheme using the following authentication challenge protocol: \begin{description}[noitemsep] -\item[Participants.] User $A$ with username $U_A$ has announced long term public key $g^A$ and emphemeral public key $g^a$. User $B$ with username $U_B$ has announced $g^B$ and $g^b$. +\item[Participants.] User $A$ with username $U_A$ has announced long term public key $g^A$ and ephemeral public key $g^a$. User $B$ with username $U_B$ has announced $g^B$ and $g^b$. \item[Round 1.] User $A$ sends user $B$ an \emph{authentication challenge} nonce $N$. \item[Round 2.] User $B$ sends user $A$ the \emph{authentication confirmation} $T = H(U_B \concat N \concat TDH(g^A, g^a, g^B, g^b))$. \item[Computation.] User $A$ verifies the correctness of the authentication confirmation. If it is correct, $A$ knows that $B$ possesses the private key $b$. @@ -439,7 +439,7 @@ \subsection{Group Key Exchange} Should the participants of the conversation then simply try again to exchange a key, the malicious participant could keep disrupting the negotiation of a key indefinitely, freezing conversation progress without anyone being able to determine the party responsible for this breakdown. The (n+1)sec protocol makes use of a version of the Abdalla-Chevalier-Manulis-Pointcheval GKE+P authenticated group key exchange \cite{acmp}. -The version of this protocol used by (n+1)sec is modified in such a way that both the participants of a key exchange, and nonparticipating observants of a key exchange, can always determine the party responsible for any failures of the key exchange; these participants can then choose not to include the responsible party in further key exchange attempts, and solve the problem thereby. +The version of this protocol used by (n+1)sec is modified in such a way that both the participants of a key exchange and nonparticipating observers of a key exchange can always determine the party responsible for any failures of the key exchange; these participants can then choose not to include the responsible party in further key exchange attempts, and solve the problem thereby. \subsubsection{Cryptography} @@ -521,7 +521,7 @@ \subsection{Cryptographic primitives} \label{sec:cryptography/cryptographic-primitives} The (n+1)sec system makes use of certain cryptographic primitives to achieve its security properties. -In particilar, the (n+1)sec protocol uses a cryptographic hash function; a digital signature scheme; and a symmetric cipher. +In particular, the (n+1)sec protocol uses a cryptographic hash function, a digital signature scheme, and a symmetric cipher. Additionally, the (n+1)sec protocol makes use of a secure finite cyclic group in which the Diffie-Hellman protocol can be performed. The (n+1)sec protocol uses the following algorithms as implementations of these abstract primitives: @@ -547,7 +547,7 @@ \section{The Conversation State Machine} For such a distributed coordinated abstraction to behave like a conventional chat room, it is critical that its participants are at all times in agreement about such things as the member list, the chat transcript, and the state and history of the conversation in general. Achieving and maintaining this agreement is a challenging affair. -Because communication over the channel provioded by the carrier chat room is not instantaneous ---messages take a nonzero time to arrive at the carrier chat room after being sent by a user, and then take another nonzero time before being received by all other users--- multiple processes involved in maintaining a conversation might happen simultaneously in an interleaved fashion. +Because communication over the channel provided by the carrier chat room is not instantaneous ---messages take nonzero time to arrive at the carrier chat room after being sent by a user, and then take nonzero time before being received by all other users--- multiple processes involved in maintaining a conversation might happen simultaneously in an interleaved fashion. For example, a new user might attempt to join a conversation at the unfortunate time when a group key exchange procedure (as described in Section~\ref{sec:cryptography/group-key-exchange}) is in progress. For another example, a conversation participant might stop responding due to connectivity problems while the process to accept a new user into the conversation is in progress, which should not cause the user-acceptance procedure to freeze indefinitely while the troubled participant fails to participate. Resolving these potential conflicts in a way that reliably results in agreement between conversation participants about what happened and in what order is a famously difficult problem. @@ -592,7 +592,7 @@ \subsection{Participating in a conversation} When receiving such a message, all other members compare this checksum against the checksum of their own copy; when these values are not equal, this indicates that the views of the conversation between the different members have diverged. When such a divergence is detected, those members that notice that other members have divergent conversation state machine contents remove the diverging users from the contents of their copies of the conversation state machine, and announce that fact. -After receiving that announcement, the victims of this divergement in turn remove the announcers from their own copies of the conversation state machine, and announce this as well. +After receiving that announcement, the victims of this divergence in turn remove the announcers from their own copies of the conversation state machine, and announce this as well. After several such messages, the incoherent conversation has split itself into two or more parts, with each resulting conversation consisting of all members of the original conversation that still have consistent state machines among themselves. In effect, the incoherent conversation has then split itself into two or more internally coherent successor conversations. @@ -753,7 +753,7 @@ \subsubsection{Key exchanges} When a key exchange procedure finishes successfully, the conversation participants involved in the key exchange will switch to using the chat key produced by the key exchange for all further chat. To coordinate this, each participant will send a \npmessage{KEY\_ACTIVATION} message announcing the chat key they will use from that point onward, and will encrypt all chat messages sent after sending that \npmessage{KEY\_ACTIVATION} message using the newly activated key. -The successful completion of a key exchange will also cancel all remaining active key exchanges that started before the just-finished key exchange; this ensures that the progression of chat keys used over time follows a monotone sequence, and no keys ever get activated that have since been superceded by more recent keys. +The successful completion of a key exchange will also cancel all remaining active key exchanges that started before the just-finished key exchange; this ensures that the progression of chat keys used over time follows a monotone sequence, and no keys ever get activated that have since been superseded by more recent keys. Key exchange procedures do not always finish successfully. Active key exchange processes may sometimes get \emph{cancelled}; this happens when one of the participants of a key exchange leaves the conversation while the key exchange is ongoing, as well as when a key exchange is superseded by the successful completion of a later key exchange. @@ -825,7 +825,7 @@ \subsubsection{Events} There are situations in the proceedings of an (n+1)sec conversation in which the processes of the conversation require specific contributions from the conversation's members. For example, active key exchanges require their participants to contribute their parts in each of the key exchange states before the key exchange can proceed to the next stage. For another example, when a participant of a conversation invites a new user, existing identified members of the conversation are required to send a message confirming that they are part of the conversation, which allows the new invitee to confirm the set of members of the conversation. -In either case, the normal function of the conversation ---or parts of it--- cannot proceed until all relevent members of the conversation have contributed their part. +In either case, the normal function of the conversation ---or parts of it--- cannot proceed until all relevant members of the conversation have contributed their part. In these situations, a member that does not cooperate by sending their contribution the conversation processes ---perhaps because they maliciously want to sabotage the conversation, or maybe simply because they are suffering network connectivity problems--- can hold up useful activity in the conversation indefinitely. To avoid (n+1)sec conversations from being entirely at the mercy of malicious saboteurs and unfortunate network contingencies alike, conversations need to enforce participation in situations where a member contribution is mandatory --- by removing nonparticipating members from the conversation, if need be. @@ -905,7 +905,7 @@ \subsubsection{Events} Thus, a \type{key-exchange-contribution} event may refer to a historic key exchange process that has since been cancelled. A \type{key-activation-contribution} event is created when a key exchange process finishes successfully. -It records the expectation that the participants of that key exchange send a \npmessage{KEY\_ACTIVATION} message, indicating that they will start using the newly negoatiated key for all further chat messages. +It records the expectation that the participants of that key exchange send a \npmessage{KEY\_ACTIVATION} message, indicating that they will start using the newly negotiated key for all further chat messages. \begin{struct}{key-activation-contribution} \structfield{key-exchange-id}{hash} \structfield{participants}{set of participant reference} @@ -935,7 +935,7 @@ \subsubsection{Timeouts} Reaching distributed consensus on this matter is challenging; a situation might easily arise in which a message sent by member $A$ arrives just in time for member $B$ to consider $A$ fast enough to avoid a timeout, but just too late for member $C$ to consider the same. The (n+1)sec protocol approaches this problem by having each member of a conversation do their own independent tracking of which other members are and are not meeting the conditions to warrant a timeout removal. -Members send a message to the conversation when they consider some other member to have crossed the timeout treshold, and these judgements are recorded in the conversation state machine. +Members send a message to the conversation when they consider some other member to have crossed the timeout threshold, and these judgements are recorded in the conversation state machine. The decision of whether or not a member is actually removed from a conversation for timeout reasons is then specified as a judgement to be computed from the opinions stored in the conversation state machine. @@ -1733,7 +1733,7 @@ \subsubsection{KEY\_ACTIVATION} If that event is a \type{key-activation-contribution} event, with \smfield{key-exchange-id} equal to \field{key-id}, the \field{sender} is removed from that pending event. If the first event has any other form, or if the state machine does not describe any pending events that include \field{sender}, the \field{sender} is removed from the conversation. -If, after removing the \field{sender} from the \type{key-activation-contribution} event in this way, the \type{key-activation-contribution} event does not have any remaining members left ---if that event's \smfield{members} field is empty, after removign \field{sender} from it--- then the key identified by \field{key-id} has been accepted by all participants described in the \type{key-activation-contribution}'s \smfield{participants} field. +If, after removing the \field{sender} from the \type{key-activation-contribution} event in this way, the \type{key-activation-contribution} event does not have any remaining members left ---if that event's \smfield{members} field is empty, after removing \field{sender} from it--- then the key identified by \field{key-id} has been accepted by all participants described in the \type{key-activation-contribution}'s \smfield{participants} field. Because all these participants are also participant to any key exchange processes that may have taken place after the exchange negotiating the \field{key-id} key, this implies that all these \smfield{participants} will have access to all future encrypted chat in the conversation. To mark this fact, the conversation state machine sets the \smfield{in-chat} field to \textsf{true} for all participants in the \smfield{participants} set.