Hello,
If you hash the consensus entirely, yes that should produce unique
hashes every time that are unpredictable until the consensus is available.
However, you cannot guarantee it will be the same value for everyone at
a given time, because consensus documents overlap and two clients/relays
might work properly but not use exactly the same consensus at a given
time (at 13:45 "Y" uses consensus document valid after 12:00 and "Z"
uses consensus document valid after 13:00. Both are within their
valid-until limits).
I don't recommend that your rely on what you've suggested because of
pour security properties and too complicated design with too many
possible failure cases to be worth it.
Very soon Tor will include an unique random value we call "Consensus
Shared Randomness [SRVALUE]" in every consensus, you can just use that.
This is proposal 250. This seams like a better standardized upstream
solution with infinite better security properties, so I'd use this as a
cookie. This has the advantage of having the same unique value on all
nodes all the time: just filter and pair consensus SRVALUE + consensus
valid-after timestamp and everyone will be requesting the SRVALUE of the
same consensus, therefor producing the same result or fail if none.
Last but not least, how will your system work in practice? The hidden
service private key will be stored on a smartcard and it cannot be
copied, it will only sign descriptors at the request of the host. So far
so good, but the smartcard has to stay plugged in the host all the time,
or at least all the time the hidden service is running, so what's the
security property here?
If you think you can manually plug in the smartcard rarely just to sign
descriptors and keep it somewhere else physically most of the time, this
will not work. In the wild things happen that demand new descriptors to
be signed in an unpredictable way: introduction points go offline;
HSDirs go offline, too many INTRODUCE2 cells received on a single
introduction point circuit.
And if the private key is on a smartcard, and the smartcard is plugged
in the host all the time, what's the gain? I am not saying there isn't
any, I just don't see it at this moment. One I can think of is that
malware and/or someone hacking can't copy the private key and hijack the
hidden service, but the risk remains in case someone physically sizes
the server ("host").
Do note that next generation of hidden services will support natively
offline keys and actually allow the hidden service to run properly: the
offline keys will generate blinded signing keys, which are used to sign
descriptor signing keys.
On 6/26/2016 12:52 AM, Razvan Dragomirescu wrote:
> Hello everyone,
>
> 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?
>
> I'm thinking of using a hash of the consensus document -
> like http://171.25.193.9:443/tor/status-vote/current/consensus - as a
> descriptor cookie in a hidden service. This way, an attacker cannot
> generate or publish a hidden service descriptor for the future (one with
> a correct cookie). A client can fetch the consensus at the time it wants
> to connect, hash it, then use that as the descriptor cookie to determine
> the correct descriptor id and decrypt the introduction point list.
>
> Does anyone see any issues with this? In my project, the hidden service
> private key is on a smartcard, so it can't be copied, you can only ask
> the smartcard to sign something with it for you - and I'm trying to
> prevent an attacker from generating hidden service descriptors in
> advance,to be used without the smartcard. If future descriptors depend
> on an unpredictable future value (the hash of the consensus at that
> time), an attacker can only generate descriptors for past and current
> time periods.
>
> Thank you,
> Razvan
>
> --
> Razvan Dragomirescu
> Chief Technology Officer
> Cayenne Graphics SRL
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev