Slashdot Mirror

Well, they could use this:
http://preshing.com/20110811/xkcd-password-generator/
I trust it more than building one from scratch using Munroe's Random Function,
https://xkcd.com/221/, I think he should have rolled again...

You are very right on the "bike shed". And of course, not using something like PBKDF2 that cryptographers have looked at is a sign of incompetence. I am just pointing out that no "knocking off 64 bits" will happen in practice, so the thing to worry about is developer incompetence, not concrete weakening of your input, because:

1. First, it converges to half the bits of the hash output, not half the bits of what you put in there. For RIPMED160 that means it converges to 80 bits. That is still far, far too large for doing a rainbow-table approach.

2. When I said, "very long time", I meant it. For an 160 bit hash, the probability of a collision (and that is the convergence mechanism) is very, very low. Admittedly, I am too lazy to calculate it, but fortunately, somebody else has done it before: http://preshing.com/20110504/h... (there may be defects in the hash that increase this rate, but not to any significant degree for this application). With that we get that we need 1.42*10^24 hashes for a 50% chance at a collision. Now, a collision costs you one bit (two instead of one passwords can have the same hash). And now I will estimate: Say, on average you lose 1 bit of entropy every 10^24 iterations. These hash algorithms do about 500'000 iterations per second, but lets give them 1'000'000 per second. That means you can do 10^6 per second and hence 10^18 seconds if dumb hash iterations cost you one bit. 10^18 seconds are 30 Million years. Hence the convergence issue is a theoretical one, not a practical one.

http://preshing.com/20110926/h...

http://preshing.com/20110822/p... http://preshing.com/20110926/h...

http://preshing.com/20110822/p... http://preshing.com/20110926/h...

Like OMG! http://preshing.com/20131219/b...

Instead of all your bullshit wordplay, all you need to do is look up some benchmarks. They'll prove your assertions wrong in 30 seconds flat.

The bullshit wordplay is on your end by repeating "Megahertz Myth" like a mantra. You have NO answer for why both Intel and AMD abandoned decades worth of exponential clock increases and instead focused on multicore. As I said, it's well documented. That article includes benchmarks.

I'm imagining they're mostly intending to sell these to folk currently running open source Linux software on x86. I wonder how much of the existing software has subtle memory ordering bugs that are hidden by the lenient characteristics of the x86 ISA? If ARM servers become thought of as unreliable - even if the cause is properly identified as software bugs - folk may be unwilling to use them.

On the other hand, the big players (such as Google) should be able to fix their own code base in test environments before pushing out to production, and if they see advantages in power consumption and density they could probably keep AMD in business all by themselves.

For those that aren't familiar with memory ordering issues, Jeff Preshing has quite a good blog. See for example This is why they call it a weekly ordered CPU.

we need better passwords for regular people:
http://xkcd.com/936/
http://preshing.com/20110811/xkcd-password-generator

But that's not going to help, that method is easily defeated by brute forcing from the most rudimentary dictionary.