Subject: [CFRG] HPKE and Key Wrapping

From: John Mattsson <[email-masked]>
Date: Tue, 29 Mar 2022 09:05:30 +0000

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://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

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Mar 2022 10:00:02 -0400

Indeed.  This is exactly the use that is moving forward in draft-ietf-cose-hpke, and CFRG review would be greatly appreciated.

Russ

> On Mar 29, 2022, at 5:05 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Hi,
>  
> https://datatracker.ietf.org/doc/html/draft-harkins-cfrg-dnhpke-01 <https://datatracker.ietf.org/doc/html/draft-harkins-cfrg-dnhpke-01>
>  
> https://datatracker.ietf.org/doc/html/rfc3394 <https://datatracker.ietf.org/doc/html/rfc3394>
> https://datatracker.ietf.org/doc/html/rfc5649 <https://datatracker.ietf.org/doc/html/rfc5649>
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf>
>  
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf>
> https://cloud.google.com/kms/docs/key-wrapping <https://cloud.google.com/kms/docs/key-wrapping>
> https://microsoft.github.io/CCF/release/1.x/js/ccf-app/interfaces/global.rsaoaepaeskwpparams.html <https://microsoft.github.io/CCF/release/1.x/js/ccf-app/interfaces/global.rsaoaepaeskwpparams.html>
>  
> _______________________________________________
> CFRG mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>

---

From: Dan Harkins <[email-masked]>
Date: Tue, 29 Mar 2022 08:29:03 -0700

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:
> AES-SIV could be used for this, but the algorithms currently approved 
> by NIST for key wrapping are AES-KW and AES-KWP.
>
> 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).
>
> 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
>
>
> [email-masked]
> 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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 30 Mar 2022 11:31:39 +1100

> CFRF should produce a good recommendation on how to use HPKE for key 

What is wrong with the existing HPKE cipher suites for protecting keying materials?  That is, aside from not carrying a NIST approval stamp.

---

From: John Mattsson <[email-masked]>
Date: Wed, 30 Mar 2022 08:51:44 +0000

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 <[email-masked]>
Date: Tuesday, 29 March 2022 at 17:29
To: John Mattsson <[email-masked]>, IRTF CFRG <[email-masked]>
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.

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

Cheers,
John

CFRG mailing list

[email-masked]<mailto:[email-masked]>

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>

--

---

From: John Mattsson <[email-masked]>
Date: Wed, 30 Mar 2022 09:15:18 +0000

Hi Martin,

>What is wrong with the existing HPKE cipher suites for protecting keying materials?  That >is, aside from not carrying a NIST approval stamp.

See my mail to Dan
https://mailarchive.ietf.org/arch/msg/cfrg/ID0JuUDIg7np4CxMZLq-7Zuaj40/

Key wrapping mechanisms has in the past tried to provide security even in the case of compromised RNG and state. To keep that attack model, I think HPKE would need to be augmented with something like AES-KWP, AES-SIV, or AES-GCM-SIV.

I would personally chose the algorithm with the best properties over NIST approval stamp (HPKE is not NIST approved either). I think it makes sense for CFRG to add AES-SIV and/or AES-GCM-SIV to HPKE.

Cheers,
John

From: CFRG <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Date: Wednesday, 30 March 2022 at 02:32
To: [email-masked] <[email-masked]>
Subject: Re: [CFRG] HPKE and Key Wrapping

_______________________________________________
CFRG mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-40f7d10cf9eb7c69&q=1&e=c95f3aec-4703-4832-9b62-2c7a79363887&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg

---

From: Taylor R Campbell <[email-masked]>
Date: Wed, 30 Mar 2022 10:27:24 +0000

> Date: Wed, 30 Mar 2022 08:51:44 +0000
> From: John Mattsson <john.mattsson=[email-masked]>
> 
> 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?

There is a fairly substantial difference.  In the Daence paper I drew
a table of advantage bounds for AES-SIV and AES-GCM-SIV, using the
best formulae I could find (with the function/permutation-switching
lemma of https://cr.yp.to/papers.html#permutations that gives better
bounds than the conventional q*(q - 1)/2 used in most papers):

https://eprint.iacr.org/2020/067.pdf#page=5

Smaller advantage bounds, i.e., larger values of n in the 2^-n terms,
are better.  1 means no advantage bound has been proven at all for
these parameters.

This table was computed using the logic at

https://github.com/riastradh/daence/blob/master/adv.py

which cites the sources in the literature I used for the formulae.
You can reuse the same logic to recompute bounds for different message
sizes/numbers if what you're looking for isn't in the table, of
course.

It may be worth noting that the security advertisment in RFC 8452 for
AES-GCM-SIV explicitly discourages nonce reuse even between different
users (different keys), which means you should even avoid the policy
of sequential message numbers that, e.g., TLS 1.3 uses with AES-GCM to
rule out a class of attacks:

