[openpgp] Re: Forwarding for v6 follow-up

Hi everyone,

In general, I tend to lean more for the additional algo ID.

Every curve / new algorithm this is applied to, the security of the whole construction has to be proven. The paper we've published covers only the X25519 curve.

Also, for curves and ML-KEM the schemes allow for decryption using (almost) the same algorithm as the the original one (the only difference being the KDF replacement).
For other schemes, the algorithm may be significantly different, aka. using a different algorithm may be more semantically correct (e.g. RSA _could_ also be used to do forwarding, allowing for a significantly different decryption forwardee algorithm). Therefore, the FKESK would need then a set of algorithm specific, that is different from the PKESK, and potentially perform a different algorithm.

Honestly, I would not expect there to be more than a couple of forwarded algorithms, corresponding to the "MUST" (i.e. X25519, X25519+ML-KEM768), and if you want forwarding you gotta pick the primary key in this set.

While interop may not seem to be an issue at Proton, because the recipient may have accepted the forwarding, users of different platforms may have accepted the forwarding on a device but not on another. Also, for ML-KEM the proposed algorithm does not require both SKs, but the forwarder SK and the forwardee PK, so in theory it could be instantiated "without their consent".

Cheers,
Aron

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



On Thursday, 31 July 2025 at 19:32, Daniel Huigens <[email protected]> wrote:

> I'll be a bit contrarian here and lean the other way :)
> 

> On Thursday, July 31st, 2025 at 18:35, Andrew Gallagher wrote:
> 

> > I concur; I think it’s also cleaner from a protocol design point of view
> 

> 

> I think defining a new packet is actually cleaner from a protocol design
> point of view, because otherwise we have to duplicate a bunch of
> algorithms in the algorithm ID registry (one for X25519 and possibly
> X448, two for ML-KEM if we figure out how to do forwarding with that,
> and then if the ML-KEM+NIST/BP draft gets adopted and they want to use
> forwarding, that'll be more yet.. there's a kind of multiplicative
> effect here that I think is not ideal).
> 

> Also, all of these algorithm IDs would only be relevant for a decrypter.
> They will never appear in a public key, and can't be used for encryption.
> 

> > and much less likely to trigger interop issues - unknown algorithm code points are generally handled more gracefully than unknown packet types.
> 

> 

> Interop issues aren't as relevant here as it's for decryption only,
> and the forwarding server knows that the final recipient has accepted
> the forwarding and therefore should support the forwarding scheme.
> 

> ---
> 

> Also, if we're leaning towards defining new packets for persistent
> symmetric keys (which seems to be the preference), I think it's cleaner
> to do the same here, as well.
> 

> Best,
> Daniel
> 

> _______________________________________________
> openpgp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmiLsg4JkH5nYVY+/jkwRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmeVnBrWcllv/unxtEutnrdhc6zncA2JQG7ib/AL
bFTSaRYhBIuVslFfa7tqthSdVX5nYVY+/jkwAAAHWQD8Cm1T892yUDqy+DAK
VCRqefzBSDuwPsTMxbRO+wexpmUA/RFmlYV0jgM4XolnzKjRY9jPdcz/TUBa
bdq1SVP/BjYM
=DiJm
-----END PGP SIGNATURE-----