On Wed, Aug 15, 2012 at 8:46 PM, Patrick Mylund Nielsen <[email protected]> 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 effect. 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. Jeff _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
