prop224: Various improvements and XXX removals.

   As a first pass, I suggest:

      * Instantiate STREAM with AES128-CTR. [TODO: or ChaCha20?]

      * Instantiate STREAM with AES256-CTR.

      * Instantiate SIGN with Ed25519 and the blinding protocol in

        [KEYBLIND].

   For legacy purposes, we specify compatibility with older versions of

   the Tor introduction point and rendezvous point protocols. These used

   RSA1024, DH1024, AES128, and SHA1, as discussed in

   rend-spec.txt. Except as noted, all RSA keys MUST have exponent

   values of 65537.

   [XXX -- is this last sentence new? I think we don't require it now. -RD]

   rend-spec.txt.

   As in [proposal 220], all signatures are generated not over strings

   themselves, but over those strings prefixed with a distinguishing

   of the hidden service descriptor. The encryption key for these is

   derived from the service's credential.

   In order to make an introduction point send a request to the server,

   the client must know the introduction point and know the service's

   per-introduction-point authentication key from the hidden service

   descriptor.

   [XXX what exactly does the intro point check then? Seems like the

    intro point should be able to send a cell down the circuit to the

    service, even if the service doesn't like the cell. -RD]

   In order to make the introduction point send a rendezvous request to the

   service, the client needs to use the per-introduction-point authentication

   key found in the hidden service descriptor.

   The final level of access control happens at the server itself, which

   may decide to respond or not respond to the client's request

   compromised, the adversary can only impersonate it for a limited

   period of time (depending on how many signing keys were generated

   in advance).

   [TODO: Define revocation mechanism?]

   It's important to not send the private part of the blinded signing

   key to the Hidden Service since an attacker can derive from it the

   Then, for each node listed in the current consensus with the HSDirV3 flag,

   we compute a directory index for that node as:

           hsdir_index(node) = H("node-idx" | node_identity_digest |

           hsdir_index(node) = H("node-idx" | node_identity |

                                 shared_random_value |

                                 INT_8(period_num) )

   where shared_random_value is the shared value generated by the authorities

   in section [PUB-SHAREDRANDOM], and node_identity_digest is a SHA1 digest of

   the node's RSA public key as described in tor-spec.txt.

[XXX Maybe include a sentence about why SHA1 isn't scary here? -RD]

   in section [PUB-SHAREDRANDOM], and node_identity is the ed25519 identity key

   of the node.

   Finally, for replicanum in 1...hsdir_n_replicas, the hidden service

   host uploads descriptors to the first hsdir_spread_store nodes whose

   /tor/rendezvous3/<z> where z is a base-64 encoding of the hidden

   service's blinded public key.

   [TODO: raw base64 is not super-nice for URLs, since it can have

   slashes. We already use it for microdescriptor URLs, though. Do we

   care here?]

   These requests must be made anonymously, on circuits not used for

   anything else.

2.3.1. Client behavior in the absense of shared random values

   If the previous or current shared random value cannot be found in a

   consensus, then Tor clients need to generate their own random value for use

   when choosing HSDirs.

   consensus, then Tor clients and services need to generate their own random

   value for use when choosing HSDirs.

   To do so, clients use:

   To do so, Tor clients and services use:

     SRV = HMAC("shared-random-disaster", TIME_PERIOD_NUM)

   as the SRV for time period TIME_PERIOD_NUM.

[Ok, this says clients. What do servers do? The same, right? Or should

 we let services choose to drop off in the disaster case? -RD]

2.3.2. Hidden services and changing shared random values

   It's theoretically possible that the consensus shared random values will

      able to contact the host. Recognized types are: 'password' and

      'ed25519'. See [INTRO-AUTH] below.

     At least once:

[XXX Why not permit descriptors that list 0 intro points? I think

 they're permitted in the legacy rend design. -RD]

     Followed by zero or more introduction points as follows:

        "introduction-point" SP link-specifiers NL

   cell, first documented in rend-spec.txt. New hidden service hosts

   must use this format when establishing introduction points at older

   Tor nodes that do not support the format above in [EST_INTRO].

   [If we roll out intro-point-side support early enough, then service

    hosts can simply avoid making intro points to old relays? -RD]

   In this older protocol, an ESTABLISH_INTRO cell contains:

3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA]

   [TODO: relocate this]

   This is a variant of the ntor handshake (see tor-spec.txt, section

   5.1.4; see proposal 216; and see "Anonymity and one-way

   authentication in key-exchange protocols" by Goldberg, Stebila, and

4.1. Establishing a rendezvous point [EST_REND_POINT]

   The client sends the rendezvous point a

   RELAY_COMMAND_ESTABLISH_RENDEZVOUS cell containing a 20-byte value.

   The client sends the rendezvous point a RELAY_COMMAND_ESTABLISH_RENDEZVOUS

   cell containing a 20-byte value.

            RENDEZVOUS_COOKIE         [20 bytes]

   Rendezvous points MUST ignore any extra bytes in an

   ESTABLISH_RENDEZVOUS message. (Older versions of Tor did not.)

   ESTABLISH_RENDEZVOUS cell. (Older versions of Tor did not.)

   The rendezvous cookie is an arbitrary 20-byte value, chosen randomly

   by the client. The client SHOULD choose a new rendezvous cookie for

   use on an existing circuit, the rendezvous point should reject it and

   destroy the circuit.

   Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point

   associates the cookie with the circuit on which it was sent. It

   replies to the client with an empty RENDEZVOUS_ESTABLISHED cell to

   indicate success.  [TODO: make this extensible]

   Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point associates

   the cookie with the circuit on which it was sent. It replies to the client

   with an empty RENDEZVOUS_ESTABLISHED cell to indicate success. Clients MUST

   ignore any extra bytes in a RENDEZVOUS_ESTABLISHED cell.

   The client MUST NOT use the circuit which sent the cell for any

   purpose other than rendezvous with the given location-hidden service.