[cryptography] Client-side SRP "vs." server-side KDF
noloader at gmail.com
Wed Aug 15 21:23:39 EDT 2012
On Wed, Aug 15, 2012 at 8:46 PM, Patrick Mylund Nielsen
<cryptography at patrickmylund.com> wrote:
> Blizzard Entertainment has been receiving a lot of flak from tech and mass
> media lately for choosing to employ SRP in their Battle.net clients and
> games. A lot of these outlets have been suggesting that SRP is "weaker" than
> KDFs, and that Blizzard switch out SRP on the client side for a KDF on the
> server side. That seems to me a very apples-to-oranges comparison (indeed
> akin to blaming Diffie-Hellman key exchange for the fact that DES is easy to
> break,) and indeed would only replace one security issue (weak password
> digests/verifiers on the server) for another (susceptibility to network
> eaves-dropping.) As far as I know, the SRP authors never made any claim
> about the verifiers being hardened against dictionary attacks.
> It seems to me that a strong KDF on the client side, like PBKDF2 or scrypt
> (optionally with a salt managed by the server,) coupled with a
> non-reproducible proof of some sort, like SRP, would be the ideal solution,
> not one or the other. What do you think?
On the server side, the salt and hash look exactly like a Unix passwd file.
One could easily beef it up in a KDF like fashion, but mobile clients
will need to perform the same pre-processing before the real SRP takes
One could also cut in a different hash, such as scrypt.
In the past, I implemented it twice and only found I needed to
increase the size of the server's authentication tag from 32 (or was
it 64) bits to something larger (96 or 128 bits). I had mobile
clients, so the UI folks would not accept the KDF pre-processing
(Windows Phone era, before iPhone was introduced).
SRP also cuts out the [useless] third party known as a Public CA. +1
to Thomas Wu and SRP.
More information about the cryptography