Re: Adding a nounce before hashing as covert channel
Frank Guthausen <[email protected]>
| Newsgroups | gmane.comp.encryption.gpg.devel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 _______________________________________________ Gnupg-devel mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-devel
signature.asc
(application/pgp-signature, 659 B)
-----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEclvqskGlryryYY6X/ZYkYCEQhlMFAmdZa9cACgkQ/ZYkYCEQ hlN4ugv9EOgTI25eNirMa3KxRjA6njks4pxdTk+tIh11gz7KcNTaA7uYEA7UNU2C ZtPIVI25EeKfJqEpeqsSDW538k+p4EiU7Bze8d3awNGPge7MpB0L7dB2n9pX3c7A rpmpMdyIWDpdeUZMvQD+u7QiyWxj7b93FMrFnxQmbbvwGYaHw1P516lFTdCb1sJ1 umgqIIoWLfPklggGjh+LY/Ouia7bo8sBF3DE7gC1e/WpnKaSxAkUKO99DMn/OwAe hJKcdQpvlcTD0aAh2oRk0Fk1mx6zLCiNtCZ+SU63b7gjQ5pvEoqJaAekKnOS5kHG bxCAEUs8KxH9FSIFbLyuUfX0MRXETv0fSmnu7kYSlZ9jdBOg3ViNDSZqv97gkUS9 dL4WiSEUu+aMO2cbMgbLXUSnnvmALE74zmzt9UHTlRX34x/59bA2oEEIBdxmDq+Y 0eUq5F3YESDxWqpNZ/wECN8WZbuvHK8kXSmcx8MI80oeBwlAHttQ2pcPLG7jqwkn 9go6Hxh3 =PGBD -----END PGP SIGNATURE-----