Adding a nounce before hashing as covert channel

[Andrew Gallagher]

On 16 Dec 2024, at 12:54, Werner Koch <wk at gnupg.org> wrote:
> 
> On Fri, 13 Dec 2024 12:43, andrewg said:
> 
>> would equally be possible to create a collision in an unsalted
>> signature by manipulating the first N bits of the message. But while
> 
> But these first N bits of the message may allow to detect a
> modification.  A non-deterministic salt allows to hide the modification.

It depends on what you’re signing. If it’s an RFC3156 message, the first N bits are in the MIME header section. And that’s just one possibility that springs immediately to mind, I’m sure there are many others.

> I have not a problem with a _deterministic_ salt but I do have one with
> adding a new covert channel.

If the salt was deterministic, I don’t see how it would address fault attacks...

> And of course with the stupid way on how
> this was added to the specs.  Extra data belongs into a signature
> subpacket

Extra data like filenames? ;-)

> and if you really want it at the begin of the subpacket area,
> well, specify it this way.

Putting it in the hashed subpacket area wouldn’t address either your concerns or those of the RFC authors though. It’s still a covert channel (just like any other unknown non-critical subpacket, BTW), and even if it’s at the beginning of the subpacket area it’s still hashed-in after the document, which doesn’t protect against chosen-prefix attacks.

> The whole point here is to willy-nilly make it impossible to support the
> new signing packet.

I am genuinely interested to know why it is _impossible_. OpenPGP has never seriously attempted to eliminate covert channels - there are several existing ones that have a much higher bandwidth than signature salts, and would surely be worthy of greater attention if we were taking plaintext covert channels as a serious threat. Also, v5 signatures have extra free-text fields (filename, timestamp) that are hashed-in before the main document, rather than as subpackets.

I’m not saying your concerns aren't genuine, but I am confused why these ones in particular are red lines, and other apparently similar ones are not.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241216/a4c28bc0/attachment.sig>