Follow Slashdot stories on Twitter


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:Turn it off (Score 1) 232

Can you really expect an 8 year old OS to support the latest USB chipset out of the box?

Seems reasonable to me. Perhaps not full support, but enough to talk to a mass storage device seems very reasonable. It's not like this is a rapidly-evolving space.

Does the manufacturer even supply Windows 7 drivers that you could burn to CD and install?


Comment Re:Turn it off (Score 1) 232

Yep, that's the problem, Windows 7 on a machine designed for Windows 10. Microsoft require basic stuff like USB to work for the computer to carry the "designed for Windows" sticker, but of course only the version that it ships with.

You say that as though it makes sense. I installed a several-year-old copy of Debian Linux on the same machine without trouble. The USB controller chipset is newer than that old kernel, for example, but the generic controller drivers in the kernel work fine.

Comment Re:Turn it off (Score 1) 232

I have no idea how a Windows guy would have solved that.

You can make a Windows live CD (called Windows PE). It's rarely necessary though.

It sounds like the version of Windows you were trying to install was not officially supported by your hardware.

I was installing a purchased copy of Win7 on a machine that came with Win10, because the tools I needed to use (for which I purchased the machine) only run on Win7. Of course, the vendor of said tools didn't bother to document that anywhere.

For your scenario. downloading the drivers onto a USB flash drive is usually the simplest option. In a pinch you can download on your phone and simply connect a USB cable to the computer, or the flash drive to the phone.

As I said in my post above, Windows didn't have drivers for the USB controller. USB was not available.

Comment Re:People without a clue commenting on crypto (Score 1) 197

> If an attacker gets the hash, he can almost certainly recover the password.

How, other than brute force?

Why do you exclude brute force? Brute forcing typical user passwords given a cryptographic hash of them, even salted, and regardless of the hash function used, is very easy. Brute force is exactly the attack I was talking about.

It's best to assume that possession of a hash of a low-entropy secret is equivalent to possession of the low-entropy secret itself.

Comment Re:Why (Score 1) 1105

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.

Comment Re:"In the wild" - slight exaggeration (Score 2) 159

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.

Comment Re:Turn it off (Score 3, Insightful) 232

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.

Comment Re:What's wrong with public domain code? (Score 1) 49

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.

Comment Re:People without a clue commenting on crypto (Score 1) 197

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.

Comment Re:Why (Score 4, Insightful) 1105

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.

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

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:What should happen and what will happen (Score 1) 142

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) 189

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) 142

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.

Slashdot Top Deals

"It ain't so much the things we don't know that get us in trouble. It's the things we know that ain't so." -- Artemus Ward aka Charles Farrar Brown