[tor-dev] is the consensus document unpredictable / unique?

Razvan Dragomirescu razvan.dragomirescu at veri.fi
Mon Jun 27 20:16:47 UTC 2016

Two clarifications/questions:

1. I've just realized that hashing the current valid-* dates into the
descriptor cookie doesn't help - those values are known to the attacker and
he can tweak his vote to generate a certain hash regardless of that date.
The rest of what I've said applies just fine.

2. How would a Directory Authority be able to tweak its vote to generate
multiple valid consensus documents? I'm not familiar with the voting
process (just read about it a bit at
) . Can a rogue DA pretend that it has knowledge of additional relays that
the other DAs don't know about and tweak their fingerprints to try to match
a precomputed hash? Do the DAs simply merge all relay lists with no other
checks? Is there any legitimate situation where a single DA would know
about a given relay? Or am I missing some random data that the DA includes
in its vote that could be used for this?

Thank you,

Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Mon, Jun 27, 2016 at 10:30 PM, Razvan Dragomirescu <
razvan.dragomirescu at veri.fi> wrote:

> Thank you Tim,
> As long as a malicious authority cannot choose a hash that is identical to
> an older consensus hash, I think the system should be fine. In addition, I
> can have the the smartcard look at one of the valid-* dates in the
> consensus and hash that into the descriptor cookie as well - I'm guessing a
> rogue authority can mess with the consensus hash but cannot change the
> valid-after, valid-until, etc dates. If I enforce increasing dates (so that
> you cannot go back in time, once you've seen a consensus for Jan 2017 for
> instance you cannot sign another one from June 2016), if you attempt to
> pre-generate a signature for a future date, you lose connectivity until
> that particular date.
> I also plan to enforce an upper limit on the number of RSA signatures the
> card can perform with a given key. SIM cards already do this to prevent
> brute force attacks.
> If you don't have access to the smartcard and if you've somehow
> pre-generated some signed descriptors, those will only work for 1 hour (a
> very specific hour in the future that you've simulated consensus for and
> somehow tricked an authority into making the consensus hash be exactly the
> one you're expecting).
> What I like about the consensus (vs shared random value) is that it's
> regenerated every hour, so a successful attack would have very limited
> impact (1 hour sometime in the future). Shared random values are generated
> once per day, so if the attacker somehow guesses them successfully, he can
> pretend to be another node for a full day.
> As a second security layer, once the communication is established, the two
> nodes can negotiate a shared symmetrical key (based on the same RSA
> keypairs they use as permanent keys for hidden services or a different
> keypair). This way, a successful attacker can only launch a Denial of
> Service type of attack (preventing the legitimate node from getting the
> traffic) but cannot decrypt or encrypt traffic from/to that node.
> Thanks again,
> Razvan
> On Mon, Jun 27, 2016 at 9:02 AM, Tim Wilson-Brown - teor <
> teor2345 at gmail.com> wrote:
>> Hi Razvan,
>> > On 26 Jun 2016, at 07:52, Razvan Dragomirescu <
>> razvan.dragomirescu at veri.fi> wrote:
>> >
>> > I couldn't find a detailed description of the Tor consensus, so I'm
>> checking that my understanding of it is correct. Basically, would it be
>> correct to assume that the consensus document (or a hash thereof) for a
>> date in the future is an unpredictable value that will also be unique to
>> all nodes inquiring about it at that time?
>> The future values of consensuses can be influenced by each of the 9
>> directory authorities, individually. A malicious authority has ~5 minutes
>> between receiving other authorities' votes and creating its own to
>> calculate a vote that creates a consensus hash that achieves a desired
>> outcome.
>> While it can't control the exact consensus hash, it can choose between
>> many possible hashes, only limited by the available computing time. And it
>> can farm out these computations to other computers.
>> A shared random commit-and-reveal scheme, like the one in proposal 250,
>> gives each authority a single choice: to reveal, or not reveal. This means
>> that a malicious authority can only choose between two different output
>> hashes, rather than choosing between many millions of possible hashes.
>> This is why OnionNS switched from using a hash of the consensus, to the
>> shared random value in the consensus.
>> > On 26 Jun 2016, at 08:18, Tom van der Woerdt <info at tvdw.eu> wrote:
>> >
>> > The consensus has signatures from all directory operators on it, and
>> computing those ahead of time requires a lot of private keys. Because they
>> also all contain the date, they're all unique. So yea, they're both unique
>> and unpredictable.
>> The signed part of the consensus is the (hash of) everything up until the
>> first signature.
>> So while the consensus eventually contains up to 9 signatures, and some
>> legacy signatures, it's not created or initially distributed between
>> authorities that way.
>> There's a few reasons you shouldn't rely on the hash of the signatures:
>> * while the consensus is produced by up to 9 authority signatures, each
>> signature is only produced by 1 authority;
>> * a client only needs 5 of the 9 signatures to use a consensus, so it's
>> not guaranteed to have them all;
>> * signatures are distributed encoded, in PKCS1-padded format that ignores
>> additional whitespace  (and various other extraneous characters), so a
>> malicious authority can control (some bits in) the hash of its own
>> signature;
>> * PKCS1.5-padding allows arbitrary pseudorandom inputs as part of the
>> padding, so a malicious authority can try multiple values for this
>> pseudorandom input until it gets a has that it wants;
>> A malicious authority also has ~5 minutes between receiving other
>> authorities' signatures and creating its own to calculate a signature that
>> creates a consensus + signatures hash that achieves a desired outcome.
>> This doesn't necessarily mean that your scheme will be insecure, but it
>> would need to be constructed very carefully to avoid giving one malicious
>> authority the ability to break it. And you might want to get some
>> cryptographers to review it.
>> (I can imagine an attack where a service creates many keys in advance
>> with random values as the consensus hash, and a malicious authority then
>> tries to vote or sign to match the consensus hash to one of the random
>> values used to create one of the keys.)
>> On the other hand, you could wait until there's a shared random value in
>> the tor consensus, and use it. This may be ready a lot sooner than the
>> entire next-generation hidden service protocol (proposal 224). It could be
>> released in 0.2.9, and it could be running on enough authorities some time
>> in 2017.
>> Tim
>> Tim Wilson-Brown (teor)
>> teor2345 at gmail dot com
>> PGP 968F094B
>> ricochet:ekmygaiu4rzgsk6n
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160627/7442af60/attachment.html>

More information about the tor-dev mailing list