Teach Stem to understand post-prop220 descriptors
- The Ed25519 identity key may be optionally kept offline, and it is used to sign the Ed25519 signing key.
- The Ed25519 signing key is used to sign everything the normal RSA-based router
All Ed25519 keys are kept in a very strange certificate (it uses OpenSSL certificate extensions to store the Ed25519 key, among other weirdish things). We'll probably want to reference both §2 of proposal !#220 (moved), and probably the code from #12498 (moved), to ensure that we're parsing it correctly. This certificate will mean it'll a bit of a PITA to parse in Python, but, personally, I rather masochistically enjoy wrangling with PyOpenSSL's brutish, kludgey internals and am more than willing to help with this part.
They also cross-certify the normal RSA-based identity keys. From proposal !#220 (moved):
Note that these keys cross-certify as follows: the ed25519 identity key signs the ed25519 signing key in the certificate. The ed25519 signing key signs itself and the ed25519 identity key and the RSA identity key as part of signing the descriptor. And the RSA identity key also signs all three keys as part of signing the descriptor.
These new keys and their related fields will be appearing in both the
@type [bridge-]server-descriptors and the
@type [bridge-]extrainfo descriptors, for routers running Tor>=0.2.7.x (0.2.7.1??), and so Stem's parsers for both types of descriptor will need to take these things into account.
We'll also need to decide if it is permissible to bring in a Python dependency to Stem. If so, there are two good Python Ed25519 modules (to my current knowledge):
|It has some type/encoding conversions which don't look quite fool-proof.||More Pythonic interface.|
|It also would be somewhat impossible to dig into the internals of it (from Stem's code) should we need to do something weird (we might), since the internals are buried in the underlying C code.||Faster.|
|Very little documentation.||Has tests.|
|No interface for taking advantage of Ed25519 batch signature verification.||Has a notion of string prefixes for signed messages (which would come in particularly handy for Tor's case).|
|Rather "academic" code… entirely undocumented.||It's quite clear what the code is doing, even without documentation. It has tests.|
|(Mostly) duck-typed/unchecked inputs; we'd have to be careful what we pass to its functions.|
|Rather poor exception raising/handling. We'd likely have to to
|No interface for taking advantage of Ed25519 batch signature verification.||Has some functions for low-level point and curve operations.|
Despite the above caveats and benefits, on a cursory reading of both, the latter looks of better use for parsing-only (i.e. not for signing or key creation).