Subject: [jose] #55: Mandatory entropy in ECC KDF inputs

From: "jose issue tracker" <[email-masked]>
Date: Sun, 11 Aug 2013 22:56:08 -0000

#55: Mandatory entropy in ECC KDF inputs

 At the interim, there was agreement to require at least 512 bits of
 entropy in the "apu" field, in order to ensure sufficient entropy in the
 resulting key.  That requirement has been lost in a subsequent revision.

-- 
-------------------------+-------------------------------------------------
 Reporter:  [email-masked]   |      Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [email-masked]
 Priority:  major        |     Status:  new
Component:  json-web-    |  Milestone:
  algorithms             |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/55>
jose <http://tools.ietf.org/jose/>

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 12 Aug 2013 12:00:17 +1000

Why do we need 512 bits of extra entropy when deriving, say, a 128-bit key?

How does that match with the NIST spec for this field? Below is the NIST definition for PartyUInfo, which JOSE calls "apu".
Perhaps the 512 bits of entropy are the nonce mentioned by the NIST text, though it only requires the nonce for a static-static scheme, not for an ephemeral-static scheme as used in JOSE.

[NIST SP 56A; revision 2, May 2013; section 5.8.1.2 OtherInfo; page 48]
PartyUInfo: A required non-null subfield containing public information about party U. At a minimum, PartyUInfo shall include ID_U, an identifier for party U, as a distinct item of information. This subfield could also include information about the public key(s) contributed to the key-agreement transaction by party U. The nonce provided by party U as required in a C(0e, 2s) scheme (see Section 6.3) shall be included in this subfield.

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> jose issue tracker
> Sent: Monday, 12 August 2013 8:56 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [jose] #55: Mandatory entropy in ECC KDF inputs
> 
> entropy in the "apu" field, in order to ensure sufficient entropy in
> the  resulting key.  That requirement has been lost in a subsequent
> revision.
> 
> --
> -------------------------+---------------------------------------------
> -
> -------------------------+---
> -------------------------+---------------------------------------------
> -
> -------------------------+---
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: <[email-masked]>
Date: Mon, 12 Aug 2013 09:40:50 +0200

I think that the ephemeral key is enough entropy. It is randomly generated, right?

-Axel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Monday, August 12, 2013 4:00 AM
To: <[email-masked]>; Richard Barnes
Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs

--
James Manger

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of jose issue tracker
> -------------------------+--------------------------------------------
> -------------------------+-
> -
> -------------------------+--------------------------------------------
> -------------------------+-
> -

---

From: Richard Barnes <[email-masked]>
Date: Mon, 12 Aug 2013 09:15:26 -0400

Axel: As I recall, the feeling was that there might be key re-use, e.g.,
within a multiple-recipient object.  So you need the nonce to ensure that
the key is different for each recipient.

James: The choice of 512 bits was just to be conservative and simple.
 Otherwise you would have to explain that there has to be at least as much
entropy as the key, etc.  A 512-bit nonce is long enough for pretty much
any use for at least the near future, so implementors can just use that
length.

This should be in the interim minutes, I'm just adding back what got
dropped in a subsequent revision :)

On Mon, Aug 12, 2013 at 3:40 AM, <[email-masked]> wrote:

> Manger, James H
> How does that match with the NIST spec for this field? Below is the NIST
> definition for PartyUInfo, which JOSE calls "apu".
> Perhaps the 512 bits of entropy are the nonce mentioned by the NIST text,
> though it only requires the nonce for a static-static scheme, not for an
> ephemeral-static scheme as used in JOSE.
>
>
> PartyUInfo: A required non-null subfield containing public information
> about party U. At a minimum, PartyUInfo shall include ID_U, an identifier
> for party U, as a distinct item of information. This subfield could also
> include information about the public key(s) contributed to the
> key-agreement transaction by party U. The nonce provided by party U as
> required in a C(0e, 2s) scheme (see Section 6.3) shall be included in this
> subfield.
>
>
> --
> James Manger
>

---

From: <[email-masked]>
Date: Mon, 12 Aug 2013 16:50:06 +0200

Which interim minutes?
http://www.ietf.org/proceedings/87/minutes/minutes-87-jose
http://www.ietf.org/proceedings/interim/2013/06/17/jose/minutes/minutes-interim-2013-jose-2

Both minutes do not contain the words entr* or eph*

I think we should not force applications that do it right (that do not reuse ephemeral keys) to include the extra entropy. I agree we should not build traps for application programmers but this is more a library issue and not a spec issue.

Axel

From: Richard Barnes [mailto:[email-masked]]
Sent: Monday, August 12, 2013 3:15 PM
To: Nennker, Axel
Cc: James Manger; [email-masked]
Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs

Axel: As I recall, the feeling was that there might be key re-use, e.g., within a multiple-recipient object.  So you need the nonce to ensure that the key is different for each recipient.

James: The choice of 512 bits was just to be conservative and simple.  Otherwise you would have to explain that there has to be at least as much entropy as the key, etc.  A 512-bit nonce is long enough for pretty much any use for at least the near future, so implementors can just use that length.

This should be in the interim minutes, I'm just adding back what got dropped in a subsequent revision :)

On Mon, Aug 12, 2013 at 3:40 AM, <[email-masked]<mailto:[email-masked]>> wrote:
I think that the ephemeral key is enough entropy. It is randomly generated, right?

-Axel

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Manger, James H
Sent: Monday, August 12, 2013 4:00 AM
To: <[email-masked]<mailto:[email-masked]>>; Richard Barnes
Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs

--
James Manger

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of jose issue tracker
> To: [email-masked]<mailto:[email-masked]>; [email-masked]
> Cc: [email-masked]<mailto:[email-masked]>
>      Type:  defect       |  [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose