Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment: Re:It's not about the presenter. (Score 1) 227

by blueg3 (#48806833) Attached to: Lawrence Krauss On Scientists As Celebrities: Good For Science?

It depends. You can get anyone to read a script on a recorded television show, but that's usually not the point. You can't really do an interesting interview with someone who is a good communicator but isn't familiar with the subject matter.

De Grasse Tyson is often talking about tacheons, wormholes and white holes and other claptrap that's horribly speculative, wildly unusupported, and very probably untrue.

It depends. All of those are supported by theory. They're only "speculative" in that they are permitted by theory but have not been observed and, as a result, it's an interesting question as to whether or not they exist. (If they don't or can't exist, can that information be used to improve our theory?) So, depending on the context and what you say about them, they are potentially interesting lines of discussion, because they offer insight into what (some) physicists are still looking in to.

Comment: Re:Who are you defending against? (Score 2) 170

by blueg3 (#48614377) Attached to: Verizon "End-to-End" Encrypted Calling Includes Law Enforcement Backdoor

1. That's pretty common simply because getting anything approved for encryption above the SBU level is difficult and expensive. (It also requires, in essence, review by and the approval of NSA.) So tons of encryption products are made only up to the SBU level.

2. Even with end-to-end encryption, it's unlikely that they would approve classified data transiting the Internet.

Comment: Re:It's required (Score 3, Informative) 170

by blueg3 (#48614353) Attached to: Verizon "End-to-End" Encrypted Calling Includes Law Enforcement Backdoor

And the ARPA guys didn't consider that, because that first 'A' stands for "Army"

The "A" stands for "Advanced". I think they were more interested in a research network than a tactical (battlefield) network. I think it's still true that "one organization controls all the infrastructure between two points on the Internet" was *not* the model of the Internet they were envisioning at the time.

Comment: Re:This should be free (Score 4, Informative) 170

by blueg3 (#48614333) Attached to: Verizon "End-to-End" Encrypted Calling Includes Law Enforcement Backdoor

The issuer generally doesn't have a copy of your private key. You make a public-private keypair, put the public key into a certificate request, send the request to a CA, and the CA generates a signed certificate from it that includes the public key. The private key is not seen by the CA at any point.

You of course *could* have the CA generate both parts and then send you both the public and private key, but that's not nearly as good a solution and is much less common. Most of the CAs I've seen that provide "easy to use" interfaces generate the keypair in the Web browser so that the private key doesn't have to be transmitted.

Comment: Re:The website states exactly what yeast (Score 1) 50

by blueg3 (#48499797) Attached to: Open Source Craft Brewery Shares More Than Recipes

That's only true if you propagate yeast (internally) for many generations. You can also buy yeast, which a lot of brewers do because it saves them the trouble of doing careful quality control on a microbial culture.

It's also possible to acquire other brewers' yeasts unless they filter or sterilize their beer. Yeast labs do this on a regular basis and then sell it to other breweries (and to homebrewers). The yeast from The Alchemist, for example, is available from a couple of different companies now.

Only a handful of yeast strains are so interesting that their being "proprietary" is economically valuable. A lot of those have been cloned and are commercially available. Some are mixed microbial cultures (like with lambics), which are very challenging to copy because they're sensitive to their particular environment.

Really, the answer is that brewers don't worry about others stealing their secrets too much, because the market is big, it's pretty easy to make interesting beer recipes, and there are so many process variables that's it's very hard to make exact clones even if you have another person's secrets.

Comment: Re:You are a bit over a decade out of date (Score 1) 131

by blueg3 (#48471775) Attached to: Regin Malware In EU Attack Linked To US and British Intelligence Agencies

With respect, you are the one that came in with the childish "my platform is better than yours because your root can do anything" bullshit, so if you can't take a rebuttal then don't try to start such an argument.

No. You're completely imaging--synthesizing--that Windows is "my platform" because Secure Boot was mentioned. The whole argument of signing kernels, root compromising the kernel with modifying the disk, etc. is just as true in Windows as in Linux. You just change the jargon. It's absolutely the same system.

Incidentally, by the nature of my work, I have all kinds of different operating systems. Most serious work gets done on Linux, or, occasionally, OS X, because I can't stand MinGW / Cygwin and command-line is faster. I also don't have a Windows system that actually supports UEFI Secure Boot.

Comment: Re:You write of reading comprehension, yet ... (Score 1) 131

by blueg3 (#48466827) Attached to: Regin Malware In EU Attack Linked To US and British Intelligence Agencies

Just because you reject a simple solution in favour of complex one

Your simple solution is simple but unusable.
Signing binaries is not complex.
The UEFI Secure Boot implementation used by Microsoft is not the only way to implement Secure Boot.

Comment: Re:You are a bit over a decade out of date (Score 1) 131

by blueg3 (#48466807) Attached to: Regin Malware In EU Attack Linked To US and British Intelligence Agencies

So, most of that post was illegible anti-MS "I imagine everyone who disagrees with me is a fanboy" twisted worldview shit and is largely unreadable. I don't particularly agree with MS's Secure Boot approach, and you manage to point out why in the one coherent sentence at the beginning:

As distinct from the complex web of trust described above where all it takes is yet another leaked key to break into it and render all that TPM stuff irrelevant

Preshipping kernel-signing keys in TPMs and making it tricky to modify the trusted-signing-key list is a dangerous approach they've taken, for this reason. The benefit is that they can get people to actually use it. You can't get many people to use any feature that requires actual configuration. But key revocation is nearly impossible to get right in userland, so there's no way it'll work in a TPM -- a compromised signing key has carte blanche.

Incidentally, as far as I know, the TPM Secure Boot implementation doesn't use web-of-trust, it uses a typical PKI hierarchy.

Somebody clicking on a link in an Outlook message is all it takes to open up Internet Explorer to run whatever it finds in an "asp" script on a hacked MS webserver and next thing you've got files on network shares encrypted and some criminal demanding money - all before the MS or any other antivirus gets a chance to block it.

Secure Boot doesn't do anything to address user-space exploitation. It's not supposed to. That's a more serious problem for most users, yes, but different solutions are for different problems.

Incidentally, with a non-compromised kernel, an antivirus can, if it wants to, block anything before it executes. They hook system calls. They strictly get to operate before any change to the system occurs. In practice, this is often not done (which is why they're not very good), because characterizing "evil behavior" is hard, hooking all system calls is expensive, and people uninstall things that slow down their machine.

You can even, if you want, enforce that every executable memory page on your entire system have a SHA-2 hash that matches the hash for a page from the corresponding signed binary, so that you have no tampered executable memory pages on your whole system. The kernel will gladly do that if you implement it. You can even whitelist individual binaries (by hash+signature, no less), so that untrusted-but-signed binaries can't run either. It's been implemented on a Linux system, years ago. This approach does ruin Javascript, since it's JIT-compiled, but that's probably for the best.

Speed of a tortoise breaking the sound barrier = 1 Machturtle