My GPG key transition to a 4096-bit key

This is long overdue, so here goes:

Hash: SHA1,SHA512

I'm transitioning my GPG key from an old 1024D key to a new 4096R key.

The old key will continue to be valid for some time, but I prefer
all new correspondance to be encrypted to the new key, and will be making
all signatures going forward with the new key.

This transition document is signed with both keys to validate the transition.

If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
re-authenticating me.

Old key:

pub   1024D/0x5DD5685778D621B4 2000-03-07
      Key fingerprint = 0F3C 34D1 E4A3 8FC6 435C  01BA 5DD5 6857 78D6 21B4

New key:

pub   4096R/0x1D661A372FED8F94 2013-12-30
      Key fingerprint = 9A17 578F 8646 055C E19D  E309 1D66 1A37 2FED 8F94

Version: GnuPG v1


The new key is available from keyservers, e.g. or others.

In other news: Yes, I've not been blogging much recently, will try to do updates more often. In the mean time, you can also refer to my Twitter account for random stuff or the new sigrok Twitter account for sigrok-related posts.

Serious remotely exploitable hole in GnuPG

Just in case you haven't heard of this yet: GnuPG <= 1.4.5 contains a remotely exploitable security issue which has been fixed in 1.4.6.

You should really upgrade ASAP, as this problem can (theoretically) occur when GnuPG decrypts/checks encrypted email messages/signatures (for example).

If you're running Debian unstable: apt-get install gnupg

Encrypted SMS Solutions?

Dear Lazyweb,

I was recently thinking about SMS encryption (you know, the short messages sent from your cell phone). Or MMS encryption for that matter. Are there any Free Software solutions to implement such a thing, based on well-known crypto primitives and proven implementations thereof?

From a quick glance I could not find anything usable, only lots of commercial, closed-source "solutions" which cost money and are basically crap.

I was thinking about hacking together a small Java application (so that most modern phones can run it) which basically asks for a password and pipes your text through AES before sending the SMS. On the receiver's side, you enter the same password and get to see the plaintext. That's pretty much it.

If you want something more elaborate you can use public-key crypto (basically embed GnuPG or similar into the application), but the above should be fine for most uses.

Anyways, I do not want to start implementing something like this if there are other, more mature projects out there which do the same...

Why you'd want to do this (other than simple paranoia, or the fact that governments and other institutions are spying on everyone these days, whether they're allowed to or not)? Well, one good reason for SMS encryption is when you're using some kind of SMS gateways, e.g. a website which gives you 2-3 free SMS per month if you sign up with them and give them tons of personal data. That alone is crappy enough, but you don't want their admins to be able to read and store all your SMSes in addition (which consist of simple plain-text, transmitted though HTTP in this case!). Neither should any local or remote scriptkiddy who knows how to use a sniffer be able to read your private SMSes.

Solution: Write the text in your favorite text editor, pipe it through aespipe (for example), cut'n'paste the result in the web form of the SMS service. The receiver does everthing backwards and you're done.

Syndicate content