Can I revitalise an old key-pair?

[Henry Hertz Hobbit]

On 09/01/2013 09:15 PM, Pete Stephenson wrote:
> On Sun, Sep 1, 2013 at 2:57 PM, MartinHvidberg <martin at hvidberg.net> wrote:
>> I'm returning to GPG, and Enigmail, and not for the first time. This means
>> that I have earlier generated key-pairs and uploaded them to servers like
>> keys.pgp.net or something like that. I did this first time in 1999 and have
>> done several new attempts later, and now have seven key-pairs on the server.
>> Latest I have generated a key-pair in 2011.
> 
> While it can be tempting to use particularly old keys (such as those
> made in 1999), the maximum length at the time (1024-bit DSA keys)
> makes them borderline too-short for modern usage. Even if you regain
> access to your 1999-era secret key, you should probably consider
> transitioning to a new, stronger keypair. See
> http://www.debian-administration.org/users/dkg/weblog/48 for some
> useful information on the subject.

Pete, it is not your advice which I agree with whole-heartedly
but Debian's choice of order for their digests and to a certain
extent their symmetric ciphers where they made the unwarranted
assumption that bigger is better and biggest is best.  Remember
the person on the other side may NOT have your latest and
greatest umpteen-core machine. Taking those people into account
this may be better choice (and is NOT what I use but is close):

setpref SHA256 SHA512 SHA384 SHA224

Actually I have SHA1 as the option before SHA384 and don't
have SHA224 due to some statements that lead me to believe
it could cause problem.  Maybe there wouldn't be problems.
But what if SHA1 is all they can do?  Okay, you can do it but
I don't like it. But SHA1 is better than nothing especially if
it is for just a one-off message.

The reason why is if you pick SHA512 first, while more secure
(unless the argument that they are all vulnerable to the same
attack since they are all the same family) your detached
signatures will be awfully large.  SHA384 and SHA224 may have
limited or no support.  Paradoxically, AES256 & AES192 had
weaknesses that made them less safe than AES (AES-128) several
years back.  May I humbly suggest TWOFISH or one of the
CAMELLLIA ciphers as a first choice UNTIL you determine whether
or not the fixes for AES-256 and AES-192 are retroactive?  DID
THEY GET THEM FIXED?  I am just assuming they did but that means
I HOPE the older implementation and the newer one can easily be
discerned when you do the decipher. If that can not be done
then you would have needed to decipher the old style AES-256
before the change happened and will be hosed if time rolls on
and that was not done. CAST5 is a good last choice because some
of the time that is all others can handle. Make sure CAST5 is
always a last or next to last choice because that may be all that
they can do with a limited horsepower box.  You may even want
3DES as a last option for those that got stuck there for some
reason.  IDEA?  Your call.  I assume everybody can handle CAST5.

http://www.securemecca.com/public/GnuPG/GnuPG_Prefs.txt

Compression?  The symmetric ciphers seem to always have better
compression than either zlib (gzip) or zip.  They are on par
with either bzip2 or 7-zip (7-zip is not available in OpenPGP).
I would just use and do use "Uncompressed".

Even if the orginal writer can dig up their old keys (the
key-servers have only the public side), do they remember their
pass-phrase?  I know others will disagree with me on this but
that is why I say you should have (unless you work for Amnesty
International, a government attache, high levels of a company
with confidential data, etcetera):

1. Keys created with a time to expire.  I know my 10 year
lifetime is ambitious and they will probably have to be revoked
before then.  But keys with no expire dates are just crazy.
If for no other reason a reasonable time-span (10 years is
really stretching it) allows people to walk away and their
old keys on the key servers will gracefully and mercifully
expire. What happens if you got struck by a Peterbilt and were
killed?  But even if you didn't get killed you can NOT use
them forever.  Time marches on and what was good 10+ years
ago (3DES) is no match for modern CPU power. Actually all
those top-secret places should be creating keys that expire
as well.  Keys that last forever are an impossible hope.

2. A revoke file created with --gen-revoke redirected to a
file and then the file enciphered.  See number 4.

3. The pass-phrase written down on a sheet of paper  and stored
in a safe place.  Remember this is advice for "normal" people.
Did I do this with mine?  No, but that is because I use them
almost every day.  Store this in a DIFFERENT LOCATION than
where the backup of the keys and the backup of revoke are stored
(see next).  Ditto for the passwords of the zips.  Store them
with the pass-phrase, NOT with the zips.  But be sure to store
both where you can get them later.

4. If possible, the backup of the keys themselves in an
an enciphered file, along with the enciphered revoke all put
in a safety deposit box where if somebody wants to get them
later and use them they can.

Backups of the keys on 'nix use an xterm or some sort of
terminal can use my crypt script available here (or some
equivalent):

http://www.securemecca.com/public/GnuPG/crypt.txt
http://www.securemecca.com/public/GnuPG/decrypt.txt
http://www.securemecca.com/public/GnuPG/

$ cd ; umask 077
$ tar -cf gnupg.tar ./.gnupg
# the equivalent of my:
$ crypt gnupg.tar
# this will give you a gnupg.tar.gpg file which is what
# you want to put into safe storage.

# undoing, put gnupg.tar.gpg in home folder and
# cd ; umask 077
$ if [ -s gnupg.tar.gpg ]
then
	rm -f gnupg.tar
	decrypt gnupg.tar
	if [ -s gnupg.tar ]
	then
		rm -fr .gnupg # move previous .gnupg to old.gnupg
		tar -xvf gnupg.tar
	fi
fi

Alternatively, 7-zip could be used with its built-in AES128 bit
cipher which MAY avoid a chicken versus egg problem (you are
deciphering a ~/.gnupg folder which should already exist or
will be created when you decipher if you use gpg or gpg2 which
is not an issue if you use 7-zip):

$ cd ; umask 077
$ 7za a -p gnupg.7z ./.gnupg
# to undo:
$ cd ; umask 077
$ if [ -s gnupg.7z ]
then
	rm -fr .gnupg # move previous .gnupg to old.gnupg
	7za x  gnupg.7z
fi

Was any of that done?  NO?  Then you didn't look ahead.  Do it
when you generate your new keys and especially point 1.  An
even better option if you had done this with all your previous
keys is to just revoke all your old keys one by one and upload
the revoked keys to the key-servers.  Then generate some new
keys with reasonable (REMEMBER THE OTHERS YOU WILL INTERACT
WITH) defaults.  Make sure you do all of the foregoing with the
new and create the backups.  Put the hand-written pass-phrase
and passwords for the zips some some place other than where the
zips are stored but all of them in a safe place.

All I know is there are a LOT of keys that will never die and
NOBODY knows their pass-phrase that are on the key-servers.
Actually top-secret types should decipher their stuff regularly
with the old keys right before the old keys expire, revooke
the keys, create new keys and then re-encipher everyting with
the new keys.  You just cannot expect keys created ten years
ago to be sufficient for todays needs.  Making huge sized keys
while tantalizing just makes it a royal pain interacting with
you now.  4096R/4096R is about the upper limit for now and I
considered them too large when I went back to 2048R/2048R about
two years ago.  I could handle the 4096R pair but could others?

HHH