This isn't exactly a security hole. It's the old thing: If you tell any program to store a password locally, it must be insecure, for this program needs to send the password and needs to decrypt it then. You could use something more complicated than xor, but it doesn't change the fact. The only issue is that they should have warned more explicitly before letting you store the password locally.
Some maths: viewing at their specs, they claim to have 50 Bits parallel I/O. Somewhere in their article they claim to achieve transfer rates of one million bytes per 10 ns. When clocking this at 12 THz, you will get 1 million bytes in 13 ns - well, not much difference. They also say that this chip will produce "almost no heat". They want to do this by using voltages in the micro volt range. This would be necessary because of the high clock rate. At 12 THz, one clock cycle is 0,8 ps (pico seconds, i.e. 1*E-12 seconds) of length, light will travel only 25 micro meters in this time. Electrical impulses reach speeds of about light speed, so you would have to reach are really HUGE integration depth so that the size your logical units that need to be in sync will not come even close to that distance. You could build linear units "along the clock line", but then a line could not "go back" more than perhaps 1.3 micro meters (most probably less) without getting serious problems. You will have to decentralize address decoding so that the decoder units are close to the area where the data is actually stored. But then, the signals travelling to different decoder units will have a hugely different run time, and so the data gets not in and out in order, but probably a few thousand clocks out of synch. You could object that you could build in some "wait cycles" of the data lines. Difficult, but perhaps possible. This again would increase the capacity of the lines to each other in a way that the chip would even heat in microvolt ranges, I think.
Slashdot Mirror
This isn't exactly a security hole. It's the old thing: If you tell any program to store a password locally, it must be insecure, for this program needs to send the password and needs to decrypt it then. You could use something more complicated than xor, but it doesn't change the fact. The only issue is that they should have warned more explicitly before letting you store the password locally.
Those guys cant even spell Hertz right, oh yes...
Some maths: viewing at their specs, they claim to have 50 Bits parallel I/O. Somewhere in their article they claim to achieve transfer rates of one million bytes per 10 ns. When clocking this at 12 THz, you will get 1 million bytes in 13 ns - well, not much difference.
They also say that this chip will produce "almost no heat". They want to do this by using voltages in the micro volt range. This would be necessary because of the high clock rate.
At 12 THz, one clock cycle is 0,8 ps (pico seconds, i.e. 1*E-12 seconds) of length, light will travel only 25 micro meters in this time.
Electrical impulses reach speeds of about light speed, so you would have to reach are really HUGE integration depth so that the size your logical units that need to be in sync will not come even close to that distance. You could build linear units "along the clock line", but then a line could not "go back" more than perhaps 1.3 micro meters (most probably less) without getting serious problems.
You will have to decentralize address decoding so that the decoder units are close to the area where the data is actually stored. But then, the signals travelling to different decoder units will have a hugely different run time, and so the data gets not in and out in order, but probably a few thousand clocks out of synch.
You could object that you could build in some "wait cycles" of the data lines. Difficult, but perhaps possible. This again would increase the capacity of the lines to each other in a way that the chip would even heat in microvolt ranges, I think.
Well, for short - I dont believe...