Hi Bill, I actually wasn't quite sure what this sentence meant.
What I want is that the input to the hash is a 128-bit (or larger) random number. The output will be determined by the hash function and, in case of SHA-256 (as suggested in the document) that output will be 32-octets. Ciao Hannes On 12/03/2014 07:10 PM, Bill Mills wrote: > Quoting from 7.1 > > "It is RECOMMENDED that the output of a suitable random number > generatorbe used to create a 32-octet sequence." > > So the spec is already recommending 256 bits of randomness, is that > language not clear enough? > > > On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig > <hannes.tschofe...@gmx.net> wrote: > > > Hi all, > > I am trying to figure out how to progress the SPOP document and > therefore I read through the discussion about the code challenge, see > > I wanted to share my view about this topic. > > As a summary, the mechanism works as follows: > > C: Compute code_verifier:=rand() > C: Compute code_challenge:=func(code_verifier) > > (For this discussion, the function func() is SHA-256.) > > C: Send(Authz Request + code_challenge,S) > > S: store code_challenge > S: Send(Authz Grant,C) > > C: Send(Access Token Request || code_verifier, S) > > S: Compute code_challenge':=func(code_verifier) > S: IF (code_challenge'==code_challenge) THEN SUCCESS ELSE FAIL. > > The document currently does not say how much entropy the random number > has to have. > > The text only talks about the output size and SHA-256 indeed produces a > 256 bit output. > > Here is the relevant text: > > " > NOTE: code verifier SHOULD have enough entropy to make it impractical > to guess the value. It is RECOMMENDED that the output of a suitable > random number generator be used to create a 32-octet sequence. > " > > I suggest to recommend at least 128 bits, which is inline with the > recommendations for symmetric ciphers in > http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 > > I would also suggest to reference RFC 4086 concerning the creation of > random numbers. > > Furthermore, since you allow other hash functions to be used as well it > would be good to give guidance about what the properties of those hash > functions should be. You definitely want a cryptographic hash function > that provides pre-image resistance, second pre-image resistance, and > collision resistance. > > Given the size of the input and output it is impractical to compute a > table that maps code_verifies to code_challenges. > > This mechanism provides better properties than the "plain" mechanism > since it deals with an attacker that can see responses as well as > requests (but cannot modify them). It does not provide any protection > against a true man-in-the-middle attacker. > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
