Subject: [Cfrg] hpke which HKDF to use for eae_prk?

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2020 19:09:25 +0100

I also have a 2nd interop issue: when calculating
the eae_prk value my code uses the HKDF from the HPKE
ciphersuite. So if I'm using x25519,hkdf-sha512,aesgcm128
in the base mode, then my eae_prk value is 64 octets
long.

In contrast, the test vectors use the HKDF that is
associated with the KEM and so in the above case the
eae_prk value is only 32 octets.

I don't think there's a real security difference here,
in which case I'd argue that using the HPKE ciphersuite
is more natural and easily understood (IOW, I prefer my
code:-).

Either way, we should clarify this and maybe again also
include that intermediate value in the test vectors.

Cheers,
S.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Aug 2020 14:42:09 -0400

I think the spec is right here.  The DHKEM instances are defined with a
curve and a KEM, so assuming your descriptor "x25519,hkdf-sha512,aesgcm128"
is meant to be "KEM,KDF,AEAD", it's either incomplete or it represents a
DHKEM instance that isn't defined in the document.  In the schemes in the
document, the KDF in DHKEM is matched to the size of the curve, so x25519
goes with SHA-256.

The current test vectors wouldn't catch this misunderstanding, though, so
maybe it would be worth adding a case.

On Thu, Aug 20, 2020 at 2:10 PM Stephen Farrell <[email-masked]>
wrote:

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 20 Aug 2020 11:43:49 -0700

On Thu, Aug 20, 2020, at 11:42 AM, Richard Barnes wrote:
> curve and a KEM, so assuming your descriptor 
> "x25519,hkdf-sha512,aesgcm128" is meant to be "KEM,KDF,AEAD", it's 
> either incomplete or it represents a DHKEM instance that isn't defined 
> in the document.  In the schemes in the document, the KDF in DHKEM is 
> matched to the size of the curve, so x25519 goes with SHA-256.  
> 
> The current test vectors wouldn't catch this misunderstanding, though, 
> so maybe it would be worth adding a case.

+1 -- we can add one such variant to the set of test vectors.

Best,
Chris

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2020 19:53:31 +0100

> document, the KDF in DHKEM is matched to the size of the curve, so x25519

Could be. Lemme delve a bit more into the openssl APIs
to see if that's easily extracted or needs some new
config before I give up :-) That'll be tomorrow. That
said it still seems unnatural to have an IANA registry
for KDFs as part of the ciphersuite and yet use something
else at this point in the process.

> maybe it would be worth adding a case.

Probably worthwhile either way - including pretty much
every possible internal value in the test vectors would
be good I think.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Aug 2020 15:09:46 +0100

Hiya,

> else at this point in the process.

Just to close the loop: I fixed this on my end and
agree the spec was correct.

Cheers,
S.

PS: With that and the x-coord thing, I'm now able
to verify all the base mode test vectors that were
updated yesterday. Will move on to auth/psk/pskauth
in a bit.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 22 Aug 2020 00:57:35 +0100

> updated yesterday. Will move on to auth/psk/pskauth

Further closing loops: my code can now verify all the
test vectors posted yesterday. So even a not very good
programmer like me can implement:-)

S.