5 ms·
> Yeah, I can't fathom how that spec got drafted with SHA1. I'm not sure, PBKDF2 existed then... though computationally expensive KDFs for passwords have becom
by nullc 12y ago
> Yeah, I can't fathom how that spec got drafted with SHA1.
I'm not sure, PBKDF2 existed then... though computationally expensive KDFs for passwords have become more popular over time. And grinding the server for SRP isn't totally cheap.
> How's that going? Is there anything amongst the PHC candidates looking like it'll 'win'? It's gone very silent.
Been pretty silent from what I've seen but the schedule gave a fair amount of time for review... though I'm not sure how much review various proposals are getting, since this is a domain with basically infinite shed-painting potential (as my own comments here go!), makes it almost feel pointless to review.
> Afaict this probably isn't too much of a problem for a client-server PAKE?
I'm not sure. It would be an unfortunate result if you sought out to make it more secure, and maybe its less secure. (E.g. server database never leaks, but lots of opportunities for timing attacks show up)
> The password is only hashed on the client/users, probably somewhat noisy and unique, machine. You're already talking about pretty sophisticated and targeted attack that's hard to pull off on a repeated basis. I know that's not a "sound" crypto argument, but you can't easily make a user enter their password 10,000 times for example.
10,000 probably isn't needed though, since extracting a few bits may let you reasonably grind out the rest against the server only; if you make pessimal (read: reasonable) assumptions about how much entropy users actually have in their passwords.
Consider an attack where the attacker code is running in the background (say in another browser tab/nacl) performing cache timing while the user logs it. It's a sophisticated attack, but it could potentially extract quite a few bits. It may be a somewhat complex attack, but a simple conventional hash PKKDF2 would be invulnerable to it.
Yea, I don't see any concern on the server. Server's commitment shouldn't be using an intentionally expensive hash, and normal cryptographic hashes in wide use are constant time.
> Hmm, interesting. Any information on this?
Will look when awake. But the result was something like checking which subgroup a point was in leaking log2(cofactor) bits about the secret. The normal way of avoiding this by multiplying all your values by the cofactor isn't readily available when you're doing some ugly trick of constructing points with no known discrete log from a hash.
- nly 12y ago> the result was something like checking which subgroup a point was in leaking log2(cofactor) bits about the secret. The normal way of avoiding this by multiplying all your values by the cofactor isn't readily available when you're doing some ugly trick of constructing points with no known discrete log from a hash. Ah, a partition attack. Could you fix this with more ugly by just iterating the hashing/munging process until your commitment was in a predetermined subgroup? I'm not at all familiar with EC subgroup theory, but the EC-SRP scheme proposed already does some deterministic munging to select the y-coordinate. Of course, even if you can do this, you're open to another timing side-channel.
- pbsd 12y agoI don't see what the problem is, exactly. If you have a secure hash function taking some string into a point of elliptic curve E, multiplying said point by the cofactor is also a secure hash function into the relevant subgroup of E. See §6.1 of [1]. [1] https://eprint.iacr.org/2009/340 https://eprint.iacr.org/2009/340
- nly 12y agoNeat. It's also pointed out in Icarts paper[0] that the naive 'try and increment' algorithm, which I believe is utilised in Yongge Wangs draft EC-SRP proposal I linked up above, is vulnerable to timing attacks. Oops Interestingly, both Dragonfly and TLS-SRP describe a 'Hunting and Pecking' algorithm to paper over this problem. Perhaps Icarts solution would be more elegant [0] https://www.iacr.org/archive/crypto2009/56770300/56770300.pdf https://www.iacr.org/archive/crypto2009/56770300/56770300.pd...
- pbsd 12y agoHunting-and-pecking is essentially the same algorithm as try-and-increment, where instead of incrementing an x-coordinate on failure one picks another x (pseudo-)randomly. Therefore both are susceptible to the same kind of timing attacks. Dragonfly went to some pains to try to make the process side-channel-free, but it looks ugly as sin, and it's still unclear whether it is actually secure (cf [1]). [1] https://www.ietf.org/mail-archive/web/cfrg/current/msg03537.html https://www.ietf.org/mail-archive/web/cfrg/current/msg03537....
- nly 12y agoThanks for that. The tone of Dan Harkins reply is fun. There's clearly a lot of ego in crypto ;) Not sure I see the point in balanced PAKE myself. If you turn weak passwords in to preshared keys then why not just use strong preshared keys to begin with and trust in the bits? Worrying about parameter binding to the verifier seems irrelevant to EC as well.
- 12y ago