<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Hi Razvan,</div><div><br></div><div>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. </div><div><br></div><div>As for your idea: it should be noted that there is not a single valid consensus. At any time there may be several valid ones and clients may have different active ones, as all consensuses are valid for a few hours but generated hourly. Using the hash as a descriptor cookie may thus be troublesome. </div><div><br></div><div>Tom</div><div><br></div><div><br></div><div><br></div><div><br>On 25 Jun 2016, at 23:52, Razvan Dragomirescu <<a href="mailto:razvan.dragomirescu@veri.fi">razvan.dragomirescu@veri.fi</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hello everyone,<div><br></div><div>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?</div><div><br></div><div>I'm thinking of using a hash of the consensus document - like <a href="http://171.25.193.9:443/tor/status-vote/current/consensus">http://171.25.193.9:443/tor/status-vote/current/consensus</a> - 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.</div><div><br></div><div>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.</div><div><br></div><div>Thank you,</div><div>Razvan</div><div><br></div><div>--</div><div>Razvan Dragomirescu</div><div>Chief Technology Officer</div><div>Cayenne Graphics SRL</div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>tor-dev mailing list</span><br><span><a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a></span><br><span><a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a></span><br></div></blockquote></body></html>