[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #16229 [Stem]: Teach Stem to understand post-prop220 descriptors



#16229: Teach Stem to understand post-prop220 descriptors
-------------------------------------------------+-------------------------
 Reporter:  isis                                 |          Owner:  atagar
     Type:  defect                               |         Status:  new
 Priority:  normal                               |      Milestone:
Component:  Stem                                 |        Version:
 Keywords:  prop220, ed25519, bridgedb-parsers,  |  Actual Points:
  crypto, python                                 |         Points:
Parent ID:                                       |
-------------------------------------------------+-------------------------
 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-descriptor`s 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. [https://pypi.python.org/pypi/ed25519/ 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). ||

   2. [http://ed25519.cr.yp.to/python/ed25519.py djb's pure-Python
 reference version]:

 || '''Caveats'''                 || '''Benefits'''                 ||
 || Slower.                       || More malleable.                ||
 || Rather "academic" codeâ entirely undocumented. Also, ''"Unittests?
 What's a unittest?"'' || It's quite clear what the code is doing, even
 without documentation. ||
 || Completely duck-typed; 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 #15055 #16227

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16229>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs