[pkg-gnupg-maint] What do we do about GnuPG 1.4 in debian?

[Daniel Kahn Gillmor]

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 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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20220430/7078093b/attachment-0002.sig>