*_hash algorithm for EdDSA ID Tokens?

[Filip Skokan]

What hash algorithm should be used for _hash claims in ID Tokens signed with EdDSA?

[Vladimir Dzhuvinov]

Ed25519 uses SHA-512 internally, so in my opinion that should be used for _hash alg.

https://tools.ietf.org/html/rfc8032#section-5.1

‌

‌

[Vladimir Dzhuvinov]

PS: Ed448 uses SHA-3: SHAKE256

https://tools.ietf.org/html/rfc8032#section-5.2

[Filip Skokan]

Thanks @Vladimir Dzhuvinov , it’d be great if this was raised and confirmed on a WG call.

So we have two behaviours for one algorithm name? As a side note, let’s not devise algorithm names like that in the future

[Vladimir Dzhuvinov]

Yep, the EdDSA sig alg differs in the hash alg and some params, depending on the key subtype (curve).

So by just looking at “alg” you cannot tell what curve was used. EC DSA in JWS doesn’t have this issue.

This means that to determine the hash alg you need to know the OKP JWK crv value. Which complicates the hash validation :(

It seems this aspect was overlooked.

[Filip Skokan]

@John Bradley @mbj No one on the regular call was able to answer here, can you take a look?

[Michael Jones]

SHA-512 sounds right for Ed25519. We plan to discuss this issue in person at IETF in 1.5 weeks in Singapore.

[Michael Jones]

We discussed this on the 25-Nov-19 call. Ed25519 should use SHA-512.

Ed448 logically should use SHAKE256 but it takes a output size parameter. EdDSA signing with Ed448 internally uses SHAKE256 with 114 byte output, so that may be the “right” answer. But apparently some SHAKE256 implementations only support 32 byte (256 bit) outputs, so that’s another possibility. It sounds like this one could use more discussion.

[Filip Skokan]

But apparently some SHAKE256 implementations only support 32 byte (256 bit) outputs

E.g. Node.js only added the possibility to specify outputLength for XOF hash functions such as shake256 little over 4 months ago.

‌

Unless there are objections i’d say it is the right answer tho, can we confirm that on the next call with more people in it?

An errata language should clarify which algorithms to use for EdDSA and maybe it wouldn’t hurt to provide an appendix with example outputs. I’ve seen this implemented wrong one too many times in the past. Table follows

Given the access_token value YmJiZTAwYmYtMzgyOC00NzhkLTkyOTItNjJjNDM3MGYzOWIy9sFhvH8K_x8UIHj1osisS57f5DduL the following table represents the at_hash values for a given ID Token signing algorithm (IANA-registered or soon to be at this time)

JWS algorithm	used digest algorithm	at_hash
PS256, RS256, ES256, ES256K, HS256	sha256(message)	xsZZrUssMXjL3FBlzoSh2g
PS384, RS384, ES384, HS384	sha384(message)	adt46pcdiB-l6eTNifgoVM-5AIJAxq84
PS512, RS512, ES512, HS512	sha512(message)	p2LHG4H-8pYDc0hyVOo3iIHvZJUqe9tbj3jESOuXbkY
EdDSA (with Ed25519 curve key)	sha512(message)	p2LHG4H-8pYDc0hyVOo3iIHvZJUqe9tbj3jESOuXbkY
EdDSA (with Ed448 curve key)	shake256(message, 114)	sB_U72jyb0WgtX8TsVoqJnm6CD295W9gfSDRxkilB3LAL7REi9JYutRW_s1yE4lD8cOfMZf83gi4
none	n/a	n/a

‌

[Michael Jones]

We decided on the 5-Dec-19 working group call to use SHAKE256(x, 114) for Ed448, matching the hash function that EdDSA uses.

[Michael Jones]

We should decide where to publish this information.

[Tangui]

Also the specification says:

the hash algorithm specified in JWA [JWA] for the alg Header Parameter of the ID Token's JOSE Header

, not the "alg” (and `"crv")`of the JWK against which the ID Token’s signature has been validated. This should be rephrased too.

‌

[Nat Sakimura]

bringing up. It has no assigned person.