<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/7/24 07:50, Werner Koch wrote:<br>
</div>
<blockquote type="cite" cite="mid:87msh7zjni.fsf@jacob.g10code.de">
<pre class="moz-quote-pre" wrap="">Hi!
On Fri, 6 Dec 2024 19:42, Jacob Bachmeyer said:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Does GPG already do this? If not, can this message count as a feature
request for secure nonces in signatures? Even 64 bits should be
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The suggestion with hashing a nonce is to mitigate a specific way to
create collisions. OTOH, an arbitrary random nonce allows to change the
data in an undetectable way - maybe even to create such a collision.</pre>
</blockquote>
<p>Which I thought I was mentioning in the parenthetical about
nonces as long as the digest used. The first counterargument is
motive: why would a signer want to create a collision?</p>
<p>Presumably, signing {nonce, hash(document, nonce, etc)} instead
of only {hash(document, nonce, etc)} would prevent a third party
from altering the nonce in order to create a collision. Of
course, changing the <span style="white-space: pre-wrap">actual signed blob cannot be done compatibly.
</span></p>
<blockquote type="cite" cite="mid:87msh7zjni.fsf@jacob.g10code.de">
<pre class="moz-quote-pre" wrap="">Even worse, a random nonce adds a covert channel to a signed message.</pre>
</blockquote>
<p>Oh bother... solving one problem creates *another* problem. I
guess I was not considering /that/ risk, on the reasoning that
your cipher software should be trusted.<span
style="white-space: pre-wrap"> (I consider nonfree cipher software categorically insecure.)
</span></p>
<blockquote type="cite" cite="mid:87msh7zjni.fsf@jacob.g10code.de">
<pre class="moz-quote-pre" wrap="">This needs to be avoided in sensitive areas where encryption is not
allowed for exactly that reason. In particular that new IETF OpenPGP
specification introduced a mandatory random salt, despite the counter
arguments that if this will be added the salt must not be random but be
derive from other information. Some people obviously want to have this
covert channel in signatures.</pre>
</blockquote>
<p>Is it plausible that they had the same line of reasoning that I
did, and simply did not consider covert channel risks?<span
style="white-space: pre-wrap">
</span></p>
<blockquote type="cite" cite="mid:87msh7zjni.fsf@jacob.g10code.de">
<pre class="moz-quote-pre" wrap="">A nonce, actually salt, can be introduced in a compatible way with
signature subpackets and maybe extra rules to place that salt as the
first subpacket. Of course the salt needs to be computed from other
info.
Anyway, there are no signs that SHA-256 can be attacked in a similar
way as SHA-1. The SHA3 development process clearly showed that
SHA256, SHA384, SHA512 are safe choices.</pre>
</blockquote>
<p>Nor were there signs that SHA-1 could be attacked until it was.
(Although the attacks on SHA-1 are still very limited.)</p>
<p><br>
</p>
<p>-- Jacob<br>
</p>
<p><br>
</p>
</body>
</html>