[tor-commits] [torspec/master] whitespace fixes on proposal 295.
nickm at torproject.org
nickm at torproject.org
Thu Apr 23 19:21:49 UTC 2020
commit 2ec807e10464c9881baef6318ff41ce58c07171e
Author: Nick Mathewson <nickm at torproject.org>
Date: Thu Apr 23 15:21:46 2020 -0400
whitespace fixes on proposal 295.
---
proposals/295-relay-crypto-with-adl.txt | 144 ++++++++++++++++----------------
1 file changed, 71 insertions(+), 73 deletions(-)
diff --git a/proposals/295-relay-crypto-with-adl.txt b/proposals/295-relay-crypto-with-adl.txt
index d3414c4..a1752df 100644
--- a/proposals/295-relay-crypto-with-adl.txt
+++ b/proposals/295-relay-crypto-with-adl.txt
@@ -3,7 +3,6 @@ Title: Using ADL for relay cryptography (solving the crypto-tagging attack)
Author: Tomer Ashur, Orr Dunkelman, Atul Luykx
Created: 22 Feb 2018
Last-Modified: 13 Jan. 2020
-
Status: Open
@@ -39,11 +38,11 @@ Status: Open
For authentication between the OP and the edge node we use
the PIV scheme: https://eprint.iacr.org/2013/835 .
-
+
A recent paper presented a birthday bound distinguisher
- against the ADL scheme, thus showing that the RUP security
+ against the ADL scheme, thus showing that the RUP security
proof is tight: https://eprint.iacr.org/2019/1359 .
-
+
2. Preliminaries
@@ -110,7 +109,7 @@ Status: Open
DIG_KEY_LEN backward digest key Khb
ENC_KEY_LEN forward tweak key Ktf
ENC_KEY_LEN backward tweak key Ktb
- DIGEST_LEN nonce to use in the
+ DIGEST_LEN nonce to use in the
hidden service protocol(*)
(*) I am not sure that if this is still needed.
@@ -136,15 +135,15 @@ Status: Open
(*) The terms hash and digest are used interchangeably.
(**) Proposal 308 suggested that using POLYVAL [GLL18]
- would be more efficient here. This proposal will work just the
- same if POLYVAL is used instead of GHASH.
+ would be more efficient here. This proposal will work just the
+ same if POLYVAL is used instead of GHASH.
3. Routing relay cells
Let n denote the integer representing the destination node. For
- I = 1...n, we set Tf'_{I} = DF_I, Tb'_{I} = DB_I, and
- Ta'_I = AF_I where DF_I, DB_I, and AF_I are generated
- according to Section 2.4.
+ I = 1...n, we set Tf'_{I} = DF_I, Tb'_{I} = DB_I, and
+ Ta'_I = AF_I where DF_I, DB_I, and AF_I are generated
+ according to Section 2.4.
3.1. Forward Direction
@@ -255,7 +254,7 @@ Status: Open
authenticate the message as follows.
4.1.1 forward direction (executed by the end node):
-
+
Ta_I = Digest(Khf_n,Ta'_I||C_{n+1})
Tag = Ta_I ^ D(Ktf_n,Ta_I ^ N_{n+1})
@@ -281,13 +280,13 @@ Status: Open
and version-heterogenic circuits
When a cell is prepared to be routed from the origin (see Section
- 3.1.1 above) the encrypted nonce N is appended to the encrypted
+ 3.1.1 above) the encrypted nonce N is appended to the encrypted
cell (occupying the last 16 bytes of the cell). If the cell is
prepared to be sent to a node supporting the new protocol, N is
- used to generate the layer's nonce. Otherwise, if the node only
- supports the old protocol, N is still appended to the encrypted
- cell (so that following nodes can still recover their nonce),
- but a synchronized nonce (as per the old protocol) is used in
+ used to generate the layer's nonce. Otherwise, if the node only
+ supports the old protocol, N is still appended to the encrypted
+ cell (so that following nodes can still recover their nonce),
+ but a synchronized nonce (as per the old protocol) is used in
CTR-mode.
When a cell is sent along the circuit in the 'backward'
@@ -402,20 +401,20 @@ Status: Open
repeat with low probability. GHASH is a universal hash function,
hence it gives such a guarantee assuming its key is chosen
uniformly at random.
-
+
6. Forward secrecy
- Inspired by the approach of Proposal 308, a small modification
- to this proposal makes it forward secure. The core idea is to
+ Inspired by the approach of Proposal 308, a small modification
+ to this proposal makes it forward secure. The core idea is to
replace the encryption key KF_n after de/encrypting the cell.
- As an added benefit, this would allow to keep the authentication
- layer stateless (i.e., without keeping a running digest for
- this layer).
-
+ As an added benefit, this would allow to keep the authentication
+ layer stateless (i.e., without keeping a running digest for
+ this layer).
+
Below we present the required changes to the sections above.
-
+
6.1. Routing from the Origin (replacing 3.1.1 above)
-
+
When an OP sends a relay cell, they prepare the
cell as follows:
@@ -424,7 +423,7 @@ Status: Open
C_{n+1} = M
T_{n+1} = Digest(Khf_n,C_{n+1})
N_{n+1} = T_{n+1} ^ E(Ktf_n,T_{n+1} ^ 0)
-
+
Then, the OP prepares the multi-layered encryption:
For the final layer n:
@@ -433,13 +432,13 @@ Status: Open
N_n = T_I ^ E(Ktf_n,T_n ^ N_{n+1})
Tf'_n = T_n
Kf_n = Kf'_n
-
- (*) CTR mode is used to generate two additional blocks. This
- 256-bit value is denoted K'f_n and is used in subsequent
+
+ (*) CTR mode is used to generate two additional blocks. This
+ 256-bit value is denoted K'f_n and is used in subsequent
steps to replace the encryption key of this layer.
- To achieve forward secrecy it is important that the
- obsolete Kf_n is erased in a non-recoverable way.
-
+ To achieve forward secrecy it is important that the
+ obsolete Kf_n is erased in a non-recoverable way.
+
For layer I=(n-1)...1:
C_I = Encrypt(Kf_I,N_{I+1},C_{I+1})
T_I = Digest(Khf_I,Tf'_I||C_I)
@@ -447,27 +446,27 @@ Status: Open
Tf'_I = T_I
The OP sends C_1 and N_1 to node 1.
-
- Alternatively, if we want that all nodes use the same functionality
+
+ Alternatively, if we want that all nodes use the same functionality
OP prepares the cell as follows:
-
+
For layer I=n...1:
(C_I,K'f_I) = Encrypt(Kf_I,N_{I+1},C_{I+1}||0||0) (*)
T_I = Digest(Khf_I,Tf'_I||C_I)
N_I = T_I ^ E(Ktf_I,T_I ^ N_{I+1})
Tf'_I = T_I
Kf_I = Kf'_I
-
- (*) CTR mode is used to generate two additional blocks. This
- 256-bit value is denoted K'f_n and is used in subsequent
+
+ (*) CTR mode is used to generate two additional blocks. This
+ 256-bit value is denoted K'f_n and is used in subsequent
steps to replace the encryption key of this layer.
- To achieve forward secrecy it is important that the
- obsolete Kf_n is erased in a non-recoverable way.
-
+ To achieve forward secrecy it is important that the
+ obsolete Kf_n is erased in a non-recoverable way.
+
This scheme offers forward secrecy in all levels of the circuit.
-
+
6.2. Relaying Forward at Onion Routers (replacing 3.1.2 above)
-
+
When a forward relay cell is received by OR I, it decrypts the
payload with the stream cipher, as follows:
@@ -478,36 +477,36 @@ Status: Open
C_{I+1} = Decrypt(Kf_I,N_{I+1},C_I||0||0)
Tf'_I = T_I
- The OR then decides whether it recognizes the relay cell as described below.
- Depending on the choice of scheme from 6.1 the OR uses the last two blocks
- of C_{I+1} to update the encryption key or discards them.
-
- If the cell is recognized the OR also processes the contents of the relay
- cell. Otherwise, it passes C_{I+1}||N_{I+1} along the circuit if the circuit
+ The OR then decides whether it recognizes the relay cell as described below.
+ Depending on the choice of scheme from 6.1 the OR uses the last two blocks
+ of C_{I+1} to update the encryption key or discards them.
+
+ If the cell is recognized the OR also processes the contents of the relay
+ cell. Otherwise, it passes C_{I+1}||N_{I+1} along the circuit if the circuit
continues.
For more information about recognizing and authenticating relay cells,
see 5.4.5 below.
-
+
6.3. Relaying Backward at Onion Routers (replacing 3.2.1 above)
When an edge node receives a message M to be routed back to the
origin, it encrypts it as follows:
-
+
T_n = Digest(Khb_n,Tb'_n||M)
N_n = T_n ^ E(Ktb_n,T_n ^ 0)
(C_n,K'b_n) = Encrypt(Kb_n,N_n,M||0||0) (*)
Tb'_n = T_n
Kb_n = K'b_n
-
- (*) CTR mode is used to generate two additional blocks. This
- 256-bit value is denoted K'b_n and will be used in
- subsequent steps to replace the encryption key of this layer.
- To achieve forward secrecy it is important that the obsolete
- K'b_n is erased in a non-recoverable way.
-
- Once encrypted, the edge node sends C_n and N_n along the circuit towards
- the OP. When a backward relay cell is received by OR_I (I<n), it encrypts
+
+ (*) CTR mode is used to generate two additional blocks. This
+ 256-bit value is denoted K'b_n and will be used in
+ subsequent steps to replace the encryption key of this layer.
+ To achieve forward secrecy it is important that the obsolete
+ K'b_n is erased in a non-recoverable way.
+
+ Once encrypted, the edge node sends C_n and N_n along the circuit towards
+ the OP. When a backward relay cell is received by OR_I (I<n), it encrypts
the payload with the stream cipher, as follows:
'Backward' relay cell:
@@ -518,7 +517,7 @@ Status: Open
Tb'_I = T_I
Each node passes C_I and N_I along the circuit towards the OP.
-
+
If forward security is desired for all layers in the circuit, all OR's
encrypt as follows:
T_I = Digest(Khb_I,Tb'_I||C_{I+1})
@@ -526,7 +525,7 @@ Status: Open
(C_I,K'b_I) = Encrypt(Kb_n,N_n,M||0||0)
Tb'_I = T_I
Kb_I = K'b_I
-
+
6.4. Routing to the Origin (replacing 3.2.2 above)
@@ -540,26 +539,25 @@ Status: Open
T_I = Digest(Khb_I,Tb'_I||C_{I+1})
N_{I+1} = T_I ^ D(Ktb_I,T_I ^ N_I)
Tb'_I = T_I
-
- And updates the encryption keys according to the strategy
+
+ And updates the encryption keys according to the strategy
chosen for 6.3.
-
+
If the payload is recognized (see Section 4.1),
then:
The sending node is I. Process the payload!
-
-
+
+
6.5. Recognizing and authenticating a relay cell (replacing 4.1.1 above):
-
- Authentication in the forward direction is done as follows:
+
+ Authentication in the forward direction is done as follows:
T_{n+1} = Digest(Khf_n,C_{n+1})
Tag = T_{n+1} ^ D(Ktf_n,T_{n+1} ^ N_{n+1})
-
+
The message is recognized and authenticated
(i.e., M = C_{n+1}) if and only if Tag = 0.
-
- No changes are required to the authentication process when the relay
+
+ No changes are required to the authentication process when the relay
cell is sent backwards.
-
More information about the tor-commits
mailing list