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:Why (Score 1) 943

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 GIT (Score 1) 129

Does the Git usage of SHA-1 *really* cause silent problems? I'm not sure how Git works internally but I was under the impression that it hashes whole objects, like individual source files at least.

The individual objects inside git aren't file.
The individual objects are commits (i.e..: the content of a patchfile, and a few information like pointer to other past commits to which this patch applies).
To make things easier, a handy number designates this commit - this is currently generated by SHA-1.

(Git is a content-addressable platform. You don't access object by name, you access them depending on their content. But instead of using the whole content to access them, you use addresses generated by SHA-1 to access the various blocks.
So to say which are the parent commits to which the patch in a commit applies, you just mention them by using the SHA-1 sum of the content of these commits).

A theoretical attack would be:
- try to generate 2 commits.
one adds a clean piece of code. the other adds a backdoored piece of code.
but both commits hash to the same SHA-1 so they would be considered as "the same content" by git.
Then try to force your target to re-download the whole repo from scratch from your backdoored history (otherwise git will simply ignore the commits with sha-1 sum that it already has - it thinks that it has the same content already).

In practice it's currently not doable.
The only thing that google managed to generate is a pair of block series. Each series contain completely random junk. Both series end-up generating the exact same shasum even if the random junk is different.
- That is exploitable in a PDF (or any other binary format that supports scripting. You could even do it in an EXE) : using the embed scripting present 2 different contents depending on which random junk is present.
- That is not exploitable in a sourcecode commit : you would need a believable explanation for why the random junk is present in the patched source code.
AND you would need a piece of code which reacts differently (normal vs. backdoor) depending on which random junk is present - to be able to pull that unnoticed would require "Underhanded C Contest"-level of ingenuity.

That's it, you only have blocks of random garbage.
Google currently can't produce hashes colliding from arbitrary pieces of data ("Hey google: here's is legit script A, and that's malicious script B. Add a small nonce at the end so they both end-up having the same sha-1sum") ("Actually don't add a nonce, that would be too conspicuous, try to tweak the punctuation in the comments instead")

Also as you mention, further edits will be problematic :
if I edit script A and submit a patch, this patch will be valid, but will completely fail on top of script B.

Comment SHA-1 in git and co (Score 1) 129

A cryptographic hash function has the properties you mention, plus the fact that it must not be easily reversible and uniformly distribute results over its entire output space.

The later is a property which is not guaranteed by most common checksums.
Thus, when you need a hash function to give a number to use as a handy "nickname" for a collection of data (e.g.: for a hash look-up table. Or for a content-addressable like git to create said addresses for a given content - and thus to give a serial number to a commit. Or apparently also used in SVN to give a simple number to designate commits), it might be a good choice to pick-up a cryptographic hash like SHA-1 because it guarantees you this additional property, which a vanilla checksum could lack.

Comment Re:"In the wild" - slight exaggeration (Score 1) 129

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 2) 179

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:Too good to be true. (Score 2) 175

It doesn't work like that. Radiative heating/cooling works via exchange of IR. You're not just giving it up; everything you're radiating at is proportionally radiating back at you. So you cool the most when you're radiatively exchanging with something that's very cold. Aka, you want to be radiatively exchanging with the cosmic microwave background, not with low-altitude clouds. That's the whole point of radiating at low absorption frequencies in the atmosphere: so that you're exchanging with space, not with atmospheric air.

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

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 Uniformity (Score 1) 187

If you only care about random bit flips CRC32 will work very well and be much faster than MD5 or SHA-1.

Well, not exactly.
- MD5 and SHA-1 have fast hardware implementation on some CPUs. CRC32 won't necessarily be a huge performance gain.

SHA-1 is used a bit more than a simple glorified checksum in GIT.
It is also used to give a handy number by which you designates commits, etc.
(i.e.: to compute a hash - e.g.: as would also be used in a hash look-up table).
That requires good output uniformity.
In other words you'd need a hashing function that "spreads" its output accross the whole output domain.
(to give an over-simplified examples: if due to a poor design, all patches ended-up having hashes that begins with the hex number "9", that would be a poor hashing function for these needs. If you used it in a hash lookup table, one part of the table would be over filled, while other would be still empty)

Cryptographic hashing functions offer these guarantees among lots of others. CRC32 doesn't, and several of the other checksums that were quickly designed for speed have also been detected not to offer these.

