Re: [CFRG] HPKE and Key Wrapping

[Dan Harkins <[e-mail]>]

   Hi John,

On 3/30/22 1:51 AM, John Mattsson wrote:
>
> 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.
>

   Well one difference is that AES-SIV can take a nonce (probabilistic 
mode) or
not (deterministic mode). If no nonce is provided you get DAE security as
described in the Rogaway and Shrimpton paper. If a nonce is provided you can
get semantic security provided it is never used twice. It does provide 
misuse
protection, though, in the event it is. With AES-GCM-SIV, you have to pass a
nonce, it doesn't have a deterministic mode, and it provides the same 
guarantees
under the same nonce use/misuse as AES-SIV.

   Another difference is the key. AES-SIV uses a "doublewide" key (for 
AES with
a 128 bit key you pass AES-SIV a 256-bit key, AES with 256 uses a 512 
bit key)
while AES-GCM-SIV uses just a single "normal" sized key. Some people seem to
think this is a problem with AES-SIV but KDFs can churn out keys of any 
length
and a call to get a 256-bit key is as easy as a call to get a 512-bit key.

   Both of them are two pass modes (in order to achieve misuse 
resistance) but
AES-GCM-SIV is probably faster than AES-SIV due to the fact that it uses a
polynomial authenticator that can take advantage of the hardware support for
carryless multiply while AES-SIV uses CMAC which is considerably slower. But
that advantage would really only be seen on the wire and that is not the
use case here. This is userland/key exchange, not kernel-level packet
encryption.

   Yes, my draft does not discuss passing a nonce to AES-SIV in HPKE but it
would be possible to do such a thing because AES-SIV takes a vector of 
AAD and
the nonce can be one component of that vector-- AES-SIV doesn't require a
distinct input for a nonce. Since I'm trying to deal with using HPKE in 
lossy
networks, I don't really want to have to deal with a nonce unless I have to
and if I do, then I really need to export the sequence number (as indicated
in my draft) and in that case the need for a DAE cipher is not really there
and I might as well just use AES-GCM in that case.

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

   The "single shot" HPKE call would not require a random nonce. It will 
just use
the base nonce that gets generated as part of the HPKE key schedule 
(since the
first and only shot will XOR a sequence number of zero onto that base 
nonce).
So a trusted RNG is needed, yes, but that's necessary to achieve the 
security
guarantees of HPKE in the first place (see section 9.7.5 of RFC 9180), 
there are
no additional requirements placed on a RNG to do "single shot" key wrapping.

   That said, yes I agree: a nonce-less and misuse-resistant mode would 
be better.
A DAE mode can achieve semantic security when the plaintext carries a 
(random)
key-- the exact use case here-- so the principal complaint of DAE goes 
away.

   regards,

   Dan.

> 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]
>
>     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

-- 
"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