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

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
http://jordan-wright.com/blog/2015/05/14/how-tor-works-part-three-the-consensus/
) . 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

--
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>