On 16 Dec 2024, at 12:54, Werner Koch <w...@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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-devel
