Goodbye 3DBD3B20, welcome BBB51E42
Sunday, December 26. 2010, 18:16
Having used my PGP key 3DBD3B20 for almost eight years, it's finally time for a new one: 4F9F43A9. The old primary key was a 1024 bit DSA key, which had two drawbacks:
1. 1024 bit keys for DLP or factoring based algorithms are considered insecure.
2. It's impossible to set the used hash algorithm to anything beyond SHA-1.
My new key has 4096 bits key size (2048 bit is the default of GnuPG since 2.0.13 and should be fairly enough, but I wanted some extra security) and the default hash algorithm preference is SHA-256. I had to make a couple of decisions for my name in the key:
1. I'm usually called Hanno, but my real/official name is Johannes.
2. My surname has a special character (ö) in it, which can be represented as oe.
In my previous keys, I've mixed this. I decided against this for the new key, because both my inofficial prename Hanno and my umlaut-converted surname Boeck are part of my mail adress, so people should still be able to find my key if they're searching for that.
Another decision was the time I wanted my key to be valid. I've decided to give it an expiration date, but a fairly long one: 10 years from now.
I've signed my new key with my old key, so if you've signed my old one, you should be able to verify the new one. I leave it up to you if you decide to sign my new key or if you want to re-new the signing procedure. I'll start from scratch and won't sign any keys I've signed with the old key automatically with the new one. If you want to key-sign with me, you may find me on the 27C3 within the next days.
My old key will be valid for a while, at some time in the future I'll probably revoke it.
Update: I just found out that having a key without SHA-1 is trickier than I thought. The self-signatures were still SHA-1. I could re-do the self-signatures and revoke the old ones, but that'd clutter the key with a lot of useless cruft and as the new key wasn't around long and didn't get any signatures I couldn't get easily again, I decided to start over again: The new key is BBB51E42 and the other one will be revoked.
I'll write another blog entry to document how you can create your own SHA-256 only key.
1. 1024 bit keys for DLP or factoring based algorithms are considered insecure.
2. It's impossible to set the used hash algorithm to anything beyond SHA-1.
My new key has 4096 bits key size (2048 bit is the default of GnuPG since 2.0.13 and should be fairly enough, but I wanted some extra security) and the default hash algorithm preference is SHA-256. I had to make a couple of decisions for my name in the key:
1. I'm usually called Hanno, but my real/official name is Johannes.
2. My surname has a special character (ö) in it, which can be represented as oe.
In my previous keys, I've mixed this. I decided against this for the new key, because both my inofficial prename Hanno and my umlaut-converted surname Boeck are part of my mail adress, so people should still be able to find my key if they're searching for that.
Another decision was the time I wanted my key to be valid. I've decided to give it an expiration date, but a fairly long one: 10 years from now.
I've signed my new key with my old key, so if you've signed my old one, you should be able to verify the new one. I leave it up to you if you decide to sign my new key or if you want to re-new the signing procedure. I'll start from scratch and won't sign any keys I've signed with the old key automatically with the new one. If you want to key-sign with me, you may find me on the 27C3 within the next days.
My old key will be valid for a while, at some time in the future I'll probably revoke it.
Update: I just found out that having a key without SHA-1 is trickier than I thought. The self-signatures were still SHA-1. I could re-do the self-signatures and revoke the old ones, but that'd clutter the key with a lot of useless cruft and as the new key wasn't around long and didn't get any signatures I couldn't get easily again, I decided to start over again: The new key is BBB51E42 and the other one will be revoked.
I'll write another blog entry to document how you can create your own SHA-256 only key.
Cryptography, English, Gentoo, Linux, Security |
Comments (3)
| Trackbacks (0)
Defined tags for this entry: cryptography, datenschutz, encryption, gnupg, gpg, key, pgp, privacy, schlüssel, security, sha1, sha2, verschlüsselung
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
What's so special in letter ö aside the fact that it does not occur in Zulu alphabet?
#1
Aga
on
2010-12-28 08:24
It's not part of the ASCII charset and it's thus represented differently in UTF-8, Codepage 850 and ISO-8859-1. This means lot's of technical problems (e. g. it seems i won't be able to get my key signed by CAcert at the moment due to a bug in CAcert's software).
I've, my self, after some years came to the conclusion that currently the best configuration (before creating the key... or change it to):
inside gpg.conf file:
comment ""
enable-dsa2
default-preference-list AES192 AES256 AES SHA384 SHA512 SHA256 ZLIB BZIP2 ZIP
personal-cipher-preferences AES192
cipher-algo AES192
personal-digest-preferences SHA384
cert-digest-algo SHA384
digest-algo SHA384
personal-compress-preferences ZLIB
compress-algo ZLIB
The maximum key I can create and that is guaranteed to work is a RSA 4096 bit key... and that "only" gives 128 bits of security according to FNISA, or between 128 and 150(?) bits of security according to ECRYPT II and NIST.
So I don't need to use AES256 by default because the RSA key doesn't provide more protection than 128/150(?) bits... and choose AES192 (just to have some security margin), and SHA-256 is supposed to offer 128 bits of security... so I choose SHA-384 (just to have some security margin).. it should provide 192 bits of security. So It's just a compromise between some security margin, speed and having in mind the weakest point (RSA key).
AES256 and SHA-512 was second choice, in case some one doesn't have AES192 or SHA384... I don't want to default to AES or worse 3DES... then it comes AES and SHA256... the latest option (because with GnuPG 2.0.19 I can't built it my self in windows) comes the insecure 3DES and SHA1... I preferred not to have this last two... but someone, somewhere wants to force insecure options (some 3 letter agency?) and the GnuPG inserts (against my will) 3DES and SHA1 either I want it or not. Camellia cypher unfortunately doesn't work with PGP... and if I use it, PGP users will complaint many times about not being able to open the messages (seems like a bug to me... not supporting is one thing, another is give error).
When creating the key it self I find it better to create first 1 main key to (C)ertify and (A)uthenticate, and after, create a new sub-key to (S)ign, and another new sub-key to (E)ncrypt. All with 4096 bits RSA key of course.
Curiously (or not) I've not see anyone else doing this, this way... but seems the better compromise between best security (achievable), speed and usability.
Security levels comparisons between technologies made at keylength.com (with the sources).
inside gpg.conf file:
comment ""
enable-dsa2
default-preference-list AES192 AES256 AES SHA384 SHA512 SHA256 ZLIB BZIP2 ZIP
personal-cipher-preferences AES192
cipher-algo AES192
personal-digest-preferences SHA384
cert-digest-algo SHA384
digest-algo SHA384
personal-compress-preferences ZLIB
compress-algo ZLIB
The maximum key I can create and that is guaranteed to work is a RSA 4096 bit key... and that "only" gives 128 bits of security according to FNISA, or between 128 and 150(?) bits of security according to ECRYPT II and NIST.
So I don't need to use AES256 by default because the RSA key doesn't provide more protection than 128/150(?) bits... and choose AES192 (just to have some security margin), and SHA-256 is supposed to offer 128 bits of security... so I choose SHA-384 (just to have some security margin).. it should provide 192 bits of security. So It's just a compromise between some security margin, speed and having in mind the weakest point (RSA key).
AES256 and SHA-512 was second choice, in case some one doesn't have AES192 or SHA384... I don't want to default to AES or worse 3DES... then it comes AES and SHA256... the latest option (because with GnuPG 2.0.19 I can't built it my self in windows) comes the insecure 3DES and SHA1... I preferred not to have this last two... but someone, somewhere wants to force insecure options (some 3 letter agency?) and the GnuPG inserts (against my will) 3DES and SHA1 either I want it or not. Camellia cypher unfortunately doesn't work with PGP... and if I use it, PGP users will complaint many times about not being able to open the messages (seems like a bug to me... not supporting is one thing, another is give error).
When creating the key it self I find it better to create first 1 main key to (C)ertify and (A)uthenticate, and after, create a new sub-key to (S)ign, and another new sub-key to (E)ncrypt. All with 4096 bits RSA key of course.
Curiously (or not) I've not see anyone else doing this, this way... but seems the better compromise between best security (achievable), speed and usability.
Security levels comparisons between technologies made at keylength.com (with the sources).
#2
Roy
on
2012-07-27 10:55
Add Comment