On 09/01/2013 09:15 PM, Pete Stephenson wrote: > On Sun, Sep 1, 2013 at 2:57 PM, MartinHvidberg <mar...@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
