diff --git a/PROTOCOL.md b/PROTOCOL.md
index 41604b4..9e817bd 100644
--- a/PROTOCOL.md
+++ b/PROTOCOL.md
@@ -33,7 +33,7 @@ A better solution would be to generate a private key on each client and use it t
**Technology requirements**
1. Mixing 2 hashes in a way that without one of them, the other is *cryptographically impossible* to guess (*i.e. [one-time pad](https://en.wikipedia.org/wiki/One-time_pad)*).
-2. Having a time-dependent unique hash, that could be found only a few seconds after sending it (as for *[TOTP](https://tools.ietf.org/html/rfc6238)*).
+2. Having a time-dependent unique feature, that could be found only a few seconds after sending it (as for *[TOTP](https://tools.ietf.org/html/rfc6238)*).
3. A cryptographic hash function that, from an input of any length, outputs a fixed-length digest in a way that is *impossible* to guess the input back from it.
**Protocols to define**
@@ -43,12 +43,12 @@ This document will define and bundle 2 distinct protocols to make up a token sys
1. a Stateless Time Scrambling Protocol to take care of the request's invalidation over time.
2. a Stateless Cyclic Hash Algorithm 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".
+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
-##### Notation
+##### Notations
| Symbols | Description |
|:-----:|:----------|
@@ -69,7 +69,7 @@ The whole system share a common **context**, each client holds a **private keyse
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)$.
-| Notation | Name | Description |
+| Variable | Name | Description |
|:--------:|:----:|:------------|
| $W$ | time window | A number of seconds that is typically the maximum transmission time from end to end. It will be used by the *time-scrambling aspect*. The lower the number, the less time an attacker has to try to brute-force the tokens. |
| $min$ | resynchonization range | A number that is used to resynchronize the client if there is a communication issue (*e.g. lost request, lost response, attack*). The higher the value, the higher the challenge for the client to recover the authentication, thus the harder for an attacker to guess it. |
@@ -78,73 +78,75 @@ These variables are both on the server and clients. They are specific to the ser
#### 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.
+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 to a **one-way function** to generate all the tokens from the keyset. Note that the client may hold a secondary keyset between the generation of a new keyset and the server's validation of it.
-| Notation | Name | Description |
+| Variable | Name | Description |
|:--------:|:----:|:------------|
| $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. |
+| $n$ | key nonce | A number that is decremented at each token generation. 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** :
- $0$ : normal request
- $1$ : will switch to the new key
- $2$ : rescue proof of work sent, waiting for the server's acknowledgement |
#### 3. Server variables
-| Notation | Name | Description |
+| Variable | Name | Description |
|:--------:|:----:|:------------|
| $T$ | last valid token | The server stores the last valid token from the client to check the next one. |
## Protocol
-#### 1. Client authentication
+## 1. Client request generation
-In each request, the client will send a pair of tokens $(x_1, x_2)$ :
+In each request, the client will send a pair of time-scrambled hashes $(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
+- $x2$ will hold the necessary data to check the next token
-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.
+The client implements 3 protocols according to the **keyset state** :
+- 0 : `NORMAL` - default authentication protocol.
+- 1 : `SWITCH` - default protocol variation to switch to a new keyset when the current one is consumed (*i.e. when $n$ if less or equal to $min+sec$*).
+- 2 : `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.
+When the client switches to a new key, it has to store 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
+#### 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)})$
+
+| Step | Calculation |
+|:--------:|:------|
+| `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
-##### 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)$
+| Step | Calculation |
+|:--------:|:------|
+| `1` | $t\_c = \mid \frac{t\_{now}}{W}\mid$ |
+| `2` | $x\_1 = h^{n}(K) \oplus h(t\_c)$ |
+| `3` | Generate $(K',n',s')$ until