On Mar 2, 2010, at 9:18 PM, Smith, Cathy wrote: > Folks > > The gpg --import option worked without any problems for importing the OpenPGP > public keyring. When I try to import the secret keyring, I get the following > message: > > [app1 ~/.gnupg]$ gpg --import secring.skr > gpg: key B4A839CC: secret key imported > gpg: key B4A8899S: "ofc" not changed > gpg: key 96B12847: secret key imported > gpg: key 96B12847: "pss" not changed > gpg: WARNING: key 96B12847 contains preferences for unavailable > gpg: algorithms on these user IDs: > gpg: "pss": preference for cipher algorithm 1 > gpg: it is strongly suggested that you update your preferences and > gpg: re-distribute this key to avoid potential algorithm mismatch problems > > Set preference list to: > Cipher: AES256, AES192, AES, CAST5, 3DES > Digest: SHA1, SHA256, RIPEMD160 > Compression: ZLIB, BZIP2, ZIP, Uncompressed > Features: MDC, Keyserver no-modify > Really update the preferences? (y/N) > > If I answer "no", the import finishes with the message: > > Key not changed so no update needed. > gpg: Total number processed: 7 > gpg: w/o user IDs: 1 > gpg: unchanged: 6 > gpg: secret keys read: 7 > gpg: secret keys imported: 7 > > > When I created my gpg keyring, I selected the default for the key, DSA and > Elgamml, and a 2048 bit keysize. > > What are the ramifications of just saying "yes" to the prompt - update > preferences? How potentially serious is the algorithm mismatch? I'd like to > better understand exactly what is happening.
OpenPGP keys contain several algorithm lists, one each for cipher algorithms, hash algorithms, and compression algorithms. Among other things, these lists are used to guarantee that someone doesn't send you a message that you can't handle. For example, if the list of ciphers on your key didn't have AES-256, then nobody should use AES-256 when sending you a message. The warning message above means that your key 96B12847, aka "pss", has a listing for cipher 1 (called "IDEA"), but your copy of GPG doesn't have IDEA. This sets up a potentially frustrating situation where someone might send you a message using IDEA (after all, your key claims that you can handle it), but you won't be able to read the message because you really can't handle it. > Just for background, this is migration has to go into production in a very > short time. Redistributing keys to the various vendors, and to test the > batch jobs using these keys to exchange files with vendors, wasn't included > when planning. So I'm under a short deadline. The right answer, I'm afraid, is to say "yes" to the prompt and update your preferences, and re-distribute the key in question (96B12847 "pss"). This isn't a problem with any other key you have. Alternately, you can re-build GPG to have IDEA support. Note, though, that there are legal implications to this. Unlike all of the other ciphers that are defined by OpenPGP, IDEA is patented and not free to use (the patent runs out in the US in January 2012, I believe, so we're not there yet). If you have a license to use IDEA, you can download the code from http://www.gnupg.org/faq/why-not-idea.en.html and use it legally. Unfortunately, the company that owns the rights to IDEA has more or less disappeared (subsumed into another company, if I recall) and does not seem to be issuing licenses any longer. This puts those people who really need IDEA in an unfortunate situation. If you're lucky, it's possible that the various vendors don't use IDEA either and would thus ignore the fact that your key allows it, but I really recommend just updating your preferences and re-distributing the "pss" key. It's likely the least painful solution here. David _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
