Wanting to eject Muslims from the US is a political aim
Bullshit. As of now I've yet to see any policy about ejecting muslims from the US.
I was making the point that one need not seek policy in order to be working towards a political goal... and you respond that you don't see anyone seeking policy, apparently completely missing the point.
Umm, that is an uncited claim in the summary. Nothing of the sort is stated in any of the links. The summary links to a paper that provides more details of the attack. Very heavy and technical though a few inital takeaways from it is that implementations only take a few days to run on gear they have so does seem safe to assume that SHA-1 collisions are pretty much pwned.
The Python script in question doesn't find new SHA-1 collisions. It takes two input PDFs and produces two output PDFs that hash to the same value. It uses some quirks of how PDFs work, plus that original SHAttered collision generated by the Google researchers. Finding another collision is a lot of work. Using a known collision to generate PDFs with the same hash value is not.
I've spent this weekend trying to repurpose an old laptop as a media/streaming machine, and decided to go Linux rather than Windows. It most certainly has not been easier. Maybe if you've worked with the system for years and know the ins-and-outs it is second nature, but Linux has caused all sorts of issues I wouldn't have had on Windows.
If you've worked with Windows for years and know the ins-and-outs of that system, it's a lot easier to set Windows up than something else. Personally, when I have to set up a Windows system, I have a lot of issues I wouldn't have on Linux.
I know because I had to install a Windows system for the first time in about a decade a few months ago. It took me all day and lots of hair-pulling to figure out how to find and install all of the drivers needed to make the thing run. At the end I was still left with a few devices showing errors in the device manager, which I was simply unable to get working. It worked enough, so I gave up on the rest. The worst part of the process was that right after installation Windows had no functioning drivers, for ethernet, Wifi or USB, which made it really hard to get drivers onto the box. I solved this by booting a Linux LiveCD (which worked out of the box), creating a small FAT32 partition, downloading the ridiculously bloated 250MB (WTF?!?) ethernet driver onto it, then booting Windows again and installing from the FAT32 partition. I have no idea how a Windows guy would have solved that.
Stallman may argue that you need to make sure the code is free in the future, but I'd settle for the code being free now.
I don't see any reason they shouldn't do both. They should release it under a good copyleft license, but note on their repository that all source code from the DoD is in the public domain. Those who wish to take the federal code and carefully verify that no non-federal contributions have been added (or who are willing to strip out all of the non-federal code) can use it in whatever way they like, since it's in the public domain. Contributions by others, however, will by default be owned by the contributor but licensed under the copyleft license. In the event someone uses their code in a way that violates the license, they'll have standing to sue for infringement, though the DoD will not.
There's nothing wrong with that use of SHA1, but I can't think of a threat model in which it actually accomplishes anything useful, not because SHA1 is defective, but because passwords are. If an attacker gets the hash, he can almost certainly recover the password. Further, your implied threat model seems to assume that an attacker may be inside the system (which is a good assumption), where he can grab the in-flight hashes. But if that's the case, what prevents the attacker from replaying the hashes? At that point in the system, the hashes are the passwords, they unlock access. So the attacker doesn't even need the user's password.
Also, have you benchmarked SHA256? On modern hardware it's generally cheaper than SHA1. Assuming there actually is a good reason for hashing, you may be able to quiet the complainers and improve performance with one change.
Did this man claim to be a member of some political group?
He clearly considers himself to be part of the American political group that hates/fears Islam. (Also part of the group who confuses all brown people with Middle Easterners, too, but that's not a political group.)
Was there any implication that this kind of violence would be repeated unless some public policy changed?
You don't have to be seeking a policy change to be seeking a political aim. Wanting to eject Muslims from the US is a political aim, and doing it by making them afraid they'll be shot is just as good as governmental action.
Sounds to me like we actually DO know the answer now. It's not, otherwise this sample wouldn't have been destroyed when the diamond applying pressure to it broke.
Maybe it wasn't destroyed. Maybe it just rolled under the coffee table. I hope the dog didn't lick it up.
So out of 172 root CAs only 14 include any path length restrictions, and even the ones who do still allow some chaining.
O_o
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.
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 keylength.com, it has a host of authoritative references.
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.
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.
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.
... 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.
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.
Actually, even with salting, no standard cryptographic hash function is appropriate for password databases. You can squeak by if you iterate the hash function enough times, but even that is pretty weak, since it means that an attacker with lots of GPUs -- or, even worse, special-purpose hardware -- can perform hashes so much faster than you can that the key stretching you obtain is minimal.
The state of the art in password hashing is algorithms like Argon2, with parameters that are tuned to require significant amounts of not just CPU time, but RAM and threads. Argon2, tuned to require, say, 10ms of time on four cores and 256 MiB of RAM, is going to significantly strengthen passwords. The RAM requirement means a GPU with 4 GiB of RAM can only test 16 passwords in parallel, making GPU-based cracking essentially useless, since what GPUs provide is huge parallelism. Custom ASICs would do better, but would still run into bottlenecks on the speed of the RAM. Making really fast cracking hardware would require either huge amounts of RAM, or large amounts of extremely fast RAM. Either way, big $$$.
Even better, if at all possible you should use a hash that is keyed as well as salted. Doing that requires having some place to store the key that won't be compromised by the same sorts of attacks that compromise your password database. In most cases that's hard to do. Argon2 will accept a key so you can get both sorts of protection, though if you can be really, really certain that no attacker can ever get the key, then you can use a standard cryptographic hash function in a keyed mode, e.g. HMAC-SHA256, though I'd still recommend using a purpose-designed password hash (e.g. Argon2) in case your key is compromised.
The amount of voter fraud in the United States is exceedingly low so the whole voter ID laws are a solution in search of a problem.
Voter ID laws solve a very clear problem, just not the one their proponents claim.
There is also widespread evidence that such laws are designed to target democratic voters and that they tend to target the poor and minorities.
Yep, that's the problem: blacks, latinos and white trash voting too much. Voter ID isn't a complete solution, but it's a useful step. I'm sure Bannon has some ideas about the final solution.
Hmm... maybe that is what Trump meant when he claimed three million "illegals" voted for Hillary. He meant "people who shouldn't be allowed to vote", rather than "people who aren't citizens", the way the silly media interpreted the words.
There are so many free sources of news, it may be impossible to sell it in the near future.
But how do those news sources get filtered and curated? The problem today is that there is so much news that you can find someone writing absolutely any story you want, regardless of the facts, and regardless of the relevance or importance.
Wow - this is some pretty cool stuff and I commend Netflix for doing it, but really? Netflix?
It's a tool developed for internal, corporate users, to make Netflix's own operations more secure. They've decided to open source it, probably in hope that others will have good ideas to make it better.
I love my government IT job. After years of working for Fortune 500 IT teams, I'm finally working with the best pros in the industry.;)
Second best.
I spent 15 years as a consultant, working with both fortune 500 companies and government agencies. Government agencies tend to have one of two personalities; either they're quite good or they're horribly bad. Sounds like you got into a good one. Corporate IT departments of non-IT companies tend to be more middle of the road, though variance is huge. But the top tier information technology companies tend to have almost uniformly excellent people.
Or he stirred a lot of it up himself, making things racial that weren't. Along with much of the media. Trayvon Martin was made immediately about race with edited clips of the call to 911 to make it seem like that's why he was being targeted. The truth was much different. Don't let the truth get in the way of your great narrative though.
The truth is that no story about a situation like Trayvon Martin's can possibly be discussed in the south (or various other parts of the country where racial tension is high) without bringing race into it, because whether you say it out loud or not, a lot of people will be assuming that if Trayvon had been white it would have gone down differently. We can't know that for sure, of course.
FWIW, I think the verdict was the only possible one because George Zimmerman's claim that Trayvon had him on the ground and was slamming his head into the pavement wasn't contradicted by any evidence. That situation easily constitutes a deadly threat and justifies the use of deadly force in response. I'm less confident that Zimmerman's story was completely true, but it wasn't inconsistent with the physical evidence and there was no eyewitness testimony.
As for Obama's comments... all he said was that it was imperative that the case be investigated thoroughly, and then he made some sympathetic remarks to Trayvon's parents. How is that "stirring up" racial tension?
I should point out that I'm no fan of Barack Obama. As a conservative-leaning libertarian, I largely disagree with his political philosophy, and I think as a president (politics aside) he was mediocre at best. As a supposed constitutional scholar I was extremely disappointed with his handling of several really important issues related to the balance of power, especially his expansion of the already excessive power held by the executive. Bush did the country great damage by expanding that power dramatically, and Obama should have rolled it back but instead he pushed the pace.
However, even though I didn't like him and didn't agree with him, I see no substance to the argument that he "stirred up" racial tension. He acknowledged it, and at several points he expressed sympathy with the black community and acknowledged his own membership in that community, but that's all. Never did he introduce it where it wasn't already present, and never did he ignore the facts and assign blame based on race. If you have any examples to the contrary, I'd like to see them.
after 8 years of Obama we have more racial tension than ever before
No, we don't. All of that racial tension you're seeing was already there. What happened was that having a black president encouraged black Americans to speak up about the ways in which they're systematically oppressed, which means that you are now more aware of the existing racial tension.
Hillary did exactly that, but the left doesn't seem concerned that they are constantly hypocrites. She had an unsecured device that they told her not to use, and she did anyways. Likely was hacked while she was in Russia.
I realize that the point of this is to generate buzz, but what's the point of buzz if you're going to follow it up with, "Ha ha, just kidding. We're not actually going to sell you the thing we're advertising."
The thing they're advertising is the shake, and they'll absolutely sell it to you. Now, you may not be interested in buying it if you don't get to try the funky straw, but advertisers know that a lot of people who see their ads won't be interested in buying the product. But some will.
And... would you ever have heard of this shake if it weren't for the straw? I wouldn't have. And neither, I'm sure, would many people who actually might be interested in a chocolate mint shake.
This is pretty much the definition of a successful advertising campaign, at least in nerd circles. We're voluntarily discussing a novelty shake from McDonalds! I can't comment on how it will play to the wider audience, but it worked on you. And me.
Slashdot Mirror
Wanting to eject Muslims from the US is a political aim
Bullshit. As of now I've yet to see any policy about ejecting muslims from the US.
I was making the point that one need not seek policy in order to be working towards a political goal... and you respond that you don't see anyone seeking policy, apparently completely missing the point.
Umm, that is an uncited claim in the summary. Nothing of the sort is stated in any of the links. The summary links to a paper that provides more details of the attack. Very heavy and technical though a few inital takeaways from it is that implementations only take a few days to run on gear they have so does seem safe to assume that SHA-1 collisions are pretty much pwned.
The Python script in question doesn't find new SHA-1 collisions. It takes two input PDFs and produces two output PDFs that hash to the same value. It uses some quirks of how PDFs work, plus that original SHAttered collision generated by the Google researchers. Finding another collision is a lot of work. Using a known collision to generate PDFs with the same hash value is not.
https://github.com/nneonneo/sha1collider
I've spent this weekend trying to repurpose an old laptop as a media/streaming machine, and decided to go Linux rather than Windows. It most certainly has not been easier. Maybe if you've worked with the system for years and know the ins-and-outs it is second nature, but Linux has caused all sorts of issues I wouldn't have had on Windows.
If you've worked with Windows for years and know the ins-and-outs of that system, it's a lot easier to set Windows up than something else. Personally, when I have to set up a Windows system, I have a lot of issues I wouldn't have on Linux.
I know because I had to install a Windows system for the first time in about a decade a few months ago. It took me all day and lots of hair-pulling to figure out how to find and install all of the drivers needed to make the thing run. At the end I was still left with a few devices showing errors in the device manager, which I was simply unable to get working. It worked enough, so I gave up on the rest. The worst part of the process was that right after installation Windows had no functioning drivers, for ethernet, Wifi or USB, which made it really hard to get drivers onto the box. I solved this by booting a Linux LiveCD (which worked out of the box), creating a small FAT32 partition, downloading the ridiculously bloated 250MB (WTF?!?) ethernet driver onto it, then booting Windows again and installing from the FAT32 partition. I have no idea how a Windows guy would have solved that.
Stallman may argue that you need to make sure the code is free in the future, but I'd settle for the code being free now.
I don't see any reason they shouldn't do both. They should release it under a good copyleft license, but note on their repository that all source code from the DoD is in the public domain. Those who wish to take the federal code and carefully verify that no non-federal contributions have been added (or who are willing to strip out all of the non-federal code) can use it in whatever way they like, since it's in the public domain. Contributions by others, however, will by default be owned by the contributor but licensed under the copyleft license. In the event someone uses their code in a way that violates the license, they'll have standing to sue for infringement, though the DoD will not.
There's nothing wrong with that use of SHA1, but I can't think of a threat model in which it actually accomplishes anything useful, not because SHA1 is defective, but because passwords are. If an attacker gets the hash, he can almost certainly recover the password. Further, your implied threat model seems to assume that an attacker may be inside the system (which is a good assumption), where he can grab the in-flight hashes. But if that's the case, what prevents the attacker from replaying the hashes? At that point in the system, the hashes are the passwords, they unlock access. So the attacker doesn't even need the user's password.
Also, have you benchmarked SHA256? On modern hardware it's generally cheaper than SHA1. Assuming there actually is a good reason for hashing, you may be able to quiet the complainers and improve performance with one change.
Did this man claim to be a member of some political group?
He clearly considers himself to be part of the American political group that hates/fears Islam. (Also part of the group who confuses all brown people with Middle Easterners, too, but that's not a political group.)
Was there any implication that this kind of violence would be repeated unless some public policy changed?
You don't have to be seeking a policy change to be seeking a political aim. Wanting to eject Muslims from the US is a political aim, and doing it by making them afraid they'll be shot is just as good as governmental action.
Sounds to me like we actually DO know the answer now. It's not, otherwise this sample wouldn't have been destroyed when the diamond applying pressure to it broke.
Maybe it wasn't destroyed. Maybe it just rolled under the coffee table. I hope the dog didn't lick it up.
So out of 172 root CAs only 14 include any path length restrictions, and even the ones who do still allow some chaining.
O_o
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.
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 keylength.com, 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 http://crypto.stackexchange.com/questions/19655/what-is-the-history-of-recommended-rsa-key-sizes
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.
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.
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.
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.
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.
The second to last Yahoo security breach was so bad in part because the passwords were hashed with a completely unsalted MD5 https://nakedsecurity.sophos.com/2016/12/15/yahoo-breach-ive-closed-my-account-because-it-uses-md5-to-hash-my-password/. The lack of salting would have been by itself a problem even when MD5 was still considered secure.
Actually, even with salting, no standard cryptographic hash function is appropriate for password databases. You can squeak by if you iterate the hash function enough times, but even that is pretty weak, since it means that an attacker with lots of GPUs -- or, even worse, special-purpose hardware -- can perform hashes so much faster than you can that the key stretching you obtain is minimal.
The state of the art in password hashing is algorithms like Argon2, with parameters that are tuned to require significant amounts of not just CPU time, but RAM and threads. Argon2, tuned to require, say, 10ms of time on four cores and 256 MiB of RAM, is going to significantly strengthen passwords. The RAM requirement means a GPU with 4 GiB of RAM can only test 16 passwords in parallel, making GPU-based cracking essentially useless, since what GPUs provide is huge parallelism. Custom ASICs would do better, but would still run into bottlenecks on the speed of the RAM. Making really fast cracking hardware would require either huge amounts of RAM, or large amounts of extremely fast RAM. Either way, big $$$.
Even better, if at all possible you should use a hash that is keyed as well as salted. Doing that requires having some place to store the key that won't be compromised by the same sorts of attacks that compromise your password database. In most cases that's hard to do. Argon2 will accept a key so you can get both sorts of protection, though if you can be really, really certain that no attacker can ever get the key, then you can use a standard cryptographic hash function in a keyed mode, e.g. HMAC-SHA256, though I'd still recommend using a purpose-designed password hash (e.g. Argon2) in case your key is compromised.
The amount of voter fraud in the United States is exceedingly low so the whole voter ID laws are a solution in search of a problem.
Voter ID laws solve a very clear problem, just not the one their proponents claim.
There is also widespread evidence that such laws are designed to target democratic voters and that they tend to target the poor and minorities.
Yep, that's the problem: blacks, latinos and white trash voting too much. Voter ID isn't a complete solution, but it's a useful step. I'm sure Bannon has some ideas about the final solution.
Hmm... maybe that is what Trump meant when he claimed three million "illegals" voted for Hillary. He meant "people who shouldn't be allowed to vote", rather than "people who aren't citizens", the way the silly media interpreted the words.
Back when I was in school (when the Earth was still cooling)
The Earth is still cooling, even if its climate is warming.
There are so many free sources of news, it may be impossible to sell it in the near future.
But how do those news sources get filtered and curated? The problem today is that there is so much news that you can find someone writing absolutely any story you want, regardless of the facts, and regardless of the relevance or importance.
Wow - this is some pretty cool stuff and I commend Netflix for doing it, but really? Netflix?
It's a tool developed for internal, corporate users, to make Netflix's own operations more secure. They've decided to open source it, probably in hope that others will have good ideas to make it better.
Yep. Exactly. Gotta love government IT workers!
I love my government IT job. After years of working for Fortune 500 IT teams, I'm finally working with the best pros in the industry. ;)
Second best.
I spent 15 years as a consultant, working with both fortune 500 companies and government agencies. Government agencies tend to have one of two personalities; either they're quite good or they're horribly bad. Sounds like you got into a good one. Corporate IT departments of non-IT companies tend to be more middle of the road, though variance is huge. But the top tier information technology companies tend to have almost uniformly excellent people.
Or he stirred a lot of it up himself, making things racial that weren't. Along with much of the media. Trayvon Martin was made immediately about race with edited clips of the call to 911 to make it seem like that's why he was being targeted. The truth was much different. Don't let the truth get in the way of your great narrative though.
The truth is that no story about a situation like Trayvon Martin's can possibly be discussed in the south (or various other parts of the country where racial tension is high) without bringing race into it, because whether you say it out loud or not, a lot of people will be assuming that if Trayvon had been white it would have gone down differently. We can't know that for sure, of course.
FWIW, I think the verdict was the only possible one because George Zimmerman's claim that Trayvon had him on the ground and was slamming his head into the pavement wasn't contradicted by any evidence. That situation easily constitutes a deadly threat and justifies the use of deadly force in response. I'm less confident that Zimmerman's story was completely true, but it wasn't inconsistent with the physical evidence and there was no eyewitness testimony.
As for Obama's comments... all he said was that it was imperative that the case be investigated thoroughly, and then he made some sympathetic remarks to Trayvon's parents. How is that "stirring up" racial tension?
I should point out that I'm no fan of Barack Obama. As a conservative-leaning libertarian, I largely disagree with his political philosophy, and I think as a president (politics aside) he was mediocre at best. As a supposed constitutional scholar I was extremely disappointed with his handling of several really important issues related to the balance of power, especially his expansion of the already excessive power held by the executive. Bush did the country great damage by expanding that power dramatically, and Obama should have rolled it back but instead he pushed the pace.
However, even though I didn't like him and didn't agree with him, I see no substance to the argument that he "stirred up" racial tension. He acknowledged it, and at several points he expressed sympathy with the black community and acknowledged his own membership in that community, but that's all. Never did he introduce it where it wasn't already present, and never did he ignore the facts and assign blame based on race. If you have any examples to the contrary, I'd like to see them.
after 8 years of Obama we have more racial tension than ever before
No, we don't. All of that racial tension you're seeing was already there. What happened was that having a black president encouraged black Americans to speak up about the ways in which they're systematically oppressed, which means that you are now more aware of the existing racial tension.
Hillary did exactly that, but the left doesn't seem concerned that they are constantly hypocrites. She had an unsecured device that they told her not to use, and she did anyways. Likely was hacked while she was in Russia.
http://www.mediaite.com/online/clinton-emailed-from-unsecure-phone-because-nsa-denied-her-request-for-a-better-one/
Yes. That's a terrible breach of security when a Secretary of State does it.
It's about a hundred times worse when a President does it.
Instead of letting us build a profile of our own, they try to guess what we want and then complain that "ads are not working".
Here you go: https://www.google.com/ads/pre...
I realize that the point of this is to generate buzz, but what's the point of buzz if you're going to follow it up with, "Ha ha, just kidding. We're not actually going to sell you the thing we're advertising."
The thing they're advertising is the shake, and they'll absolutely sell it to you. Now, you may not be interested in buying it if you don't get to try the funky straw, but advertisers know that a lot of people who see their ads won't be interested in buying the product. But some will.
And... would you ever have heard of this shake if it weren't for the straw? I wouldn't have. And neither, I'm sure, would many people who actually might be interested in a chocolate mint shake.
This is pretty much the definition of a successful advertising campaign, at least in nerd circles. We're voluntarily discussing a novelty shake from McDonalds! I can't comment on how it will play to the wider audience, but it worked on you. And me.
Why bad lip reading? Why not your basic garden variety bad speech recognition?
https://www.youtube.com/user/BadLipReading