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 ESTABLISH_INTRO
:
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 (rend_mid_establish_intro_legacy()
).
Fortunately for us, this code is getting release in 030 but only be actually used in 032 (#12424 (moved)).