3 ms·

Removal of PGP-2 support Some algorithms and parts of the protocols as used by the 20 years old PGP-2 software are meanwhile considered unsafe. In particular t

Removal of PGP-2 support Some algorithms and parts of the protocols as used by the 20 years old PGP-2 software are meanwhile considered unsafe. In particular the baked in use of the MD5 hash algorithm limits the security of PGP-2 keys to non-acceptable rate. Technically those PGP-2 keys are called version 3 keys (v3) and are easily identified by a shorter fingerprint which is commonly presented as 16 separate double hex digits. With GnuPG 2.1 all support for those keys has gone. If they are in an existing keyring they will eventually be removed. If GnuPG encounters such a key on import it will not be imported due to the not anymore implemented v3 key format. Removing the v3 key support also reduces complexity of the code and is thus better than to keep on handling them with a specific error message. There is one use case where PGP-2 keys may still be required: For existing encrypted data. We suggest to keep a version of GnuPG 1.4 around which still has support for these keys (it might be required to use the --allow-weak-digest-algos option). A better solution is to re-encrypt the data using a modern key. https://gnupg.org/faq/whats-new-in-2.1.html https://gnupg.org/faq/whats-new-in-2.1.html This only affects data encrypted by PGP-2, the original Phil Zimmerman PGP. If you are on GPG 1.4 or 2.0 and want to switch over to 2.1 this shouldn't be a problem.

acqq 12y ago
It affects the data encrypted by GPG until that "new and improved" version, as long as the keys have "older" format. Until recently the GPG was able to use such "older format" key for both encryption and decryption. Now it can't do both. And that was even not necessarily known by the users, that they used something "older": you saw the shorter fingerprint but otherwise everything worked. GPG even doesn't inform the users in the runtime that it silently removes user's "old format" keys from the set of keys they had. They just "dissaper." The people who use the PGP the longest are the ones most inconvenienced. The old data, supposed to be backups, can't be read by the new version.
- zaroth 12y ago
  We must maintain perfect backward compatibility back to the beginning of time! We must have pristine clean and cruft-free code to help ensure mistakes are easy to catch! Sounds like the age old, More Taste! Less Filling! Backward compatibility for insecure algorithms is exactly the code which should be jettisoned. We have VMs which run Amiga and DOS, if you're terrified of not being able to decrypt then grab a cup of coffee and get to re-encrypting with a key that doesn't inline MD5! You did get the part where this is free software, and you are free to fork it if you wish? I tend to think it's the users responsibility, by choosing to use the package, to actually understand how it works. The maintainer owes you nothing. It's stated right there in the license. P.S. The scare quotes do not help your argument. The old keys are technically weak. That happens with crypto from time to time. If you can't plan for that, might as well keep it cleartext.
  - lawl 12y ago
    While I agree that support needs to be dropped eventually. Printing a warning and only allowing decryption with weak keys would have been a better option IMO. Keep that around for a year or two, then drop support fully.
  - gaius 12y ago
    We must maintain perfect backward compatibility back to the beginning of time! Actually, if you are writing archiving software, yeah. Especially for official or legal records.

acqq 12y ago

It affects the data encrypted by GPG until that "new and improved" version, as long as the keys have "older" format. Until recently the GPG was able to use such "older format" key for both encryption and decryption. Now it can't do both. And that was even not necessarily known by the users, that they used something "older": you saw the shorter fingerprint but otherwise everything worked. GPG even doesn't inform the users in the runtime that it silently removes user's "old format" keys from the set of keys they had. They just "dissaper." The people who use the PGP the longest are the ones most inconvenienced. The old data, supposed to be backups, can't be read by the new version.

zaroth 12y ago
We must maintain perfect backward compatibility back to the beginning of time! We must have pristine clean and cruft-free code to help ensure mistakes are easy to catch! Sounds like the age old, More Taste! Less Filling! Backward compatibility for insecure algorithms is exactly the code which should be jettisoned. We have VMs which run Amiga and DOS, if you're terrified of not being able to decrypt then grab a cup of coffee and get to re-encrypting with a key that doesn't inline MD5! You did get the part where this is free software, and you are free to fork it if you wish? I tend to think it's the users responsibility, by choosing to use the package, to actually understand how it works. The maintainer owes you nothing. It's stated right there in the license. P.S. The scare quotes do not help your argument. The old keys are technically weak. That happens with crypto from time to time. If you can't plan for that, might as well keep it cleartext.
- lawl 12y ago
  While I agree that support needs to be dropped eventually. Printing a warning and only allowing decryption with weak keys would have been a better option IMO. Keep that around for a year or two, then drop support fully.
- gaius 12y ago
  We must maintain perfect backward compatibility back to the beginning of time! Actually, if you are writing archiving software, yeah. Especially for official or legal records.