Become a fan of Slashdot on Facebook


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Re:"Research Projects" (Score 1) 36

The problem is that all these attempts to interest kids in STEM are so earnest and dull.

What we should be doing is tempting them with mad science. You see? It's not all death rays and monkey testicle implants.

It's important to hook them by middle school, when the all important sense of being misunderstood is its keenest.

Comment Re:For variable values of "practical" and "relevan (Score 1) 130

So out of 172 root CAs only 14 include any path length restrictions, and even the ones who do still allow some chaining.


We're doomed.

I don't think the SHApocalypse will be tomorrow. This was an identical-prefix attack instead of a chosen-prefix which constrains the attacker considerably, and the computation required is much higher even to generate simple collisions. However, (again, please correct me if I'm missing something) it does seem plausible that that further weaknesses will be found which provide just enough leverage to forge a signature with one of those 172 CAs, and we may eventually see a rogue sha1WithRSAEncryption CA issued.

I concur, completely.

Comment Re:Call me crazy... (Score 1) 80

Well, they're both solutions. But they run afoul of questions. Which users benefit most from each solution? And if someone benefits most from the massive battery with conservative display and processor specs, can you sell it to him?

I'll tell you right here that I'd much prefer LG's approach, but I'm an engineer. I think about my requirements differently than most people.

Comment US Life Expectancy is 91.9 years (Score 3, Insightful) 99

If you're a woman in the top 1% by income. If you're a man in the top 1% it's 88.8 years.

If you're middle class you live about 78.3 years if you're a man, which is big step up from 1980, probably because of smoking. If you're a woman you live 79.7 years, a decline of a few months since 1980.

Now if you're a poor your life expectancy has declined since 1980, to 76.1 for men and 78.3 for women.

So here's the picture: if you're rich, medical advances since 1980 have increased your expected lifespan by about seven years. But those advances haven't had any effect on middle class lifespans. If you're poor you apparently are having difficulty paying for medical care at all, which is not surprising because health care costs have consistently outpaced inflation since the mid-70s. If you're a working poor American health care inflation meant you basically screwed by the 2000s: you were too rich for Medicaid, to poor to avoid medical care.

One more thing: US has a GINI coefficient (measure of income disparity) of 45. That's the highest in the industrialized world, and much higher than it's low point of 34 in 1969. Basically all of the income growth sicne 1990 have gone to the top quintile, in fact the lion's share to the top 5%. People at the 80th percentile by income and below have seen basically zero income growth when adjusted for inflation. And since health care inflation rises faster than inflation, it means 80% of the the US has seen a cut in its disposable income.

Comment Re:So, America might have a lower life expectancy. (Score 1) 99

Why single out one cause, when there's obviously many.

Take food. I live near a supermarket that is probably three times the size of the one my parents went to, but the produce section is smaller, the meat and dairy sections about the same size. The surplus acreage is taken up with cheap, calorie dense, no-preparation convenience food.

Or the fact that Amercians spend more time in cars than they used to, on average over 290 hours a year.

Here's another interesting fact: research shows that the portion size you choose is positively correlated to the size of the package you serve yourself from; this doesn't happen consciously, it's just that a cup of cereal from a 9 ounce box appears like a lot more than a cup of cereal from a 21 oz box.

The huge sizes are driven in part by an attempt to cut down on trips to the grocery store. American home kitchens are the largest in the world, and most of that is needed for storage because we don't do very much food preparation.

So if there's a single root cause it's the pursuit (sometimes failed) of efficiency; we have the wealth to try to reduce labor and time spent doing things, but our bodies are designed to spend time doing things.

Comment Re:The solution is simple. (Score 1) 316

The problem may be the while Garcina Cambogia causes 30% more weight to be lost, 30% more of zero is still zero.

If that's what happens anyway it's somewhat problematic to use the word causes -- unless it's a different 30% in each case that would have happened otherwise. It's a bit like Woody Allen's the Great Roe: "A mythological beast with the head of a lion and the body of a lion, though not the same lion."

Comment Re:What should happen and what will happen (Score 1) 130

Using memory dependent hashes works better if one is a small server since one will rarely have a lot of people sending in their passwords at the same time, so the RAM space you need isn't that large. If you are a large organization then this doesn't work as well because you then need room to be able to do many such calculations functionally simultaneously.

Meh. If you are a large organization, you can afford more.

Anyway, the point is that you should turn it up as much as you can afford.

I agree that there's a linear v. exponential difference there(although for many of these it is more like linear and subexponential due to algorithms like the number field sieve),

Yes, NFS is subexponential, but not very "sub". And anyway, RSA is old, broken crypto which should be migrated away from.

but the rest of your comment is essentially wrong. We keep keys just long enough that we consider it to be highly unlikely that they are going to be vulnerable, but not much more than that.

I hate to resort to appeal to authority, but the actual analysis required to prove it is way more effort than I have time for this morning. Take a look at, it has a host of authoritative references.

In fact, it would be a lot safer if we increased key sizes more than we do, but there are infrastructural problems with that. See e.g. discussion at

Heh. In my previous reply I actually typed a long section about why RSA is a weak counterexample to my argument, but deleted it because it's nitpicking. Since you chose to pick that nit...

It's a valid counterexample because RSA key generation, and, to a much lesser extent, RSA private key operations, are computationally expensive enough to stress low-end devices (an issue I often have to deal with... I'm responsible for some of the core crypto subsystems in Android). But it's a weak counterexample because RSA is not modern crypto. It's ancient, outmoded, we have some reasons to suspect that factoring may not be NP hard, using it correctly is fraught with pitfalls, and it's ridiculously expensive computationally. And even still, the common standard of 2048-bit keys is secure for quite some time to come. As that stackoverflow article you linked mentions, the tendency has been to choose much larger-than-required keys (not barely large enough) rather than tracking Moore's law.

