Opened 21 months ago

Closed 21 months ago

Last modified 20 months ago

#10324 closed enhancement (implemented)

Sign status documents with RSA2048

Reported by: ln5 Owned by:
Priority: normal Milestone: Tor: 0.2.5.x-final
Component: Tor Version:
Keywords: Cc:
Actual Points: Parent ID:
Points:

Description

Directory authorities sign status documents (votes and consensuses) with a 1024 bit RSA key called a directory signing key. These keys are typically valid for one year. Being in possession of a majority of the signing keys means that you control the consensus. We should start signing with RSA2048 instead.

I've been testing signing votes and consensuses in a Chutney network. All but 0.2.0.x clients seem happy to bootstrap using a consensus signed with a 2048 bit key. Directory authorities running 0.2.4.18-rc and 0.2.5.1-alpha are happily voting and signing together.

I'm going to create a new signing key for maatuska and see if the Tor network is happy too. If that turns out OK, I'm going to suggest that tor-gencert.c is changed to create 2048 bit keys and then ask other authority operators to generate new keys using that version.

Child Tickets

Change History (18)

comment:1 Changed 21 months ago by ln5

020c/notice.log:Dec 09 21:41:41.250 [notice] Tor 0.2.0.35 opening log file.
021c/notice.log:Dec 09 21:41:41.268 [notice] Tor 0.2.1.32 (git-887bddb7e7323334) opening log file.
021c/notice.log:Dec 09 21:41:42.782 [notice] Bootstrapped 100%: Done.
022c/notice.log:Dec 09 21:41:41.279 [notice] Tor 0.2.2.39 (git-bec76476efb71549) opening log file.
022c/notice.log:Dec 09 21:41:43.738 [notice] Bootstrapped 100%: Done.
023c/notice.log:Dec 09 21:41:41.000 [notice] Tor 0.2.3.25 (git-17c24b3118224d65) opening log file.
023c/notice.log:Dec 09 21:41:43.000 [notice] Bootstrapped 100%: Done.
024c/notice.log:Dec 09 21:41:41.000 [notice] Tor 0.2.4.18-rc (git-1cda452bc136de6b) opening log file.
024c/notice.log:Dec 09 21:41:43.000 [notice] Bootstrapped 100%: Done.
025c/notice.log:Dec 09 21:41:41.000 [notice] Tor 0.2.5.1-alpha (git-e65b54ec75e3c9e9) opening log file.
025c/notice.log:Dec 09 21:41:43.000 [notice] Bootstrapped 100%: Done.

comment:2 Changed 21 months ago by ln5

The reason for 0.2.0.35 not bootstrapping might not be related to the 2048 bit key but rather to the fact that it doesn't know about TestingTorNetwork.

I suggest that we test how 020 react to a 2048 bit key once we have one such signature in the real network.

comment:3 Changed 21 months ago by arma

sounds great to me! let us know how it goes

comment:4 Changed 21 months ago by ln5

As of consensus valid-after 2013-12-11 18:00:00 maatuska is signing with a 2048 bit key. Other dir auths apparently like the votes and none of my clients have complained, at least loudly enough for me to hear it.

A 0.2.0.35 client doesn't bootstrap properly, but I doubt that this is because of the longer signature. Silly enough I didn't try bootstrapping before the change. Any idea if 020 is actually supposed to work nowadays?

comment:5 follow-up: Changed 21 months ago by nickm

0.2.0 is not actually supposed to work nowadays; the issue is that it would be Bad Indeed if an 0.2.0 client responded to this change by downloading a consensus and a set of certs over and over, rejecting the consensus and the certs as invalid every time, and then downloading a new set. A small set of zombie 0.2.0 clients would thereby put an unpleasant amount of needless load on the network.

It's also not enough to test that 0.2.0 doesn't do this with the current network; we really need to test that 0.2.0 doesn't have this failure mode when confronted with a network containing *only* 2048-bit signing keys. Otherwise, things might seem fine until we drop below 5 1024-bit keys out of 9 and all hell breaks loose.

Other than that, it looks okay to me.

comment:6 Changed 21 months ago by ln5

I see. Good points. Both these have been confirmed not to be a problem in the Chutney testing.

I will move forward with convincing people to update by starting to nag arma who's key expires in three weeks from now.

Please see bug10324 in my repo for a tor-gencert.c with SIGNING_KEY_BITS 2048.

I am tempted to change DEFAULT_LIFETIME from 12 to 6 months too but will poll the dir auth operators first.

comment:7 in reply to: ↑ 5 Changed 21 months ago by arma

Replying to nickm:

Otherwise, things might seem fine until we drop below 5 1024-bit keys out of 9 and all hell breaks loose.

Another option to ponder is using the legacy key model to sign the consensus with both your 1024-bit key and your 2048-bit key.

comment:8 Changed 21 months ago by nickm

The legacy key model assumes two identity keys, and is a means for migrating between identity keys. This is above making signing keys longer. Identity keys are already 3072-bit RSA.

comment:9 Changed 21 months ago by arma

Excellent. Scratch my suggestion.

comment:10 Changed 21 months ago by nickm

Also let's try to get people to switch over one at a time, with at least a few days between each switch. Everybody switching certs on the same day could be exciting.

comment:11 Changed 21 months ago by ln5

  • Status changed from new to needs_revision

Tracking which dir auths that have switched at https://people.torproject.org/~linus/sign2048 .

arma, what do you think about being next?

nickm, would you rather wait merging bug10324 until we've done the first five?

comment:12 Changed 21 months ago by ioerror

What other modulus makes sense? What are the performance tradeoffs? That is 3072-bit RSA is current largest key in all of Tor - do we see considerable performance degradation if we use keys that are only that small? I'd be curious to see the OpenSSL bench for various authorities for 1024, 2048, 3072 and 4096 bit keys.

Might it also make sense to consider key size changes when rotating the long term identity keys? I'd like to rotate mine at some point, for example.

Linus - if you'd like me to change keys size before mid-Feb, I should do it in the next ten days before CCC Congress.

comment:13 Changed 21 months ago by nickm

CPU impact:

RSA signing with authority signing keys is probably not a significant performance impact in CPU, since we sign three things per period: a vote, and both kinds of consensus. My little laptop takes 9 ms for an RSA4096 signature. This just doesn't matter.

For verification, clients need to verify every signature on a certificate when they load it, and every signature on a consensus when they load that. Worst case, that's 18 signatures, assuming you're starting cold. My laptop verifies an RSA4096 signature in 0.14 ms.

Document size impact

Currently, signatures take up only 0.3% of the compressed size of a microdesc consensus, so quadrupling them in size would probably eat up no more than 1% of the compressed microdesc consensus size.

comment:14 Changed 21 months ago by nickm

Merged. I'd also take a patch to allow configurable identity-key size and signing key size.

comment:15 Changed 21 months ago by nickm

  • Milestone set to Tor: 0.2.5.x-final
  • Resolution set to implemented
  • Status changed from needs_revision to closed

comment:16 Changed 21 months ago by arma

I'm going to aim to do it soon, but ioerror, you're welcome to beat me to it.

comment:17 Changed 20 months ago by arma

moria1 has done it (yesterdayish).

comment:18 Changed 20 months ago by ln5

Noticed, updated https://people.torproject.org/~linus/sign2048, thanks.

I'm going to wait until about Wednesday before asking Mike to go.

Note: See TracTickets for help on using tickets.