[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting
> On 29 Oct 2015, at 05:26, David Goulet <dgoulet@xxxxxxxxx> wrote:
>
> Finally, we would like your opinion also on if we should keep the
> conflict mechanism or not?. Since those partition attacks are basically
> dumb, do not achive much result for an attacker and it's at a high cost
> of comprimising a directory authority, should we keep them? Keep in mind
> that it adds a layer of complexity in the code especially with shared
> random keys which rotates every 30 days and are only available in the
> vote of an authority. It gets difficult to validate a conflict of an
> authority if we haven't seen yet a vote from that authority. There are
> ways to fix that code wise but is this worth it considering that every
> partition attack will be detected anyway by DocTor? One argument to keep
> it is resilience of the protocol. With conflict line, if one dirauth
> does stupid things, it will get ignored for the rest of the protocol run
> so we can still compute a fresh random value in the end. Again, does it
> worth it?
The protocol is already resilient because if there is a failure, it still produces a (predictable) value based on the previous value. As long as a misbehaving authority can't mess with this fallback behaviour, and as long as sufficient directory authority operators can react within 24 hours to remove a misbehaving authority, then this seems ok to me.
A few questions:
Do we expect 24 or 48 hours of shared random downtime in the event of an incident, taking into account response time to remove an authority?
What would an authority do when it detects a conflict under the new proposal? Ignore it (pick the numerically higher value?) and expect DocTor to detect it?
What if an authority changes shared random signing keys partway through a round?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev