[pkg-gnupg-maint] What do we do about GnuPG 1.4 in debian?
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sat Apr 30 19:11:24 BST 2022
> 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
On Fri 2022-04-29 18:04:18 -0700, Russ Allbery wrote:
> Paul Wise <pabs at 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
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
- 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
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
- 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 227 bytes
Desc: not available
More information about the pkg-gnupg-maint