https://datatracker.ietf.org/doc/html/rfc8452#page-12

The bottom line is that AES-GCM-SIV is designed for randomized nonces,
with some level of protection if your RNG fails.  In contrast, AES-SIV
is designed for security without nonces at all, and is particularly
well-suited to key-wrap, which should come as no surprise since that's
what it was designed for originally, as sung in Appendix F of:

https://web.cs.ucdavis.edu/~rogaway/papers/keywrap.html

---

From: John Mattsson <[email-masked]>
Date: Wed, 30 Mar 2022 11:46:10 +0000

Thanks Taylor!

Then it seems to me that AES-256-SIV and AES-512-SIV are the AES-based modes that should be added to HPKE to enable key wrapping security independent of the RNG. These are exactly the two AEADs suggested by draft-harkins-cfrg-dnhpke-01. Key wrapping mechanisms have in the past aimed to provide security even in the case of compromised RNG but it would be interesting to hear if someone think that property is needed in this case.

Cheers,
John

From: Taylor R Campbell <[email-masked]> on behalf of Taylor R Campbell <[email-masked]>
Date: Wednesday, 30 March 2022 at 12:29
To: John Mattsson <[email-masked]>
Cc: Dan Harkins <[email-masked]>, IRTF CFRG <[email-masked]>
Subject: Re: [CFRG] HPKE and Key Wrapping

lemma of https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a129ecc550c2c3ad&q=1&e=117ce771-01cf-4d9c-aa89-a8b4b42eab86&u=https%3A%2F%2Fcr.yp.to%2Fpapers.html%23permutations that gives better

https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-fc96309953b1fcfb&q=1&e=117ce771-01cf-4d9c-aa89-a8b4b42eab86&u=https%3A%2F%2Feprint.iacr.org%2F2020%2F067.pdf%23page%3D5

https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-ab6fc8eec24511fa&q=1&e=117ce771-01cf-4d9c-aa89-a8b4b42eab86&u=https%3A%2F%2Fgithub.com%2Friastradh%2Fdaence%2Fblob%2Fmaster%2Fadv.py

---

From: Christopher Wood <[email-masked]>
Date: Wed, 30 Mar 2022 08:16:58 -0700

Apologies if I’m misunderstanding something here, but this threat model seems somewhat convoluted. In particular, it assumes an adversary that controls the RNG, and therefore key schedule state as well. The AEAD key and nonce are both derived from this state. However, the DAE security model from [1] assumes the attacker controls the message header and message itself, but not the key. (For MRAE, it assumes the attacker also controls the nonce/IV.) So it’s not clear to me why SIV or similar modes would offer meaningful improvements over the existing HPKE AEADs under the assumption that the attacker controls the nonce and key. Can someone help clarify what I’m missing?

Thanks,
Chris

[1] https://web.cs.ucdavis.edu/~rogaway/papers/keywrap.html

> On Mar 30, 2022, at 4:46 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Thanks Taylor!
>

---

From: John Mattsson <[email-masked]>
Date: Wed, 30 Mar 2022 17:53:12 +0000

Hi Chris,

I think the model in [1] does not map directly to HPKE as [1] discusses a deterministic one-layer symmetric key wrap method and HPKE is a randomized two-layer asymmetric key wrap method. As stated in [1] "So key-wrap’s raison d’ˆetre is to remove AE’s reliance on a nonce or random bits" and by NIST [2] "consideration of additional circumstances (e.g., resilience to operator error, low-quality random number generators)". My high-level summary of the key wrap attack model would be that the attacker can control all inputs but that the attacker does not know the outer secret key used in the key wrap.

- The input to AES-SIV used for key wrap would be:

ct = SIV-ENCRYPT(key, aad, pt)
pt = SIV-DECRYPT(key, aad, ct)

where pt is the key to be wrapped. Nonce and random bits are not even taken as input. This construction is secure under the assumption that the attacker does not know “key”.

- The input to RSAES-OAEP + AES-KWP [3] is

ct = RSAES-OAEP+AES-KWP-encrypt(pkR, random bits, pt)
pt = RSAES-OAEP+AES-KWP-dencrypt(skR, ct)

where “random bits” are used to generate the mask. My understanding is that this construction is secure under the assumption that the attacker does not know skR.

- The input to single-shot HPKE used for key wrap would be

ct = HPKE-single-shot-encrypt(pkR, random bits, aad, pt)
pt = HPKE-single-shot-decrypt(skR, aad, ct)

where “random bits” are used in GenerateKeyPair(). With AES-GCM this is not secure at all under the assumption that the attacker controls “random bits”. With AES-SIV I think the construction is secure under the same assumption.

