thinking is dangerous — it leads to ideas
thinking is dangerous — it leads to ideas
Member of the Board of the Polish Linux Users Group. Human rights in digital era hacktivist, Free Software advocate, privacy and anonimity evangelist; expert volunteer to the Panoptykon Foundation; co-organizer of SocHack social hackathons; charter member of the Warsaw Hackerspace; and Telecomix co-operator; biker, sailor.
Formerly President of the Board of the Polish Free and Open Source Software Foundation; CTO of BRAMA Mobile Technologies Laboratory on Warsaw University of Technology and a student at Philosophy Institute on Warsaw University.
This is my GPG key transition statement. I am transitioning off of my old key:
To a new key:
The old key has not been compromised. The main reason for transition is this weak subkey:
I have generated a new, much stronger key. And I have done so in a way that (to an extent) protects me from ugly consequences of a possible private key loss (think: stolen laptop, with keys). I used these three great howtos:
With their help I have generated a master keypair, stowed away in a safe place; and a laptop keypair that I use day-to-day.
The master keypair has never touched my laptop or any device associated with me — it has been generated on an airgapped random loner laptop in the Warsaw Hackerspace (every hackerspace has a few of these), running a copy of TAILS.
From it, the laptop keypair has been also generated on the airgapped loner lappy. Then, the master keypair has been transferred to the storage medium, and the laptop pair — to my laptop; both have been safely wiped from the loner afterwards (besides, everything was happening on a ramdisk anyway).
The minor inconvenience if this setup is that I can only sign other people's keys with my master keypair, i.e. when I am not travelling.
Below you'll find my key transition statement. You can also download this statement signed by both the old and the new key.
GPG Key Transition Statement
Date: 30th December, 2014
For a number of reasons, i've recently set up a new OpenPGP key, and will be transitioning away from my old one.
The old key will continue to be valid for some time, but i prefer all future correspondence to come to the new one. I would also like this new key to be re-integrated into the web of trust. This message is signed by both keys to certify the transition.
The old key was:
pub 4096R/0x5337E3B760DEC17F 2011-09-28 [expires: 2014-12-30]
Key fingerprint = 07FD 0DA1 72D3 FC66 B910 341C 5337 E3B7 60DE C17F
And the new key is:
pub 4096R/0xEAA4EC8179652B2E 2014-10-14 [expires: 2020-10-12]
Key fingerprint = D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E
To fetch the full key from a public key server, you can simply do:
gpg --keyserver keys.riseup.net --recv-key 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E'
If you already know my old key, you can now verify that the new key is signed by the old one:
gpg --check-sigs 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E'
If you don't already know my old key, or you just want to be double extra paranoid, you can check the fingerprint against the one above:
gpg --fingerprint 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E'
If you are satisfied that you've got the right key, and the UIDs match what you expect, I'd appreciate it if you would sign my key. You can do that by issuing the following command:
NOTE: if you have previously signed my key but did a local-only signature (lsign), you will not want to issue the following, instead you will want to use —lsign-key, and not send the signatures to the keyserver
gpg --sign-key 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E'
I'd like to receive your signatures on my key. You can either send me an e-mail with the new signatures (if you have a functional MTA on your system):
gpg --export 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E' \
| gpg --encrypt -r 'D0E9 E1E3 D80A 098A 0D0D 7EC4 EAA4 EC81 7965 2B2E' \
--armor | mail -s 'OpenPGP Signatures' email@example.com
Additionally, I highly recommend that you implement a mechanism to keep your key material up-to-date so that you obtain the latest revocations, and other updates in a timely manner. You can do regular key updates by using parcimonie to refresh your keyring. Parcimonie is a daemon that slowly refreshes your keyring from a keyserver over Tor. It uses a randomized sleep, and fresh tor circuits for each key. The purpose is to make it hard for an attacker to correlate the key updates with your keyring.
I also highly recommend checking out the excellent Riseup GPG best practices doc, from which I stole most of the text for this transition message ;-)
Please let me know if you have any questions, or problems, and sorry for the inconvenience.
Michał "rysiek" Woźniak