Goodbye 3DBD3B20, welcome BBB51E42

Sunday, December 26. 2010

Goodbye 3DBD3B20, welcome BBB51E42

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.
Posted by Hanno Böck in Cryptography, English, Gentoo, Linux, Security at 18:16 | Comments (3) | Trackbacks (0)
Defined tags for this entry: , , , , , , , , , , , ,
Related entries by tags:

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 (Reply)
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).
#1.1 Hanno (Homepage) on 2010-12-28 11:47 (Reply)
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).
#2 Roy on 2012-07-27 10:55 (Reply)

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA
 
 

About me

You can find my web page with links to my work as a journalist at https://hboeck.de/.

You may also find my newsletter about climate change and decarbonization technologies interesting.

Hanno Böck
mail: hanno@hboeck.de

Hanno on Mastodon

Impressum

schokokeks.org

Creative Commons

CC0
Unless noted otherwise, all content is CC Zero / public domain

Show tagged entries

Frontpage
Datenschutz / Privacy