Unless necessary, I would be very hesitant to move to a key wrap mechanism that relies heavily on the trust in the random number generator. Using AES-GCM might be ok for key transport in some circumstances, but I would like to also see a HPKE key wrap mode that removes the reliance on “random bits”.

Cheers,
John

[1] https://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf
[2] https://en.wikipedia.org/wiki/Key_wrap
[3] https://cloud.google.com/kms/docs/key-wrapping

From: Christopher Wood <[email-masked]>
Date: Wednesday, 30 March 2022 at 17:18
To: John Mattsson <[email-masked]>
Cc: Taylor R Campbell <[email-masked]>, IRTF CFRG <[email-masked]>
Subject: Re: [CFRG] HPKE and Key Wrapping
Apologies if I’m misunderstanding something here, but this threat model seems somewhat convoluted. In particular, it assumes an adversary that controls the RNG, and therefore key schedule state as well. The AEAD key and nonce are both derived from this state. However, the DAE security model from [1] assumes the attacker controls the message header and message itself, but not the key. (For MRAE, it assumes the attacker also controls the nonce/IV.) So it’s not clear to me why SIV or similar modes would offer meaningful improvements over the existing HPKE AEADs under the assumption that the attacker controls the nonce and key. Can someone help clarify what I’m missing?

Thanks,
Chris

> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-40f7d10cf9eb7c69&q=1&e=4d15d9d4-caaf-4057-bff5-ccea9b384b51&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 30 Mar 2022 18:09:51 +0000

+1

AES-SIV may be better with nonce reuse than AES-GCM-SIV (based on Taylor’s analysis), but either one would be OK from cryptographic point of view.

I have to agree. It makes perfect sense to add AES-SIV and/or AES-GCM-SIV. (I could probably live with Deoxys-II-256 from CAESAR competition as well)

Unfortunately, NIST approval stamp on cipher modes seems to have lost its relevance. Note that despite multiple requests, NIST has yet to “approve” a nonce misuse-resistant mode – so far they’ve been saying “no” or “we’re thinking about it”.   <Sigh>

Thanks!

---

From: Richard Barnes <[email-masked]>
Date: Wed, 30 Mar 2022 15:43:48 -0400

This thread seems pretty confused.  For purposes of RNG resilience, it
doesn't matter if you use AES-SIV, AES-GCM, or GOST 28147-89 -- none of the
symmetric algorithms are fed by an RNG in HPKE.   The symmetric parameters
are all determined based on the KEM interaction.

So if you want HPKE to survive in a model where you assume the RNG is
compromised, you'll need a KEM that is OK in that model.  And given the
IND-CCA2 requirement and the API, it seems like Encap(pkR) is inevitably
going to rely on an RNG.

--RLB

On Wed, Mar 30, 2022 at 2:10 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> Key wrapping mechanisms has in the past tried to provide security even in
> the case of compromised RNG and state. To keep that attack model, I think
> HPKE would need to be augmented with something like AES-KWP, AES-SIV, or
> AES-GCM-SIV.
>
>
>
> +1
>
>
>
> AES-SIV may be better with nonce reuse than AES-GCM-SIV (based on Taylor’s
> analysis), but either one would be OK from cryptographic point of view.
>
>
>
> I would personally chose the algorithm with the best properties over NIST
> approval stamp (HPKE is not NIST approved either). I think it makes sense
> for CFRG to add AES-SIV and/or AES-GCM-SIV to HPKE.
>
>
>
> I have to agree. It makes perfect sense to add AES-SIV and/or AES-GCM-SIV.
> (I could probably live with Deoxys-II-256 from CAESAR competition as well)
>
>
>
> Unfortunately, NIST approval stamp on cipher modes seems to have lost its
> relevance. Note that despite multiple requests, NIST has yet to “approve” a
> nonce misuse-resistant mode – so far they’ve been saying “no” or “we’re
> thinking about it”.   <Sigh>
>
>
>
> Thanks!
>
>
>
> *From: *CFRG <[email-masked]> on behalf of Martin Thomson <
> [email-masked]>
> *Date: *Wednesday, 30 March 2022 at 02:32
> *To: [email-masked] <[email-masked]>
> *Subject: *Re: [CFRG] HPKE and 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.
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 30 Mar 2022 16:15:44 -0400

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

Russ

---

From: Dan Harkins <[email-masked]>
Date: Wed, 30 Mar 2022 13:42:00 -0700

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.

> 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 <[email-masked]>
> *Date: *Tuesday, 29 March 2022 at 17:29
> *To: *John Mattsson <[email-masked]>, IRTF CFRG 
> <[email-masked]>
>     AES-SIV could be used for this, but the algorithms currently
>     approved by NIST for key wrapping are AES-KW and AES-KWP.
>
>     <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>
>
>     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
>
>
>
>     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>
>
>
>
> --

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 31 Mar 2022 09:19:35 +1100