At this situation, a programmer can choose two paths :
- Some coder would try design their own new hashing which offers both good speed and the important properties (e.g.: That's exactly what LZ4's Yann Collet did, and created xxHash64. It's not a cryptographic hash, but at least offers all the properties that cyann needed)
- Other would instead jump to a quick'n'dirty solution, and go for the major overkill: take a cryptographic hash (e.g.: And that's what Linus Torvalds did. He's a lazy git. He knows that a cryptographic hash would provide all the properties he needs. SHA-1 is one that was popular back then, had even some hardware implementation. So he picked it and didn't think much about it. It offers all the properties Linus needed for git. It also offered much more but Linus didn't give a fuck about that. Though it doesn't offer security (anymore. specially since the google proof of concept) but that's something that Linus doesn't care and didn't even bother to check (as mentioned SHA-1 was already suspected backthen, and serious cryptographic usage relied on SHA-2 instead), relying instead on signed repositories if security is needed).

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

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 Not an assumption: actual non-India use. (Score 1) 45

And on exactly what basis do you make this assumption?

It's NOT an assumption. It's the personal anecdotal experience of what is running on my phone.
I'm not from India, I'm from Europe.
I have a Microsoft account and it's configured to use a time-based OTP as a second factor in the 2 factor authentication.
I don't have biometrics configured as a way to log-in.
I don't even have my biometrics data stored in the Aadhaar database.

I installed Skype Lite (note: like with Facebook's "Lite" applications, you need to side-load it manually, because inside the Google Playstore the app is geo-restricted and the store will refuse to install it on smartphone outside the target market).
App asks me my credential, app asks me my 2nd factor.
That's it, it works.

At no point in time did it ask me to upload my biometrics into the Aadhaar database, nor did it even consider using biometrics as an authentication factor.
So even if Aadhaar is apparently a leaky mess of privacy violations, I'm not concerned by it.
My fingerprints are not going to get pwnd and leaked to the net by Aadhaar as they don't have them.

So okay, I'm a single data point. Maybe there are other factors that I'm overlooking.
But still, my personnal anecdotal experience is a good sign that people outside of India could be using Skype without beeing affected by Aadhaar's "peculiar" relationship with personal information and privacy.
The only limitation that I've seen is the Playstore's own geo-locking, preventing non-Idan google accounts to deploy the app. (This can easily be circumvented by manually installing).
No practical limitation would prevent a US user, like the top poster, to use it in the USA (just like I did) and enjoy a skype client that only uses a fractions of the resources that the current mainstream android app uses.

The same is similarily valid with Facebook Lite and Facebook Messenger Lite.

Comment Re:Monopolies hurt everyone but (Score 1) 85

"That sort of thing" stopped, technically, in 1996 by federal law. No, really.

Here's the NYC cable franchise agreements:

Inconveniently, they're non-searchable PDFs. But, go read em. Every one of them is a non-exclusive franchise agreement, because exclusive ones have been illegal since the Telecoms act of 1996. True story.

Now, reality on the ground is that 'overbuilding' has basically lead to bankruptcy every time it's every been tried due to the huge first-mover advantage. And, it's not that government is blameless... they'll usually demand 100% coverage of a region not pick-n-choose customers. But, it's wrong to say that the Franchise Agreements are exclusive.

Comment Seems simple to me (Score 1) 230

We don't need a right to repair law. All we need is a law that says if a manufacturer adds something to a product to make it harder for the end-user to fix, then they must fix the product for free forever.

The rationale being that if the end-user is not free to fix the product, then the end-user is not the owner. The end-user has merely rented the product. The manufacturer is still the owner, and thus is responsible for the cost of repairs.

Comment Re:Ever notice how Hollywood (Score 1) 43

I posted a brief analysis in a previous article (using the RIAA and MPAA's own numbers) showing how Hollywood tries to hamstring industries with a much larger economic contribution than theirs. And provided accounting evidence (using Sony's own annual reports) how their music division almost single-handedly killed their audio electronics division by forcing them to use DRM.

I'm sure someone could do the same for global sales.

Comment Re:I think the difference is (Score 1) 943

I would reckon your odds of surviving being run over by a truck are much lower than surviving being shot.

After 2016, I would've thought it would've been obvious to everyone that guns weren't the problem. If you take away guns, the crazies will just resort to other methods to kill people (like trucks - the fantasy that they'd use knives is only true for crimes of passion, but not for deliberate killings like this one). Heck, the driver of the truck in Nice had a gun, and opted to use the truck instead. Likewise, in the Brussels attack, the terrorists realized they'd probably be shot and killed quickly by armed security had they charged in guns blazing, so they resorted to using bombs which would inflict casualties before security could respond.

This is like those checklists criticizing anti-spam solutions. Outlawing the tools doesn't work. You have to recognize and admit that violence is a social problem and concentrate on solutions which address why people might resort to violence.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (9) Dammit, little-endian systems *are* more consistent!