Russ wrote: > gpg: Total number processed: 101 > gpg: skipped PGP-2 keys: 84 > gpg: unchanged: 17 Thanks for this review, Russ! Can you give a more detailed breakdown of these keys? for example, at least algorithm choice and size? (iiuc, all PGP-2 keys are RSA keys, but i don't think their sizes are constrained). On Fri 2022-04-29 18:04:18 -0700, Russ Allbery wrote: > Paul Wise <pabs@debian.org> writes: >> and nothing other than GnuPG 1 supports these keys? > > I'm personally not aware of anything other than the even more obsolete > commercial PGP implementations, but maybe the package maintainers know > more. I'm not aware of anything other than GnuPG 1 and the older, obsolete PGP implementations, but i haven't tested everything. I think it's worth remembering that each key can be used for a range of different operations, and they have different deprecation patterns. Using RFC 2119-style syntax, i think we have roughly the following requirements: - Encryption: this is dangerous to do with a small key because it means the encrypted session key is weakly protected. Implementations MUST NOT encrypt to old, weak keys. - Decryption: it's not insecure to decrypt data encrypted to these keys, but it *is* insecure to indicate to the user that the data was effectively protected. I like to think about this as the "base64 decode" problem" -- there's nothing wrong with running "base64 -d" but there is a problem with presenting the decoded data as confidential. See also the various E-Fail attacks related to decryption of poorly-encrypted data. Implementations MAY decrypt data with these keys provided that they do not indicate strong confidentiality. - Verification: a signature from an old, weak key does not offer a strong guarantee of authenticity or integrity, because it may be possible for an attacker to forge data. Implementations MUST NOT treat any signature from an old, weak key as valid. - Signing: Signing data with an old, weak key that uses weak algorithms may actually increase the risk of dangerous signature validations by legacy implementations that are not following the guidance above for not verifying signatures. For example, PGP-2 keys sign data with MD5. In the event that the keyholder is making signatures over attacker-supplied data, the attacker could create an MD5 collision, get the victim to sign one variant, and then replay the signature on the other variant. There may be other attacks that increase the risk for a key with each signature made; if any attack risks leakage of even a small amount of information about the secret key, then small, weak keys are even more vulnerable than modern, stronger keys. Making a signature with a key that modern implementations will refuse to verify is also kind of pointless. Implementations MUST NOT make signatures using known-weak digest algorithms. Implementations SHOULD NOT make signatures with old, weak keys. I don't know enough about how Usenet uses these keys, but I think they're only relevant for continued use if they involve decryption. If someone wants to make and distribute a dedicated tool for decryption with old keys (a "base64 -d" equivalent 😛), i wouldn't object to that. But I don't think that implementation should be called GnuPG. --dkg
Attachment:
signature.asc
Description: PGP signature