simplified protocol

PROTOCOL.md

@@ -40,8 +40,11 @@ A better solution would be to generate a private key on each client and use it t
 
 This document will define and bundle 2 distinct protocols to make up a token system that implements the previous statements.
 
-1. a <u>Stateless Time Scrambling Protocol</u> to take care of the request's expiration over time.
-2. a <u>Stateless Cyclic Hash Algorithm</u>  to generate several public tokens from a private key in a way that no clue is given over published tokens (*i.e. one-way function*).
+1. a <u>Stateless Time Scrambling Protocol</u> to take care of the request's invalidation over time.
+2. a <u>Stateless Cyclic Hash Algorithm</u> to use a private key as a one-time token generator in a way that no clue is given over published tokens (*i.e. one-way function*).
+3. A key renewal mechanism in a way that no clue is given over neither the old nor the new key.
+4. A rescue protocol to resynchronise the client with a new key in a way that no clue is given over the network and the client has to process a "proof of work".
+
 
 ## General knowledge & Notations
 
@@ -52,23 +55,17 @@ This document will define and bundle 2 distinct protocols to make up a token sys
 | $\parallel a\parallel $ | The absolute value of $a$ ; *e.g.* $\parallel -12 \parallel = 12$ |
 | $\mid a \mid$ | The integer value of $a$ ; *e.g.* $\mid 12.34 \mid = 12$ |
 | $a \oplus b$ | The bitwise operation XOR between binary words $a$ and $b$ |
+| $a \And b$ | The bitwise operation AND between binary words $a$ and $b$ |
 | $h(m)$ | The digest of the message $m$ by a (consistent) secure cryptographic hash function $h()$ ; *e.g. sha512* |
 | $h^n(m)$ | The digest of the $n$-recursive hash function $h()$ with the input data $m$ ; <br>$h^2(m) \equiv h(h(m))$, $h^1(m) \equiv h(m)$, and $h^0(m) \equiv m$. |
-| $a \mod b$ | The result of $a$ modulo $b$ ; *i.e.* the remainder of the Euclidean division of $a$ by $b$ |
+| $a \ \mathbb{Z}_{(b)}$ | The result of $a$ modulo $b$ ; *i.e.* the remainder of the Euclidean division of $a$ by $b$ |
 | $t_{now}$ | The current *Unix Timestamp* in seconds |
 
-
-
-##### Entities
-
-- A client $C$ (*typically a client*)
-- A server $S$ (*typically a server*)
-
 ## Variables
 
 The whole system share a common **context**, each client holds a **private keyset**, and the server stores the **last valid token** of each client.
 
-##### Common context
+#### 1. Common context
 
 These variables are both on the server and clients. They are specific to the server so each client must match its values. These variables shape the system's **context** $(W, min, belt, max)$.
 
@@ -79,7 +76,7 @@ These variables are both on the server and clients. They are specific to the ser
 | $sec$ | security range | A number that is used to resynchronize the client if there is a communication shift (*e.g. lost request, lost response, attack*). It corresponds of the number of desynchronizations the client can handle before never being able to gain the authentication again. |
 | $max$ | maximum nonce | A number that is used to cap the value of client's nonces. A too high value will result on keys that will never be replaced, thus making them open to long-processing attacks (*e.g. brute-force*). |
 
-##### Client keyset
+#### 2. Client keyset
 
 Every client holds a **keyset** $(K, n, s)$. It represents its private key and is used to generate the tokens. The secure hash function is extended as a **one-way function** to generate all the tokens from the keyset.
 
@@ -87,19 +84,72 @@ Every client holds a **keyset** $(K, n, s)$. It represents its private key and i
 |:--------:|:----:|:------------|
 | $K$ | private key | A secret binary data that must be large and *random* enough not to be brute forced. |
 | $n$ | key nonce | A number that is decremented before each request. Before $n$ reaches 0, a new keyset must be generated. |
-| $s$ | key state | A number that reflects the state of the keyset. It is used to know what to do on the **next request** : <br>- $0$ : normal request<br>- $1$ : will use the new key<br>- $2$ : resynchronization processed, waiting for the server's acknoledgement |
+| $s$ | key state | A number that reflects the state of the keyset. It is used to know what to do on the **next request** : <br>- $0$ : normal request<br>- $1$ : will switch to the new key<br>- $2$ : rescue proof of work sent, waiting for the server's acknowledgement |
 
-The token generation algorithm is :
-1. Decrement $n$
-2. Process token $= h^n(K)$
-
-##### Server variables
+#### 3. Server variables
 
 | Notation | Name | Description |
 |:--------:|:----:|:------------|
 | $T$ | last valid token | The server stores the last valid token from the client to check the next one. |
 