So, yeah, if you use an outdated, ridiculously expensive algorithm, and you do it on very low-spec hardware, and you want it to be secure for a very long time then, yeah, you might end up having to use barely-large-enough key sizes.

Don't do that. For asymmetric crypto use ECC. Preferably with an Edwards curve, so you don't have to deal with niggling suspicions that the curve is weak in some obscure way known only to the NSA.

Comment Re:Hard wired (Score 1) 172

As hunter-gatherers (you know, in the time before writing and the invention of religion)

Before writing, yes. I strongly suspect that religion existed even then. All of the hunter-gatherer societies that survived to historical times had religions, often quite sophisticated ones.

Comment Re:What should happen and what will happen (Score 1) 130

The problem with that is on the other practical end: if you massively increase the resources needed will also increase the server side resources; it won't be as bad as it will be on the cracking end, but server resources are expensive.

It won't be as bad as on the cracking end, that's the whole point. The reason for doing password hashing is to exploit the asymmetric level of effort between hashing and brute force search. To make that work, though, you do need to invest as much as you can afford in the server, to move the bar for the attacker as high as possible -- hopefully out of reach of all but the most serious. If you can't afford very much, fine, but realize that you're also not setting the bar very high.

But this is exactly why good password hashing algorithms are moving to RAM consumption as the primary barrier. It's pretty trivial for a server with many GiB of RAM to allocate 256 MiB to hashing a password, for a few milliseconds, but it gets very costly, very fast, for the attacker. And if you can't afford 256 MiB, how about 64?

What you definitely do not want is a solution that takes microseconds and uses a few dozen bytes. That creates a trivial situation for the attacker given modern hardware, and your server absolutely can afford more than that.

This is similar to why we don't use much longer keys for public key encryption and use really large primes for DH key exchange.

Nope. The leverage factor in the password hashing case is linear, since the entropy of passwords is constant (on average). The leverage factor for cryptographic keys is exponential. The reason we don't use much longer keys for public key encryption, etc., is because there's no point in doing so, not because we can't afford it. The key sizes we use are already invulnerable to any practical attack in the near future. For data that must be secret for a long time, we do use larger key sizes, as a hedge against the unknown.

Comment Re:Are two hashes better than one? (Score 1) 130

... however it's worth noting that there are currently no ways of finding a collision for both MD5 and SHA-1 hashes simultaneously

Any crypto geeks want to weigh in on the truth of this statement? I've often wondered about this. Wouldn't using two hash algorithms be easier and more effective over the long term than getting the whole world to upgrade to the Latest And Greatest Hash every ~10 years?

MD5 + SHA1 is a "new hash algorithm". Think about what you have to do to shift to a new algorithm... all of the message formats that have to be updated, all of the stored values that have to be recomputed, all of the cross-system compatibility dances you have to do to ensure that you can upgrade both sides (or all sides; there are often more than two) in order to update without having to make some error-prone attempt to cut over simultaneously.

The challenge of changing hash algorithms has nothing to do with getting correctly-implemented source code for a new algorithm. That's super easy. The challenges are all about how to handle the changeover, which is exactly the same whether you're switching to an actual new algorithm that incorporates the latest ideas and is (currently) completely invulnerable to all known attacks, or to a combination of old, broken algorithms that may or may not be better than either one alone.

The right solution is to build systems with algorithm agility and algorithm negotiation, then to add new algorithms as soon as they're standardized and remove algorithms completely once all parties have updated.

Comment Re:For variable values of "practical" and "relevan (Score 2) 130

Not a lot you can do?

Anything that requires signatures is vulnerable to forgery if the signer's certificate specifies SHA1.

An attacker could forge:

1. Software signatures - to slip malware into a software vendor's distribution channels.

That requires a second pre-image attack, not just a collision attack. (What gweihir called "two-sided" rather than "one-sided"... though that is not standard terminology).

2. SSL certificates - to MITM web connections to phish, steal data, or distribute malware.

Also requires a second pre-image attack.

3. Personal digital signatures - to fabricate documents, including emails, transaction, orders, etc that are normally trusted implicitly due to the signature

This one can be done with a collision attack. You generate two different documents which hash to the same value, but have different contents. The PDF format, unfortunately, make it pretty easy to generate documents which look sensible and have this property. It's not possible with more transparent formats (not without a second pre-image attack).

4. Subordinate CA certificates - to create trusted certificates which permit all of the above

The problem lies with #4.

This can only be done with a collision attack if the CA is really, really stupid. Proper CAs should include chain-length restrictions in their certificates. That way even if you can create two certificates which hash to the same value, one of which has the keyCertSign bit set to true (which the CA would refuse to sign) and one of which does not (which presumably you can get the CA to sign), it wouldn't matter because if you used the former to generate other certs, no one would accept them due to the fact that your chain is too long.

The only solution is to discontinue the use of SHA1 internally and to revoke trust for all CAs that still use SHA1.

I certainly agree that any CA still issuing certificates with SHA1 should not be trusted. Any existing certs based on SHA1 should be scrutinized, but most of them are still secure.

Better crypto has existed for a long time---the standard for SHA2 was finalized in 2001, well over a decade ago.

Absolutely. Of course, I say that as the maintainer (ish) of an open source crypto library that still uses SHA1. In systems that weren't originally designed for digest agility, it's often hard to retrofit. Today's news is a nice kick in the pants, though.

Slashdot Top Deals

How many hardware guys does it take to change a light bulb? "Well the diagnostics say it's fine buddy, so it's a software problem."