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
--=-=-Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYm17zQAKCRA+nXFzcd5W XF+nAPoDFVczEKyueUPA/d+rfY0Yhh++E58cuwdYiCVuqLsGZgD9Em12kntsYvRa 3RojGtNt7rmNzi1gQl2B/esHkwTR1gY=K6v4
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)