Interesting thesis, but I don't buy it. Audience were not discovering technology for the first time, and it was not the first time cinema explored it. One of the most classic sci fi films ever was Metropolis, made in the 1920s. There were some very good sci fi films made in that era (and some very bad ones too).

In fact, Blade runner didn't appeal to audiences much when it was released. It has become a classic afterwards, probably because it's based on a quality story and the acting, direction, music and atmosphere of the film are great. And because Ridley got rid of the annoying voice over, which the movie execs mandated so the dumb audience could understand it. Not a passionate audience, note, or at least, that's not how the movie industry saw the audience and the films they were creating for them.

I put it in quotes because it is not a genuine paradox.

Wrong, nothing to do with being modulo some number. It's the permutations of pairs that gives rise to it.

Mod parent up, wish I had mod points.

This is exactly right. It's the number of permutations of pairs that gives rise to the birthday "paradox". Nothing to do with being modulo some number.

Hmmm... I got my performance stats from a different web site. But the performance table on oclHashcat's fron page says 11231M c/s for SHA256. That's eleven billion a second, admittedly using 8 GPUs, but in the ballpark of my original post.

If crypt is iterating SHA256 110,000 times, that sounds fairly good. I've been looking at scrypt, which is explicitly designed to resist hardware based attacks.

Well, I would dispute those calculations a bit, but I accept that good long per-account salting forces each password to be cracked individually. I assume that the salt is compromised along with the password (or they won't be cracked at all).

Even randomly selected passwords from all alphanumeric characters only gives us about 6 bits of entropy per character. Most passwords are shorter than 10 characters, the average is more like 7. This only gives us 42 bits of entropy per password, assuming complete random selection from that space.

But - users don't randomly select from that space, and modern password crackers don't simply try all possible letter permutations, although they can successfully do this for passwords which are less than 7 characters. They exploit the patterns and techniques which users use to select passwords, using rules engines, password dictionaries, markov chains and all sorts of clever magic.

Run this on GPUs using hashcat, which for SHA256 can check about 3 billion hashes a second. A small cluster of 4 of these machines can then easily check over 10 billion hashes a second. You can now rent Amazon EC2 instances with GPUs. In a minute you can check 600 billion hashes, admittedly for a single password at a time.

Salted hashes are now crackable even for quite reasonable passwords, if the hash algorithm can be run on modern GPUs, and assuming the attacker has the salt as well.

It's not particularly the strength of the hash that worries me, it's the speed of it. If they're using something like SHA256 - strong, but fast - then I'd be worried.

Good point. I checked out http://www.stroustrup.com/appl... and I can see they're mostly all quite demanding applications. I guess they deserve a demanding language :) But yes, fair enough. There are plenty of times getting the most out of what you have is going to be important.

I once worked on Java code which ran on the most ludicrously limited hardware. It was like treacle. I spent a lot of time tuning that code. Logging was the worst offendor, but some poor algorithms lurked in there too. Garbage collection was quite noticeable, even after rewriting to minimise it as much as possible.

Fair enough... I'm pretty ignorant on how CUDA or OpenCL is programmed. What is it about C++ that makes it a good fit?

Yes, I can see that sort of code would benefit a lot. Not an area I've done much work in, but I guess a lot of people are. I'm actually really interested in code that performs well - I spend quite a lot of time profiling and tuning. Some of the things Martin Thomson has done in Java land are pretty cool. Check out http://lmax-exchange.github.io... and http://mechanical-sympathy.blo...

Sure, resource handling in C++ is one of the examples I do give of the sheer power and beauty of what you can do with the language. I used it extensively even back then. I also remember some of the issues I encountered in passing them around safely were a big lesson in the complexities, pitfalls (and opportunities) that lurk in the language. It was enormous fun, but I think I've probably been more effective in less demanding languages.

I had the most fun ever with C++ back when the original story ran. But it was too complex, too big and yet lacking standard ways of doing really very common things. Every library took a different approach. No standard libraries to do pretty much anything you wanted to in the real world. And it was always possible to shoot both feet off at once while doing something you thought was obvious and/or designed to make your code safer. Incredibly slow to compile. Compilers never supported the full C++ spec, or supported different bits of it on different platforms.

The trouble is, I can't see any compelling reason to use it for anything much these days. Maybe the latest C++ is better - but given what I know of the language I suspect the main criticisms I have of it must be still valid.

Use cases where you need that insane low level of power and control while retaining a high level language syntax are not common at all.

Can anyone give an example of where C++ really shines these days over other languages?

It looks like a message authentication code, but it isn't. Hash(Key || data) is vulnerable to a length extension attack.

I think we need a "Misleading" category.

Without the salts, the hashes are essentially uncrackable, if the salts aren't incredibly short. So don't waste your time trying to crack these.

Salts are not secrets. They are usually stored right alongside the account details in the password database.

If your solution is to make the salt secret, you're not using salts anymore. Per-account salts protect against pre-computation attacks and do not need to remain secret to provide this protection. They are a cheap and effective defense for this purpose.

If you want to keep your salts secret, they are technically called "keys", and are expensive and difficult to manage securely.