zerotier/zssp
0
0
Fork 0
mirror of https://github.com/zerotier/zssp.git synced 2026-05-22 16:28:40 -07:00
Code Issues Packages Projects Releases Wiki Activity

Fix minor grammar issues

Browse Source
This commit is contained in:
Joseph Henry
2023-11-21 15:20:00 -05:00
committed by Monica Moniot
parent 2f3ce584e2
commit eddcd4c600
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
whitepaper/zssp.pdf
BIN
View File
Binary file not shown.
whitepaper/zssp.tex
+2 -2
View File
@@ -243,7 +243,7 @@ ZSSP is a stack of three closely related, but independent protocols. These are t
The next section will be dedicated to describing ZKE in explicit detail. We will be making heavy use of common mathematical notions and notation surrounding Deterministic Finite Automata, State Machines and AKE security. The goal with this section is to describe ZKE at a level of detail necessary both to allow someone to implement ZKE, and to aide future mathematical analysis of ZKE.
\begin{definition}[ZKE packet types]
We define 8 different packet types that essential for the functioning of ZKE.
We define 8 different packet types that are essential for the functioning of ZKE.
\begin{itemize}
\item $X_1$: This packet type contains the first message of Noise XK. It is identified internally with packet type number `0'.
\item $X_2$: This packet type contains the second message of Noise XK. It is identified internally with packet type number `1'.
@@ -462,7 +462,7 @@ At the end of this section we will have defined $\zeta$, which is the high-level
\end{itemize}
\sectionref{sec:trans_alg} discusses how these packets are structured, and what algorithms are used to create and process each packet.
$\zeta$ has a timer system to automatically and locally trigger state transitions or packet resends. This system exists primarily as a solution to the ``two generals problem''. Since ZKE assumes a out-of-order, lossy transport environment it is necessary to have a system of resending lost messages and timing out those resends, similar to TCP. The ZKE timer system is designed to be lightweight, security focused, and simple. It provides strong guarantees about the maximum amount of time that may pass until certain security critical events, such as completing a handshake or ratcheting a session key, must occur.
$\zeta$ has a timer system to automatically and locally trigger state transitions or packet resends. This system exists primarily as a solution to the ``two generals problem''. Since ZKE assumes an out-of-order, lossy transport environment it is necessary to have a system of resending lost messages and timing out those resends, similar to TCP. The ZKE timer system is designed to be lightweight, security focused, and simple. It provides strong guarantees about the maximum amount of time that may pass until certain security critical events, such as completing a handshake or ratcheting a session key, must occur.
We assume that the underlying computer running $\zeta$ exposes some mechanism for creating a \emph{timer} which can be \emph{set} to some amount of time, and the computer will \emph{trigger} the timer after approximately that amount of real time has passed.
\begin{itemize}