Transition smoothly away from Erinn's signing key for the coming releases

We should find a good transition away from Erinn's signing key. There are already different proposals on the table with different kinds of efforts involved:

1. Move on to a different key of one of the Tor people.
2. Move away from single points of failure and use the sha256sums verification we already describe on https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification
3. Create a role key for signing the bundles to be not dependent on single people available signing the release.

...

added component::applications/tor bundles/installation owner::erinn priority::medium resolution::fixed security status::closed type::task usability labels

I'm strongly in favor of creating a role key and continue to sign files individually.

I vote for option 3. A master key* with rotating Subkeys.

*Lunar mentioned people use gfshare to keep the private-key collectively. I think it's super badass if we can do something like that :)

Trac:
Keywords: N/A deleted, security, usability added
Cc: lunar, mikeperry, gk to lunar, mikeperry, gk, mrphs

Replying to lunar:

I'm strongly in favor of creating a role key and continue to sign files individually.

1. How should we handle that role key in a sane way given how distributed we are?
2. What are the blockers you see for giving all users the full benefits of reproducible builds?

Replying to gk:

Replying to lunar:

I'm strongly in favor of creating a role key and continue to sign files individually.

1. How should we handle that role key in a sane way given how distributed we are?

• Define a set of trusted people.
• Have a computer hardened as possible to do key manipulation with the master key. Hardened X60 + Tails + air gap?
• After the master key has been generated, use gfshare to split it so that a subset of the trusted people will be needed to ever reconstitute the master key again.
• Use the master key to create subkeys that will go on smartards. Have some people in the Tor Browser team carry these smartcards. Maybe 2 or 3 smartcards not in the same part of the world. Optionally other people in the team could carry revocation certificates for these subkeys.
• Every year, have enough trusted people meet to be able to rotate the subkeys.

2. What are the blockers you see for giving all users the full benefits of reproducible builds?

I would rather postpone that for another time. Right now there's a hell lot of documentation out there that assumes that files are signed individually. I'm interested in finding the best ways to continue doing so.

Trac:
Cc: lunar, mikeperry, gk, mrphs to lunar, mikeperry, gk, mrphs, mcs

Replying to lunar:

Replying to gk:

2. What are the blockers you see for giving all users the full benefits of reproducible builds?

I would rather postpone that for another time. Right now there's a hell lot of documentation out there that assumes that files are signed individually. I'm interested in finding the best ways to continue doing so.

Huh? I fail to see why "there's a hell lot of documentation out there that assumes that files are signed individually" should prevent enumerating the blockers for moving to a different verification scheme. But it seems at least the amount of documentation relying on single keys is one of the blockers (which is, btw, kind of a catch-22 situation as we won't get new documentation if we are not switching the verification scheme). Good, what else?

Trac:
Cc: lunar, mikeperry, gk, mrphs, mcs to lunar, mikeperry, gk, mrphs, mcs, boklm

A few stupid thoughts as I am distracted from other things:

There doesn't need to be a single unitary solution here. Suppose that our we believe that what we'd really like to do (were usability not an issue) is sign everything using threshold postquantum signatures over blake2 + cubehash, with a drum solo to drive away the evil spirits. And suppose that from a usability POV we have no idea how to make that usable, and we think that we need to do gpg signatures for the forseeable future if we want any hope of users actually checking these things.

What stops us from doing both? Give people a high-security way to check packages and a high-usability way if we don't believe we can make a single way that has both properties.

Replying to nickm:

What stops us from doing both? Give people a high-security way to check packages and a high-usability way if we don't believe we can make a single way that has both properties.

Nothing is stopping us from doing both. In fact, we do both already. There was just the thought that we maybe could drop the high-usability only way and have a high-security AND, say, usability way of doing things instead.

As Mike noted today on IRC we are hopefully soon able to ship signed MAR files for the updater which means that it might not be worth all the fancy efforts in trying to safeguard a role signing key given that we need to include that one MAR signing key into our Tor Browser which creates yet another single point of failure... (granted I am simplifying a bit given the certificate pinning but still...).

Here we go:

  pub  4096R/93298290 2014-12-15            
	 Fingerprint=EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290 

uid Tor Browser Developers (signing key) <torbrowser@torproject.org>

http://hkps.pool.sks-keyservers.net/pks/lookup?op=vindex&search=0x4E2C6E8793298290&fingerprint=on It is signed by my current key and will be used from now on unless we fuck things up trying to get the secret master key in Mike's dungeon.

Trac:
Username: ilf
Cc: lunar, mikeperry, gk, mrphs, mcs, boklm to lunar, mikeperry, gk, mrphs, mcs, boklm, ilf@zeromail.org

Trac:
Cc: lunar, mikeperry, gk, mrphs, mcs, boklm, ilf@zeromail.org to lunar, mikeperry, gk, mrphs, mcs, boklm, ilf@zeromail.org, adrelanos@riseup.net

Since there are various TBB downloaders (tb-updater and torbrowser-launcher), please excuse the following question to make sure.

In future files such as https://dist.torproject.org/torbrowser/4.5-alpha-2/tor-browser-linux64-4.5-alpha-2_en-US.tar.xz.asc will be signed by the above rather than Erinn's key, right?

At least the *.xz, *.exe and *.dmg bundles will be signed by the new key, so, assuming that is what you meant, yes.

Replying to gk:

At least the *.xz, *.exe and *.dmg bundles will be signed by the new key, so, assuming that is what you meant, yes.

Or, more exact, they will be signed by one of its subkeys.

Trac:
Cc: lunar, mikeperry, gk, mrphs, mcs, boklm, ilf@zeromail.org, adrelanos@riseup.net to lunar, mikeperry, gk, mrphs, mcs, boklm, ilf@zeromail.org, adrelanos@riseup.net, micahlee

Created two related tickets:

• #14625 (moved) set expiration date for Tor Browser Developers signing key
• #14626 (moved) Apply OpenPGP Best Practices for Tor Browser Developers Signing Key

Trac:
Username: u
Cc: lunar, mikeperry, gk, mrphs, mcs, boklm, ilf@zeromail.org, adrelanos@riseup.net, micahlee to lunar, mikeperry, gk, mrphs, mcs, boklm, ilf@zeromail.org, adrelanos@riseup.net, micahlee, u@451f.org

OK. I updated our verifying signatures instructions with the attached patch. We are ready for the switch on the stable series then.

Trac:
0001-Bug-13407-Update-signature-verification.patch

Not as smooth as I had hoped but, hey, we made it.

Trac:
Status: new to closed
Resolution: N/A to fixed

closed

mentioned in issue #14625 (moved)

mentioned in issue #14626 (moved)

mentioned in issue tpo/applications/tor-browser#14625 (closed)

mentioned in issue tpo/applications/tor-browser#14626 (closed)