Document vanity onion domain (HS private key) generation
Apparently some people are generating their K_hs_id in a nonstandard way (that is, in a way that is not compliant with the ed25519 spec) in order to more efficiently generate a "vanity" .onion address.
@nickm explained this to me here: arti!980 (comment 2872112)
This should be discussed somewhere in our protocol documentation. Possibly not in rend-spec-v3 itself, but as an informational note somewhere. We should write down whether we think this is a good idea, and any limitations or risks we foresee, and countermeasures that should be taken. (For example, are there additional risks arising from the possibility that private key storage might be corrupted by accident or malice? Should we expect private keys to be stored in some way that has an additional integrity check? Should we define a format for that?)
There are two reasons why IMO this ought to be covered in our spec docs, even if it's not relevant for on-the-wire interop. Firstly, I think specs for cryptographic protocols ought to cover private key generation algorithms, even if they are necessarily invisible as regards interop. This is because private key generation is a frequent source of security bugs. And, having seen that users are doing this, we would ideally support them properly, rather than washing our hands of the situation.
Secondly, this is in fact relevant for interop. Because K_hs_id is a long-term key whose public half is widely distributed, it is necessary to be able to move the private half between implementations. That means that implementations need to be able to support using keys available only in the expanded private key format, because the compressed format cannot represent some keys.