Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Submission + - Transforming robot gets stuck in Fukushima nuclear reactor

An anonymous reader writes: The ability to change shape hasn’t saved a robot probe from getting stuck inside a crippled Japanese nuclear reactor. Tokyo Electric Power will likely leave the probe inside the reactor housing at the Fukushima Dai-ichi complex north of Tokyo after it stopped moving. On Friday, the utility sent a robot for the first time into the primary containment vessel (PCV) of reactor No. 1 at the plant, which was heavily damaged by the 2011 earthquake and tsunami in northern Japan. 'The robot got stuck at a point two-thirds of its way inside the PCV and we are investigating the cause,' a Tokyo Electric spokesman said via email. The machine became stuck on Friday after traveling to 14 of 18 planned checkpoints.

Submission + - The 'Page 63' Backdoor to Elliptic Curve Cryptography 3

CRYPTIS writes: The security of Elliptic curve cryptography is facilitated by the perceived 'hard' problem of cracking the Discrete Logarithm Problem (DLP) for any given curve. Historically, for FIPS (Federal Information Processing Standards) compliance it was required that your curves conformed to the FIPS186-2 document located at http://csrc.nist.gov/publicati... . Page 63 of this specifies that the 'a' and 'b' elliptic curve domain parameters should conform to the mathematical requirement of c*b^2 = a^3 (mod p).

Interestingly, back in 1982, A. M. Odlyzko, of AT & T Bell Laboratories, published a document entitled “Discrete logarithms in finite fields and their cryptographic significance” ( http://www.dtc.umn.edu/~odlyzk... ). Page 63 of this document presents a weak form of the DLP, namely a^3 = b^2*c (mod p).

It seems then, that the National Institute of Standards and Technology (NIST), driven in turn by the NSA, have required that compliant curves have this potentially weak form of the DLP built in; merely transposing the layout of the formula in order to obtain what little obfuscation is available with such a short piece of text.

Comment Re:One highly-publicized case is all it took (Score 1) 489

This is a really good fair question. I thought about this because in my reply to the article, I cited this same example.

A private company paid a bunch of money to another private company and users got better video streaming performance.

So which private company paid which private company? In this case, Netflix paid Comcast. Isn't that... odd? Netflix paid Comcast even though Comcast did absolutely nothing?

So imagine if Comcast wasn't a monopoly. I can think of 3 possibilities: 1) Comcast would have upgraded their infrastructure. 2) Customers would have moved to another ISP who had more bandwidth. 3) Comcast would have paid Netflix to colocate their servers within Comcast's network, since it saves Comcast from having to upgrade their infrastructure.

Because Comcast is a monopoly, they profited from *not* upgrading their service. That's maddening! But that is what monopolies do: they profit from extorting other companies using their monpoly power, rather than profiting from providing a good product. So the net result is that Comcast customers don't have better bandwidth. So what happens when another content provider has bandwidth problems with Comcast customers? Perhaps the company will fold. Or perhaps they will do what Netflix did, continuing the ugliness.

Now here's a criticism of my argument: What did the FCC's network neutrality do to prevent this scenario? I'm not sure it actually helped. Can someone chime-in on that? What does the new regulation do for deals like this between ISPs and content providers? I'm not sure there is a solution here other than competition.

Comment Interesting article (Score 4, Interesting) 489

The article is full of colorful language about network neutrality advocates, but also some sound reasoning that is unfortunately based on technical misunderstandings or misinformation. Once you look past the mischaracterizations (it's a political piece, after all - you speak to your audience and insult everyone who disagrees with you before you even consider making a point!), it's actually not that bad. There are lots of items in it that I'd like to respond to, as if I could fix the author's misunderstandings, but I'll just pick a one:

The more good content that providers make available, the more consumers will demand access to sites and apps, and the more ISPs will invest in the infrastructure to facilitate delivery.

That's what we want, but that isn't what is happening. The ISPs have little economic incentive to invest in infrastructure since they are mostly monopolies. That's why Comcast chose, instead of upgrading their bandwidth when customers started watching Netflix, to pressure Netflix into co-locating servers within Comcast's network. They only could do that because they are a monopoly. Comcast customers could not choose to switch to another provider, and Netflix cannot choose to route around Comcast.

One would think that after 10 years of political teeth-gnashing, regulatory rule making, and relentless litigating, there would by now be a strong economic case for net neutrality—a clear record of harmful practices and agreements embodying the types of behavior that only regulation can pre-empt. But there isn't.

This sounds like someone citing their ignorance on a topic as evidence that something didn't happen. In general, the authors need to recognize that:
- ISPs are tied to cable/telecom monopolies.
- ISPs can't pick different "business models" without impacting individuals' free speech.
- We learned these lessons from what came before the internet. :-) Clearly they never had to dial-up to Prodigy to see one "web site" and then use Compuserve to see another one, then dial AOL to email someone else.
- We've had real issues without Network Neutrality.

It will be interesting to see how "broken" the internet is in 10 years. Usually those predicting doom and gloom fade away. We shall see, eh?

Comment Re:The answer to the problem (Score 1) 153

Assuming you're aware that it requires an online server when you buy it.

I recently bought LEGO Batman 3 since I love the LEGO games and enjoyed the previous two Batman games in the series. None of them have ever had an online component. LEGO Batman 3 has no online multiplayer, it only has single player and split screen co-op.

Guess what? It requires an online connection to some server somewhere. This isn't mentioned in the Steam page anywhere. If you can't connect to the server, you can't play the game.

I hadn't thought to check if it required an Internet connection to play because why the fuck should it?!! (And if I had checked, I almost certainly wouldn't have found out about it because none of the reviews mention that fact.)

