stipes

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.

There's a good wiki on Starting Strength at http://startingstrength.wikia.com/

I was surprised by the lack of mention for PlanetLab and Emulab.

TLS/SSL can cache the session in order to actually improve performance and scalability. Otherwise you'd have to redo the exchange each time you made a request.

My guess is that the level of caching you'd want TLS/SSL to do is dependent on what kind of content you're serving, the usage patterns of visitors, etc. As an example, Facebook has relatively long user sessions, and would benefit greatly from caching and just refreshing the session keys. Something like Google search, where a user session may only last a few seconds and a couple requests... maybe not so useful. I'm not familiar (off the top of my head) with any in-depth studies on this.

I read this back as a private preprint. Definitely well designed (a good fit for USENIX, where it will be published). They had to overcome some significant technical hurdles in order to get it to be properly backwards compatible (issues with TCP header size, NAT boxes, etc.).

My biggest interest is in the much lower computational overhead for the server, which, I can hope, will mean it will get used much more often than TLS/SSL (thus the idea of it being "ubiquitous").

There's growing interest in the idea of "opportunistic encryption", where the results are transparent and beneficial, but not always guaranteed. (I'm working on this in a different area currently.)

My initial reaction to the title was that winning a professional level soccer game by more than five points does cause a loss of sorts: the physiological taxation that such effort causes could easily decrease the chances of winning games in the near future. Taking this physical side effect of over-effort into account in finding the optimal strategy would be interesting.

> ''The practicable and certain way of finding Longitudes'' - satellite navigation.

We figured that out (for varying definitions of "practicable and certain") as early as the invention of the watch.

Of note is that most of what are called "distributed social networks" are actually federated social networks.

The government would still know (if they were logging traffic) that you accessed the page. In this case, as it is publicly accessible, the encryption is fairly meaningless.

After some brief digging, it appears there has been some published research on location diversity in path selection in Tor since I last worked on that problem. https://docs.google.com/viewer?url=http://www.cs.rpi.edu/~ed... has some good results, if anyone is interested.

Yes, Tor is for anonymity, not privacy. But that just means you still need to be operating over a secure channel---be that SSL or sending the documents encrypted, etc.

The fact that they operated compromised nodes does NOT diminish from Tor's anonymity. Most anonymity systems assume about 1/5 of the nodes will be compromised (which is reasonable barring a very large global adversary).

In general, timing attacks are the biggest issue in low-latency anonymity systems: if you can track packets going into Tor and coming out of Tor, you can link the sender to the destination. But, if the traffic was encrypted, that still doesn't get you the documents themselves.

Edit: More specifically to the grandparent---even with a compromised exit node, that doesn't reveal the source (that's the point of onion routing). The case of China is a hard one, due to the level of state control. There are ways to request exit nodes in the Tor network (I have no idea how well documented this is), so for them, selecting an exit outside China for accessing international sites would probably be best (this would remove/greatly reduce the risk of Chinese gov't timing attacks).

There has been some work on strategically choosing entrance/exit nodes to reduce the risk of these kinds of timing attacks, but I don't know of anything that has been published or implemented yet (I haven't worked on that particular aspect in a while). Basically, some of the methods would have automatically chosen exit nodes outside of China (to prevent exit->destination traffic from travelling through the same autonomous systems as source->entrance traffic).