[Openid-specs-ab] [openid/connect] client_secret to key (issue #762)

Brian Campbell issues-reply at bitbucket.org
Thu Feb 7 19:40:32 UTC 2013

--- you can reply above this line ---

New issue 762: client_secret to key

Brian Campbell:

client_secret is a string but most crypto operates on bytes

There is text that says, "[MAC] is calculated using the value of client_secret as the shared key"[1] or "use a left truncated SHA-256 hash of client_secret to ..." [2]

(side question, is SHA-256 there too restrictive as far as crypto agility is concerned?) 

Should the spec(s) explicitly state how to go from the client_secret string to the bytes input into the MAC or hash functions? Probably it could just be "the bytes of the UTF-8 representation" or something like that. 
Or restrict client_secret to only ASCII printable characters? Which it kind of is already, I guess, by its possible use in HTTP Basic.

Lastly should we consider/address potential loss of entropy or key-space in such a conversion?   I.e. the bytes of the UTF-8 representation of a 32 character sting will produce a 256 bits but the likely make up of the string (even machine generated) means that you don't really get the full 256 bits of strength. I'm not sure if that's esoteric or important. JOSE/JWA is pretty strong about key size, "a key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with [HMAC] algorithm[s]." [3] (though I think most implementations are ignoring that currently).

This is somewhat related to https://bitbucket.org/openid/connect/issue/761

[1] http://openid.net/specs/openid-connect-messages-1_0-15.html#client_authentication

[2] http://openid.net/specs/openid-connect-messages-1_0-15.html#enc

[3] http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-3.2


This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.

More information about the Openid-specs-ab mailing list