Follow Slashdot stories on Twitter


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:Same error, repeated (Score 1) 307

by Xylantiel (#49127893) Attached to: Moxie Marlinspike: GPG Has Run Its Course

Yes, same error, but you missed it. The fundamental problem is that truely secure non-centralized key verification is HARD. If the bank publishes their GPG key, why would you trust it?

Tools for managing one's trust network barely exist. This problem is not isolated to GPG. This problem is so difficult that the more commonly used protocols, HTTPS and S/MIME, solve it effectively by ignoring it and replacing it with a system in which individuals have little or no control over their trust network. Marlinspike has participated in efforts to improve the trust network for HTTPS, but makes the same error, as use of his tools requires one to trust him.

Comment: Re:No single point of failure is permissible (Score 1) 98

Exactly. The problem here is the way the SIM is being used. The SIM manufacturer stores a key on the SIM and gives a copy to the carrier. Then if the NSA can just steal the key (from the SIM manufacturer or the carrier) they can do all sorts of nasty. The right way to do this is have a private key generated on the SIM and never leaving it and the carrier only gets the corresponding public key from the SIM manufacturer. Then the information that the SIM manufacturer and the carrier has is not sensitive and cannot be used to impersonate the SIM and decrypt communications. I'm sure there are reasonable historical reasons why the "right thing" is not being done. This reminds me of wifi which took several iterations of the standard to get something that is not trivially insecure, and even still it is not too hard to just pick the wrong settings and it becomes insecure.

Comment: Why are they using SIMS this way? (Score 1) 155

by Xylantiel (#49113363) Attached to: NSA, GHCQ Implicated In SIM Encryption Hack
The first article says they are just storing a secret key on the SIM and on the network provider's systems. That is just dumb and was totally insecure even before this happened. They should be using privat/public key pairs in which the private key is generated on and never leaves the SIM.

Comment: Re:Nuclear plants don't like sudden shutdowns (Score 2) 311

by Xylantiel (#49064305) Attached to: Nuclear Plant Taken Down In Anticipation of Snowstorm
Even if they had gotten the generators, you can't just rewire things on the spur of the moment like that, especially not when a significant section of the country has also been wiped out. Of course if they had proper hardened vents like are required in the US, there wouldn't have been any explosions. Still would have been a technical loss of containment due to the necessity of venting, and probably still a meltdown, but the destruction of the outer containment and cooling systems by the explosions was the real disaster.

Comment: Re:I can't wait! (Score 1) 471

by Xylantiel (#48969557) Attached to: Systemd Getting UEFI Boot Loader

The case in the article seems like an example of this kind of problem with the systemd team. Instead of working with one of the prominent bootloaders to get the UEFI trust chain worked out, they just adopt an infrequently-updated nonstandard (sounds like = buggy) bootloader and run with it. This has the effect of abandoning all the work already put in by the prominent bootloaders to get corner cases working. It's a shortcut so systemd can add a bullet to their feature list, but provides the feature in such a way that it is buggy for many use cases.

I don't object so much to replacing sysv init, but the systemd team appears to have a tendency toward repeatedly reinventing the wheel badly just to get things done faster, and being kinda rude about it, and that makes one a bit uneasy. Though I'm honestly unsure if this is just the sensationalization of a few usual cases or more typical behavior.

Comment: Re:If it's accessing your X server, it's elevated (Score 1) 375

by Xylantiel (#48926689) Attached to: Why Screen Lockers On X11 Cannot Be Secure
The lock screen and the login screen are different things in X. Typically on X ctrl-alt-backspace will kill the X server and give you a fresh login screen. I always thought that the assumption is that propagating this behavior from login to unlock has too many gotchas to be worthwhile. In an environment where security is essential, you should always log out instead of locking and hit ctrl-alt-backspace before you log back in.

Comment: Useful changes (Score 5, Interesting) 55

by Xylantiel (#48860493) Attached to: Jim Blasko Explains BitCoin Spinoff 'Unbreakable Coin' (Video 1 of 2)
How about a cryptocurrency that targets an inflation rate that is known to be economically stable, say 2%, by standardizing on a openly evaluated standard basket of goods. You know, how actual currencies work but without the middlemen of the reserve banks. Most of the discussion of cryptocurrencies don't even distinguish growth of money supply from inflation, even though they are two entirely different (though related) things. The cryptocurrencies currently termed "inflationary" just grow their money supply. That's not even what is meant by "inflation" when discussing real currencies like the dollar or the euro.

Comment: Re:Particularly given their Android response (Score 3, Insightful) 263

by Xylantiel (#48833823) Attached to: Google Releases More Windows Bugs

The other option is that Microsoft could acknowledge reality - they are not fixing things fast enough to resist targeted attacks. MS's statement about it "not being seen in the wild" demonstrates that they don't understand the current state of exploits. Google's hypothetical attacker is one who will go to lengths to keep an exploit from being used specifically so that MS won't fix it. Also a monthly schedule for updates is a huge liability against such an attacker, as they know their window of opportunity. MS is stuck in the old model that an exploit is not important unless it has been seen in the wild. While that is all well and good for preventing worms from spreading (and therefore protecting MS's image) it is not good enough to protect your company's data from a targeted attack that can buy or discover a zero-day vulnerability. That is reality.

Another way to look at it is that people using MS stuff have chosen interoperability over security. Thus the longer patch testing cycle, and the once-a-month updates. Therefore they shouldn't be surprised when it is demonstrated that... they chose interoperability over security.

Comment: Re:Screw them (Score 2) 141

by Xylantiel (#48824979) Attached to: Google Glass Is Dead, Long Live Google Glass

You seem to have missed the fact that even with the early google search, they used javascript tricks to send every click on a link back to google. That is pretty darn close to spying, since it was not obvious that they were doing this. You don't seem to have noticed that you were being spied on.

So the model for search as well as for gmail was the user trading their privacy for a service. Thus "built on the concept of invading privacy". I think this is a much more even trade on the search side - I'm not averse to reporting to google which of their search results I looked at for a given query before I left the page. That provides better search. But I think one can make an argument that even offering a service in which you are scanning the user's email to market things to them is inherently evil. If you found out your IT staff at a company was just trolling through email for anything you would fire them in a second. Then it just went downhill from there. Though Big Brother Facebook beat Big Brother Google in the race to the bottom.

Comment: Re:No, it doesn't!!! (Score 1) 629

by Xylantiel (#48797019) Attached to: Google Throws Microsoft Under Bus, Then Won't Patch Android Flaw

The fact is that the vendor you purchased your device from (Verizon) actively discourages third-party updates is between you and them. In most cases you cat jailbreak your device and install cyanogenmod, which is pretty similar to what you describe. The status of vendor-supplied updates has been discussed since the inception of Android. Google has mostly made the situation better compared to before Android, since updates for many devices are now controlled by the hardware vendor instead of the network provider. When you purchased your device, you chose to get something from a vendor (Verizon) who is well-known to be hostile to its customers. Don't complain that google didn't save your bacon. You could have bought a Google nexus 7, which is still getting updates, though the latest makes the old ones too slow to use. (In fact they did save your bacon, because you could just root your device to install cyanogenmod. Except that it appears that verizon patched the hole that was being used to root it! Wow that's hostile.)

In the case of Windows, you probably purchased your machine from someone like Dell (not comcast, which would be the closest analog of Verizon in the PC world) and it at least purported to have software from a separate vendor, Microsoft. Verizon, by locking the bootloader, actively prevents you from using system software from another vendor.

Comment: Re:Funny how "free trade" is not on this level (Score 1) 437

by Xylantiel (#48728265) Attached to: Netflix Cracks Down On VPN and Proxy "Pirates"
Buy? What is this buy thing that you speak of? We only rent our culture at this point, it's all actually owned by corporations. Or put a more serious way: does havig something available on netfix even count as being distributed for copyright purposes? I didn't think that movie theater shows did, since they are technically private exhibitions. I think HBO does, but what about netflix?

Comment: Re:PRIVATE encryption of everything just became... (Score 1) 379

I think typically each file would be encrypted with a separate symmetric key. Then you can choose who is able to decrypt it by sticking a header with this key encrypted for various public/private key pairs. Then all you have to do is remove one of the encrypted keys, not re-upload the whole file.

As far as I know asymmetric encryption is never used the way you say in practice. It is too slow. It is used to encrypt a key for a symmetric cipher that is then used to encrypt the actual data. And that "combining your private key and their public key" statement is nonsense. Your private key is useless for securing information originating from you, since your public key is, well, public. It is useful for authenticating that information came from you, which is independent of recipient.

This is all setting aside the fact that once a party has access to some data, "revoking" that access has a sortof squishy meaning because they can just keep a copy of what they retrieved before.

Comment: Re:Just wondering... (Score 4, Insightful) 416

by Xylantiel (#48575427) Attached to: MIT Removes Online Physics Lectures and Courses By Walter Lewin

I would expect removing them would be to prevent anyone else being a victim. Rather than marking every page with him on it with a "warning this former faculty was found to have sexually harassed students," the prudent course of action is to shut it all down and sort things out later. While Lewin is no longer active in the courses, they are still active courses and a student might approach him if they didn't know about the issue. There are plenty of other physics faculty at MIT that can fill in the content.

Machines certainly can solve problems, store information, correlate, and play games -- but not with pleasure. -- Leo Rosten