Re: [CFRG] HPKE and Key Wrapping

[John Mattsson <[e-mail]>]

Thanks Dan,

AES-SIV seems preferable to AES-KWP for symmetric key wrapping, but I understand NISTs reluctance to change unless some weakness is found in KWP. I am fine with algorithms published in RFCs, but not algorithms published behind paywalls such as X9.102.

How does AES-SIV (RFC 5297) compare with AES-GCM-SIV (RFC 8452)? Do we need both algorithms in the future? Does AES-GCM-SIV with a fixed nonce provide the same properties as nonce-less AES-SIV or is there a difference? Your current draft only specifies a nonce-less AEAD, but I would not be surprised if somebody in the future wants to also add a nonce misuse-resistant AEAD to HPKE. Feels like it would be good with some CFRG discussion on this, so we add the right AEADs to HPKE. I don't have enough knowledge of these two SIV algorithms to have an opinion at this point in time.

>if you want to use HPKE for key wrapping you don't even need a key wrapping
>cipher mode, just do AES-GCM in the "one shot" HPKE variant. Wouldn't that work?

Stated goals for key wrapping has been to try to avoid external state and reliance on RNGs. Single-shot HPKE (with AES-GCM) seems similar to using AES-GCM with a random nonce for key wrap. The difference is which layer a trusted RNG is needed. When using single-shot HPKE (with AES-GCM), an RNG controlling attacker that has knowledge of one of the keys can compromise all other keys. I would be much more comfortable with using a nonce-less or nonce misuse-resistant mode like AES-KWP, AES-SIV, or AES-GCM-SIV when using HPKE for key wrapping.

Cheers,
John

From: Dan Harkins <[e-mail]>
Date: Tuesday, 29 March 2022 at 17:29
To: John Mattsson <[e-mail]>, IRTF CFRG <[e-mail]>
Subject: Re: [CFRG] HPKE and Key Wrapping

  Hi John,

  There is a very nice critique of AES-KW (which is also defined in the X9.102
draft as well as the RFCs you mention) in Appendix A of the Rogaway and Shrimpton
paper that defined SIV. To sum:

    "[O]ur conclusion is that none of the X9.102 algorithms are mature. Most
     severely, none has been proven secure—and, prior to this paper, there
     was not even a clear target for a security proof. Each scheme has multiple
     problems from among the following: a restricted message space; an inability
     to handle an associated header; a restricted header space; ciphertext
     lengths that grow with the header length (even though the header is only
     authenticated); a large number of blockcipher calls; mysterious aspects of
     the construction (eg, the byte-reversals or xoring-in counters); and use
     of cryptographic primitives beyond a blockcipher. For a modern encryption
     scheme one might reasonably hope for a formally defined and provably achieved
     security goal, an aesthetic construction coming out of an enunciated paradigm,
     message headers being supported and the message space and header space being
     large and natural sets, message expansion of some fixed value, one or two
     blockcipher calls per block, and further efficiency characteristics (like
     being able to cheaply handle static headers)."

It's also worth noting that AES-KW suffers from the same issue that was brought
up when I mentioned using AES-SIV in HPKE: it is stateless and deterministic and
therefore it is not really possible to achieve indistinguishability of ciphertexts
under an adaptive chosen ciphertext attack, which is what HPKE is supposed to
provide.

  You're right that AES-SIV is not approved by NIST. I discussed this with NIST
a decade ago and there is an effective catch-22 in which NIST doesn't want to
spend cycles analyzing and approving a cipher mode that is not specified in any
standards and standards bodies are loath to specify cipher modes that have not
been NIST approved. AES-SIV was formally submitted to NIST but no action has
been taken, yet I persist (in trying to get NIST to approve AES-SIV).

  So while I think that AES-SIV is an improvement over AES-KW for the purposes
of key wrapping (it's faster, and it's provably secure) if you want to use HPKE
for key wrapping you don't even need a key wrapping cipher mode, just do AES-GCM
in the "one shot" HPKE variant. Wouldn't that work?

  regards,

  Dan.
On 3/29/22 2:05 AM, John Mattsson wrote:
Hi,

Dan Harkins draft and presentation made me think about HPKE and key wrapping.
https://datatracker.ietf.org/doc/html/draft-harkins-cfrg-dnhpke-01

AES-SIV could be used for this, but the algorithms currently approved by NIST for key wrapping are AES-KW and AES-KWP.

https://datatracker.ietf.org/doc/html/rfc3394
https://datatracker.ietf.org/doc/html/rfc5649
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf

For asymmetric key wrapping. AES-KWP is often used with RSA-OAEP (which NIST calls KTS-OAEP: Key-Transport Using RSA-OAEP in SP 800-56Br2).

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf
https://cloud.google.com/kms/docs/key-wrapping<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-106ef86c5fe35cef&q=1&e=62784b61-59e7-42e7-a0f2-18e13e958a75&u=https%3A%2F%2Fcloud.google.com%2Fkms%2Fdocs%2Fkey-wrapping>
https://microsoft.github.io/CCF/release/1.x/js/ccf-app/interfaces/global.rsaoaepaeskwpparams.html

I think HPKE is the future of asymmetric encryption including asymmetric key wrapping.

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.

Cheers,
John



_______________________________________________

CFRG mailing list

[e-mail]<mailto:[e-mail]>

https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-40f7d10cf9eb7c69&q=1&e=62784b61-59e7-42e7-a0f2-18e13e958a75&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>



--

"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