[prev in list] [next in list] [prev in thread] [next in thread]
List: gpg4win-users-en
Subject: Re: [Gpg4win-users-en] Reusing keys across protocols is dangerous [was: Re: Okular - GnuPG edition]
From: Andrei Boros <andrei () srr ! ro>
Date: 2024-01-22 9:25:43
Message-ID: cdc26b1e-03dd-dba0-1248-95ad9b7bdb3e () srr ! ro
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/mixed)]
[Attachment #6 (multipart/alternative)]
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@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@srr.ro <mailto:andrei@srr.ro>|
[Attachment #9 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
This is sound reasoning. And now I understand why not. Thank you. <br>
<br>
<br>
<div class="moz-cite-prefix">On 2024-01-20 6:55 AM, Daniel Kahn
Gillmor wrote:<br>
</div>
<blockquote type="cite" cite="mid:87bk9gob7d.fsf@fifthhorseman.net">
<pre wrap="">On Fri 2024-01-19 09:48:04 +0100, Bernhard Reiter wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Am Donnerstag 18 Januar 2024 10:26:18 schrieb Andrei Boros:
</pre>
<blockquote type="cite">
<pre wrap="">Is there a way to convert or otherwise transfer a OpenPGP key \
to CMS? (ie use the same key)
</pre>
</blockquote>
<pre wrap="">
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.)
</pre>
</blockquote>
<pre wrap="">
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:
<a class="moz-txt-link-freetext" \
href="https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130">https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130</a> \
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:
<a class="moz-txt-link-freetext" \
href="https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-13.html#sig-co \
mputation-notes">https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-13.html#sig-computation-notes</a>
# 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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gpg4win-users-en mailing list
<a class="moz-txt-link-abbreviated" \
href="mailto:Gpg4win-users-en@wald.intevation.org">Gpg4win-users-en@wald.intevation.org</a>
<a class="moz-txt-link-freetext" \
href="https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en">htt \
ps://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en</a></pre> \
</blockquote> <br>
<div class="moz-signature">-- <br>
<p><b>ing. Andrei Boros</b></p>
<p>Serviciul IT&C<br>
<b>Radio Romania</b><br>
<code>
Tel: +40-21-303-1870<br>
+40-745-115721<br>
Email: <a href="mailto:andrei@srr.ro">andrei@srr.ro</a></code></p>
</div>
</body>
</html>
["signature.asc" (application/pgp-signature)]
[Attachment #11 (text/plain)]
_______________________________________________
Gpg4win-users-en mailing list
Gpg4win-users-en@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic