the exponential problem is that increasing key size by a single bit doubles the time required to check the key space.

So yes, should quantum factorization actually work for real-world key sizes this would be a huge advantage for the attacker compared to the current situation but it's still less costly for the defender to double the key size in order to keep the "probably not decrypted while earth still exists" timeframe than for the attacker increase their cracking capability to match.

Of course Amazons EC2 do not automatically protect you from DDOS, they merely allow you to build an automatically scalabale system should you have the money and interest to pay for that scaling when needed. This is not a critisism of EC2, just pointing out that there's no magical Amazon unicorn defending your website even if you happen to host it on a server in EC2.

Yup, that was in fact a completely secondary point to me as I first thought that is what you *must* have meant , since hashes are not reversible, and only seconds later decided that maybe pointing the fact out might be a good idea.

A fair point, though that would require either plaintext passwords (*very* bad) or unsalted passwords (slightly bad) in db (or first validating the username to get the specific users salt to be passed on to the client but that is again rather bad).

IMO someone attacking the server gaining access to wholesale set of plaintext or unsalted (rainbow tables here we come) usernames&passwords is in fact worse than someone sniffing plaintext passwords in POSTs in you network segment (or between you and server but that's less likely).

Actually on wired network it depends on the switching hardware whether you're getting packets meant for others on your port or not (discounting active mac/arp spoofing but with properly configured high-end HW you will find yourself in an isolated network segment really quickly if you try that)

The login forms/submissions AFAIUnderstand do go over SSL so doing encrypting the password is kinda pointless there.

Also there is no such thing as "un-md5", now the password might be encrypted (des/aes/whatever) but hashes are by definition one-way.

You are missing the point.

The problem is not reading the password as plaintext from the cookie (now that would be monumentally stupid design) but that since the cookie equals valid session authentication copying the cookie equals session hijacking (or sidejacking since the original cookie is still there on the original users machine).

Replying to myself, seems like PhonebookFS has many of the same ideas as Rubberhose, but is probably easier to get into (it's not been pronounced officially dead yet but things are not looking good for it either)

Unless you're Bruce (Schneier).

It seems rubberhose is dead, but look at it and especially the fundamental ideas in it if you really wish to pursue this (I like the idea of having N encrypted volumes and the fact that you cannot prove that you have fully co-operated [and they cannot prove that you're not], of course you need some interesting data on the "bait" volumes as well).

The problem with properly used encryption being indistinguishable from random data is that you need a lot of good quality random data to hide your encrypted data in, because it will be distinguishable from the not-so-random data that you get out of /dev/urandom.

If you are in a situation where you will actually need encryption (especially deniable the sort) then don't trust your own code. As they say: A lawyer who represents himself has a fool for a client. (Don't trust someone elses code either unless it has been actually reviewed by more than two people who actually know how to do cryptoanalysis)

Cracking HDCP would probably be one of the most inefficient ways of backing up your whatever happens to travel over HDMI: the protocol is for encrypting the uncompressed data streams, which are *huge* (current HDMI max bandwidth is 10.2Gbit/s though 1080p + 7ch audio uses less than that but it's still multiple gigabits/s).

And it's not like there hasn't been any HD material on the pirate networks before...

I don't really understand why the hell HDCP was ever taken into use; it causes a ton of problems due to subtle implementation differences and even specification issues (my brother does big AV-system installations [well, programming for the control touchscreen controllers etc] and HDCP causes them no end of headaches) and the protection value is questionable at best since capturing the raw uncompressed bitstreams wasn't even close to practicality back when the protocol was designed. Sure HW will get better, so "it's for the future" is a valid argument, however attacks too will get better and now we have a total break and nothing but trouble and expense to show for it.

Of course the trouble and most of the expense is externalized to us, the customers, so maybe it was a good deal to those that wanted to temporarily block a totally unpractical approach to copying the content.

"anybody" (with sufficient resources for HW design and manufacture) can now create source or sink device, which is nice but doesn't yet solve the most problems HDCP causes on practical level (not all compliant devices like to talk to each other, my old DVD player [with DVI output, high-end device back in the day] crashed every time I tried to connect it to my new projector, either directly or through my amp which has repeater) for those HDCP would have to be turned off. OTOH for the problems of the big-AV-setups (think monitor matrices etc) now a HW solution can be made, need to route picture to multiple monitors or do PiP ? All but impossible before because it was not possible to do decrypt->mix->re-encrypt (according to specs repeaters have to be dumb AFAIUnderstand)

Case point industrial processes: some take multiple days to restart if halted, and downtime costs 20-60kEUR/minute (and beyond). So "oops I accidentally the whole" that triggers emergency shutdown by mistake is simply not an option.

Doing proper correctness verification gets very, very expensive as soon as complexity goes beyond trivial.

AFAIUnderstood none and it's not the currency networks problem anyway (as long as the botherders are running peers that act within the rules of the network).

OTOH the bot-herders are already turning their victims electricity and broadband bills to cash and usually in ways that generate damage to third parties as well, I for one would be very pleased if they suddenly decided it would be more profitable just to generate bitcoins instead.

1. The cost of the SMS is cost enough that nosy people won't go on a massive trawl of the data (since if it was legal to publish said info someone would set up a crowdsourced database).

2. When the vehicle changes owner the traffick authority knows about it, you probably don't (and since your incentive to publsih someones info is to "name and shame" someone else is now in the receiving end of hate intended to the previous owner of registration number X)

3. They want to protect their revenue stream (see crowdsourced db from point 1)

to nitpick: the gas wents and the semi/full -auto mechanism eat a nontrivial amount energy of the "equal but opposite reaction".

> Wouldn't getting hold of THOSE codes be interesting? They'd amount to the capability for any terrorist with the codes and a radio to launch a nuclear strike on the West.

This is different from the American looking glass radio-controlled launch authorization how ?

The interesting thing about micropayments is the micro-part, I've consulted for website that sells subscriptions and ala carte access to articles, but these cost 8EUR minimum (they're also well researched articles on international politics by known and respected analysts and thus well worth the money to those who buy them...), micropayments by definition are very small.

The problem is that there is a limit where transaction costs make the exercise worthless to the publisher and that means it's simply not possible to pay say 10eurocents for an X (let alone single cents or fractions of cents). thus either X must be ad-funded, free, or much higher value for the user.