Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:59:14Zhttps://gitlab.torproject.org/legacy/trac/-/issues/19560running tor trying to access its ed25519_signing_secret_key, log message too ...2020-06-13T14:59:14Zweasel (Peter Palfrader)running tor trying to access its ed25519_signing_secret_key, log message too loudI keep my key files away from the running tor instance.
For some reason, tor seems to want to re-open them regularly:
```
Jul 04 08:17:09.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied
```
I...I keep my key files away from the running tor instance.
For some reason, tor seems to want to re-open them regularly:
```
Jul 04 08:17:09.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied
```
It probably shouldn't want that.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19303Revise {extend,create}_cell_format to use trunnel2020-06-13T14:58:22ZNick MathewsonRevise {extend,create}_cell_format to use trunnelAs part of the prop220 extend cell work, we'll be making these functions bigger. It's time to be safe and make them use trunnel.As part of the prop220 extend cell work, we'll be making these functions bigger. It's time to be safe and make them use trunnel.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19302Send ed25519 IDs in EXTEND2 cells2020-06-13T14:58:21ZNick MathewsonSend ed25519 IDs in EXTEND2 cellsOnce we have #19301 complete, we can update clients to generate circuits using ed25519 identities.
We'll have to actually store the ed25519 identity in the extend_cell_t when we make in .
We'll have to encode it as part of extend_cell...Once we have #19301 complete, we can update clients to generate circuits using ed25519 identities.
We'll have to actually store the ed25519 identity in the extend_cell_t when we make in .
We'll have to encode it as part of extend_cell_format.
We'll have to decide whether to use it: it's only okay to send the ed25519 ID when both servers support the new link handshake.
We can enable this with a tristate, for testing, and to make sure that this turns on for a big pile of clients at once.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19301Accept Ed25519 identities in EXTEND2 cells2020-06-13T14:58:20ZNick MathewsonAccept Ed25519 identities in EXTEND2 cellsOnce we have the link-connection part of prop220 implemented, we can start here, and allow relays to start accepting Ed25519 identities in their extend2 cells.
We'll have to update extend_cell_parse to handle these, and extend_cell_t to...Once we have the link-connection part of prop220 implemented, we can start here, and allow relays to start accepting Ed25519 identities in their extend2 cells.
We'll have to update extend_cell_parse to handle these, and extend_cell_t to contain them.
We'll have to update channel_get_for_extend to look up by the complete set of link specifiers.
We'll have to update channel_connect_for_circuit to accept an ed25519 ID, if it hasn't already.
And we'll have to update circuit_extend to handle all that properly.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19157[prop220] Check all new certificate types (incl cross-cert and ed25519)2020-06-13T14:57:48ZNick Mathewson[prop220] Check all new certificate types (incl cross-cert and ed25519)If we're using ed25519 authentication, we should understand and check all the relevant certificate types when they're presented in the CERTS cell.
Partially implemented in my work-in-progress #15055 branch.If we're using ed25519 authentication, we should understand and check all the relevant certificate types when they're presented in the CERTS cell.
Partially implemented in my work-in-progress #15055 branch.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19156[prop220] send AUTHENTICATE cells with correct ed25519 signatures2020-06-13T14:57:48ZNick Mathewson[prop220] send AUTHENTICATE cells with correct ed25519 signaturesWhen we're using AuthType2, we send a new AUTH0002 cell, with a slightly different format from the one we use today. It's documented in section 4.2 of prop220.
It's mostly implemented in my work-in-progress Ed25519 branch.When we're using AuthType2, we send a new AUTH0002 cell, with a slightly different format from the one we use today. It's documented in section 4.2 of prop220.
It's mostly implemented in my work-in-progress Ed25519 branch.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19155[prop220] send CERTS cells correctly for Ed255192020-06-13T14:57:47ZNick Mathewson[prop220] send CERTS cells correctly for Ed25519Part of implementing proposal 220 is to make sure that severs receiving connections send all the new certificate types, including:
* identity->signing cert (type 4)
* signing->TLS-RSA (6) (respondor only)
* signing->link (5) cert (...Part of implementing proposal 220 is to make sure that severs receiving connections send all the new certificate types, including:
* identity->signing cert (type 4)
* signing->TLS-RSA (6) (respondor only)
* signing->link (5) cert (initiator only)
* RSA identity cross-cert (7)
This code is mostly implemented in my WIP #15055 branch.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16229Teach Stem to understand post-prop220 descriptors2015-11-29T21:22:05ZIsis LovecruftTeach Stem to understand post-prop220 descriptorsFor 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.
...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. [Brian Warner's Python extension which wraps the SUPERCOP Ed25519 reference code](https://pypi.python.org/pypi/ed25519/):
| **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. [djb's pure-Python reference version](http://ed25519.cr.yp.to/python/ed25519.py):
| **Caveats** | **Benefits** |
|-----------------------------|------------------------------|
| Slower. | More malleable. |
| Rather "academic" code… entirely undocumented. | It's quite clear what the code is doing, even without documentation. It [has](http://ed25519.cr.yp.to/python/sign.input) [tests](http://ed25519.cr.yp.to/python/sign.py). |
| ([Mostly](http://ed25519.cr.yp.to/python/checkparams.py)) 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 #16227Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15061Support Ed25519 identities in controller interface2020-06-13T14:43:51ZNick MathewsonSupport Ed25519 identities in controller interfaceOnce #12498 is merged, we'll be able to identify nodes by ed25519 keys. We should allow the controller to do this too.
This might be a use case for USEFEATURE -- `USEFEATURE ed25519-ids` could allow us to describe nodes by their best k...Once #12498 is merged, we'll be able to identify nodes by ed25519 keys. We should allow the controller to do this too.
This might be a use case for USEFEATURE -- `USEFEATURE ed25519-ids` could allow us to describe nodes by their best keys, and we could accept ed25519 keys regardless.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15059Allow UI to identify servers by Ed25519 keys2020-06-13T14:43:49ZNick MathewsonAllow UI to identify servers by Ed25519 keysEverything that currently allows users to identify servers by fingerprint, such as various torrc options and the .exit syntax, should allow Ed25519 keys as well.Everything that currently allows users to identify servers by fingerprint, such as various torrc options and the .exit syntax, should allow Ed25519 keys as well.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12980Implement ed25519 primitives for proposals 220, 224, 2282020-06-13T14:38:09ZNick MathewsonImplement ed25519 primitives for proposals 220, 224, 228For proposal 220, we need ed25519 with detached signatures. (#12498)
For proposal 224 (#12424), we need ed25519 with key blinding (#8106).
For proposal 228, we need the ability to convert curve25519 keys to ed25519 keys. (#12499)For proposal 220, we need ed25519 with detached signatures. (#12498)
For proposal 224 (#12424), we need ed25519 with key blinding (#8106).
For proposal 228, we need the ability to convert curve25519 keys to ed25519 keys. (#12499)Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5563Better support for ephemeral relay identity keys2020-06-13T18:11:25ZMike PerryBetter support for ephemeral relay identity keysTagging-based amplification attacks are primarily an issue of node integrity. For the most part, they are impossible to perform if you are external to the tor network, and they are detectable if the adversary's proportion of compromised ...Tagging-based amplification attacks are primarily an issue of node integrity. For the most part, they are impossible to perform if you are external to the tor network, and they are detectable if the adversary's proportion of compromised nodes on the network is low, due to excessive circuit failure at non-colluding nodes.
However, this all changes if most nodes have easily accessible identity keys. All the adversary need do is make a quick stop at each high capacity tor relay, freeze the ram/reboot the box, and extract the keys. From that point on, the adversary is free to intercept and tag traffic transparently upstream. Worse, as the adversary performs this procedure at more and more nodes, their circuit failure rate will fall. At least according to the math of some dude who claims to be a raccoon: https://lists.torproject.org/pipermail/tor-dev/2012-March/003361.html
I believe the best stopgap solution to this (at least until whatever comes out of #5460 is deployed) is to encourage relay operators to keep their relay keys on a ramdisk, so they are discarded in the event of reboot. This would at least require the adversary to retain persistent access to the machine, which risks discovery via auditing mechanisms.
Unfortunately, there are a few issues with how Tor treats relay identity keys that makes it extremely inconvenient for relay operators if they ever change.
This ticket is to serve as the parent ticket for enumerating these inconveniences.Tor: unspecified