[cryptography] PBKDF2 + current GPU or ASIC farms = game over for passwords (Re: TLS2)

Wasa wasabee18 at gmail.com
Mon Sep 30 14:41:20 EDT 2013

On 30/09/13 19:22, Adam Back wrote:
> On Mon, Sep 30, 2013 at 06:52:47PM +0100, Wasa wrote:
>>> Also the PBKDF2 / scrypt happens on the client side - how do you think
>>> your ARM powered smart phone will compare to a 9x 4096 core GPU 
>>> monster. Not well :)
>> How much would it help to delegate PBKDF2 / scrypt to smartphone GPU to
>> break this asymmetry?
> It might help a little in the right direction, and so probably should be
> done; but I presume phone GPUs wont have that many cores nor high
> performance to compare to an AMD 7990 (4096x 1Ghz cores) even if it
> outperforms the phone CPU by a reasonable margin.
>> since SRP and JPAKE use exponent_modulo sort of computation rather 
>> than a
>> hash, any idea how this impacts attackers?  how well can you 
>> paralellize a
>> dictionary brute force for DL problem?  I'm not expert so glad to hear
>> about it.
> The A part of AKE password amplification, means that you cant break it 
> via
> the DL stuff.  The password only authenticates the diffie-hellman like 
> key
> exchange, so it just is there to prevent MITM.  You still have a full 
> 2048
> bit DL or 256-bit ECDL to attack and that is hopeless.
> 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?
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.

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).

>>> Anyway and all that because we are seemingly alergic to using client 
>>> side
>>> keys which kill the password problem dead.  For people with smart 
>>> phones
>>> to hand all the time eg something like oneid.com (*) can avoid 
>>> passwords
>>> (split keys between smart phone and server, nothing on server to grind,
>>> even stolen smart phone cant have its encrypted key store offline 
>>> ground
>>> to recover encrypted private keys (they are also split so you need to
>>> compromise the server and the client simultaneously).  Also the user 
>>> can
>>> lock the account at any time in event of theft or device loss.
>> i like the idea. Any issue/complications with re-provisioning or 
>> multiple devices with same identity?
> If you lose one device you can replace the device enrole it 
> authenticated by
> your other devices and securely restore access keys into it.  It does
> support multiple devices, though each device also has a unique key as 
> well
> as a common identity key so that individual devices can be revoked 
> instantly
> if they are stolen.  It uses some fun crypto like a blind MAC to do split
> key KDF and AKE type protocols.
> They have a recovery mechanism also I think if you simultaneously lose 
> all
> our devices (laptop and smartphone) (user print out 128-bit key on
> registration).  If the user doesnt do that they have to re-enrole as a 
> new
> identity with oneid and the relying parties.
> I was thinking it could be a good tech for access to bitcoin online 
> wallets
> and exchanges because also the transaction details are displayed for
> approval on the smart phone, so even if the laptop had bitcoin related
> password targetted malware on it, you could still securely transact if 
> you
> read the transaction details on the smartphone before approving.

so I wonder:
- with no server, what would be the user perception of security? and 
would that prevents them from using such systems? Say, you log into your 
online banking with no password; would user feel secure and use the service?
- would Facebook/twitter and co. like this sort of security where users 
cannot log-in from anywhere from any device? Surely they prefer a bit 
less security on client side + more ML detection server-side and more 
users connected; right?
- I guess the sort of service you describe is great for large companies; 
but the complexity might put off smaller ones. Thoughts?
- how different is the client cert approach compared to token used on 
mobile devices (e.g. Google stores a unique token on smartphones to 
access google services and hence requires no passwd)? Essentially it too 
removes phishing problems, but seems more flexible. But it does not have 
fancy crypto so maybe less exciting on an intellectual level :-)

> Adam

More information about the cryptography mailing list