On 2014/11/19, at 18:01, Sergey Beryozkin wrote:
> Hi
>
> Apologies for getting into this thread (I do not understand most of the
> mathematics at this stage :)),
> On 19/11/14 06:43, takamichi saito wrote:
>> (2014/11/18 13:54), Bill Mills wrote:
>>> There will b
done faster
> than 3 Giga SHA256 Hash/s.
> on a small system http://thepasswordproject.com/oclhashcat_benchmarking
>
> I don't think the largest disk arrays can keep up with that.
>
> Do you have some evidence that shows that precomputing hashes would be an
> effectiv
adding entropy, but never
actually justifying it.
Adding client_ID is not only for like adding password's salt.
Adding client_ID is not same as adding password's salt in this context.
On Monday, November 17, 2014 8:34 PM, takamichi saito
wrote:
(2014/11/18 13:17), Bill Mills wrote:
dence that shows that precomputing hashes would
be an effective attack against 256 bits of entropy. I agree that
it would be agains the 40 ish bits of entropy in a password.
The likely mitigation is using PBKDF2 or BCrypt rather than SHA256,
but that would slow adoption a
I never confuse about password in these discussions.
Regards,
-bill
On Monday, November 17, 2014 7:27 PM, takamichi saito
wrote:
I agree that GPU can/may find the value on the fly.
But, it can not find it within the session.
The draft idea is enough against the attack with GPU.
On the other,
rote:
I am actually not convinced. Since the code verifier is 256bit random,
adding salt does not seem to help.
Salting definitely helps if len(password) << 256 bit, but ...
On Mon Nov 17 2014 at 11:39:07 takamichi saito mailto:sa...@cs.meiji.ac.jp>> wrote:
(2014/11/14 1
equired for the basic functionality/security
of the mechanism.
In the threat model of the SPOP scheme, a wiretap is in it.
And more, the hash is not used to keep secretly in the sever/client.
On Thursday, November 13, 2014 7:07 PM, takamichi saito
wrote:
Sorry for my poor english.
2014/1
challenge is only one time use and has a short
validity period. " from the start, and I said so.
So, the attacker can not have "code_verifier" within the attack time.
"John's comment on brute force" is not my concern.
My concern is the above constraint against att
code to be tried once
>> -at a very minimum should have a severely limited number of tries for a
>> code
>> -a short time window to use a code
>>
>> Unless you can brute force 256 bits of (pseudo)random in under a minute or
>> two the code is dead. G
I will come up with some text for the spec, as you are not the only person
> asking that question.
>
> The other issue is that the term HMAC is scary to developers and we want
> maximum adoption.
>
> John B.
>
> Sent from my iPhone
>
> > On Nov 13, 2014, at 3
t isn't then the attacker could be stealing the original
> credential used to authenticate anyway.
>
Is it correct?
You mean that we don’t need to use hash itself? Only to use plain is enough?
>
>
>
> On Thursday, November 13, 2014 5:40 PM, takamichi saito
> wrote
the spec, as you are not the only person
> asking that question.
Thank you.
>
> The other issue is that the term HMAC is scary to developers and we want
> maximum adoption.
>
> John B.
>
> Sent from my iPhone
>
>> On Nov 13, 2014, at 3:28 PM, takamichi saito
Hi all,
I appreciate this idea, simple and powerful to achieve proof of possession.
But, I have some questions against the scheme.
Sorry if these ware already discussed.
I worry about using a hash function in simple way.
I mean, a simple use of random as code_verifier may cause that malicious cl
13 matches
Mail list logo
