Indeed, with more applications moving to Gnome or KDE, I guess on Linux the problem will lessen over time. Moreover, the high configurability of the Linux GUIs means that distributions can make the UIs of both quite similar in the distribution's default configurations.
Thus maybe at some time we get to a situation where Linux interfaces are actually more consistent than Windows interfaces!
No, I don't return to nature. Unless nature suddenly started to grow energy-saving light bulbs, busses and trains. Or maybe switching my computer off when I don't use it for some time (e.g. over night) is returning to nature?
And after all, you'd be a pirate, and thus fighting global warming directly. BTW, why should Al Gore object if you use his invention to distribute his movie...;-)
Ok, let's assume that tomorrow something is moving toward where you currently live coming from, say, Iran, and all the experts who looked at it say it's most probably a rocket carrying an atomic bomb, and the nearest nuclear-safe bunker is far enough away that you only have a good chance to reach it in time if you run to it immediatly, would you
run as fast as possible to get into the atomic bunker, or
continue life normally, because after all, there's not yet any hard proof that the thing is indeed an atomic bomb carrying rocket, and interrupting your normal life style would be too inconvenient, and may even be harmful to you, so you won't do it just on speculation and consensus of experts?
... do they think we're going to run binary blobs on our computers in order to use the CPU?
You already do. Except that the binary blob (aka microcode) is embedded into the CPU. Which is somewhat inavoidable because without a working CPU there would be no way to read that binary blob into the CPU (although I could imagine to have a CPU which initially cannot do anything but read some binary blob from a specified memory address residing in the system bios flash, which then contains the actual implementation of the CPU instructions).
We can't predict weather 5 days out with our current computer models, how could they possibly predict these other trends?
When will people stop using this silly argument?
Do you know if in ten days it will be warmer or cooler than now? Probably not. Do you know if the next summer will be warmer than the next winter? If you live in the northern hemisphere, at a sufficient distance to the equator, I'd bet on it.
So how can we know that the summer will be warmer than the winter if we can't even tell the temperature change in about ten days? Think about it!
STOP SHOUTING! Guess why I used a loop instead of a single increment instruction in my example code? Exactly: Because it's a bigint!
they have nothing to do with what an x86 thinks they are
I've used x86 assembly as example because there you can see exactly where a branch occurs. I could also have written some generic C code to do the same which could have been in a bigint library (OTOH I can imagine a bigint library using assembler as well, just in order to speed things up).
that is the branching they are talking about in the article nothing else.
What about actually reading the article? They explicitly don't target the multiplication algorithm, but the branch in the SM loop itself.
In short such attack don't work will in multitasking OSs running on multiple execution pipeline processors.
Again, RTFA. Their attack specifically works in multitasking OSs running on multiple execution pipeline processors (such as Intel's Hyperthreading). It won't work on multicore processors with only one pipeline per core, however.
everyone one of the statements that contain *, mod and + have branching. Or did you just think they magically happen?
The question is if they have exploitable branching. For example, the only + in that algorithm is the C=C+1, and that can clearly be done without exploitable branching, e.g. with the following x86 assembler code (assuming lsb-first storage, as usual for x86):
Note that the only branch here is the jnz for the loop, but that doesn't reveal anything about the key.
Also multiplication can be implemented without exploitable branches. I'm not completely sure about modulo, but I don't see an immediate reason why it shouldn't be possible as well.
The fact that internally the processor has to make decisions does not have any relevance for this exploit, because those won't affect the branch predictor (which is only concerned with instruction-level branches, not possible branches in microcode). So yes, from the instruction level view, the addition/multiplication "magically" happen (the "magic" of course being in the microcode and the digital logic of the processor).
After now having read the complete article: Shouldn't it be possible to eliminate the branches completely? The following loop (adapted from fig. 3 in the paper) should IMHO work as well (although less efficiently):
S = M A = M - 1 for i from 1 to n-1 do
S = S * S (mod N)
C = di/* should be doable without branch by just bit masking and shifting */
C = C * A
C = C + 1/* now if di was 1, C is M, otherwise C is 1 */
S = S * C (mod N) return S
The only branch here is in the for loop, and that's independent of the key. Unless there are exploitable branches in the multiplication routine, of course.
You don't need a priviledged access to the CPU. A normal shell account and a compiler suffice. That's usually not enough to read someone else's keyboard typing.
What about just adding small random timing loops into the encryption algorithm? That is, just make so much noise in timing that you simply cannot recognise the signal in it.
Of course if such a solution became widespread enough, malware would probably commonly attack the integrity of VMware itself, in order to infect the host OS. Also note that whatever program can modify the CD image can also modify the checksum.
but for an on-line voting system, there are so much better things you can do, like send people a list of one-time passwords along with their voter registration card.
Or have the voter registration card be a smartcard with one-time passwords directly stored on them (protected by a password/pin which is never transmitted anywhere, not even to the computer the smartcard reader is connected to). You'd need to have a smartcard reader with pin field for online voting, but hey, if you don't want to pay for that, you can still go to the traditional voting booth.
Yes, there'd still be the possibility that the smartcard reader is compromised, so it sends your smartcard PIN to the computer, where a malware can read it (that's the only way the reader can be compromised, besides causing it to not work at all, since the actual PIN authentification is done on the smart card).
Thinking about it, you could also use the card reader to enter your vote (e.g. you have a candidate list, and type 3 on the reader panel to select candidate 3), thus effectively bypassing the computer in the voting process, which only transmits the voting data (encrypted by the card). That way, the only things to trust are the candidate list (but the correctness of that can be easily verified, since there's no secret data on it), the smartcard and the card reader. Ok, the computer has to be trusted to correctly submit the data, but that should be easy to verify, too.
Of course the hard part is to verify that your data is handled correctly after submission...
Slashdot Mirror
No. That one is called Skynet.
Indeed, with more applications moving to Gnome or KDE, I guess on Linux the problem will lessen over time. Moreover, the high configurability of the Linux GUIs means that distributions can make the UIs of both quite similar in the distribution's default configurations.
Thus maybe at some time we get to a situation where Linux interfaces are actually more consistent than Windows interfaces!
The Apollo program did cost an estimated $135 billion in today's dollars. And the expected payoff was what?
$12 billion is less that 1/10 of that. And it might give us a great source of energy.
Ok, let's rename the project to "green fusion power" and let everyone know it's hydrogen energy we are speaking about! :-)
No, I don't return to nature. Unless nature suddenly started to grow energy-saving light bulbs, busses and trains. Or maybe switching my computer off when I don't use it for some time (e.g. over night) is returning to nature?
And no, all that won't ruin me.
And after all, you'd be a pirate, and thus fighting global warming directly. ... ;-)
BTW, why should Al Gore object if you use his invention to distribute his movie
You already do. Except that the binary blob (aka microcode) is embedded into the CPU. Which is somewhat inavoidable because without a working CPU there would be no way to read that binary blob into the CPU (although I could imagine to have a CPU which initially cannot do anything but read some binary blob from a specified memory address residing in the system bios flash, which then contains the actual implementation of the CPU instructions).
If I had the choice between a flashy-screen-ATM and a boring one, I know which I'd choose. Hint: If I want to see videos, I use my TV or my computer.
Of course, the real solution is to increase piracy.
Reminds me of the old joke:
Two planets meet: "Hello, how are you?" - "Bad. I've got homo sapiens." - "Don't worry. That passes."
When will people stop using this silly argument?
Do you know if in ten days it will be warmer or cooler than now? Probably not.
Do you know if the next summer will be warmer than the next winter? If you live in the northern hemisphere, at a sufficient distance to the equator, I'd bet on it.
So how can we know that the summer will be warmer than the winter if we can't even tell the temperature change in about ten days? Think about it!
I knew I've read about that on Slashdot before.
If you follow the link in the old Slashdot story, you'll find out that it's indeed about Paul Crutzen's idea as well.
STOP SHOUTING!
Guess why I used a loop instead of a single increment instruction in my example code? Exactly: Because it's a bigint!
I've used x86 assembly as example because there you can see exactly where a branch occurs. I could also have written some generic C code to do the same which could have been in a bigint library (OTOH I can imagine a bigint library using assembler as well, just in order to speed things up).
What about actually reading the article? They explicitly don't target the multiplication algorithm, but the branch in the SM loop itself.
Again, RTFA. Their attack specifically works in multitasking OSs running on multiple execution pipeline processors (such as Intel's Hyperthreading). It won't work on multicore processors with only one pipeline per core, however.
OTOH, I frequently read here on Slashdot how terrible people behave in US cinemas. I've never experienced such bad behaviour in German cinemas.
For di=0:For di=1:
The question is if they have exploitable branching. For example, the only + in that algorithm is the C=C+1, and that can clearly be done without exploitable branching, e.g. with the following x86 assembler code (assuming lsb-first storage, as usual for x86):Note that the only branch here is the jnz for the loop, but that doesn't reveal anything about the key.
Also multiplication can be implemented without exploitable branches. I'm not completely sure about modulo, but I don't see an immediate reason why it shouldn't be possible as well.
The fact that internally the processor has to make decisions does not have any relevance for this exploit, because those won't affect the branch predictor (which is only concerned with instruction-level branches, not possible branches in microcode). So yes, from the instruction level view, the addition/multiplication "magically" happen (the "magic" of course being in the microcode and the digital logic of the processor).
No, it's during key usage.
The following loop (adapted from fig. 3 in the paper) should IMHO work as well (although less efficiently):The only branch here is in the for loop, and that's independent of the key. Unless there are exploitable branches in the multiplication routine, of course.
You don't need a priviledged access to the CPU. A normal shell account and a compiler suffice. That's usually not enough to read someone else's keyboard typing.
On a multi-user system, someone may well have the right to run arbitrary code on the same processor, but not to access your data.
What about just adding small random timing loops into the encryption algorithm? That is, just make so much noise in timing that you simply cannot recognise the signal in it.
Is there already a Windows port of vrms? :-)
Of course if such a solution became widespread enough, malware would probably commonly attack the integrity of VMware itself, in order to infect the host OS. Also note that whatever program can modify the CD image can also modify the checksum.
Or have the voter registration card be a smartcard with one-time passwords directly stored on them (protected by a password/pin which is never transmitted anywhere, not even to the computer the smartcard reader is connected to). You'd need to have a smartcard reader with pin field for online voting, but hey, if you don't want to pay for that, you can still go to the traditional voting booth.
Yes, there'd still be the possibility that the smartcard reader is compromised, so it sends your smartcard PIN to the computer, where a malware can read it (that's the only way the reader can be compromised, besides causing it to not work at all, since the actual PIN authentification is done on the smart card).
Thinking about it, you could also use the card reader to enter your vote (e.g. you have a candidate list, and type 3 on the reader panel to select candidate 3), thus effectively bypassing the computer in the voting process, which only transmits the voting data (encrypted by the card). That way, the only things to trust are the candidate list (but the correctness of that can be easily verified, since there's no secret data on it), the smartcard and the card reader. Ok, the computer has to be trusted to correctly submit the data, but that should be easy to verify, too.
Of course the hard part is to verify that your data is handled correctly after submission