Did he modify the libraries he's using? Is he sure it's actually GPL and not LGPL or even MIT or BSD? And in particular that there isn't a reasonable linking exception? My impression from the summary is that he's merely linking said FOSS libraries, and my (much less founded) impression from casual observation is that using FOSS libraries is usually ok so long as any modifications made to the libraries and redistributed are done so following any viral licenses that might apply.
Actually, if I'm not mistaken ksplice already is completely free and open source. They operate kind of like Red Hat--what you're paying for is support. From what I can tell though, there's one crucial difference--ksplice can't function without support. Now in either case you are free to provide your own support, but I think the task of providing ksplice patches is just nontrivial enough (due to the nature of the problem, not ksplice's design), that the economies here significantly favor everyone paying one company to do it, rather than anyone trying to do it themselves.
Now, don't jump down my throat just yet. Yes, I realize these are not for most people, but your "minimize" idea reminded me of dwm and xmonad's default tiling behavior. While replacing standard window managers with things like dwm and xmonad wouldn't be acceptable, perhaps standard window managers should be extended with faculties that allow easy tiling when desired. Supplying this particular need with hardware seems... silly.
On the other hand, given that the extra screens are touchscreens there are other advantages. I would not object to my laptop being a giant DS, but I'm a sucker fo gimmicks.
Nope, Bluray players are required to support MPEG4 (alright, you got me. Not sure what compression level (3.5 generation ipod videos support a highly restricted profile of h.264), but the size ratios wikipedia quotes me indicate it's about the same as most rips end up with). Vaguely explains the cost premiums actually.
So apparently ripping mostly just sloughs off extra content. That doesn't seem to quite account for all the size difference though, so I wouldn't be surprised if bluray movies are just mostly encoded at higher than necessary bitrates to pad out the empty space, or possibly just come on significantly unfilled discs.
Basically, bluray movies that actually need the full 20-50GB are generally encoded in MPEG2. MPEG4 is about twice as efficient at the same quality level. Movies that are already in an MPEG4 format on-disc I would assume are just bundling a crapton of extra worthless features.
On the other hand, yes, 9GB may still seem a little small (remember the parent gave 5GB as a reasonable size for 720p), so perhaps 11GB really is more reasonable for movies approaching 2 hours. On the other hand, cutting down to 9GB often is not a significant quality downgrade, so the convenience of DVD storage is often worthwhile.
There's no way my friend's place is going to get an internet connection that is capable of handling all of us simultaneously, with latency comparable to a LAN.
Really? What are the bandwidth requirements per player for SC2? And how did you get those numbers?
oye. high bandwidth != low latency. Yours is the same fallacious "speed" concept that makes many SSDs suck. For example, my internet connection is through comcast (massive stupidity on my part there, but that's beside the point). It's a decently speedy connection--I consistently get 2MByte/sec downstream--but my lag times (to the edge of comcast's internal routing mind you--this is invariant with my destination ip) are often consistently around 2 seconds. (Imagine a thousand-lane highway of nursing home patients) With that connection, I can download large files mighty quickly, but the lag makes even controlling a terminal through ssh unbearable; playing starcraft through it is simply out of the question.
Hmmm... some of the comments on structure got me thinking. What if I write two algorithms--one that fails to halt on equal data, and another that fails to halt on unequal data, then feed both your cipherdata, to compare to a guess encrypted with your public key. This feels to me like a much more credible guess-and-check attack. Admittedly, guess-and-check not such a great attack anyways, but what if I take this further, to, say, a regex pattern match?
Ah, thanks for the clarification. That clears up a misconception I had about randomization and sufficiently answers my remaining question about how that might mesh with the homomorphism aspect.
Though, I'm aware that public key encryption doesn't produce identical ciphertexts for the same plaintext. But I thought that involved encrypting the plaintext with a randomly generated symmetric key, and then encrypting the symmetric key with an asymmetric key. I noted in my comment that that would be "cheating". The parent's concern seemed to be from a purely mathematical standpoint, and I was trying to address it from the same. In particular, we both allowed the assumption for this particular discussion that we're modeling encryption here as an ideal homomorphism.
That this scheme is both randmized and allows equality tests is ridiculously neat though. Could you explain this for me, or point me at additional resources for exploring this further?
It doesn't prevent equality tests in a single encrypted domain. But in a single encrypted domain, two ciphertexts for the same plaintext (i.e. including an extra block for obfuscation/resolution is cheating) are the same anyways. The unnecessary worry is about equality across different encrypted domains. I should hope the kernel is trivial, else we have collisions, and this indicates a different sort of a problem with our encryption scheme.
Your decryption concern is more interesting, but it takes me out of my depth for the moment. I think there's a flaw to be found in that line of reasoning though. Perhaps someone more knowledgeable reading this thread can provide a proper explanation?
...can produce another encrypted block of "I like apples" or XOR "I like apples" or...
ah... sorry. failed to properly proofread my comment. That should be "...can produce another encryptoed block of "I like apples" or XOR "I like apples" or..."
It doesn't allow you to compare data encrypted by different ciphers. It allows particular "multiplication" and "addition" operations on data encrypted by the same cipher. If I like apples, and have a username that starts with "S", someone with both encrypted blocks can produce another encrypted block of "I like apples" or XOR "I like apples" or something more computationally complicated along those lines. So, it does not allow the sort of attack you're proposing.
This article needs some clarification. In particular, a lot of the worried comments here show a lack of understanding of the word "homomorphic".
Here's a very simplified example of a homomorphism. I define a function
f(x) = 3x
This function is a homomorphism on numbers under addition. Its image "preserves" the addition operation. What I mean more precisely is
f(a) + f(b) = f(a + b)
That's pretty easy to verify for the function I've given.
Homomorphic encryption is interested in an encryption function f() that preserves useful computational operations. If we take my example as a very very simplified encryption then, say I have two numbers, 6, and 15, and I lack the computational power to do addtion, but I can encrypt my data with my key--3. (I'm generalizing my function to be multiplication by a key. And yes, for some reason I have the computational power to do multiplication. Humor me). I can encrypt my data, f(6) = 18 and f(15) = 45, and pass these to you, and ask you do do addtion for me. You'll do the addition, get 63, and pass this result to me, which I can then decrypt, which yields 21.
Now, my encryption here is very simple and very, very weak, but if you're willing to suspend disbelief, you'll note that the information I've allowed you to handle does not reveal either my inputs or my outputs. (In fact, with the particular numbers I've chosen, you might guess that my key is 9 instead of 3, (though relying on lucky choices or constraining myself to choices which have this property make my scheme rather useless))
If you generalize this to strong encryption and more useful computational operations, you begin to see how homomorphic encryption can be useful. One should note that, no, homomorphic encryption will not be a drop-in replacement for other forms of encryption. (Sending encrypted emails with homormorphic encryption would be unwise. An attacker can modify the data (though, if my understanding is correct, only with other data encrypted with the same key)) Homomorphic encryption simply fills a need that the other forms do not serve.
Hopefully you now also see how the article's use of the word "analysis" can be rather misleading. In particular, one of the earlier comments notes that it might be useful in allowing you to determine if different people's encrypted information is identical. By my understanding, homomorphic encryption would not allow this.
In any case, if my explanation is not enough, here's the wikipedia article.
What?! No! The heart of science is not fitting hypotheses to data. That's the sort of dangerous fallacy that produces Aristotle's "science", and in fact what dangerous fundamentalists thrive on. The thing that sets science apart is rigorous, repeatable empirical testing of not previously observed predictions.
Not to say that the hypothesis in the article isn't exciting, but the already raising it up as a shining example of scientific triumph starts down a path I find terrifying.
Slashdot Mirror
Did he modify the libraries he's using? Is he sure it's actually GPL and not LGPL or even MIT or BSD? And in particular that there isn't a reasonable linking exception? My impression from the summary is that he's merely linking said FOSS libraries, and my (much less founded) impression from casual observation is that using FOSS libraries is usually ok so long as any modifications made to the libraries and redistributed are done so following any viral licenses that might apply.
Actually, if I'm not mistaken ksplice already is completely free and open source. They operate kind of like Red Hat--what you're paying for is support. From what I can tell though, there's one crucial difference--ksplice can't function without support. Now in either case you are free to provide your own support, but I think the task of providing ksplice patches is just nontrivial enough (due to the nature of the problem, not ksplice's design), that the economies here significantly favor everyone paying one company to do it, rather than anyone trying to do it themselves.
Not to diminish the achievement, but haven't they built him a redundant right hand?
Why throw hardware at a software problem?
http://en.wikipedia.org/wiki/Tiling_window_manager
Now, don't jump down my throat just yet. Yes, I realize these are not for most people, but your "minimize" idea reminded me of dwm and xmonad's default tiling behavior. While replacing standard window managers with things like dwm and xmonad wouldn't be acceptable, perhaps standard window managers should be extended with faculties that allow easy tiling when desired. Supplying this particular need with hardware seems... silly.
On the other hand, given that the extra screens are touchscreens there are other advantages. I would not object to my laptop being a giant DS, but I'm a sucker fo gimmicks.
Time for the advent of FAT64?
Viruses have metabolisms?
From the title, "Scientists Deliver Bee Toxin To Tumors..."
Although, I did have the same initial reaction. I think the term "nanobee" is just far too distractingly catchy.
Limit the damage to one publisher, right?
Well... to one gargantuan distributor, but aye, I agree with the sentiment.
...and how, might I ask, are you generating your primes?
Nope, Bluray players are required to support MPEG4 (alright, you got me. Not sure what compression level (3.5 generation ipod videos support a highly restricted profile of h.264), but the size ratios wikipedia quotes me indicate it's about the same as most rips end up with). Vaguely explains the cost premiums actually.
So apparently ripping mostly just sloughs off extra content. That doesn't seem to quite account for all the size difference though, so I wouldn't be surprised if bluray movies are just mostly encoded at higher than necessary bitrates to pad out the empty space, or possibly just come on significantly unfilled discs.
http://en.wikipedia.org/wiki/Bluray#Codecs
Basically, bluray movies that actually need the full 20-50GB are generally encoded in MPEG2. MPEG4 is about twice as efficient at the same quality level. Movies that are already in an MPEG4 format on-disc I would assume are just bundling a crapton of extra worthless features.
On the other hand, yes, 9GB may still seem a little small (remember the parent gave 5GB as a reasonable size for 720p), so perhaps 11GB really is more reasonable for movies approaching 2 hours. On the other hand, cutting down to 9GB often is not a significant quality downgrade, so the convenience of DVD storage is often worthwhile.
There's no way my friend's place is going to get an internet connection that is capable of handling all of us simultaneously, with latency comparable to a LAN.
Really? What are the bandwidth requirements per player for SC2? And how did you get those numbers?
oye. high bandwidth != low latency. Yours is the same fallacious "speed" concept that makes many SSDs suck. For example, my internet connection is through comcast (massive stupidity on my part there, but that's beside the point). It's a decently speedy connection--I consistently get 2MByte/sec downstream--but my lag times (to the edge of comcast's internal routing mind you--this is invariant with my destination ip) are often consistently around 2 seconds. (Imagine a thousand-lane highway of nursing home patients) With that connection, I can download large files mighty quickly, but the lag makes even controlling a terminal through ssh unbearable; playing starcraft through it is simply out of the question.
Hmmm... some of the comments on structure got me thinking. What if I write two algorithms--one that fails to halt on equal data, and another that fails to halt on unequal data, then feed both your cipherdata, to compare to a guess encrypted with your public key. This feels to me like a much more credible guess-and-check attack. Admittedly, guess-and-check not such a great attack anyways, but what if I take this further, to, say, a regex pattern match?
Ah, thanks for the clarification. That clears up a misconception I had about randomization and sufficiently answers my remaining question about how that might mesh with the homomorphism aspect.
Ah... that's even neater than I thought then.
Though, I'm aware that public key encryption doesn't produce identical ciphertexts for the same plaintext. But I thought that involved encrypting the plaintext with a randomly generated symmetric key, and then encrypting the symmetric key with an asymmetric key. I noted in my comment that that would be "cheating". The parent's concern seemed to be from a purely mathematical standpoint, and I was trying to address it from the same. In particular, we both allowed the assumption for this particular discussion that we're modeling encryption here as an ideal homomorphism.
That this scheme is both randmized and allows equality tests is ridiculously neat though. Could you explain this for me, or point me at additional resources for exploring this further?
More specifically, your decryption fails in any ideal in which 1 alone is not a complete basis.
Ah, I've got a response for your decryption concern now. Your decryption fails to work in the ring of polynomials, among other things.
It doesn't prevent equality tests in a single encrypted domain. But in a single encrypted domain, two ciphertexts for the same plaintext (i.e. including an extra block for obfuscation/resolution is cheating) are the same anyways. The unnecessary worry is about equality across different encrypted domains. I should hope the kernel is trivial, else we have collisions, and this indicates a different sort of a problem with our encryption scheme.
Your decryption concern is more interesting, but it takes me out of my depth for the moment. I think there's a flaw to be found in that line of reasoning though. Perhaps someone more knowledgeable reading this thread can provide a proper explanation?
I'm an idiot. There a modifier for HTML retard?
"[username]I like apples" or [username] XOR "I like apples"
...can produce another encrypted block of "I like apples" or XOR "I like apples" or...
ah... sorry. failed to properly proofread my comment. That should be "...can produce another encryptoed block of "I like apples" or XOR "I like apples" or..."
It doesn't allow you to compare data encrypted by different ciphers. It allows particular "multiplication" and "addition" operations on data encrypted by the same cipher. If I like apples, and have a username that starts with "S", someone with both encrypted blocks can produce another encrypted block of "I like apples" or XOR "I like apples" or something more computationally complicated along those lines. So, it does not allow the sort of attack you're proposing.
This article needs some clarification. In particular, a lot of the worried comments here show a lack of understanding of the word "homomorphic".
Here's a very simplified example of a homomorphism. I define a function
f(x) = 3x
This function is a homomorphism on numbers under addition. Its image "preserves" the addition operation. What I mean more precisely is
f(a) + f(b) = f(a + b)
That's pretty easy to verify for the function I've given.
Homomorphic encryption is interested in an encryption function f() that preserves useful computational operations. If we take my example as a very very simplified encryption then, say I have two numbers, 6, and 15, and I lack the computational power to do addtion, but I can encrypt my data with my key--3. (I'm generalizing my function to be multiplication by a key. And yes, for some reason I have the computational power to do multiplication. Humor me). I can encrypt my data, f(6) = 18 and f(15) = 45, and pass these to you, and ask you do do addtion for me. You'll do the addition, get 63, and pass this result to me, which I can then decrypt, which yields 21.
Now, my encryption here is very simple and very, very weak, but if you're willing to suspend disbelief, you'll note that the information I've allowed you to handle does not reveal either my inputs or my outputs. (In fact, with the particular numbers I've chosen, you might guess that my key is 9 instead of 3, (though relying on lucky choices or constraining myself to choices which have this property make my scheme rather useless))
If you generalize this to strong encryption and more useful computational operations, you begin to see how homomorphic encryption can be useful. One should note that, no, homomorphic encryption will not be a drop-in replacement for other forms of encryption. (Sending encrypted emails with homormorphic encryption would be unwise. An attacker can modify the data (though, if my understanding is correct, only with other data encrypted with the same key)) Homomorphic encryption simply fills a need that the other forms do not serve.
Hopefully you now also see how the article's use of the word "analysis" can be rather misleading. In particular, one of the earlier comments notes that it might be useful in allowing you to determine if different people's encrypted information is identical. By my understanding, homomorphic encryption would not allow this.
In any case, if my explanation is not enough, here's the wikipedia article.
What?! No! The heart of science is not fitting hypotheses to data. That's the sort of dangerous fallacy that produces Aristotle's "science", and in fact what dangerous fundamentalists thrive on. The thing that sets science apart is rigorous, repeatable empirical testing of not previously observed predictions. Not to say that the hypothesis in the article isn't exciting, but the already raising it up as a shining example of scientific triumph starts down a path I find terrifying.