Comment Re:Opposite? (Score 1) 42

The only way a new header is going to work is if you use http:/// for the first request, and then include a header that tells the browser it can pull the same pages over TLS, but without doing authenticity checks on the certificate.

That's what I meant. Someone further up the comment chain said that is how OE works. First it connects with HTTP, then when "data is submitted" (I took that to mean a forms submission) it uses the OE.

So, in trying to understand the intent here:

No, we created it to make it actually possible to do unauthenticated encryption with self-signed certificates on public websites.

We already have that capability, but as you say:

Currently, nobody uses self-signed certs because of the invalid cert warnings.

So that seems to confirm that yes, the purpose of this is to hide the cert warnings. Am I missing something?

Aside: I just learned about dh_anon, which actually does not even require a certificate. Interesting.

Comment The only part that matters (Score 1) 136

Once they received the names of account holders, the company would then have to prove copyright infringement had taken place.

So long as they have to prove the infringement took place, then I have no problem with this. If someone commits copyright infringement, and the copyright holder can go to court and prove it, then the legal system is working. But does it seem likely that they will file 4,726 unique court cases? They will instead send extortion letters, or do a big massive case, or sue the ISPs to recover the money, or something like that.

Comment Re:Opposite? (Score 1) 42

So we created this mechanism just to hide the certificate prompt? It seems like it would be better just to put text on the form that says "Hey, I used a self-signed certificate so ignore the message you see when you click submit" then just submit the form to an HTTP URL as usual. Alternatively, we could standardize on an HTML meta-attribute or HTTP header attribute that tells the browser to ignore the cert. No special browser feature required.

Surely I am missing something here.

Submission + - Research Finds Shoddy Security on Connected Home Gateways (securityledger.com)

chicksdaddy writes: Connected home products are the new rage. But how do you connect your Nest thermostat, your DropCam surveillance device and your Chamberlin MyQ "smart" garage door opener? An IoT hub, of course. But not so fast: a report from the firm Veracode (https://info.veracode.com/whitepaper-the-internet-of-things-poses-cybersecurity-risk.html ) may make you think twice about deploying one of these IoT gateways in your home.

As The Security Ledger reports (https://securityledger.com/2015/04/research-iot-hubs-expose-connected-homes-to-hackers/), Veracode researchers found significant security vulnerabilities in each of six IoT gateways they tested, suggesting that manufacturers are giving short shrift to security considerations during design and testing.

The flaws discovered ranged from weak authentication schemes (pretty common) to improper validation of TLS and SSL certificates, to gateways that shipped with exposed debugging interfaces that would allow an attacker on the same wireless network as the device to upload and run malicious code. Many of the worst lapses seem to be evidence of insecure design and lax testing of devices before they were released to the public, Brandon Creighton, Veracode’s research architect, told The Security Ledger.

This isn't the first report to raise alarms about IoT hubs. In October, the firm Xipiter published a blog post (http://www.xipiter.com/musings) describing research into a similar hub by the firm VeraLite. Xipiter discovered that, among other things, the VeraLite device shipped with embedded SSH private keys stored in immutable areas of the firmware used on all devices.

Submission + - Data centers face embedded systems threat (datacenterdynamics.com)

judgecorp writes: Remember the danger from embedded systems in power stations and other infrastructure — controlled by insecure protocols such as SCADA? The problem could also affect data centers, according to Singapore-based critical systems expert Ed Ansett. The IT kit in data centers may be secure — but it is placed in a building whose heating and power systems, installed by non-IT people, may include unsecured embedded network access. In these sites, the data may be secure, but the systems could be shut down by attackers interfering with temperature controls or power supplies, Ansett warns.

Comment Re:Opposite? (Score 1) 42

But when you submit data to it, the browser will automatically switch on-the-fly to an alternate, encrypted route, so the data is sent encrypted to a alternate destination handling encryption.

What benefit does that have over regular HTTPs? Why is this different from just having the submit URL be HTTPs? And wouldn't a security-aware user refuse to click submit when they saw the page wasn't encrypted?

Thanks for the explanation. I've been reading about this since I saw the Slashdot headline a few days ago and I'm just not getting it.

Submission + - TrueCrypt Alternatives Step Up Post-Cryptanalysis (threatpost.com) 1

msm1267 writes: What's next for TrueCrypt now that a two-phase audit of the code and its cryptography uncovered a few critical vulnerabilities, but no backdoors? Two alternative open source encryption projects forked TrueCrypt once its developers decided to abandon the project in early 2014, giving rise to VeraCrypt and CipherShed--and both are ready to accelerate growth, compatibility and functionality now that the TrueCrypt code has been given a relative clean bill of health.

Slashdot Top Deals

The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford

Working...