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

[Andrei Boros]

This is sound reasoning. And now I understand why not. Thank you.


On 2024-01-20 6:55 AM, Daniel Kahn Gillmor wrote:
> 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
>
>
> _______________________________________________
> Gpg4win-users-en mailing list
> Gpg4win-users-en at wald.intevation.org
> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en

-- 

*ing. Andrei Boros*

Serviciul IT&C
*Radio Romania*
|Tel:   +40-21-303-1870
       +40-745-115721
Email: andrei at srr.ro <mailto:andrei at srr.ro>|

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20240122/afb3c20d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1513 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20240122/afb3c20d/attachment.sig>