-If a client sends its token $h^n(K)$ ; if valid the server stores it inside $T$. Note that for the system's **initialisation**, the server has to be given $T = h^{n-1}(K)$.
+
+## Protocol
+
+#### 1. Client authentication
+
+In each request, the client will send a pair of tokens $(x_1, x_2)$ :
+- $x1$ will hold the current one-time token
+- $x2$ will hold data to check the next one-time token to be used
+
+The client's current keyset has 3 states :
+- `normal` - default authentication algorithm.
+- `switch` - default algorithm variation to switch to a new keyset when the current one is consumed.
+- `rescue` - process the proof of work after receiving the server's challenge when there is a desynchronisation and generate a new keyset.
+
+When the client switches to a new key, it has to the new keyset along the current one, in order not to lose its authentication if the network fails.
+- $(K,n,s)$ - the current keyset
+- $(K',n',s')$ - the new keyset
+
+##### a. `normal` protocol
+
+1. Decrement $i$
+2. $t\_c = \mid \frac{t\_{now}}{W}\mid$
+3. $x\_1 = h^{n}(K) \oplus h(t\_c)$
+4. $x\_2 = x\_1 \oplus (t\_c \ \mathbb{Z}\_{(2)})$
+
+Send $x_1$ and $x_2$.
+
+If $i \leq min+sec$, go to `switch` protocol.
+
+##### b. `switch` protocol
+
+1. $t\_c = \mid \frac{t\_{now}}{W}\mid$
+2. $x\_1 = h^{n}(K) \oplus h(t\_c)$
+3. Generate $(K',n',s')$ in a way where the following condition is met :
+	- $[(h^n(K) \oplus h^{n'}(K')) \And 1] \ \mathbb{Z}\_{(2)} = t\_c \ \mathbb{Z}\_{(2)} $
+4. $x\_2 = h^{n'}(K') \oplus h(t\_c)$
+
+Send $x_1$ and $x_2$.
+
+#### c. `rescue` protocol
+
+The rescue protocol is processed when receiving $y_1$ and $y_2$ from the server instead of the standard response.
+
+1. $m_s = y_1 \oplus y_2$
+2. $t\_c = \mid \frac{t\_{now}}{W} \mid $, $m\_c = t\_c \mathbb{Z}\_{(2)}$
+3. $t'\_s = t\_c - \parallel m\_c - m\_s\parallel$
+4. $T = x\_1 \oplus h(t'\_s)$
+5. Find $N \in [min ; n-min[,\ h^{N}(K) = T$.
+6. $x\_1 = h^N(K) \oplus h(t\_c)$
+7. Generate $(K',n',s')$ in a way where the following conditions are met :
+	- $[(h^N(K) \oplus h^{n'}(K')) \And 1] \ \mathbb{Z}\_{(2)} = t\_c \ \mathbb{Z}\_{(2)} $
+	- $[(h^N(K) \oplus h^{n'}(K')) \And 11110000] \ \mathbb{Z}\_{(3)} = 2$
+8. $x\_2 = h^{n'}(K') \oplus h(t\_c)$
+
+Send $x_1$ and $x_2$.
+
+
+## blablabla
 
 ##### Check a token
 
@@ -135,7 +185,7 @@ The receiver has to guess $t_s$ with the following steps:
 
 As a result, the receiver will only be able to retrieve the sender's time id if the reception time is at most $W$ seconds after the sending time :
 
-$$t\_{now}^r \leq t\_{now}^s + W \implies t\_s = t'_s2$$
+$$t\_{now}^r \in [t\_{now}^s ; t\_{now}^s + W] \Longrightarrow t\_s = t'_s2$$
 
 In practice, the time id is **hashed** and used to achieve a [one-time pad](https://en.wikipedia.org/wiki/One-time_pad) with the token. Because they both result from the same hash function their sizes are the same.
 
@@ -145,11 +195,11 @@ As a result from the sent token $x_1 = token \oplus h(t_s)$, it is impossible to
 * The time id corresponds to the index of the time slice where slices are $W$ seconds wide. By dividing the time in slices of $W$ seconds, if we process the same calculation at an interval of $W$ or less seconds, we will have either the same result or a result greater by 1.
 * The time id parity $m_s$ allows us to adjust the receiver's time id $t_r$ when it receives the request. This difference of 1 second is caused by the division of time in slices, the precision is also divided by $W$.
 
-	- $ t_{now}\mod W = 0 \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid $; no need for adjustment
-	- $ t_{now}\mod W = 1 \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$
-	- $ t_{now}\mod W = 2 \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$
+	- $t\_{now}\mod W = 0 \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now+(W-1)}}{W} \mid $; no need for adjustment
+	- $t\_{now}\mod W = 1 \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now+(W-1)}}{W} \mid + 1 $; need to subtract $1$
+	- $t\_{now}\mod W = 2 \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now+(W-1)}}{W} \mid + 1 $; need to subtract $1$
 	- $...$
-	- $ t_{now}\mod W = (W-1) \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$
+	- $t\_{now}\mod W = (W-1) \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$
 
 ## Protocol properties
 
@@ -243,7 +293,7 @@ The server receives $(x_1, x_2)$. It does have to :
 | `s5` | Calculate the time hash $h_{t'_c}$ | $h_{t'_c} = h(t'_c)$ |
 | `s6` | Extract the token $T'_c$ | $T'\_c = x_1 \oplus h\_{t'\_c}$ |
 | `s7` | Extract the next token $T_{next}$ | $T\_{next} = x\_2 \oplus m\_c \oplus h\_{t'\_c}$ |
-| `s8` | Check the token | $h(T'\_c) = T \implies T = T_{next}$ |
+| `s8` | Check the token | $h(T'\_c) = T \Longrightarrow T = T_{next}$ |
 
 If the token is valid on step `s8`, the next validation token $T_{next}$ is stored and the request can be processed by the server. If the token mismatches, the recovery mode is enabled.