[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Proofreading by seborn
commit daf782e82c2ab1b66da07155ff83622923ba4140
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date: Mon Oct 31 16:47:58 2011 -0400
Proofreading by seborn
---
proposals/ideas/xxx-new-crypto-sketch.txt | 62 ++++++++++++++---------------
1 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/proposals/ideas/xxx-new-crypto-sketch.txt b/proposals/ideas/xxx-new-crypto-sketch.txt
index 83711c3..551b403 100644
--- a/proposals/ideas/xxx-new-crypto-sketch.txt
+++ b/proposals/ideas/xxx-new-crypto-sketch.txt
@@ -13,10 +13,10 @@ Author: Nick Mathewson
IDENTITY KEYS AND FINGERPRINTS
Addressed here in Section 2.
LINK CRYPTO (TLS) --
- Addressed in proposls 176, 184. We say a little here though in
- section 5.
+ Addressed in proposals 176, 184. We say a little here in section 5,
+ though.
CREATE/EXTEND CRYPTO --
- Addressed in xxx-ntor-handshake.txt and rransom's extend draft at
+ Addressed in xxx-ntor-handshake.txt and rransom's EXTEND draft at
[*] and subsequent discussion on the tor-dev mailing list. Not
considered here.
RELAY CRYPTO
@@ -41,7 +41,7 @@ Author: Nick Mathewson
groups (hereinafter "DH>1024"). {But see ECC Notes in 1.1 below.}
FOR A HASH FUNCTION: SHA256, switching to SHA3 in 2012 when it comes
- out. It might be worthwhile waiting for SHA3 in most places, and
+ out. It might be worthwhile waiting for SHA3 in most places and
skipping over the SHA256 stage entirely.
FOR A STREAM CIPHER: AES-CTR is in one sense a conservative choice
@@ -49,7 +49,7 @@ Author: Nick Mathewson
cache-based timing attacks are pretty worrisome. We can mitigate that
some by using random secret IVs for AES-CTR, so that we will be
encrypting neither attacker-chosen nor attacker-known plaintext with
- out AES cipher, but that's a bit kludgy. There are also supposed to
+ our AES cipher, but that's a bit kludgy. There are also supposed to
be time-invariant implementations that use Intel's AESNI instructions
where available, and time-invariant implementations that use
bit-slicing.
@@ -90,7 +90,7 @@ Author: Nick Mathewson
levels of security, and the resulting outputs are much shorter.
As near as I can tell as a layman, Certicom is muddying the waters as
- much as possible wrt claiming that it's nigh impractical to deploy ECC
+ much as possible wrt claiming that it's nigh-impractical to deploy ECC
without licensing their patents. This is rather like the silliness
that PKP used to pull back in the day, where they claimed that their
patents covered not only the existing public key cryptography
@@ -131,12 +131,12 @@ Author: Nick Mathewson
Identity keys and their fingerprints are used:
- To sign router descriptors.
- - To identify nodes in consensus directories
- - To make sure we're talking to the right node in the link handshake
+ - To identify nodes in consensus directories.
+ - To make sure we're talking to the right node in the link handshake.
- To make sure that the extending node is talking to the right next
- node when sending an extend cell
- - To identify particular nodes in the hidden service subsystem
- - To identify nodes in the UI in various places
+ node when sending an extend cell.
+ - To identify particular nodes in the hidden service subsystem.
+ - To identify nodes in the UI in various places.
- Internally, to identify a node uniquely in the codebase.
- To determine which part of the circuit ID space to use on a Tor
instance's links.
@@ -219,11 +219,11 @@ Author: Nick Mathewson
Let's review our use of identity keys again and make sure that we can
handle all of them with the ideas above.
- - To sign router descriptors
+ - To sign router descriptors.
We discussed this in 2.2.
- - To make sure we're talking to the right node in the link handshake
+ - To make sure we're talking to the right node in the link handshake.
The current v3 link handshake can handle presenting multiple identity
certificates in the CERT cell. We should consider ourselves to be
@@ -233,14 +233,14 @@ Author: Nick Mathewson
identity we can.
- To make sure that the extending node is talking to the right next node
- when sending an extend cell
+ when sending an extend cell.
The new extend cell format needs to allow the client to tell the
extending node about some identity for the destination node that the
extending node will be able to understand. This is a capability of
the extending node that the client needs to be able to check. (Also,
the extend cell needs to hash that identity in a form the extending
- node can understand; but that's a fingerprint issue.)
+ node can understand, but that's a fingerprint issue.)
- To determine which part of the circuit ID space to use on a Tor
instance's links.
@@ -251,19 +251,19 @@ Author: Nick Mathewson
the initiator always gets the low circIDs and the responder always
gets the high ones.
- - To identity nodes in consensus directories
- - To identify nodes in the UI in various places
+ - To identify nodes in consensus directories.
+ - To identify nodes in the UI in various places.
- Internally, to identify a node uniquely in the codebase.
See sections 3 and 4 below.
- - To identify particular nodes in the hidden service subsystem
+ - To identify particular nodes in the hidden service subsystem.
Out of scope.
2.5. Migrating away from short ID keys entirely
- Eventually no version of Tor that requires 1024-bit identity keys will
+ Eventually, no version of Tor that requires 1024-bit identity keys will
remain. When that happens, we should stop using them entirely. That
means that if we take any path other than the "slow migration" path of
2.1, we'll need to make everything that looks at a node's identity
@@ -307,9 +307,11 @@ Author: Nick Mathewson
Since 43 base-64 characters is enough to represent a 256-bit digest,
with 2 bits left over, I propose that the b64 value encode
- hh | D(hash algorithm name, key type, encoded key),
- where hh is a 2-bit value, with one of the values:
+ hh | D(hash algorithm name, key type, encoded key)
+
+ where hh is a 2-bit value, with one of the following values:
+
00 -- sha256
01 -- sha3
10 -- to be determined
@@ -356,7 +358,7 @@ Author: Nick Mathewson
This implies a proliferation of fingerprints! We should tread
carefully here. To prevent proliferation, the easiest solution is not
- to add too many new types, and to have a good plan for retiring older
+ to add too many new types and to have a good plan for retiring older
types.
3.4. Implications for EXTEND cells
@@ -428,7 +430,7 @@ Author: Nick Mathewson
get a set of identity fingerprints for each node in the format that
the client likes best -- see 3.3 and 3.4 above. So every flavor of
consensus we serve needs to include a node identity in a format the
- client understands, and a node identities in formats such that every
+ client understands, and node identities in formats such that every
node will understand at least one.
4.3. An option: compound signatures on directory objects
@@ -481,7 +483,7 @@ Author: Nick Mathewson
technically slightly more difficult than xor-based tagging, and it
could be useful to boost our defense-in-depth a little bit, just in
case other active end-to-end attacks turn out to be harder than we'd
- though.)
+ thought.)
6.1. Option 1: Use AES-CTR in a less scary mode
@@ -541,7 +543,7 @@ Author: Nick Mathewson
Consider that if option 3 is in place, an end-to-end attacker who
wants to do a tagging attack at one node can garble the rest of the
- circuit, and see if the output is garbled at the exit node. But such
+ circuit and see if the output is garbled at the exit node. But such
an attacker could just as easily close the circuit at one of those
nodes and watch for a corresponding close event, or even better --
simply pause traffic on that circuit for a while and watch for a
@@ -563,7 +565,7 @@ Author: Nick Mathewson
above, except that we'd have a MAC on them. For outgoing cells,
each node would check that the first N bytes of the cell
match a MAC of all data seen so far, *including the rest of the
- cell*. They'd then remove the first N bytes, and re-pad the cell
+ cell*. They'd then remove the first N bytes, re-pad the cell
with bytes from a PRNG, and decrypt the resulting re-padded cell.
(This is basically how mixmaster works, and how mixminion works in
the common case.)
@@ -629,7 +631,7 @@ Author: Nick Mathewson
were from node i, or relayed by node i,
and let cellbody = the body of the cell, except for the last
MACBYTESb[i] bytes,
- and let cell mac = the last MACBYTESb[i] bytes of this cell.
+ and let cellmac = the last MACBYTESb[i] bytes of this cell.
If cellmac is nonempty, check wither cellmac = mac_received,
where mac_received is the first MACBYTESb[i] bytes of
@@ -702,7 +704,7 @@ Author: Nick Mathewson
If we restrict MACBYTESf values to range 0..HL/2, where HL is the
length of the MAC output, we can replace
- MAC(x | "RECOGIZED")[:MACBYTESf] and MAC(x | "OK")[:MACBYTESf]
+ MAC(x | "RECOGNIZED")[:MACBYTESf] and MAC(x | "OK")[:MACBYTESf]
with
MAC(x)[:MACBYTESf] and MAC(x)[HL-MACBYTESf:]
@@ -755,10 +757,6 @@ Author: Nick Mathewson
total of 3 bytes for those 15 bits. That's an opportunity to
save another byte.
-6.5. Other ideas for
-
-
-
ACKS
Lots of the good ideas and concerns here are due to Robert Ransom.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits