Re: phasing out SHA1 for digest creation

On 12/7/24 07:50, Werner Koch wrote:
> Hi!
>
> On Fri,  6 Dec 2024 19:42, Jacob Bachmeyer said:
>
>> 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
> 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.

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?

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 
actual signed blob cannot be done compatibly.

> Even worse, a random nonce adds a covert channel to a signed message.

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.(I consider nonfree cipher software 
categorically insecure.)

> 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.

Is it plausible that they had the same line of reasoning that I did, and 
simply did not consider covert channel risks?

> 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.

Nor were there signs that SHA-1 could be attacked until it was. 
(Although the attacks on SHA-1 are still very limited.)


-- Jacob

_______________________________________________
Gnupg-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-devel