prop224: Change descriptor format for legacy encryption key
It turns out that we might have miscalculated the legacy feature for introduction point.
Currently, proposal 224 looks like this for legacy encryption keys:
Encryption key is specified as follow: [Exactly once enc-key per introduction point] "enc-key" SP "ntor" SP key NL The key is a base64 encoded curve25519 public key used to encrypt the introduction request to service. "enc-key" SP "legacy" NL key NL Base64 encoded RSA key, wrapped in "----BEGIN RSA PUBLIC KEY-----" armor, for use with a legacy introduction point as described in [LEGACY_EST_INTRO] and [LEGACY-INTRODUCE1] below.
This doesn't make much sense because this encryption key is used to encrypt the
ENCRYPTED section of the INTRODUCE1 cell (section 3.2.1. and 3.2.2.). That section can only be decrypted by the service so the introduction point, being legacy or not, doesn't touch it at all, it just passes along the bytes.
So, the descriptor should always contain a ntor key per intro point because we still want the ntor handshake to happen since both client and service do speak the prop224 protocol.
If the intro point is a legacy one, it should also have a "legacy key" which is an extra RSA public key needed in the INTRODUCE1 legacy cell and used by the intro point to relay the cell on the right circuit (used in the ESTABLISH_INTRO):
LEGACY_KEY_ID [20 bytes] [...] Here, LEGACY_KEY_ID is the hash of the introduction point legacy encryption key that was included in the hidden service descriptor.
In the legacy
PK Bob's public key or service key [KL octets]
In the current legacy code, the intro point validates that this PK field is an ASN.1 encoded RSA key (
Fortunately for us, this code is getting release in 030 but only be actually used in 032 (#12424 (moved)).