On Thu, Mar 31, 2022, at 07:15, Russ Housley wrote:
> 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.

I'm not following Russ.  HPKE operates on bytes, which both COSE and JOSE can produce.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 31 Mar 2022 09:23:14 +1100

On Thu, Mar 31, 2022, at 04:53, John Mattsson wrote:
> where “random bits” are used in GenerateKeyPair(). 

I agree that this would not be secure if the attacker was even able to cause the same randomness to be used twice.

HPKE has a PSK input too.  Are you forgetting that option?  Given the setting, that is the more relevant mode to consider.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 30 Mar 2022 23:11:18 +0000

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.

Yes. And you can compute the boundaries for your use case (whether you do or do not allow for nonce to repeat, how many times, etc.) for each mode.

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.

>From my point of view, it’s a deficiency of AES-SIV – because it means that instead of feeding the algorithm just one 256-bit key and letting it figure out the rest, I need to create another logical piece that would intake my 256-bit key and produce pseudo-“key schedule” – aka, AES-SIV input keys. An unnecessary complication (from my point of view).

  Both of them are two pass modes (in order to achieve misuse resistance) but

Respectfully disagree here. Speed matters, kernel or “userland”. In all of my use cases, at least – which do encrypt packets, but not “in the kernel”.

  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. 

We’re in agreement here.

  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. 

Again, yes.

Thanks

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Mar 2022 13:34:06 +0300

On Wed, Mar 30, 2022 at 04:15:44PM -0400, Russ Housley wrote:
> > What is wrong with the existing HPKE cipher suites for protecting
> > keying materials?  That is, aside from not carrying a NIST
> > approval stamp.
> 

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.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Mar 2022 13:41:32 +0300

On Thu, Mar 31, 2022 at 09:23:14AM +1100, Martin Thomson wrote:
> I agree that this would not be secure if the attacker was even able
> to cause the same randomness to be used twice.
> 
> HPKE has a PSK input too.  Are you forgetting that option?  Given
> the setting, that is the more relevant mode to consider.

Wouldn't that still result in key/nonce collision, which breaks any
current cipher HPKE can use, in case random bits get reused with the
same PSK and recipient key?

However, I expect that virtually invariably if random bits get reused,
those random bits are very weak anyway. Which would let attacker decrypt
the message anyway (unless PSK is also used).

-Ilari

---

From: John Mattsson <[email-masked]>
Date: Thu, 31 Mar 2022 11:23:19 +0000

>same PSK and recipient key?

I don’t know why a PSK would be relevant? My use case would be to use a public key to encrypt another key, in this case using ECIES/HPKE.

>the message anyway (unless PSK is also used).

That is a good point. The current HPKE will always be reliant on random bits. Using HPKE in way that is not dependant on random bits would require to make skX an input to the algorithm. I.e. doing Static-Static Diffie-Hellman (NIKE) instead of Ephemeral-Static, but where the recipient would not need to have pkX beforehand.

From: CFRG <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
Date: Thursday, 31 March 2022 at 12:42
To: [email-masked] <[email-masked]>
Subject: Re: [CFRG] HPKE and Key Wrapping

-Ilari

_______________________________________________
CFRG mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-40f7d10cf9eb7c69&q=1&e=971901ec-a598-4ea4-afd9-3b94ad573de0&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Mar 2022 14:42:30 +0300

On Thu, Mar 31, 2022 at 11:23:19AM +0000, John Mattsson wrote:
> I don’t know why a PSK would be relevant? My use case would be to
> use a public key to encrypt another key, in this case using
> ECIES/HPKE.

Oh, and then there are auth and authpsk modes too...

IIRC, the inputs that affect the symmetric encryption key and nonce
are:

- Randomness
- Recipient public key
- PSK (if present)
- Authentication key (if present)

If all these collide, then symmetric keys collide, and that makes all
the ciphers currently in HPKE break.

Fixing this would require adding a new MRAE cipher.

> That is a good point. The current HPKE will always be reliant on
> random bits. Using HPKE in way that is not dependant on random
> bits would require to make skX an input to the algorithm. I.e.
> doing Static-Static Diffie-Hellman (NIKE) instead of Ephemeral-Static,
> but where the recipient would not need to have pkX beforehand.

I think one would need MRAE cipher too, as otherwise the symmetric
encryption keys and nonces could get reused, which breaks current
ciphers.

-Ilari

---

From: Neil Madden <[email-masked]>
Date: Thu, 31 Mar 2022 12:50:18 +0100

> On 31 Mar 2022, at 11:34, Ilari Liusvaara <[email-masked]> wrote:
> 

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