mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
r15268@tombo: nickm | 2007-12-11 18:22:52 -0500
tweaks to bridge-disbursement document svn:r12774
This commit is contained in:
parent
8de822b544
commit
b865587265
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user