[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