[Gpg4win-users-en] Reusing keys across protocols is dangerous [was: Re: Okular - GnuPG edition]

[Daniel Kahn Gillmor]

On Fri 2024-01-19 09:48:04 +0100, Bernhard Reiter wrote:
> Am Donnerstag 18 Januar 2024 10:26:18 schrieb Andrei Boros:
>> Is there a way to convert or otherwise transfer a OpenPGP key to CMS?
>> (ie use the same key)
>
> Not really. (Theoreticall if the same algorithms were used, the
> private key material could be used in both systems, but there is no
> technical support for this, that I would know of, so it would only be
> a hack.)

I'd go so far as to say that "no technical support for" reusing secret
keys across protocols is a feature, not a bug.

Even as a hack, it's probably a bad idea to reuse any key for two
entirely different protocols.  I say this as someone who has tried to do
it before, and now wish that i hadn't :P

The risk here is a "cross-protocol" attack risk: consider signing for a
moment (i can describe a kind of encryption risk separately if you're
interested).

When signing, there are cryptographic signatures (typically minimalist
cryptographic operations involving a single stream of bytes), and there
are protocol-level signatures, which depend on a cryptographic
signature.

A protocol-level signature knows something about the context in which
the data being signed is used, and they document/describe explicitly how
to structure that data so that it can be transformed into a stream of
bytes which is then passed to the cryptographic signature.

When verifying a signature, an implementation first transforms the
incoming data in a protocol-specific way to a stream of bytes, and then
calculates the cryptographic signature over that bytestream.

# Description of Cross-protocol Signing Attack

Now consider two signing protocols that permit the use of the same
secret key material.  Call the data→bytes transformation function for
OpenPGP `T_OpenPGP(data)→bytes` and the same for CMS
`T_CMS(data)→bytes`.

Say you hold a secret key Z and you have announced that you are using it
both protocols, by making both an OpenPGP certificate that contains the
secret key material, and an X.509 certificate that contains the secret
key material.

Say you want to use Z to sign an e-mail X.  That is, you'll generate a
cryptographic signature with:

   Sig = Sign(X, T_OpenPGP(X))

You now have to ask yourself: does there exist any CMS input object Y
such that the bytestreams match?  or, evaluate this predicate:

  ∃ Y | T_CMS(Y) == T_OpenPGP(X)

if there is such a Y object, then the signature you have published on X
can be effectively replayed by an adversary over Y, and anyone holding
your CMS certificate will observe that it validates.

I'd call Y an "alias" for X, in that it can appear to be the same signed
thing, based only on a single signature.

Will that Y object be something that you actually wanted to sign?
Will it be dangerous to sign?  Can you know?

The only defense against this is when the two protocols have been
rigorously designed or proven to generate distinct bytestreams.  This is
sometimes called "domain separation".

I can tell you from being involved in some parts of standardization of
both OpenPGP and CMS that these protocols *were not* designed with such
domain separation in mind.  Was that a mistake?  Yes, probably.  Is a
cross-protocol attack actually possible between these two specific
protocols?  I'm not sure, and i haven't tried to do an in-depth analysis
or proof.  But i'm unaware of any attempt to enforce that the protocols
cannot have an aliased bytestream as described above.

There can even be signature aliasing flaws within the same protocol as
it evolves (you might call this within-protocol flavor of the problem a
"cross-version" or "version aliasing" attack).  For example, the OpenPGP
working group was in the process of preparing an update when it was
discovered that the proposed new version of the signature format would
actually have such an alias to an old version of OpenPGP signatures,
over subtly different data.

Demi Marie Obenour spotted this in time:
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130 and the working
group fixed the problem so that the new signature format does *not* have
such a cross-version problem, and future versions of the spec will
contain a note to help keep this property:

  https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-13.html#sig-computation-notes

# Conclusion

Anyway, the short version is: i understand why it might be appealing to
re-use secret key material across protocols, especially if you're
committed to your secret keys being hardware-backed, and hardware is
scarce and expensive.

But please don't do it.  We don't really know how to do it safely, and
there hasn't been sufficient coordination across protocols.

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20240119/f85c1f4d/attachment.sig>