/discussion from the tor-dev
community ahead of publishing this as a Tor Project tech report.
--
----
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesota
Visiting Re
t a random group element Q, and publishes a signed
document containing the decryption shares and Q.
--
Nicholas Hopper
Associate Professor, C
n solve the DDH problem in the
Curve25519 group. This property could be useful depending on the
eventual scaling designs supported.
(There is a typo that confused me several paragraphs later: s/faileds/fields/ )
--
Nichola
On Thu, Dec 12, 2013 at 11:11 PM, Nicholas Hopper wrote:
> Your analysis looks correct to me. But what's wrong with using
> threshold crypto or secret sharing? Since you're already assuming
> some sort of bounded delay synchronization, I think we can eliminate
> any advant
On Fri, Jan 10, 2014 at 1:07 PM, Ian Goldberg wrote:
> On Fri, Jan 10, 2014 at 10:38:06AM -0600, Nicholas Hopper wrote:
>> We'll need a hash function H that can output elements of the subgroup
>> generated by B with unknown discrete logarithms. For Curve25519, it
>>
conf/ccs/EdmanS09.pdf
----
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesota
Visiting Research Director, The Tor Project
___
tor
when parties claim *not* to have received
messages from others. (e.g. imagine that floor(n/2) authorities are
corrupted and claim that an uncorrupted party did not send them any
input)
--
---
y
authorities...
[1] http://freehaven.net/anonbib/bibtex.html#ccs09-shadowwalker
[2] http://freehaven.net/anonbib/bibtex.html#ccs09-torsk
[3] http://freehaven.net/anonbib/bibtex.html#camenisch2002da for example.
--
--------
Ni
n connection attempts.
This sounds like a great way to DoS your least favorite hidden service
at low cost.
--
----
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesota
guard threshold" becomes an
interesting attack.
Another thought: we also should investigate how various thresholds
affect the relationship between the cumulative guard weight total and
the total exit weight.
--
----
Nicholas
On Tue, Feb 25, 2014 at 5:04 PM, Nicholas Hopper wrote:
> Another thought: we also should investigate how various thresholds
> affect the relationship between the cumulative guard weight total and
> the total exit weight.
Well, that turns out not to be a real issue: even if we set
the threshold beyond
2MB/s doesn't really help much)
(This data is based on the consensus documents from 13 February 2014,
chosen pretty much arbitrarily from the most recent month of archived
consensus documents and relay descriptors)
--
---
ion period, then its weight for some other
position should be
k*(weight with the guard flag) + (1-k)*(weight without the guard flag)
--
Nich
;t have any way to simulate the CBT logic:
http://torps.github.io/
--
--------
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Mi
ndwidth for these
connections.
But if a relay has only fraction k of its "guard bandwidth" used up
this way, then (1-k) of this bandwidth should go back into the pool
for other positions. I think that's what the formula does, but I
could have it wrong. Does that make sense?
--
possible a relay operator could shoot themselves in the
foot here by causing some inconsistent state between these three
files. I guess at worst, though, this should again be a case where
the window of vulnerability is small, so very few (or possibly no)
relays would lose their history this way.
--
On Tue, Apr 8, 2014 at 2:15 PM, Nicholas Hopper wrote:
> To clarify here: does "router[s] descriptors signed by the old
> identity" include the old-id field? That is, in case an identity key
> is compromised is there a race to claim the old-id mapping? If not,
> how
been a guard for 0.25 of the rotation period => 0.25
of the clients weight the relay as a guard." Since we don't actually
want to partition the network this way, the (weighted) average of the
two weights will produce the same behavior.
--
-----
guard-node.patch
--
----
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesota
Visiting Research Director, The Tor Project
___
ests
through circuit guards to avoid this?
--
----
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesot
#x27;t learn what HS it's serving if it doesn't know
the descriptor, but any HS server that knows the secret key (x) can
compute the IP secret key x*t.
--
Nicholas Ho
clients by enabling the DirPort option.".
This would make sense, but note that nothing in the config file tells
a relay that it's a guard. So it won't notice this without looking
for its entry in the network status.
--
--
5], so their weight percentage gets smaller.
This doesn't sound right - total guard weight shouldn't change. All
the proposal does is re-allocate some fraction of the weight of a
guard back to the middle (M) category.
--
---
k at
http://www.cs.okstate.edu/~chantin/ARES2013.pdf before working further
on this topic.
--
--------
Nicholas Hopper
Associate Professor, Computer Science & E
This proposal doubles the default number of IPs and reduces the "cost"
of being an IP since the probability of being selected is no longer
bandwidth-weighted. Is this a fair tradeoff for the performance
improvement?
--
---
only local changes in the
topology, so if the client is using a different version of the
consensus they can still locate one of the responsible HSDirs. (Note:
I do not claim this cannot be done; it just seems like an important
detail to sort out...)
--
-------
r each
location, track how many distinct relays would be responsible for
that location for one calendar day. The simulation was run for 7/1/15
through 7/7/15. With Aaron's algorithm, the average hash ring
location mapped to 9.96 disti
quot; but not a
>"consensus directory", since it doesn't list any relays.)
>
>
> 4. Putting it all together
>
>[This is the section where, in a later version of this proposal, I
>would specify the exact behavior and data formats to be used here.
>Right now, I'd say we'
could choose a key to
match another issuer's keys) Because you can generate an RSA key with
a targeted most- or least-significant bytes value in roughly the same
amount of work that it takes to
29 matches
Mail list logo
