summaryrefslogtreecommitdiff
path: root/doc/spec
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2007-12-11 23:23:25 +0000
committerNick Mathewson <nickm@torproject.org>2007-12-11 23:23:25 +0000
commitb865587265a480b8114cdbd23ffe15013ffd3c17 (patch)
tree6ce9529d811fa97ac0d31e2699630a958de67beb /doc/spec
parent8de822b544fd9d619f6a4712ba270c06ffbe2896 (diff)
downloadtor-b865587265a480b8114cdbd23ffe15013ffd3c17.tar.gz
tor-b865587265a480b8114cdbd23ffe15013ffd3c17.zip
r15268@tombo: nickm | 2007-12-11 18:22:52 -0500
tweaks to bridge-disbursement document svn:r12774
Diffstat (limited to 'doc/spec')
-rw-r--r--doc/spec/proposals/ideas/xxx-bridge-disbursement.txt20
1 files changed, 18 insertions, 2 deletions
diff --git a/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt b/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt
index 03262535fa..24ee9ea865 100644
--- a/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt
+++ b/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt
@@ -55,6 +55,13 @@ IP-based.
approach would also resolve the "Make sure you can't construct a
distinct address to match an existing one" note below. -RD]
+ [I think, if we get a replay, we need to sen back the same
+ answer as we did the first time, not say "try again."
+ Otherwise we need to worry that an attacker can keep people
+ from getting bridges by preemtively asking for them,
+ or that an attacker may force them to prove they haven't
+ gotten any bridges by asking. -NM]
+
[While we're at it, if we do the replay cache thing and don't need
repeatable answers, we could just pick K random answers from the
pool. Is it beneficial that a bridge user who knows about a clump of
@@ -68,12 +75,20 @@ IP-based.
the difference in clumps and estimate how quickly the bridge pool
is growing. -RD]
+ [Random is one more darn thing to implement; rings are already
+ there. -NM]
+
[If we make the period P be mailbox-specific, and make it a random
value around some mean, then we make it harder for an attacker to
know when to try using his small army of gmail addresses to gather
another harvest. But we also make it harder for users to know when
they can try again. -RD]
+ [Letting the users know about when they can try again seems
+ worthwhile. Otherwise users and attackers will all probe and
+ probe and probe until they get an answer. No additional
+ security will be achieved, but bandwidth will be lost. -NM]
+
To normalize an email address:
Start with the RFC822 address. Consider only the mailbox {???}
portion of the address (username@domain). Put this into lowercase
@@ -140,8 +155,9 @@ IP-based.
in the ring after X.
[Don't we want to compute C = HMAC(key, area) to learn what cluster
- to answer from, and then X = HMAC(key, PS|area) to pick a point in
- that ring? -RD]
+ to answer from, and then X = HMAC(key, PS|area) to pick a point in
+ that ring? -RD]
+
Need to clarify that some HMACs are for rings, and some are for
partitions. How rings scale is clear. How do we grow the number of