Re: Adding a nounce before hashing as covert channel

Andrew Gallagher via Gnupg-devel <[email protected]> Mon, 16 Dec 2024 13:30:04 +0000

Newsgroups	gmane.comp.encryption.gpg.devel
Message-ID	<[email protected]>

On 16 Dec 2024, at 12:54, Werner Koch <[email protected]> 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

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

signature.asc (application/pgp-signature, 833 B)