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

[Tim Wilson-Brown - teor]

> On 28 Jun 2016, at 05:30, 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.

> 
> On 28 Jun 2016, at 06:16, Razvan Dragomirescu <razvan.dragomirescu at veri.fi> wrote:
> 
> 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.

You could have your smart card parse a consensus and check the dates are on or after previous signed dates, before signing a descriptor for those dates. But text parsing is error-prone.

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

You might actually want to limit the number of signatures per-hour as well.
But no-one has statistics for the number of hidden service descriptors per service per hour, as far as I know.
It's likely somewhere between 0 and 10.

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

An hour is enough to de-anonymise a lot of clients.

The shared random value lasts for a day, because all clients and hidden services and hidden service directories need to agree on it, and need to cache valid descriptors for a reasonable period of time.

If an attacker is capable of guessing a 256-bit random value… seems exceedingly unlikely.
If an attacker is capable of calculating a 256-bit shared random value, which depends on the private state of the 9 directory authorities, and even that state is only created 24 hours in advance… again, seems unlikely, and it only works 24 hours in advance.

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

An attacker can prevent the node from getting some of the traffic. Typically, the attacker will control the descriptor on each of the 6 hidden service directories until the hidden service uploads a new one. All connections made by clients using attacker-controlled descriptors will go to the attacker's introduction points.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160628/d24d2491/attachment-0001.sig>