Thanks, Ilari.
My question was not correct. When we restrict the algorithms at layer0 for
"HPKE key encryption" to AEAD algorithms, specifically A{128,192, 256}GCM
and ChaCha20Poly1305, are there any reasons why we need next_alg?
Additionally, in COSE-HPKE, are there any problems when restricting the
algorithms at layer0 for "HPKE key encryption" to AEAD algorithms (
A{128,192, 256}GCM and ChaCha20Poly1305)?
Daisuke
2024年3月19日(火) 17:59 Ilari Liusvaara <[email protected]>:
> On Tue, Mar 19, 2024 at 07:47:57AM +0900, AJITOMI Daisuke wrote:
> > >
> > > (HPKE is both bulk and aad capable, so it is its own class in COSE,
> > > not Key Transport class. This also gives it correct properties w.r.t.
> > > sections 5.3 and 5.4.)
> >
> >
> > Under the premise of prohibiting the use of AE algs at layer0 and using
> > HPKE algs for key wrapping at layer1, should we really introduce
> next_alg?
> >
> > I just want to understand the reason correctly.
>
> It is the symmetric encryption algorithms that are neither AE nor AEAD
> that are the problem. While AE is not great (e.g., no protected
> headers), it is not a major problem.
>
> Currently, there are six such algorithms, from -65534 to -65529,
> inclusive (the AES-CTR and AES-CBC algorithms).
>
> There really are not AE algorithms that are usable at layer0. AFAICT,
> AES-KW is allowed at layer0, but it is very slow.
>
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
