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
