stipes's comments

Agreed.

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.

1. http://www.nervous.it/lang/en-us/2012/06/cracking-sha1-on-am...

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

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.

1. http://news.ycombinator.com/item?id=4365079

2. http://www.opine.me/blizzards-battle-net-hack/

3. http://trone.di.fc.ul.pt/images/e/e2/ASAP11-paper.pdf

4. http://golubev.com/gpuest.htm

My guess? The team was solid. Since they found something else (i.e., something better), they probably are.

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.

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.

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.

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

Whoops. The protocol you described is actually secure against that, since your login passes the preimage to the server for hashing and then comparison.

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.

I believe Koza has several patents for things he has discovered using Genetic Programming / Algorithm techniques.

Well, as true decentralized bootstrapping is still an open problem (as far as I know), I'll give them a bit of a pass on that.

It's an interesting idea, but I'd agree that there are possible ramifications of repeated pseudonymous communication over Tor.

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

He isn't CEO anymore...

I'm more familiar with the term "Computer Engineer" applied to hardware design folks, and "Software Engineer" with human programming. Am I nuts?

Aside from the nitpick, the point is a good one. Thanks for the essay.

AGPL is the license that closes the service provider loophole. Normal GPL only applies if you are delivering binaries---providing a service is considered "in-house" use.

Thus the reason the AGPL was created, although hardly anyone uses it (to my knowledge).

I much prefer this treatment: http://rjlipton.wordpress.com/2010/06/26/stating-pnp-without...

However, it is more of a "p vs. np for non CS theory people".

The article is rather sparse on technical details. The homepage for LOCKSS is http://www.lockss.org/lockss/Home.

It appears to use some sort of Byzantine fault tolerance in its auditing system (to detect the fault and repair) spread across many "boxes" running the system. There is also a manual audit process by librarians to check that content is correct (this may handle cases where the "live" copies are tampered).

For the most part (from what I can gather from their site), the system is a kind of "self-audited" backup for live content, not for ensuring that that live content is correct. So, for a document that you needed to keep correct (given that a live copy may be tampered), you could simply not have a live copy.