Your numbers show that SRP-SHA1 is about 50000 times better than salted SHA1. Not great, better than nothing (at least for those of us without dictionary-targetable passwords).
I've been continuing to work on this through the night. Initial benchmarking on EC2 show you can test SRP passwords at a rate of ~180k / sec on c1.xlarge, at $0.66/hr per instance.
Particularly with Blizzards strange 'case-insensitive alphanumeric only' policy, anything less than truly random 8+ character passwords are within reach.
For 90% of their users, this spells trouble. If you've seen John the Ripper, you know 'dictionary-targetable' is an increasingly ambiguous term.
My main point is that Blizzard is coming out and saying in their press release: "We use Secure Remote Password protocol (SRP) to protect these passwords, which is designed to make it extremely difficult to extract the actual password"
And in their FAQ: "Cryptographically scrambled versions of passwords for North American players were accessed, protected by Secure Remote Password (SRP) protocol.... The added layer of protection from SRP makes that process computationally very difficult and expensive."
When what they SHOULD be saying is, "we used industry standard best practices, but even so the majority of the passwords have most likely already been cracked. Please make sure you change them immediately."
It would be nice if I could still tweak the title at this point.
As a point of comparison, it looks like you can get 650 million/s on a cg1.4xlarge instance [1] (Amazon's GPU computing instance with 2x Tesla Fermi M2050 GPUs), and it looks like they cost $2.10/hour per instance. So some quick math does show that cracking SRP is only about 572 times slower, if we normalize for cost of the instances on EC2.
Down-thread [1], someone claims to have found SRP to be about 172 times slower than SHA1 on CPU due to the modular exponentiation and other overhead.
Some numbers run by zaroth (down-thread) [2] show that we could see 100k 1024-bit modular exponentiations per second on a new Intel Core i7 with the cryptography extensions. A 2011 implementation paper [3] had about
20k 1024-bit RSA decryptions per second on a GTX260 using Montgomery exponentiation, so it doesn't seem like using the GPU has that much benefit for performing modular exponentiation. I haven't had time to figure out an estimated price/attempt for SRP, so it's hard to compare to the existing SHA1 figures [4].
Still, if we take the 100k/second figure for modular exponentiation (extrapolated from the number of cycles per 1024-bit modexp on a Core i7), versus the 5B/s for SHA1 on a single GPU, being 50000 times slower than the best SHA1 speeds seems pretty good to me.
The design of BitCoin only includes very weak anonymity. A medium-to-large scale network analysis could most likely break any anonymity people thought they had.
I did some research work last semester on crypto inside VMs. One of our initial readings was Yilek's work on attacking VM crypto through VM snapshots http://cseweb.ucsd.edu/~syilek/ndss2010.html
That's an interesting trick but not really representative of the problem. Reusing an RNG's entropy pool wholesale after restarting a snapshot is a mistake, not a design flaw.
Part of the problem is the conflict of transparency and security here. Fixing the wholesale reuse of RNG state would most likely require modifying the guest so that it is aware of being restarted from a snapshot so it can react appropriately.
However, that might have consequences on what restoring from a snapshot means conceptually.
Yes, in general write to /dev/random with the write permissions is how entropy gathering daemons and the like work. It gets added the input and mixed in. However, that doesn't fix the issue of how a snapshot restore works on most hypervisors. Adding an RNG refresh as part of the restore process could be possible, but definitely not trivial, and it could have other consequences if not carefully implemented.
This increases the password space (assuming a cryptographically strong hash), but if the datastore is compromised, an attacker can just bypass the client hashing (by changing JavaScript, etc) and just pass in the hash itself.
Yes, if someone breaks into the server, and changes the code for the login process, they can get around this. But that's always true. The server is a higher priority target than a single account. If your scenario requires breaking a higher priority target than the one in question, it's not really a security hole.
Similarly, someone can compromise my account on a Linux box if they get root access. They won't know my password, but they can change my password or just replace the login program with their own. But we consider getting root access a higher target that compromising a single account.
In other words, this is begging the question.
edit: I must have responded to a different understanding.
Whoops. The protocol you described is actually secure against that, since your login passes the preimage to the server for hashing and then comparison.
Bodybuilders would tend to go for the 100% method, not the 80/20. Although reading through some responses to the book on bodybuilding forums is an entertaining way to spend an hour.
I would personally say that even if nearly everything in the book fails for me, it was a good enough read to be worth $15 (roughly what I would pay for a novel, let's say).
