Re: GnuPG 2.4.4 still using legacy packets?

On 11/13/25 05:56, Andrew Gallagher via Gnupg-users wrote:
> Hi, Peter.
>
> On 13/11/2025 09:23, Peter Pentchev wrote:
>> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>>    the least common denominator
>
> This is not how GnuPG's compliance options currently work though; 
> non-default compliance options cause GnuPG to comply with *earlier* 
> specs, to improve backwards compatibility at the expense of 
> cryptographic strength.
>
> It would be reasonable, and still solidly defensive, for GnuPG to emit 
> the old packet framing iff a compliance option such as --rfc2440 was 
> supplied, or if the key being encrypted to advertised old defaults, or 
> if the key material uses an algorithm or packet version that pre-dates 
> rfc4880. But it serves no purpose to continue to use the old format 
> with modern cryptography that legacy code can't understand anyway.

This is what I am suggesting:  when using ciphers that were not 
available in the ancient implementations that do not understand the new 
format, use the new format because interoperability is broken (at the 
user's command) anyway.

I also noted that it may be possible for some modern signatures to be 
usable in those ancient implementations.  If that is so, this should 
*not* be gratuitously broken unless we find some serious cryptographic 
flaw in that format.

If there *is* such a flaw, GnuPG could still have an option to generate 
the old form, in case someone out there actually has a workflow that 
depends on it, but should emit a BIG SCARY WARNING explaining the 
problem, both when generating a weak signature and especially upon 
verifying one!


-- Jacob



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