[openpgp] Re: Persistent Symmetric Keys: new algorithms or new packets?

Sorry for the late reply, I'll keep it short, I think AEAD support is a
MUST and HMAC for detached integrity use cases is a SHOULD. I concur with
Mr. Winter's comments.


On Wed, 23 Jul 2025 at 11:20, Justus Winter <[email protected]> wrote:

> Daniel Huigens <[email protected]> writes:
>
> > On Wednesday, July 23rd, 2025 at 15:15, Justus Winter wrote:
> >> I think wouldn't mind the new kind of key packet also using PKESK
> >> packets and signature packets.
> >
> > How do you envision this part concretely? Those packets have a public
> > key algorithm field, so we would presumably still need to register at
> > least one algorithm ID for this scenario, then?
> >
> > Or we could set it to 0, which is reserved?
>
> I would still register public key algorithm IDs for AEAD and HMAC keys.
>
> I'm less worried about having a few symmetric algorithms in the "public
> key algorithm" registry than about re-using the key packets, which have
> a public key and a secret key variant, and the former doesn't make sense
> with symmetric keys, yet the latter is defined in terms of the former,
> and because of that relationship current implementations may assume that
> one can derive a public key packet from a secret key packet.
>
> And then there is the expectation of being able to compute fingerprints,
> and have them be reasonably unique.
>
> All of those concerns just go away when we use a different key packet.
> And, I think implementations then have a chance of adding a new
> interface for these packets (on the low-level, I'm not suggesting
> exposing this as a new interface to users, though I'm sure that these
> new mechanisms will require application-specific handling).
>
> Best,
> Justus
> _______________________________________________
> 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]