Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#17349 closed defect (wontfix)

Create an ed25519 shared randomness key for dirauths

Reported by: asn Owned by:
Priority: High Milestone:
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: s7r Actual Points:
Parent ID: #16943 Points:
Reviewer: Sponsor:

Description

In proposal250, dirauths sign their commitments. We assume an ed25519 key is going to be used for signatures, both for signature length and for security. Unfortunately, there is currently no ed25519 key that authorities use.

I talked to Nick about this and he suggested that a new key will need to be created especially for this reason. IIUC this new SR key will need to be chain-certified down to the RSA signing key, since we still use RSA keys as the long-term identity of dirauths.

A few questions here:

a) What's the key hierarchy we are aiming for here?

Is it:

RSA signing key -> ed25519 identity key -> ed25519 signing key -> ed25519 SR key

or

RSA signing key -> ed25519 signing key -> ed25519 SR key

or

RSA signing key -> ed25519 SR key

We discussed this in IRC the other day, but my box crashed and I lost backlog :(
Could you please remind me what's the best option here?

b) Where should these new long-term ed25519 keys be listed? Should they be part of the dir-key-certificate-version block in the votes?

c) How should they be generated? It should be part of tor-gencert right? Sebastian pointed out that dirauths firing up tor-gencert in their offline machines is not an easy task and costs them lots of money and time. So we should make sure that this procedure works for them well.

What is the procedure for generating new keys with tor-gencert? I would like to understand this, since Sebastian suggested we should prepare the tor-gencert patch well in advance, and send an email to dirauth operators so that they have time to run it and be all set by the time the shared randomness patch hits Tor.

If we do so, then in the shared randomness code we can assume that the keys are already generated. If they are not, we should complain to the dirauth operator and ask them to run the tor-gencert command. However, it should also be possible for a dirauth operator that doesn't have the right ed25519 keys to work as a dirauth but not participate in the SR protocol.

d) This seems like lots of work! Is there a less demanding way out? For example, would it be super stupid to just sign the ed25519 SR key with the long-term RSA signing key?

Child Tickets

Change History (18)

comment:1 Changed 4 years ago by asn

Also, it's worth mentioning that dirauths are relays by default, and hence they have ed25519 keys as relays. Those keys should also be included in their votes, so other dirauths should be able to get them.

Could we use those keys for prop250? And would we use those keys as they are, or would we need to generate a subkey for SR purposes?

How could this be done?

comment:2 Changed 4 years ago by nickm

a) This one.

RSA authority signing key ==> ed25519 master identity key -> ed25519 signing key ==> ed25519 SR key

The only missing parts here are the ones I've done as "==>". The first means that authorities should affirm their ed25519 identities.

b) They could go in the certificate, but I'm not 100% sure they have to. Certificates do not currently include the RSA OR identity key. I think that putting them in the voter-info block would make more sense. The one that goes

dir-source dannenberg 585769C78764D58426B8B52B6651A5A71137189A dannenberg.torauth.de 193.23.244.244 80 443
contact Andreas Lehner <ops@torauth.de>
vote-digest FB581F58EFCA26CD61323CE2E2082542960AA405

Votes are signed by the RSA authority signing key, so this would authenticate the ed25519 master identity key using that.

c) not necessarily; only if they go into the dir-key-certificate thing.

d) This really isn't a lot of work. The rest of the chain is already there. It's just adding another signed key.

e)

Also, it's worth mentioning that dirauths are relays by default, and hence they have ed25519 keys as relays. Those keys should also be included in their votes, so other dirauths should be able to get them.
Could we use those keys for prop250? And would we use those keys as they are, or would we need to generate a subkey for SR purposes?

Yes, these are the keys I'm talking about. The master ed25519 identity key as a relay can already be kept offline and has similar security properties to the master RSA authority key. I'm saying that the master ed25519 identity key, as used by relays, should be certified by the RSA certificate chain.

We _do_ want to make a new key for this case, though. We are trying hard to avoid multipurpose signing keys.

Last edited 4 years ago by dgoulet (previous) (diff)

comment:3 in reply to:  2 Changed 4 years ago by asn

Replying to nickm:

a) This one.

RSA authority signing key ==> ed25519 master identity key -> ed25519 signing key ==> ed25519 SR key

The only missing parts here are the ones I've done as "==>". The first means that authorities should affirm their ed25519 identities.

b) They could go in the certificate, but I'm not 100% sure they have to. Certificates do not currently include the RSA OR identity key. I think that putting them in the voter-info block would make more sense. The one that goes

dir-source dannenberg 585769C78764D58426B8B52B6651A5A71137189A dannenberg.torauth.de 193.23.244.244 80 443
contact Andreas Lehner <ops@torauth.de>
vote-digest FB581F58EFCA26CD61323CE2E2082542960AA405

Votes are signed by the RSA authority signing key, so this would authenticate the ed25519 master identity key using that.

Thanks for the help. I think I understand a bit better now.
Please allow me to demonstrate my understanding, by showing you the extra lines that have to be added in the voter-info block to complete this:

