Documentation: Correct a few typos

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,15 +346,15 @@ \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:
 
 \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}

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;