On Mon, Sep 30, 2013 at 07:41:20PM +0100, Wasa wrote:
The only attack is on the PBKDF2 stored on the server (or malware to grab
the password on the client)
right. I was think SRP/JPAKE where the server does not store
PBKDF2(salt,pwd) server-side, but rather it stores something like
g^{PBKDF2(pwd)}. If I break into server and get hold of all
g^{PBKDF2(pwd_i)}, can I parallelize the DL part?
Well ok, this IRTF draft I was coincidentally just reading claims to be
marginally more efficient than SRP
https://datatracker.ietf.org/doc/draft-irtf-cfrg-augpake/?include_text=1
and has a verifier of that form.
You could parallelize it somewhat at a micro level but I dont think you need
to because you can just try lots of passwords in parallel against the same
verifier.
Because I think one of the claims of SRP and JPAKE is not only to be
resistant to passive/active sniffing followed by offline brute-force,
but also to be more resistant against server compromise.
No I do not think that is true. And I noticed the IRTF draft above's
security comments section confirms, it explicitly states that all it can
offer in the event of server compromise is that the attacker has to brute
force the PBKDF (aka function H in their terminology). (Actually that is
why I bothered to read the draft because of their title/abstract I wondered
if they had claimed to do better against server compromise and if so how as
that is beyond the state of the art AFAIK; turns out they are the same as
SRP etc).
Idea?
If it turns out to be difficult to parallelize the brute-force, why
not move towards this? It would be an incremental improvement more
likely to be widely-accepted than brand-new schemes. JPAKE is a bit
slow I presume (given the number of required rounds), SRP is not and
the patent expires soon (if memory serves).
I think SRP is not patented, and in fact is designed to be free from
reliance on any pre-existing patent details. There were some EKE patents
but coincidentally the AKE version just expired last month. Nice timing.
Adam
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
