[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [CFRG] HPKE and Key Wrapping
From: Dan Harkins <dharkins () lounge ! org>
Date: 2022-05-31 23:43:51
Message-ID: 4d389c70-ce13-c465-1db4-5a8c221fba20 () lounge ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
> <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
>
--
"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
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 5/31/22 10:15 AM, Shay Gueron wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHP81y9rkZ+swjR4DiTji786YtCCBt5Z1edY9LAJTmnZonisZA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif">The thread was
brought to my attention. </div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">I am not sure what
other schemes were compared to AES-SIV, in a way that the
latter had advantage over them. <br>
</div>
</div>
</div>
</blockquote>
<font face="monospace"> <br>
It was compared to AES-KW: RFC 3394 and RFC 5649. The advantage
of AES-SIV over AES-KW<br>
is efficiency, provable security, accepting associated data, and
allowing for natural<br>
inputs instead of cramming everything into fixed-sized blocks. <br>
<br>
</font>
<blockquote type="cite"
cite="mid:CAHP81y9rkZ+swjR4DiTji786YtCCBt5Z1edY9LAJTmnZonisZA@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif">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). <br>
</div>
</div>
</div>
</blockquote>
<font face="monospace"> <br>
Yes it can. But AES-GCM-SIV MUST always be passed a nonce which
is why it's not really<br>
thought of as a key wrapping scheme. Key wrapping schemes are
deterministic and the<br>
security of the scheme is in the assumption that the data being
wrapped-- the secret<br>
key-- provides the probabilistic contribution so no nonce is
needed, not even a<br>
misuse-resistant one. <br>
<br>
AES-GCM-SIV is more of a bulk data encryption scheme that
provides MRAE (compared to<br>
AES-GCM) than it is a key wrapping scheme. <br>
<br>
I think adding AES-GCM-SIV to HPKE is a good idea too, it's just
not really addressing<br>
the keywrap use case, IMHO, while AES-SIV is. <br>
<br>
</font>
<blockquote type="cite"
cite="mid:CAHP81y9rkZ+swjR4DiTji786YtCCBt5Z1edY9LAJTmnZonisZA@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif">I think Uri had
commented about the key wrapping performance. <br>
</div>
</div>
</div>
</blockquote>
<font face="monospace"> <br>
Yes, AES-GCM-SIV can take advantage of the carryless multiply
instruction that is<br>
used in many popular microprocessors. AES-SIV uses CMAC which is
much less efficient.<br>
Both require two passes over the data (for MRAE purposes) though.
<br>
<br>
Uri's other complaint about AES-SIV is that it takes a
"doublewide" key. He seems to<br>
think that's a big drawback. The way I look at it, HKDF can
generate 512-bits as easily<br>
as it can generate 256-bits, I just pass a different value for L,
the crank gets turned<br>
and I take the single bitstring as the key for my cipher. The fact
that it's doublewide<br>
is not really an issue-- I ask for "keylength" bits and I pass the
result to the cipher<br>
along with my plaintext. But different strokes for different
folks, this is an issue<br>
that has been brought up with AES-SIV. <br>
<br>
regards,<br>
<br>
Dan.<br>
<br>
</font>
<blockquote type="cite"
cite="mid:CAHP81y9rkZ+swjR4DiTji786YtCCBt5Z1edY9LAJTmnZonisZA@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif">Regards, Shay</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, May 31, 2022 at 7:51
PM Blumenthal, Uri - 0553 - MITLL <<a
href="mailto:uri@ll.mit.edu" moz-do-not-send="true"
class="moz-txt-link-freetext">uri@ll.mit.edu</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" lang="EN-US">
<div class="gmail-m_8023696731188376338WordSection1">
<p class="MsoNormal"><span style="font-size:12pt">I
support advancement of this draft, as I think that
standardizing a SIV mode is necessary for
cryptographic protocols.</span></p>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
<p class="MsoNormal"><span style="font-size:12pt">Having
said that, I prefer the way AES-GCM-SIV deals with
keys to what you’re doing, but that’s secondary.</span></p>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
<p class="MsoNormal"><span style="font-size:12pt">Thanks!</span></p>
<div>
<div>
<p class="MsoNormal"><span style="color:black">--</span></p>
<p class="MsoNormal"><span style="color:black">V/R,</span></p>
<p class="MsoNormal"><span style="color:black">Uri</span></p>
<p class="MsoNormal" style="margin-left:0.5in"><i> </i></p>
<p class="MsoNormal"><i><span style="color:black">There
are two ways to design a system. One is to
make it so simple there are obviously no
deficiencies.</span></i><span
style="font-size:12pt;color:black"></span></p>
<p class="MsoNormal"><i><span style="color:black">The
other is to make it so complex there are no
obvious deficiencies.</span></i><span
style="font-size:12pt;color:black"></span></p>
<p class="MsoNormal"><i><span style="color:black">
\
- C. A. R. Hoare</span></i><span
style="font-size:12pt;color:black"></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
<div
style="border-right:none;border-bottom:none;border-left:none;border-top:1pt
solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-left:0.5in"><b><span
style="font-size:12pt;color:black">From: </span></b><span
style="font-size:12pt;color:black">CFRG <<a
href="mailto:cfrg-bounces@irtf.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">cfrg-bounces@irtf.org</a>>
on behalf of Dan Harkins <<a
href="mailto:dharkins@lounge.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">dharkins@lounge.org</a>><br>
<b>Date: </b>Tuesday, May 31, 2022 at 12:43<br>
<b>To: </b>CFRG <<a
href="mailto:cfrg@irtf.org" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">cfrg@irtf.org</a>><br>
<b>Subject: </b>Re: [CFRG] HPKE and Key Wrapping</span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<p class="MsoNormal"
style="margin-right:0in;margin-bottom:12pt;margin-left:0.5in"><br>
<span style="font-family:"Courier New"">
Hi,<br>
<br>
I'd like to resurrect this thread. There seemed to
be some support for<br>
adding an MRAE cipher to HPKE for key wrapping and
also some support for<br>
AES-SIV being the cipher to add do to its advantages
over other key wrapping<br>
schemes-- it accepts any length input without
required padding out to some<br>
particular block size, and it accepts associated
data. <br>
<br>
At the last IETF I asked for a consensus call on
draft-harkins-cfrg-dnhpke,<br>
which proposes adding AES-SIV to the HKDF AEAD
registry. If we advanced that<br>
draft we'd have the permanent and readily available
specification that is<br>
required. Can we do that? Then all we'd need is the
designated expert<br>
to review and approve.<br>
<br>
I guess alternatively we could point to RFC 5297
as the permanent and<br>
readily available specification. Then all we'd need
is a designated expert.<br>
Still, I'd like to see if there's support to advance
my draft.<br>
<br>
regards,<br>
<br>
Dan.</span></p>
<div>
<p class="MsoNormal" style="margin-left:0.5in">On
3/31/22 4:50 AM, Neil Madden wrote:</p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal" style="margin-left:0.5in"> </p>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal" style="margin-left:0.5in">On
31 Mar 2022, at 11:34, Ilari Liusvaara <<a
href="mailto:ilariliusvaara@welho.com"
target="_blank" moz-do-not-send="true"
\
class="moz-txt-link-freetext">ilariliusvaara@welho.com</a>> wrote:</p>
</div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><span
style="font-size:8.5pt;font-family:FiraMono-Regular,serif">On Wed, Mar
30, 2022 at 04:15:44PM -0400, Russ Housley
wrote:<br
\
style="font-variant-caps:normal;text-align:start;word-spacing:0px"> <br>
</span></p>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal" style="margin-left:0.5in"><span
style="font-size:8.5pt;font-family:FiraMono-Regular,serif">Martin:<br>
<br>
</span></p>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal"
style="margin-left:0.5in"><span
\
style="font-size:8.5pt;font-family:FiraMono-Regular,serif"><br> On Tue, Mar 29, \
2022, at 20:05, John Mattsson wrote:<br>
<br>
</span></p>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal"
style="margin-left:0.5in"><span
\
style="font-size:8.5pt;font-family:FiraMono-Regular,serif">Would it make sense to \
standardize AES-KWP for HPKE or do CFRG believe<span
\
class="gmail-m_8023696731188376338apple-converted-space"> </span><br> that AES-SIV \
is the future of key
wrapping? Irrespectively I think the<span
class="gmail-m_8023696731188376338apple-converted-space"> </span><br>
CFRF should produce a good
recommendation on how to use HPKE for
key<span
\
class="gmail-m_8023696731188376338apple-converted-space"> </span><br> \
wrapping.</span></p> </blockquote>
<p class="MsoNormal"
style="margin-left:0.5in"><span
\
style="font-size:8.5pt;font-family:FiraMono-Regular,serif"><br> What is wrong with \
the existing HPKE cipher suites for protecting<br>
keying materials? That is, aside from
not carrying a NIST<br>
approval stamp.</span></p>
</blockquote>
<p class="MsoNormal" style="margin-left:0.5in"><span
style="font-size:8.5pt;font-family:FiraMono-Regular,serif"><br>
If you try to apply HPKE to the COSE or
JOSE structures, it just does<br>
not quite fit. However, by using HPKE to
deliver a key-encryption key<br>
(KEK) to the recipient, the structures
fit. So, it would be really<br>
nice to use a Key-Wrap algorithm in HPKE
to encrypt the KEK.</span></p>
</blockquote>
<p class="MsoNormal" style="margin-left:0.5in"><span
style="font-size:8.5pt;font-family:FiraMono-Regular,serif"><br>
Not sure about JOSE, but in COSE, the
structures do fit even for direct<br>
encryption. COSE-HPKE does not use
receipients itself, so it can go into<br>
cose_encrypt0, resulting in direct
encryption.</span></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">I’m
not sure if this point is directly related to what
is being proposed here, but I think it is worth
mentioning:</p>
</div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
<div>
<p class="MsoNormal" style="margin-left:0.5in">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 <a href="https://eprint.iacr.org/2020/1499.pdf"
target="_blank" moz-do-not-send="true"
\
class="moz-txt-link-freetext">https://eprint.iacr.org/2020/1499.pdf</a>) 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.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">This
is why <a
href="https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04"
target="_blank" moz-do-not-send="true"
\
class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04</a> \
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 (<a
href="https://mailarchive.ietf.org/arch/msg/cfrg/iNoSj9g2cQ0JvDbHs4I70bfhrRc/"
target="_blank" moz-do-not-send="true"
\
class="moz-txt-link-freetext">https://mailarchive.ietf.org/arch/msg/cfrg/iNoSj9g2cQ0JvDbHs4I70bfhrRc/</a>)
and some offline discussions.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">(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).</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Kind
regards,</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Neil</p>
</div>
<p class="MsoNormal" style="margin-left:0.5in"><br>
<br>
</p>
<pre \
style="margin-left:0.5in">_______________________________________________</pre> <pre \
style="margin-left:0.5in">CFRG mailing list</pre> <pre style="margin-left:0.5in"><a \
href="mailto:CFRG@irtf.org" target="_blank" moz-do-not-send="true" \
class="moz-txt-link-freetext">CFRG@irtf.org</a></pre> <pre \
style="margin-left:0.5in"><a href="https://www.irtf.org/mailman/listinfo/cfrg" \
target="_blank" moz-do-not-send="true" \
class="moz-txt-link-freetext">https://www.irtf.org/mailman/listinfo/cfrg</a></pre> \
</blockquote> <p class="MsoNormal" style="margin-left:0.5in"><br>
<br>
</p>
<pre style="margin-left:0.5in">-- </pre>
<pre style="margin-left:0.5in">"The object of life is not to be on \
the side of the majority, but to</pre>
<pre style="margin-left:0.5in">escape finding oneself in the ranks of \
the insane." -- Marcus Aurelius</pre> </div>
</div>
_______________________________________________<br>
CFRG mailing list<br>
<a href="mailto:CFRG@irtf.org" target="_blank"
moz-do-not-send="true" \
class="moz-txt-link-freetext">CFRG@irtf.org</a><br> <a \
href="https://www.irtf.org/mailman/listinfo/cfrg" rel="noreferrer" target="_blank" \
moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.irtf.org/mailman/listinfo/cfrg</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
"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</pre>
</body>
</html>
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic