Re: [CFRG] HPKE and Key Wrapping

The thread was brought to my attention.

I am not sure what other schemes were compared to AES-SIV, in a way that
the latter had advantage over them.

However, I point out that that AES-GCM-SIV (RFC8452) handles inputs of
different lengths, AAD's, and one can choose to use it with a fixed nonce
(for wrapping keys).

I think Uri had commented about the key wrapping performance.

Regards, Shay

On Tue, May 31, 2022 at 7:51 PM Blumenthal, Uri - 0553 - MITLL <
uri@ll.mit.edu> wrote:

> I support advancement of this draft, as I think that standardizing a SIV
> mode is necessary for cryptographic protocols.
>
>
>
> Having said that, I prefer the way AES-GCM-SIV deals with keys to what
> you’re doing, but that’s secondary.
>
>
>
> Thanks!
>
> --
>
> V/R,
>
> Uri
>
>
>
> *There are two ways to design a system. One is to make it so simple there
> are obviously no deficiencies.*
>
> *The other is to make it so complex there are no obvious deficiencies.*
>
> *
>                                                                                                                    -
> C. A. R. Hoare*
>
>
>
>
>
> *From: *CFRG <cfrg-bounces@irtf.org> on behalf of Dan Harkins <
> dharkins@lounge.org>
> *Date: *Tuesday, May 31, 2022 at 12:43
> *To: *CFRG <cfrg@irtf.org>
> *Subject: *Re: [CFRG] HPKE and Key Wrapping
>
>
>
>
>   Hi,
>
>   I'd like to resurrect this thread. There seemed to be some support for
> adding an MRAE cipher to HPKE for key wrapping and also some support for
> AES-SIV being the cipher to add do to its advantages over other key
> wrapping
> schemes-- it accepts any length input without required padding out to some
> particular block size, and it accepts associated data.
>
>   At the last IETF I asked for a consensus call on
> draft-harkins-cfrg-dnhpke,
> which proposes adding AES-SIV to the HKDF AEAD registry. If we advanced
> that
> draft we'd have the permanent and readily available specification that is
> required. Can we do that? Then all we'd need is the designated expert
> to review and approve.
>
>   I guess alternatively we could point to RFC 5297 as the permanent and
> readily available specification. Then all we'd need is a designated expert.
> Still, I'd like to see if there's support to advance my draft.
>
>   regards,
>
>   Dan.
>
> On 3/31/22 4:50 AM, Neil Madden wrote:
>
>
>
> On 31 Mar 2022, at 11:34, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
>
>
> On Wed, Mar 30, 2022 at 04:15:44PM -0400, Russ Housley wrote:
>
> Martin:
>
>
> On Tue, Mar 29, 2022, at 20:05, John Mattsson wrote:
>
> Would it make sense to standardize AES-KWP for HPKE or do CFRG believe
> that AES-SIV is the future of key wrapping? Irrespectively I think the
> CFRF should produce a good recommendation on how to use HPKE for key
> wrapping.
>
>
> What is wrong with the existing HPKE cipher suites for protecting
> keying materials?  That is, aside from not carrying a NIST
> approval stamp.
>
>
> If you try to apply HPKE to the COSE or JOSE structures, it just does
> not quite fit.  However, by using HPKE to deliver a key-encryption key
> (KEK) to the recipient, the structures fit.  So, it would be really
> nice to use a Key-Wrap algorithm in HPKE to encrypt the KEK.
>
>
> Not sure about JOSE, but in COSE, the structures do fit even for direct
> encryption. COSE-HPKE does not use receipients itself, so it can go into
> cose_encrypt0, resulting in direct encryption.
>
>
>
> I’m not sure if this point is directly related to what is being proposed
> here, but I think it is worth mentioning:
>
>
>
> JOSE and COSE allow sending the same message to multiple recipients using
> key-wrapping. In the case of an authenticated KEM (AKEM), this usage
> undermines the authenticity guarantees due to the lack of Insider-Auth
> security (as per section 5.4 of https://eprint.iacr.org/2020/1499.pdf) in
> HPKE AKEM. In short, any recipient of the original message can simply take
> the unwrapped content encryption key and use it to produce a new message
> that appears to come from the original sender.
>
>
>
> This is why
> https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04 requires
> a compactly-committing AEAD for symmetric content encryption (DEM) and
> includes the AEAD tag in the KEM KDF computation to ensure the KEM
> encapsulation for each recipient is bound to the whole message. This
> current design was arrived at after previous discussion on the CFRG list (
> https://mailarchive.ietf.org/arch/msg/cfrg/iNoSj9g2cQ0JvDbHs4I70bfhrRc/)
> and some offline discussions.
>
>
>
> (An alternative approach is to include the AEAD tag in associated data of
> the key-wrapping process, which is another advantage of SIV-AES over AES-KW
> - the latter not supporting associated data).
>
>
>
> Kind regards,
>
>
>
> Neil
>
>
>
> _______________________________________________
>
> CFRG mailing list
>
> CFRG@irtf.org
>
> https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> --
>
> "The object of life is not to be on the side of the majority, but to
>
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>