[openpgp] Re: I-D Action: draft-ietf-openpgp-persistent-sy mmetric-keys-02.txt

On Tuesday, November 4th, 2025 at 19:46, andrewg <[email protected]> wrote:

> On 2025-11-04 16:26, Daniel Huigens wrote:
> 
> > I realized that no, we don't, we could simply use AEAD as a MAC, too,
> > by passing the input as additional data, and the empty string as the
> > message to encrypt.
> 
> That is very clever, I like it. ;-)

Thanks :)

> > If we really want to introduce HMAC or KMAC at a later date after all
> > for whatever reason, plenty of nobs remain to do so, such as in a new
> > packet or packet version, or a new algorithm ID anyway, and so on.
> 
> I think we should pick an extensibility mechanism sooner rather than
> later. If we register the special asymmetric code point 0, then IMO this
> implies that future extensibility will be marked by packet version
> bumps.

I don't think this is necessarily true. If we define algorithm ID 0 as
AEAD, then the most natural point of extension is the AEAD algorithm
registry.

For example, if we define ChaCha20-Poly1305 there, then we gain a new
encryption mode and a new MAC (Poly1305) for free. I don't think we'll
ever really need more extensibility than that, so defining an additional
registry seems overkill.

If we want to, we could even define HMAC or KMAC as a "MAC-only AEAD",
with an IV size of 0 and a tag size of 256. But even that doesn't seem
super necessary.

Best,
Daniel

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