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