Create an ed25519 shared randomness key for dirauths

added component::core tor/tor parent::16943 priority::high resolution::wontfix severity::normal status::closed type::defect labels

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?

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.

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?

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.

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).

Trac:
Cc: N/A to 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.

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.

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.

I wrote a spec for this (as part of prop250). Please see it here: https://gitweb.torproject.org/user/asn/torspec.git/tree/proposals/250-commit-reveal-consensus.txt?h=prop250-asn-v2#n496

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!

Trac:
Status: new to needs_review

Trac:
Priority: Medium to High

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.

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.
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)

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)

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.

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

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 :)

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.???

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

Trac:
Status: needs_review to closed
Resolution: N/A to wontfix

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Milestone deleted

Trac:
Milestone: Tor: 0.3.??? to N/A

closed

moved to tpo/core/tor#17349 (closed)

Create an ed25519 shared randomness key for dirauths

Child items 0

Activity