Adding a nounce before hashing as covert channel

Frank Guthausen fg.gnupg at shimps.de
Wed Dec 11 11:39:19 CET 2024


Some thoughts about signing a document, e.g. a contract:

1. Someone, either Alice or Bob, will make a last change to the
   document proposal. WLOG Alice.
2. This might offer an attack vector regarding two versions of the
   document with the same hash value.
3. Alice sends the final draft to Bob for signing. Bob wants mitigation
   of this attack vector.

Can Bob modify the document in a defined way (i.e. a nonce inside the
document rather an external salt while hashing and signing) which will
solve the problem? Let's have Bob adding a line to the document:

nonce1: f1d2d2f924e986ac86fdf7b36c94bcdf32beec15

This example is obtained from ``echo foo | sha1sum'', but might be
completely random.

4. Bob sends the document back to Alice for purpose of signing. Since
   Alice does not want Bob to prepare an evil document with different
   nonce, she adds a line to the document:

nonce2: e242ed3bffccdf271b7fbaf34ed72d089537b42f

obtained by ``echo bar | sha1sum'' for this example. If she sends it
back to Bob, the problems starts all over again (infinite regress).

On Tue, 10 Dec 2024 09:48:19 +0100
Bernhard Reiter via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> 
> There can be unwanted side effects of adding a nonce
> (is what I understand from the example).

As shown above, a trivial "solution" with a nonce does not really work.
There are some implicit or explicit expectations which interfere here:

- both sides sign the same document (symmetric)
- nonces are inside the signed document
- the time and place of signing are different (asymmetric), and
  - the time interval between signatures is big enough to create a
    good/evil hash collision
- no third trust party involved

The attack vector discussed refers to the asymmetric part which allows
to modify both versions of the document (good and evil) to create a
hash collision. A nonce inside the document mirrors the problem back.
Are there any good solutions to the problem (workflow, best practice)
besides hoping the hash algorithm will prevent such an attack in
reasonable time?

- external nonce/salt
- signing two different documents

The more I consider the problem, the more difficult it appears.

kind regards
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241211/40517aef/attachment.sig>


More information about the Gnupg-devel mailing list