From a386ccd5a191724ee55a72839589c6d43201d498 Mon Sep 17 00:00:00 2001 From: xdrm-brackets Date: Wed, 5 Sep 2018 17:22:51 +0200 Subject: [PATCH] updated PROTOCOL.md (WIP) > began actual protocol --- PROTOCOL.md | 111 ++++++++++++++++++++++------------------------------ 1 file changed, 46 insertions(+), 65 deletions(-) diff --git a/PROTOCOL.md b/PROTOCOL.md index 99428ce..4050e46 100644 --- a/PROTOCOL.md +++ b/PROTOCOL.md @@ -131,19 +131,19 @@ The receiver has to guess $t_s$ with the following steps: | 1 | receive the sender's time parity | $Receive \ m_s$ | | 2 | process the receiver's time id | $t\_r = \mid \frac{t_{now}^r}{W} \mid $ | | 3 | process the receiver's time parity | $m_r = t_r \mod 2$ | -| 4 | Try to guess the sender's time id | $t_{s2} = t_r - \parallel m_s - m_r \parallel $ | +| 4 | Try to guess the sender's time id | $t'_s2 = t_r - \parallel m_s - m_r \parallel $ | 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 \leq t\_{now}^s + W \implies 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. -As a result from the sent token $x_1 = token \oplus h(t_s)$, it is impossible to guess the token nor $h(t_s)$ without the other. +As a result from the sent token $x_1 = token \oplus h(t_s)$, it is impossible to guess neither the token nor $h(t_s)$ without the other. **Explanation** * 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 window 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$. +* 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$ @@ -194,93 +194,74 @@ For a given key, every token sent has a lower nonce $n$ than every other ## Protocol definition -Each request will hold a pair of tokens $(x_1, x_2)$. If the server's check fails (*i.e. the client is not authenticated*), it will send back to the client a pair of tokens $(y_1, y_2)$ for resynchronization. +Each request will hold a pair of tokens $(x_1, x_2)$. If the server's check fails (*i.e. the client is not authenticated*), it will send back to the client a pair of tokens $(y_1, y_2)$ for resynchronization purposes. Each token has a size defined by the *hash function*, which is `sha512` for this specification ; the size is then 512 bits. > For readability purposes, the tokens are sent as their hexadecimal representation ; each token is then a string of 128 characters. -### 1. Request +### 1. Send the request -This case is the default where $i$ is far from $1$ so there is no key generation to do. +This case is the default where $i$ is far from $1$ so there is no key generation or synchronization to do. | Step | Description | Formula | |:----:|-------------|:--------| | `c1` | Decrement the shifting nonce | $i = i - 1$ | -| `c2` | Calculate the one-time token $T_C$ | $T_C = h^{i}(K)$ | -| `c3` | Get the current window id $t_C$ | $t_C =\ \mid \frac{t_{now}}{W} \mid$ | -| `c4` | Calculate $m_C$, the parity of $t_C$ | $m_C = t_C \mod 2$ | -| `c5` | Calculate the time hash $h_{t_C}$ | $h_{t_C} = h(t_C)$ | -| `c6` | Calculate $x_1$, the scrambled *request token* | $x_1 = T_C \oplus h_{t_C}$ | -| `c7` | Calculate $x_2$, the next token + time parity | $x_2 = x_1 \oplus m_C$ | +| `c2` | Calculate the one-time token | $T_c = h^{i}(K)$ | +| `c3` | Get the current time id | $t\_c =\ \mid \frac{t\_{now}}{W} \mid$ | +| `c4` | Calculate the parity of $t_c$ | $m_c = t_c \mod 2$ | +| `c5` | Calculate the time hash $h_{t_c}$ | $h_{t_c} = h(t_c)$ | +| `c6` | Calculate $x_1$, the scrambled *request token* | $x\_1 = T\_c \oplus h\_{t\_c}$ | +| `c7` | Calculate $x_2$, the scrambled *next token* | $x_2 = x_1 \oplus m_c$ | -**Security** : We process a one-time pad between $T_C$ and $h_{t_C}$ it is crucial that both values have the same size of $L$ bits. It makes $T_C$ impossible to extract without having the value $h_{t_C}$, this property applies in both ways. +**Security** : We process a one-time pad between $T_c$ and $h_{t_c}$ it is crucial that both values have the same size of $L$ bits. It makes $T_c$ impossible to extract without having the value $h_{t_c}$, this property applies in both ways. **Short formulas** -| Field to send | Short formula | +| Field | Short formula | | :-----------: | ------------------------------------------------ | -| $T_{req}$ | $h^{i}(K) \oplus h(\mid\frac{t_{now}}{W}\mid)$ | -| $m_C$ | $\mid\frac{t_{now}}{W}\mid \mod 2$ | +| $t_c$ | $\mid\frac{t_{now}}{W}\mid$ | +| $x_1$ | $h^{i}(K) \oplus h(t_c)$ | +| $x_2$ | $x_1 \oplus (t_c \mod 2)$ | -> Note -> -> - In order to send all the data in one request, for instance you can simply concatenate the 2 variables. +Send $(x_1, x_2)$. +### 2. Receive the request -### 2. Response - -Received data - -- $T_{req}$ the received request token -- $m_C$ the received time id parity +The server receives $(x_1, x_2)$. It does have to : +1. Guess the client's time id to un-scramble the token +2. Check the token | Step | Description | Formula | -|:----:|-------------|---------| -| `s1` | Store the reception time window id $n'$ | $n' = \mid \frac{t_{now}}{W}\mid$ | -| `s2` | Calculate $m_S$, the parity of $n'$ | $m_S = n' \mod 2$ | -| `s3` | Use $m_C$ to try to correct the reception window id and guess the request time id | $n_S = n' - \parallel m_C - m_S \parallel$ | -| `s4` | Calculate the time hash $h_{n_S}$ | $h_{n_S} = h(n_S)$ | -| `s5` | Cancel $h_{n_S}$ to extract $T_{C'}$ | $T_{C'} = T_{req} \oplus h_{n_S}$ | -| `s6` | Check if $T_{C'}$ matches $T_S$ | $T_{C'} = T_S ?$ | - -> If $T_{C'} = T_S$, $S$ can consider that $C$ sent the request $0$ to $(W + \frac{W}{2})$ seconds ago. - - - -**Steps explanation** - -- `s1` - If $C$ and $S$ have the same values for $K$ and $n^1$, $f(K,n^1)$ must result in the same output; in other words $T_C=T_S$. -- `s3`/`s4` - $\parallel m_C - m_s\parallel$ is the difference between $m_C$ and $m_S$. -- If the receiver time window id ($n'$) is the same as the sender ($n_C$) - $n'=n_C \implies m_S=m_C$ - $m_C=m_S \implies \parallel m_C - m_S\parallel = 0$ - $n_S = n_C - 0$ - $n_S=n_C$, the time ids are the same, $S$ can now unscramble the request to check the token - - If the receiver time window if further the sender by $1$ - $n'=n_C+1 \implies \parallel m_C - m_S \parallel = 1$ - $n_S = n_C + 1 - 1$ - $n_S = n_C$, the time ids are the same, $S$ can now unscramble the request to check the token - - If the receiver time window if further the sender by $2$ or more, let $k \in \N$ - $n'= n_C+2+k \implies \parallel m_C - m_S\parallel \in \{0,1\}$ - $- \parallel m_C - m_S\parallel \in \{-1,0\}$ - $n_S \in \{n_C + 2 + k - 1, n_C + 2 + k + 0\}$ - $n_S \in \{n_C + k + 1, n_C + k + 2\}$ - $\rarr n_S = n_C + k + 1 \implies \forall (k\in \N), n_S \gt n_C$, the time ids differ, $S$ cannot extract $T_S$ - $\rarr n_S = n_C + k + 2 \implies \forall (k \in \N), n_S \gt n_C+1$, the time ids differ, $S$ cannot extract $T_S$ -- `s6` - By the *non-idempotency* (*i.e. $a\oplus b \oplus a = b$*) and *associativity* properties of the *XOR* operator, considering $h_{n_S}=h_{n_C}$: - $T_{C'} = T_{req} \oplus h_{n_S} = (T_C \oplus h_{n_C}) \oplus h_{n_S}$ - $h_{n_S} = h_{n_C} \implies T_{C'} = T_C \oplus h_{n_C} \oplus h_{n_C}$ - $T_{C'} = T_C$, the one-time token of $C$ have successfully been extracted -- `s7` - If $K$ and $n^1$ are the same on both machines, $T_S=T_C$. Furthermore, if the time ids are the same (*c.f. step `s6`*) the 2 tokens should match. - +|:----:|-------------|:--------| +| `s1` | Extract the client's time parity | $m_c = x_1 \oplus x_2$ | +| `s2` | Get the current time id | $t\_s =\ \mid \frac{t_{now}}{W} \mid$ | +| `s3` | Calculate the parity of $t_s$ | $m_s = t_s \mod 2$ | +| `s4` | Guess the client's time id | $t'_c = t_s - \parallel m_s - m_c \parallel$ | +| `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}$ | +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. **Short formulas** ​ The whole unscrambling process can be shortened into the following formula resulting in $0$ if the client is authenticated. -$T_{req} \oplus h(\mid \frac{t_{now}}{W}\mid - \parallel m_C - (\mid \frac{t_{now}}{W}\mid \mod 2) \parallel) \oplus f(K, n^1)$ +$$x\_1 \oplus h(\mid \frac{t\_{now}}{W}\mid - \parallel (x\_1 \oplus x\_2) - (\mid \frac{t\_{now}}{W}\mid \mod 2) \parallel) \oplus T$$ + +| Step | Description | Formula | +|:----:|-------------|:--------| +| `rs1` | Get the current time id | $t\_s = \mid \frac{t\_{now}}{W} \mid$ | +| `rs2` | Calculate the parity of $t_s$ | $m_s = t_s \mod 2$ | +| `rs3` | Calculate the time hash $h_{t_s}$ | $h_{t_s} = h(t_s)$ | +| `rs4` | Calculate $y_1$, the recovery hash | $y\_1 = T \oplus h\_{t_s}$ | +| `rs5` | Calculate $y_2$, used for parity | $y_2 = y_1 \oplus m_s$ | + +Send $(y_1, y_2)$. + +