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

Wed Jun 29 10:31:11 UTC 2016

Fair enough, this needs to be reviewed by a cryptographer once the dust
settles. I'm just trying to get a good grasp of what's possible within the
boundaries of the TOR network and how that translates to
cryptographic/security primitives I can use in this particular project
(like using the consensus hash as a future unpredictable value, etc).

As of last night, I have a very basic proof of concept, it needs a bit of
polish and then I'll start showing it off and submitting it to external
analysis.

Thank you!

Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL

On Wed, Jun 29, 2016 at 2:22 AM, Tim Wilson-Brown - teor <teor2345 at gmail.com
> wrote:

>
> > On 28 Jun 2016, at 21:36, Razvan Dragomirescu <
> razvan.dragomirescu at veri.fi> wrote:
> >
> > Thank you Tim,
> >
> > I've been thinking about it and it looks like an easy fix for the
> problem would be to prevent the rogue DA from farming out the hash
> calculations or generating a lot of them in the 5 min voting window. If the
> hash only depends on public info (consensus data, current date, etc), you
> can't prevent this. But if the hash includes a shared secret key _inside
> the smartcard_, the attacker has to ask the smartcard to compute the hash
> and that's orders of magnitude slower than a computer (and can be made
> artificially slower by burning some CPU cycles inside the card doing RSA
> key generations or something - it has no internal clock so you can't just
> "sleep", but you can give it something time-consuming to do before it
> computes the hash).
> >
> > So here's the new setup I have in mind:
> >
> > 1. Each card can be provisioned with a "network key". This is a value
> that all cards (and nodes) that are part of a given network share. It can
> only be set, not read and can be used in the computation of the Descriptor
> Cookie.
> >
> > 2. The descriptor cookie will be calculated as H ( network-key |
> timestamp (rounded down to a full hour) | H (consensus) )
> >
> > The terminal provides the current consensus hash and a timestamp. The
> card checks that the timestamp is greater than the last timestamp it has
> used. It then concatenates the secret network-key, the given timestamp and
> the consensus hash and returns the hash of the result.
> >
> > This means a few things:
> >
> > 1. An attacker can no longer generate a hash independently or farm it
> out to other computers. It has to ask a smartcard to do it. We can make
> this arbitrarily slow since the operation is only meant to be done once an
> hour, so I could make it take a minute per hash inside the card.
> >
> > 2. Generating a hash for a future date would lock you out until that
> date/time (since decreasing timestamps will be refused by the card). You
> could compute the correct hash for the current timestamp and consensus on
> another card, but you would not be able to generate a signed descriptor
> with that correct hash (you can't inject a hash computed somewhere else
> into the signed descriptor).
> >
> > 3. The card doesn't have to parse the consensus - it just uses it as a
> shared random value (the hash of the consensus).
> >
> > Makes sense?
>
> There are now so many moving parts in this scheme, I think you need to
> specify it all in one place, and then convince a cryptographer to review
> it. (I am not a cryptographer.) And then have your implementation reviewed
> against the spec.
>
> How is the card you're using for side-channels?
> Keys have beed extracted using power usage information, or electromagnetic
> emissions, or even audio.
>
> Tim
>
> >
> > Thank you,
> > Razvan
> >
> >
> > On Tue, Jun 28, 2016 at 6:02 AM, Tim Wilson-Brown - teor <
> teor2345 at gmail.com> wrote:
> >
> > > 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
> >
> >
> >
> >
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> >
> >
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
> 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/20160629/f30731ec/attachment-0001.html>