(2014/11/18 13:54), Bill Mills wrote:
There will be no rainbow table for 256bits of search space. Suppose then that
clientID has 256 possible values. How does salting with client ID do anything
more than making the search space 264 bits?
You keep saying that a salt is better than just adding
(2014/11/18 17:08), Nat Sakimura wrote:
The code verifier is 256 bit high entropy cryptographic random.
Let D:= {d | all possible 256 bit random}. This is the set of all
possible code verifiers.
Let S be SHA256 function.
Then, set of all possible code challenge corresponding to D, which is
den
Yes SHA512 or even a left half SHA512 slows the attacker significantly over
SHA256 as that alg has had a lot of ASIC optimization.
I personally think that SHA256 for a short lived token is still good for a
while.
Sent from my iPhone
> On Nov 18, 2014, at 11:33 AM, Bill Mills wrote:
>
>
In this case it ceaper to add bits than use soemthing like BCrypt.
On Monday, November 17, 2014 9:33 PM, John Bradley wrote:
I think where we are differing is that you think looking up a precomputed plain
based on a indexed hash across some sort of media can be done faster than 3
Giga SHA256
The code verifier is 256 bit high entropy cryptographic random.
Let D:= {d | all possible 256 bit random}. This is the set of all possible
code verifiers.
Let S be SHA256 function.
Then, set of all possible code challenge corresponding to D, which is
denoted by R, is defined as:
S:D->R.
Note that
