[tor-commits] [torspec/master] Replace proposal 295 with the right version :/
nickm at torproject.org
nickm at torproject.org
Wed Jul 4 20:42:02 UTC 2018
commit 09220cc5b7da9aae30549f0d58cd9de0d9db447d
Author: Nick Mathewson <nickm at torproject.org>
Date: Wed Jul 4 16:41:58 2018 -0400
Replace proposal 295 with the right version :/
---
proposals/000-index.txt | 4 +-
proposals/295-relay-crypto-with-atl.txt | 469 ++++++++++++++++----------------
2 files changed, 230 insertions(+), 243 deletions(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index d9c7e93..6b3295f 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -215,7 +215,7 @@ Proposals by number:
292 Mesh-based vanguards [ACCEPTED]
293 Other ways for relays to know when to publish [OPEN]
294 TLS 1.3 Migration [DRAFT]
-295 Using the ATL construction for relay cryptography (solving the crypto-tagging attack) [OPEN]
+295 Using ADL-GCM for relay cryptography (solving the crypto-tagging attack) [OPEN]
Proposals by status:
@@ -245,7 +245,7 @@ Proposals by status:
287 Reduce circuit lifetime without overloading the network
289 Authenticating sendme cells to mitigate bandwidth attacks
293 Other ways for relays to know when to publish [for 0.3.5]
- 295 Using the ATL construction for relay cryptography (solving the crypto-tagging attack)
+ 295 Using ADL-GCM for relay cryptography (solving the crypto-tagging attack)
ACCEPTED:
188 Bridge Guards and other anti-enumeration defenses
249 Allow CREATE cells with >505 bytes of handshake data
diff --git a/proposals/295-relay-crypto-with-atl.txt b/proposals/295-relay-crypto-with-atl.txt
index 74e31b1..73eb98b 100644
--- a/proposals/295-relay-crypto-with-atl.txt
+++ b/proposals/295-relay-crypto-with-atl.txt
@@ -1,10 +1,9 @@
Filename: 295-relay-crypto-with-atl.txt
-Title: Using the ATL construction for relay cryptography (solving the crypto-tagging attack)
+Title: Using ADL-GCM for relay cryptography (solving the crypto-tagging attack)
Author: Tomer Ashur
Created: 09 Apr 2018
Status: Open
-
0. Context
Although Crypto Tagging Attacks were identified already in the
@@ -13,8 +12,8 @@ Status: Open
improved relay encryption protocols for Tor cells) Nick Mathewson
discussed two approaches to stymie tagging attacks and generally
improve Tor's cryptography. In Proposal 261 (AEZ for relay
- cryptography) Nick put forward a concrete approach which uses the
- tweakable wide-block cipher AEZ.
+ cryptography) Mathewson puts forward a concrete approach which uses
+ the tweakable wide-block cipher AEZ.
1. Motivation
@@ -27,250 +26,238 @@ Status: Open
describes an improved algorithm for circuit encryption based on
CTR-mode which is already used in Tor, and an additional component
for hashing. When this additional component is GHash, a GCM-based
- solution can be used from the OpenSSL library. If a solution that is
- based solely on components that already exist in Tor is desirable,
- SHA-1 can be used for hashing (however, this is highly discouraged as
- SHA-1 is broken!).
+ solution can be used from the OpenSSL library.
Incidentally, and similar to Proposal 261, this proposal employs the
ENCODE-then-ENCIPHER approach thus it improves Tor's E2E integrity by
using (sufficiently enough) redundancy.
- For more information about the scheme and a security proof for its
- RUP-security see
+ For more information about the scheme and a security proof for its
+ RUP-security see
+
+ Tomer Ashur, Orr Dunkelman, Atul Luykx: Boosting Authenticated
+ Encryption Robustness with Minimal Modifications. CRYPTO (3)
+ 2017: 3-33 available online at https://eprint.iacr.org/2017/239 .
+
+2.1. Cryptographic algorithms
+
+ As an encryption primitive we use AES. We denote one call to the
+ primitive by E(·), e.g.,
+
+ Z = E_k(X)
+
+ where k is a K-bit key, X is the input to AES and Z is the output. We
+ omit k where it is irrelevant or is clear from context. While we
+ propose to set K=256 to ensure long-term post-quantum resistance, we
+ stress that the solution also works for other key lengths.
+
+ To encrypt, we use AES is counter mode and a nonce N to produce a
+ random bit stream, e.g.,
- Tomer Ashur, Orr Dunkelman, Atul Luykx: Boosting Authenticated
- Encryption Robustness with Minimal Modifications. CRYPTO (3) 2017:
- 3-33 available online at https://eprint.iacr.org/2017/239 .
+ CTR(N) = E(N)||E(N+1)||...||E(N+l) = z_1||z_2||...||Z_{n+1} = Z
-2.1 An instructive 1-node circuit
+ and XOR Z with the message M to produce the ciphertext C, e.g.,
+
+ C = Z ^ M
+
+ For authentication, we use the universal hash function GHASH and a
+ key k, e.g.,
+
+ T = H(K||X) = H_k(X)
+
+ where K is a 256-bit key, X an arbitrary length string, and T a
+ unique authentication tag for X. While we propose to set K=256 to
+ ensure long-term post-quantum resistance, we stress that the solution
+ works for any universal hash function as well as for keys of length
+ K!=256.
+
+3. The proposed solution
+
+3.1 An overview of the proposed solution
Noting that in CTR-mode the nonce is essential for the
encryption/decryption operations, the proposed solution is based on
- encrypting its value in such a way that any change to the ciphertext
- or the tag (e.g., through a tagging attack) would randomize the nonce
- and result in a random value as the output of CTR-mode.
-
- The basic crypto components of the proposal are:
- * a block cipher E(·)
- * A universal hash function, H(·);
-
- Using the block cipher E(·) and a non-repeating nonce N, one can
- construct the CTR mode-of-operation:
-
- CTR(N) = E(N)||E(N+1)||...||E(N+l)
-
- For simplicity, let us for now consider normal encryption using
- CTR-mode (This is akin to building a circuit with a single node. In
- the sequel we will see what happens when this idea is used in a 3-node
- circuit):
-
- * Input: a nonce N, a message M = (m_0,...,m_l)
- 1. (z_0,...,z_l) = CTR(N)
- 2. (c_0,...,c_l) = (z_0 ^ m_0, ... z_l ^ m_l)
-
- The client sends C = (c_0,...,c_l) to the receiver which repeats Step
- (1) to generate the random stream Z = (z_0,...,z_l) and recovers the
- message through M = C ^ Z. A protocol using this scheme is vulnerable
- to the crypto tagging attack due to the malleability of
- CTR-mode. Indeed, since Z depends only on N rather than on the
- message M itself, a change to a ciphertext bit affects the respective
- plaintext bit and nothing else.
-
- Our solution is based on the idea that linking N and C makes it
- impossible to change C without affecting N (and hence Z) in such a
- way that it is impossible to recover M. This can be done by extending
- the protocol in the following way:
-
- 3. X = H(C)
- 4. S = X ^ E(N ^ X)
-
- Now, instead of sending C, the client sends C||S to the receiver. To
- decrypt, the receiver first repeats Step (3) to obtain X, then
- inverts Step (4) to obtain N: N = D(S ^ X) ^ X (where D(·) is the
- inverse function of E(·)). Then, having obtained N, the receiver
- continues to decrypt C as before. If the receiver already knows N
- (e.g., in the case of a synchronized nonce), they can authenticate C
- by comparing N = D(S ^ X) ^ X to the nonce they expect.
-
- Let us consider what happens when a change is made to C. Let C' be a
- variant of C with one or more bits flipped. Since H(·) is a universal
- hash function, X' = H(C' ≠ C) is random. Trying to execute D(S ^ X')
- ^ X' would result in a random N' ≠ N which in turn would result in a
- random Z' (and hence a random M'). Similarly for a change in S.
-
-2.2 Extending to a 3-node Tor circuit
-
- The Tor protocol uses layered encryption to encapsulate the
- message. Generally speaking, this can be written as:
-
- * input: synchronized nonces (N^0, N^1, N^2), a message M = (m_0,...,m_l)
- 1. (z^2_0,...,z^2_l) = CTR(N^2)
- 2. (c^2_0,...,c^2_l) = (z^2_0 ^ m_0, ... z^2_l ^ m_l)
- 3. (z^1_0,...,z^1_l) = CTR(N^1)
- 4. (c^1_0,...,c^1_l) = (z^1_0 ^ c^2_0, ... z^1_l ^ c^2_l)
- 5. (z^0_0,...,z^0_l) = CTR(N^0)
- 6. (c^0_0,...,c^0_l) = (z^0_0 ^ c^1_0, ... z^0_l ^ c^0_l)
-
- The crypto-tagging stems from the fact that a change to C affects M
- directly since all z^j_i depend only on N^j rather than on C^j.
-
- An extension of the 1-layer solution presented in Section 2.1 would
- look like this:
-
- * Input: a nonce N, a message M = (m_0,...,m_l)
- 1. (z^2_0,...,z^2_l) = CTR(N)
- 2. (c^2_0,...,c^2_l) = (z^2_0 ^ m_0, ... z^2_l ^ m_l)
- 3. X^2 = H(C^2)
- 4. S^2 = X^2 ^ E(N^2 ^ X^2)
-
- 5. (z^1_0,...,z^1_l) = CTR(S^2)
- 6. (c^1_0,...,c^1_l) = (z^1_0 ^ c^2_0, ... z^1_l ^ c^2_l)
- 7. X^1 = H(C^1)
- 8. S^1 = X^1 ^ E(S^2 ^ X^1)
-
- 9. (z^0_0,...,z^0_l) = CTR(S^1)
- 10. (c^0_0,...,c^0_l) = (z^0_0 ^ c^1_0, ... z^1_l ^ c^0_l)
- 11. X^0 = H(C^0)
- 12. S^0 = X^0 ^ E(S^1 ^ X^0)
-
- The client sends the message C^0||S^0 = ((c^0_0,...,c^0_l)||S^0) to
- the guard. To decrypt, the guard repeats Step (11) and inverts Step
- (12) to obtain S^1 which it uses to generate Z^0 and decrypt C^0 into
- C^1. The guard then forwards C^1||S^1 to the middle node which
- repeats this process and forwards C^2||S^2 to the exit. The exit
- removes the final encryption layer and processes the cell as in the
- old protocol.
-
- Let us now consider what happens when the crypto tagging attack is
- applied to this protocol. Without loss of generality, after inverting
- Step (11) the guard tags either C^1 or S^1 and forwards C'^1||S'^1 to
- the middle node. The middle node, unaware of the change follows the
- protocol to decrypt C'^1||S'^1 which results in a random string as
- per the explanation above. Since both CircID and CMD are not part of
- the payload, the middle node can still forward the random string
- (unaware of this fact) to the exit node. Upon receiving the random
- string, the exit node decrypts it, sees that the 'Rec' field is not
- all-zero and acts accordingly.
-
-
-3. Design considerations
-
-3.1 Choice of primitives
-
- We stress that the proposed protocol is primitive agnostic.
-
- Noting that Tor currently uses AES_CTR we tried to design a solution
- that requires only minimal changes. Most importantly, the encryption
- is still performed using CTR-mode, and can be instantiated using
- AES_CTR (however, the solution works just as well with any other
- block cipher).
-
- The hashing of the ciphertext requires a universal hash function. The
- GCM mode of operation uses CTR+GHash and is available from the
- OpenSSL crypto library which is already used within Tor. Any
- available universal hash function can be used instead of GHash if the
- latter introduces an unacceptable latency.
-
- The nonce-encryption step uses a tweakable block cipher. In the
- example above we used the XEX trick to transform a "regular" block
- cipher into a tweakable block cipher which allows reusing whatever
- underlying primitive is used in CTR-mode. A tweakable block cipher
- can be used directly (with X as the tweak) if one is available but
- this is not required.
-
-3.2 Security requirements
-
- In Proposal 202, Nick Mathewson outlined the security requirements
- for any solution. We copy them here verbatim and discuss how each of
- them is addressed in the proposed solution:
-
- * " ... we'd like any attacker who controls a node on the circuit
- not to have a good way to learn any other nodes, even if he/she
- controls those nodes" - By construction, once processed by an
- honest node the cell's payload is completely destroyed, thus
- unlinking any relation between what is seen by nodes further
- down the circuit and the original message. An adversary
- controlling the exit node can still see that the circuit turned
- into junk (borrowing the professional jargon of Proposal 202);
- this seems unavoidable (if any of the other proposals somehow
- solved this, we would like to know so we can see if it can
- somehow be adapted here.
-
- * "no relay should be able to alter a cell between an honest sender
- and an honest recipient in a way that they cannot detect" - Any
- alternation of a cell between a sender and a recipient will be
- decrypted to junk and never delivered to the recipient. (**)
-
- * "Relay cells should be secret: nobody but the sender and
- recipient of a relay cell should be able to learn what it says."
- - since the protocol is an extension of the existing one,
- whatever secrecy was present before remains so.
-
- * "... Circuits should resist transparent, recoverable tagging
- attacks... " - that's the whole point. Once a change was injected
- and passed to an adjacent honest node, no node further down the
- circuit can recover the relay cell.
-
- * "... The above properties should apply to sequences of cells
- too... " - this one is more tricky. To the best of my
- understanding this property is currently ensured through the
- 'Digest' field in the payload. Keeping this field, our solution
- can provide the same functionality as before. However,
- re-arranging the 'Rec' and 'Digest' fields in a way similar to
- Proposal 261 would reduce the overhead but would require
- developing a different solution. It seems possible though. (*)
-
- In addition to supporting these security requirements, this proposal
- improves Tor's E2E authentication by replacing the broken SHA-1 with
- an ENCODE-then-ENCIPHER authentication. By introducing redundancy to
- the cell (either through the 'Rec' and 'Digest' fields or otherwise)
- the exit node can verify that the cell was not altered en route. This
- is similar to what is done in Proposal 261 but without the trouble of
- using a tweakable wide-block cipher.
-
- (*) a possible solution would be to digest X as part of H(C) but
- this requires further discussion.
-
- (**) my understanding is that a single circuit can be used for
- more than one TCP stream. If this is not the case, then the
- recipient receives a random string and can identify that this is
- not a valid message.
-
-
-3.3 Feature requirements
-
-
- In addition to security requirements, Proposal 202 also discusses
- some feature requirements. We discuss two of them here as the others
- seems to be trivially supported (although this needs to be verified
- by someone who understands Tor better than me).
-
-
- * "Any new approach should be able to coexist on a circuit with the
- old approach" - following the IRC discussion, we had an internal
- discussion and we think that the proposed solution works even if
- only the middle node supports the new protocol. This involves
- encrypting the nonce only for the middle nonce. We came up with
- two ways to achieve this, both have their pro's and con's and
- should be discussed once we agree on the general idea.
-
- Since the Crypto tagging attack requires a collusion between a
- corrupted guard and a corrupted exit, it does not make sense to
- discuss what happens when one of them runs the new protocol.
-
- * "Cell length needs to be constant as cells move through the
- network." - The solution was designed to allow for a fixed cell
- size. this should be discussed though.
-
-4. Specifications
- TBD
-
-5. Compatibility
- See Section 3.3
-
-6. Implementation
- TBD
-
-7. Performance and scalability notes
- TBD
+ linking the nonce and the transmitted data in such a way that any
+ change to the data (e.g., through a tagging attack) randomizes the
+ nonce and results in a random value Z' != Z for CTR(N' != N).
+
+3.1.1. 'Forward' direction (same direction as CREATE):
+
+ When preparing a message to be sent in the forward direction, the
+ client is responsible for encrypting all layers. The client starts by
+ digesting the message to create a synthetic tweak T_0 = H_{k_fM}(M)
+ and uses this tweak to encrypt an all-zero string to create a
+ synthetic IV: S_0 = T_0 ^ E_{k_fE}(0 ^ T_0).
+
+ The message and the synthetic IV (i.e., M||S_0) are passed as input
+ to the first encryption layer which uses S_0 to produce the random
+ stream Z = CTR_k1(S_0) and the ciphertext C = Z ^ M. Then, a tweak T
+ = H_k2(C) is generated by digesting the ciphertext of this
+ layer. Finally, S_0 is encrypted using AES and the tweak T to produce
+ an encrypted nonce S = T ^ E_k3(N ^ T) which is appended to the the
+ ciphertext and is used as the nonce for the next encryption layer.
+
+ After encrypting 3 times, the client sends C||S to the guard. Whereas
+ the protocol previously required that the nonce be kept in sync
+ between each node and the client, this is no longer required as it
+ can now be recovered from C||S. To decrypt, the node first computes T
+ = H_k2(C) then uses it to obtain S = D_k3(S ^ T) ^ T. Finally, CTR(S)
+ is used to decrypt C into M. The once-decrypted nonce is appended to
+ the data and M||S is sent to the next node which repeats this
+ process.
+
+ The exit verifies the integrity of the message by digesting it and
+ using the resulting T to decrypt S_0 into N. If N=0, the message is
+ authenticated. Otherwise, if the message has been changed by an
+ adversary, N!=0 and the circuit is destroyed.
+
+3.1.2 'Back' direction (opposite direction from CREATE):
+
+ When sending back a message from the exit to the client, each node
+ adds an additional layer of encryption. The exit starts by digesting
+ the message to create a synthetic tweak T_0 = H_{k_bM}(M) and uses
+ this tweak to encrypt an all-zero string to create a synthetic IV:
+ S_0 = T_0 ^ E_{k_bE}(0 ^ T_0). The synthetic IV is then used to
+ produce the random stream Z = CTR_k1(S_0) and uses that to encrypt
+ the plaintext through C = Z ^ M. The nonce is appended to the
+ ciphertext and C||S_0 is sent to the next node.
+
+ Receiving a message from the exit, the middle starts by producing a
+ tweak T = H_k2(C). The tweak is then used to encrypt the nonce
+ through S = T ^ E_k3(N ^ T) which is then used to produce the random
+ stream Z' = CTR_k1(S). Finally, the message is encrypted via C' = Z'
+ ^ C and the encrypted nonce is appended to C'. The message C'||S is
+ sent to the next node which repeats this procedure.
+
+ When the message arrives at the client, the client peels each layer
+ using the nonce that is appended at the end of the message. The
+ decrypted layer is used to compute the tweak T = H_k2(P), which is
+ used to decrypt this layer's nonce into the next layer's nonce.
+
+ The client verifies the integrity of the message by digesting it and using
+ the resulting T to decrypt S_0 into N. If N=0, the message is
+ authenticated. Otherwise, if the message has been changed by an adversary,
+ N!=0 and the circuit is destroyed.
+
+3.2 Circuit management
+
+3.2.1 Creating circuits
+
+ The general process of creating a circuit remains the same (see
+ tor-spec.txt), except for step 5 where instead of creating a pair of
+ keys (kf_1,kb_1) for forward and backward communication,
+ respectively, 2 triplets of keys (kf_1,kf_2,kf_3) and
+ (kb_1,kb_2,kb_3) are created for communication in the forward and
+ backward directions, respectively. Two additional pairs of
+ "authentication keys" (k_fM,k_fE) and (k_bM,k_bE) are created between
+ the client and the exit in the forward and backward directions,
+ respectively.
+
+ note: the keys can be created by running KDF-RFC5869 3 times in each
+ direction, or by running it once in each direction to create a
+ master-key and derive the rest as subkeys from this master key
+
+3.2.2 Routing relay cells
+
+ When an OR receives a RELAY or RELAY_EARLY cell, it checks the cell's
+ circID and determines whether it has a corresponding circuit along
+ that connection. If not, the OR drops the cell.
+
+ Otherwise, if the OR is not at the OP edge of the circuit (that is,
+ either an 'exit node' or a non-edge node), it de/encrypts the payload
+ with the stream cipher, as follows (the message structure is C||S):
+
+ 'Forward' relay cell (same direction as CREATE)
+ (input structure is: C||S):
+
+ 1. T = H_{kf_2}(T'||C); digest ciphertext (T' is a running digest
+ of all previous cells, i.e., last round's T)
+
+ 2. N = T ^ D_{kf_3}(S ^ T); decrypt nonce
+
+ 3. M = CTR_{kf_1}(N) ^ C; decrypt message
+ (output structure is M||N)
+
+ 'Back' relay cell (opposite direction from CREATE)
+ (input structure is: M||N):
+
+ 1. T = H_{kb_2}(T'||M); digest ciphertext (T' is a running digest
+ of all previous cells, i.e., last round's T)
+
+ 2. S = T ^ E_{kb_3}(N ^ T); encrypt nonce
+
+ 3. C = CTR_{kb_1}(S) ^ M; encrypt message
+ (output structure is C||S)
+
+ Note that in counter mode, decrypt (D) and encrypt (E) are the same
+ operation.
+
+ The OR then decides whether it recognizes the relay cell, by
+ inspecting the payload as described in Section 4.1 below. If the OR
+ recognizes the cell, it processes the contents of the relay cell.
+ Otherwise, it passes the decrypted relay cell along the circuit if
+ the circuit continues. If the OR at the end of the circuit
+ encounters an unrecognized relay cell, an error has occurred: the OR
+ sends a DESTROY cell to tear down the circuit.
+
+4. Application connections and stream management
+
+4.1 Relay cells
+
+ Within a circuit, the OP and the exit node use the contents of RELAY
+ packets to tunnel end-to-end commands and TCP connections ("Streams")
+ across circuits. End-to-end commands can be initiated by either
+ edge; streams are initiated by the OP.
+
+ The payload of each unencrypted RELAY cell consists of:
+ Relay command [1 byte]
+ 'Recognized' [2 bytes]
+ StreamID [2 bytes]
+ Length [2 bytes]
+ Data [PAYLOAD_LEN-23 bytes]
+
+ The 'recognized' field is used for a simple indication if the cell
+ still encrypted or not. When sending cells, the unencrypted
+ 'recognized' MUST be set to zero.
+
+ When receiving and decrypting cells the 'recognized' will always be
+ zero if we're the endpoint that the cell is destined for. For cells
+ that we should relay, the 'recognized' field will usually be nonzero,
+ but will accidentally be zero with P=2^-32.
+
+ The old Digest field is removed, since sufficient information for
+ authentication is now included in the all-zero string used to create the
+ nonce for the first encryption layer.
+
+ The 'Length' field of a relay cell contains the number of bytes in
+ the relay payload which contain real payload data. The remainder of
+ the payload is padded with NUL bytes.
+
+4.2 Appending the encrypted nonce
+
+ When a cell is prepared by the client to be sent in the 'forward'
+ direction, as explained in Section 3.2.2, the encrypted nonce S 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, S is used as the nonce for the next round's
+ encryption. Otherwise, if the next node only supports the old
+ protocol, S is still appended to the encrypted cell, but a
+ synchronized nonce (as per the old protocol) is used for encryption.
+
+ When a cell is sent along the circuit in the 'backward' direction,
+ nodes supporting the new protocol always assume that the last 16
+ bytes of the input are the nonce used by the previous node, which
+ they process as per Section 3.2.2. If the previous node also supports
+ the new protocol, these cells are indeed the nonce. If the previous
+ node only supports the old protocol, these bytes are either encrypted
+ NUL bytes or encrypted data.
+
+4.3 Authenticating the message
+
+ End-to-end authentication is performed in both directions in the same
+ way. Once the final layer of encryption is removed, the
+ message-to-be-authenticated is digested and this digest is used to
+ decrypt the nonce used in this layer. If the decrypted nonce is
+ all-zero, the message is authentic. Otherwise, if a change was made
+ to the ciphertext or the encrypted nonce somewhere along the circuit,
+ the nonce decrypts into a random value and the circuit is destroyed.
More information about the tor-commits
mailing list