Opened 4 years ago

Closed 3 years ago

#16229 closed enhancement (user disappeared)

Teach Stem to understand post-prop220 descriptors

Reported by: isis Owned by: atagar
Priority: High Milestone:
Component: Core Tor/Stem Version:
Severity: Normal Keywords: prop220, ed25519, bridgedb-parsers, crypto, python
Cc: atagar, isis, nickm, karsten, meejah, asn, dgoulet Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by isis)

For proposal #220 (#12498), Ed25519-SHA-512 router identity and signing keys were added for relays (and soon for bridges?).

  • 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 signing-key would sign.

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, and probably the code from #12498, 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:

   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):

  1. Brian Warner's Python extension which wraps the SUPERCOP Ed25519 reference code:
Caveats Benefits
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).
  1. djb's pure-Python reference version:
Caveats Benefits
Slower. More malleable.
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 except Exception as error and then parse the message to figure out where something went wrong.
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).

Related Tickets: #12498 #15054 #16227

Child Tickets

Change History (4)

comment:1 Changed 4 years ago by isis

Description: modified (diff)

comment:2 Changed 4 years ago by isis

Description: modified (diff)

comment:3 Changed 4 years ago by atagar

Priority: normalmajor
Type: defectenhancement

Hi Isis, sorry this has gone so long without a reply! Tor recently added its ed25519 additions to the spec, after which I added support to Stem.

Would the benefit of these dependencies be to validate descriptors via their ed25519 credentials? If so then a patch using either library would be most welcome! We presently use pycrypto *if* it's available to validate signatures, and doing something similar with ed25519 would be great.

comment:4 Changed 3 years ago by atagar

Resolution: user disappeared
Severity: Normal
Status: newclosed

Hi isis, tis been a couple months. Feel free to reopen if you'd like to discuss this.

Note: See TracTickets for help on using tickets.