*_hash algorithm for EdDSA ID Tokens?

Issue #1125 open
Filip Skokan created an issue

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

Comments (11)

  1. Filip Skokan reporter

    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 🙂

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

  3. Filip Skokan reporter

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

  4. Michael Jones

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

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

  6. Filip Skokan reporter

    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

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

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

  9. Log in to comment