master-key-ed25519 G8F9MHeldbWqj6F9jMozR4dd8Wof7u3tVWUwxMO3t8R
-----BEGIN ED25519 CERT----- (ed25519 master key -> ed25519 signing key)...
-----BEGIN ED25519 CERT----- (ed25519 signing key -> ed25519 shard random key)...

The first line introduces the master ed25519 to the voting document (currently it's only in the relay descriptor of the dirauth). Since it's in the vote, it's signed by the RSA signing key, and hence we complete the RSA authority signing key -> ed25519 master identity key part of the chain.

The second line completes the ed25519 master identity key -> ed25519 signing key part of the chain. Also these ed25519 certificates (as defined in prop220) seem to include the to-be-certified key, so in this case we don't need an extra line to introduce the ed25519 signing key explicitly.

The final line finishes the chain by doing ed25519 signing key -> ed25519 shared random key.

How does that sound?


I wonder what other things I need to think about. Like what should the lifetime of the SR key be. But maybe I can set it to the same lifetime as the signing key? Or maybe a bit shorter?

comment:4 Changed 4 years ago by asn

Also, should these key and certs also be in the consensus? I think I don't see a reason for prop250 specifically, but it seems like the whole current voter-info block gets included in the consensus.

Last edited 4 years ago by asn (previous) (diff)

comment:5 Changed 4 years ago by s7r

Cc: s7r added

To keep symmetry the lifetime of the SR key will be equal to the lifetime of medium term signing key. This means 30 days by default, unless otherwise configured by SigningKeyLifetime in torrc.

In order not to confuse directory authority operators with a lot of keys and subkeys, I recommend the SR ed25519 key to be only generated automatically by Tor if/when started as a directory authority and only be chained to the medium term signing key with exactly the same validity period. The SR key shouldn't be linked directly with the ed25519 master id key which can be kept offline, instead it'll be chained via an intermediary certificate. It would be nice if we could append this second intermediate certificate to already existent file 'ed25519_signing_cert' so we have a single certificate file in our keys folder.

Manually calling '--keygen' shouldn't generate a SR key, this way we keep it simpler and don't have to add more commands for directory authorities and at the same time eliminate the possibility to accidentally generate useless SR keys on normal non directory authorities relays.

The ed25519 master identity keys of directory authorities could be included in the consensus - this could come handy when/if we want to get rid of RSA ultimately (we plan to remove RSA1024 but directory authorities master identity RSA keys are > 1024 so they'll stick around for more time).

Last edited 4 years ago by s7r (previous) (diff)

comment:6 Changed 4 years ago by s7r

asn: dgoulet: the code should know how to handle situations where the SR key changes during protocol run, even during the run of only one phase of the protocol (commit phase or reveal phase).

Accept any SR key and even multiple different SR keys in the same phase for the same directory authority if it is properly linked to the ed25519 master identity key (which we could include in the consensus).

Since an expiration date exists, we have a 100% probability that the medium term signing key (and implicitly SR key) will expire during a protocol run (either commit phase, either reveal phase - doesn't matter). Directory authorities should be able to replace medium term signing key and HUP/reload/restart Tor at anytime without affecting anything.

comment:7 Changed 4 years ago by s7r

Also, having the exact same expiration date with the medium term signing key - one single expiration date for everything ed25519 key related means little less code (which is good). Nick already coded Tor to warn in advance about this date, want to generate fresh keys, need to generate fresh keys and recover from a lot of failure cases. We don't have to reinvent the wheel for the SR key and add more lines of code for no reward.

Last edited 4 years ago by s7r (previous) (diff)

comment:8 Changed 4 years ago by asn

OK, an initial version of this feature can be found at my branch prop250-ed25519-day1.

The patch is quite messy, but it generates SR keys and adds the cert chain in the votes. Then it's also able to parse the keys from votes.

David, to use this:

  • Use get_shared_random_keypair() to get the shared randomness keypair to sign the commitments.
  • Then, after vote parsing, use networkstatus_t.ed25519_shared_random_cert.signed_key to get the shared random key of other authorities and verify their commitment signatures.

I will be working on this the following days to make it nicer and more robust. I also need to write up the proposal, but I first wanted to make sure that what I'm doing makes sense.

comment:10 Changed 4 years ago by asn

Status: newneeds_review

Hello,

I have a ready to review branch at prop250-ed25519-day2 in my repo.

The patch makes auths generate the ed25519 shared randomness key and include it in their votes. The other dirauths will parse it and save it for use in the prop250 protocol.

Some comments I would appreciate from the reviewer since I'm quite the newbie with this part of Tor:

  • load_ed_keys() was quite complicated and I'm not familiar with all the functionality in there. It would be great if someone else could double check the logic to make sure I didn't fuck up anything.

I'm mainly wondering if use_signing is the right variable to use there.

I'm also wondering if my need_new_sr_key logic is good, or it needs to be more advanced like need_new_signing_key and want_new_signing_key.

  • Currently, the lifetime of the SR cert is 30 days like the signing key cert. Is this OK?

Should we check for a minimum lifetime of SharedRandomKeyLifetime like we do in SigningKeyLifetime? Should I introduce something like TestingSigningKeySlop? I couldn't quite understand how that worked.

And here are some guidelines for using this branch:

  • Use get_shared_random_keypair() to get the shared randomness keypair to sign the commitments.
  • Then, after vote parsing, use networkstatus_t.ed25519_shared_random_cert.signed_key to get the shared random key of other authorities and verify their commitment signatures.
  • Use networkstatus_t.ed25519_signing_key_cert.signing_key to get the e25519 master key of other authorities.

Thanks!

comment:11 Changed 4 years ago by nickm

Priority: MediumHigh

comment:12 Changed 4 years ago by s7r

Maybe this is helpful. From the little C I could make sense of, I think that the code in prop250-ed25519-day2 branch currently keeps a separate SharedRandomKeyLifetime. Maybe this logic will make sense and simplify a little bit. Here goes:

Everything additional should happen after load_ed_keys() does the existent checks to keep a logic.

  1. On fresh start or HUP signal, after doing all the existent checks for ed25519 identity keys, only if we are an authority: also check if ed25519_shared_random_secret_key and ed25519_shared_random_cert files exist in $datadirectory/keys.
  1. If these files are missing (or just one of them is missing, doesn't matter):
  • generate a new ed25519_shared_random_secret_key and an ed25519_shared_random_cert chained to ed25519_signing_secret_key. When generating the ed25519_shared_random_cert, also check the expiration timestamp of ed25519_signing_cert and copy/paste it. Since Tor will first do the checks for ed25519_signing_secret_key and ed25519_signing_cert, and only after this, in order, the checks for ed25519_shared_random*, this step cannot go wrong. (this way we avoid the need for a SharedRandomKeyLifetime and we rely on the checks and thresholds implemented for SigningKeyLifetime)
  1. If ed25519_shared_random_secret_key and ed25519_shared_random_cert both exist in $datadirectory/keys:
  • first, check if expiration timestamp of ed25519_shared_random_cert == expiration timestamp of ed25519_signing_cert. If not, it means the ed25519_signing_secret_key has changed, so delete ed25519_shared_random_secret_key and ed25519_shared_random_cert entirely and fail back to step 2. Only if is the same or is not the same logic should matter here, since we can generate a medium term signing key valid for 100 days and reconsider after 2 days and issue a new one valid for 60 days, so the expiration timestamp of ed25519_signing_cert will go back from let's say 30.04.2016 to 20.03.2016. If ed25519_shared_random_cert is expired, implicitly ed25519_signing_cert is expired so Tor will either not start at all either generate valid medium term signing key. This makes it impossible to reach this step with an expired ed25519_signing_cert (it is checked before this step, at the checks for ed25519 identity keys).
  • second, if the expiration timestamps in both certificates match, check if ed25519_shared_random_cert is valid and properly chains ed25519_shared_random_secret_key to ed25519_signing_secret_key. If they somehow do not match, delete ed25519_shared_random_secret_key and ed25519_shared_random_cert entirely and fail back to step 2.(this way we rely on the already existent need_new_signing_key and want_new_signing_key)
  1. Proceed if all these went well as normally. Unlike ed25519_signing_secret_key - when the ed25519_master_id_secret_key is kept offline or encrypted, there is no excuse for not being able to automatically generate an ed25519_shared_random_secret_key and ed25519_shared_random_cert if we follow all the steps in the logic order, so the above checks should be sufficient.

asn:
I am sorry if I am missing something obvious, but why do the other authorities need to get the shared random key of other authorities? Can't the other directory authorities, when receiving a vote, tell just from the signature included with each commit or reveal if it belongs to a key (shared randomness key) that at a certain timestamp (commitment or reveal timestamp) was valid (properly chained) to the ed25519_master_id_public_key (ed25519 identity) of the directory authority that broadcasted it? So any other authority will validate itself a conflict (0 trust in other players) just by checking the signatures and comparing the commit / reveal values. If more data is required, better make signatures slightly bigger and include within each signature what else is needed to verify each signature at any time by anyone.

If the other authorities can verify this just from the signatures, there is no security benefit for getting the shared randomness keys from other authorities, given there is a 100% chance that they will change during protocol run at some moment anyway.

Last edited 4 years ago by s7r (previous) (diff)

comment:13 Changed 4 years ago by nickm

(Should I still be looking at this, or wait for the final prop250 design to land?)

comment:14 in reply to:  13 Changed 4 years ago by asn

Replying to nickm:

(Should I still be looking at this, or wait for the final prop250 design to land?)

Hello. No need to look at this. We have simplified the prop250 design for KISSness, and we have removed the need for SR keys.

I'd suggest you just wait for final prop250 design/code to land :)

comment:15 Changed 4 years ago by asn

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

comment:16 Changed 4 years ago by dgoulet

Resolution: wontfix
Status: needs_reviewclosed

The need for an ed25519 key has been removed from the proposal 250 and also in the code located in #16943. Closing it.

comment:17 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:18 Changed 3 years ago by nickm

Milestone: Tor: 0.3.???

Milestone deleted

Note: See TracTickets for help on using tickets.