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
