Allow ed25519 keys to be banned in the approved-routers file

Once we start pinning ed25519 keys, we should probably also allow directory authorities to ban them in approved-routers. This will allow us to migrate away from RSA keys at some point.

(Where else do we use RSA fingerprints?)

changed milestone to %Tor: 0.4.3.x-final

added 034-removed-20180328 034-triage-20180328 component::core tor/tor milestone::Tor: 0.4.3.x-final owner::neel points::1 priority::medium resolution::implemented reviewer::nickm severity::normal status::closed type::enhancement labels

Oh fine idea!

Quick question here. Can a relay have N rsa keys (for N > 1) for 1 ed25519 key and still keep it's uptime/weight?

I'm asking here because we currently block by RSA fingerprint but what if I can rotate that everyday (or when blocked) but still keep my consensus weight because my ed25519 is still recognized by dirauths?

Replying to dgoulet:

Oh fine idea!

Quick question here. Can a relay have N rsa keys (for N > 1) for 1 ed25519 key and still keep it's uptime/weight?

Yes, but not for long.

The directory authorities keep a key pinning journal, but don't enforce it.

When we turn on key pinning, authorities won't vote for relays that change one key and keep the other the same.

I'm asking here because we currently block by RSA fingerprint but what if I can rotate that everyday (or when blocked) but still keep my consensus weight because my ed25519 is still recognized by dirauths?

The bandwidth script uses RSA fingerprints, so changing your RSA removes all your bandwidth.

In the far future, when we remove RSA keys, we will want to have a file that bans both RSA and ed25519 keys, to make the transition easier.

Trac:
Milestone: Tor: 0.3.2.x-final to Tor: 0.3.3.x-final

Deferring various "new"-status enhancement tickets to 0.3.4

Trac:
Milestone: Tor: 0.3.3.x-final to Tor: 0.3.4.x-final

Trac:
Keywords: N/A deleted, 034-triage-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

Trac:
Keywords: N/A deleted, 034-removed-20180328 added

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: unspecified

Trac:
Owner: N/A to neel
Status: new to assigned

Trac:
Cc: N/A to neel

The function dirserv_load_fingerprint_file() reads the file approved-routers. I have a few questions:

1. Should the ed25519 key in the approved-routers file be a base16-encoded key (similar to what we do right now with RSA fingerprints)?
2. Would it be okay that if a ed25519 key was given, I check keypin hashtable to get the relay's corresponding RSA key and then add it to the list? I propose will be done with a new function that searches the ed25519 keypin hash table for each entry until a matching ed25519 key is given, and then return a corresponding RSA key.

I am concerned with Point 2 however because of the O(n^2^) running time from needing to go through the list of all Tor relays. Another concern is that mapping ed25519 to RSA could mean we prolong the life of the RSA code.

Would it be better to overhaul the relay data structures to be ed25519-first and then do this?

Replying to neel:

The function dirserv_load_fingerprint_file() reads the file approved-routers. I have a few questions:

1. Should the ed25519 key in the approved-routers file be a base16-encoded key (similar to what we do right now with RSA fingerprints)?

I think it should base64-encoded; that's how ed25519 keys are printed everywhere else in Tor.

2. Would it be okay that if a ed25519 key was given, I check keypin hashtable to get the relay's corresponding RSA key and then add it to the list? I propose will be done with a new function that searches the ed25519 keypin hash table for each entry until a matching ed25519 key is given, and then return a corresponding RSA key.

I think it should just store the ed25519 keys, and look up by the ed25519 key.

I am concerned with Point 2 however because of the O(n^2^) running time from needing to go through the list of all Tor relays. Another concern is that mapping ed25519 to RSA could mean we prolong the life of the RSA code.

Would it be better to overhaul the relay data structures to be ed25519-first and then do this?

I think that might be a good idea, but instead of being ed25519-only, we should make it handle both ed25519 and RSA keys.

Thank you for your responses, nickm!

I do have a few more questions, however:

I think it should just store the ed25519 keys, and look up by the ed25519 key.

Does that mean something like authdir_config_t should be done for ed25519 (even if the digests are stored as a union), and then introduce a function like dirserv_get_status_impl() that takes in ed25519 keys. And then I should make dirserv_router_get_status() look at ed25519 keys as well?

I would suggest adding a third element to authdir_config_t, a digest256map_t, mapping ed25519 identities to router_status_t elements. Would that work?

I would suggest adding a third element to authdir_config_t, a digest256map_t, mapping ed25519 identities to router_status_t elements. Would that work?

Yes. I thought about doing the same thing as well (even before you responded).

My patch is ready and the PR is here: https://github.com/torproject/tor/pull/682

Trac:
Status: assigned to needs_review

Trac:
Milestone: Tor: unspecified to Tor: 0.4.1.x-final

Trac:
Reviewer: N/A to teor