commit b07f2d53cba33a6b2efed5904e5874b767a5406a Author: Roger Dingledine arma@torproject.org Date: Sun Nov 4 18:28:50 2012 -0500
simple fixes to proposal 202 --- proposals/202-improved-relay-crypto.txt | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/proposals/202-improved-relay-crypto.txt b/proposals/202-improved-relay-crypto.txt index dafafdd..695df30 100644 --- a/proposals/202-improved-relay-crypto.txt +++ b/proposals/202-improved-relay-crypto.txt @@ -135,7 +135,7 @@ Overview: * It permits tagging attacks. Because AES_CTR is an XOR-based stream cipher, an adversary who controls the first node in a circuit can XOR anything he likes into the relay cell, and - then see whether he/she encounters an correspondingly + then see whether he/she encounters a correspondingly defaced cell at some exit that he also controls.
That is, the attacker picks some pattern P, and when he @@ -469,7 +469,7 @@ Overview:
This approach is also simple and (given good parameter choices) can achieve our goals. The trickiest part is the algorithm that - clients must follow to package cells, but that's no so bad. + clients must follow to package cells, but that's not so bad.
It's not necessary to check MACs on inbound traffic, because nobody but the client can tell scrambled messages from good ones, @@ -496,7 +496,7 @@ Overview: tweak with each cell (possibly based on the unused portion of the MAC).
- This protocol does support loose source routing, so long as the + This protocol does support loose source routing, so long as no padding bytes are added by any router-added nodes.
In a circuit, every node has at least one relay cell sent to it: