Re: [CFRG] HPKE and Key Wrapping

[Dan Harkins <[e-mail]>]

On 5/31/22 10:15 AM, Shay Gueron wrote:
> 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.

   It was compared to AES-KW: RFC 3394 and RFC 5649. The advantage of 
AES-SIV over AES-KW
is efficiency, provable security, accepting associated data, and 
allowing for natural
inputs instead of cramming everything into fixed-sized blocks.

> 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).

   Yes it can. But AES-GCM-SIV MUST always be passed a nonce which is 
why it's not really
thought of as a key wrapping scheme. Key wrapping schemes are 
deterministic and the
security of  the scheme is in the assumption that the data being 
wrapped-- the secret
key-- provides the probabilistic contribution so no nonce is needed, not 
even a
misuse-resistant one.

   AES-GCM-SIV is more of a bulk data encryption scheme that provides 
MRAE (compared to
AES-GCM) than it is a key wrapping scheme.

   I think adding AES-GCM-SIV to HPKE is a good idea too, it's just not 
really addressing
the keywrap use case, IMHO, while AES-SIV is.

> I think Uri had commented about the key wrapping performance.

   Yes, AES-GCM-SIV can take advantage of the carryless multiply 
instruction that is
used in many popular microprocessors. AES-SIV uses CMAC which is much 
less efficient.
Both require two passes over the data (for MRAE purposes) though.

   Uri's other complaint about AES-SIV is that it takes a "doublewide" 
key. He seems to
think that's a big drawback. The way I look at it, HKDF can generate 
512-bits as easily
as it can generate 256-bits, I just pass a different value for L, the 
crank gets turned
and I take the single bitstring as the key for my cipher. The fact that 
it's doublewide
is not really an issue-- I ask for "keylength" bits and I pass the 
result to the cipher
along with my plaintext. But different strokes for different folks, this 
is an issue
that has been brought up with AES-SIV.

   regards,

   Dan.

> Regards, Shay
>
> On Tue, May 31, 2022 at 7:51 PM Blumenthal, Uri - 0553 - MITLL 
> <[e-mail]> 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 <[e-mail]> on behalf of Dan Harkins
>     <[e-mail]>
>     *Date: *Tuesday, May 31, 2022 at 12:43
>     *To: *CFRG <[e-mail]>
>     *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
>             <[e-mail]> 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
>
>         [e-mail]
>
>         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
>     [e-mail]
>     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