a pair of mobiles each with 2 Watts of transmitter output will take three minutes to boil a large free range egg
OK, let's do the math. How much energy does it take to boil an egg? Let's say a "large free range egg" weighs 100g. The egg proteins start coagulating at around 65 degrees celsius, i.e., about 40 degrees above room temperature. Heating up the egg by this much would take 100g*40deg = 4000 calories, by definition of calorie, assuming an egg has specific heat close to that of water (actually it's slightly lower). Converting to joule, that's 4000*4.185 = 16739 joule. Since Watt is joule per second, two 2W transmitters will take 16739/(2*2) seconds, i.e., 69 minutes, to output that amount of energy.
So even under ideal conditions and perfect efficiency, it will take the described setup over an hour (rather than "three minutes") to output sufficient energy. Of course, during that time the egg would give up heat to its environment; and anyway, only a tiny portion of the radiation will be absorbed by the egg (most energy won't even radiate in the egg's direction). Realistically, the egg will never heat up by more than a few degrees.
It still has the lousy 1024x768 XGA display resolution, like all X series ThinkPads. At 12.1" they could pack much more than that at the same DPI as other ThinkPad models (e.g., 1400x1050 in 14.1" and 1600x1200 in 15" for the T series).
My primary potential use for a convertible in tablet mode is as an e-book reader, for reading and annotating those lengthy PDF documents. A width of 768 pixels is just not enough to produce sharp text when viewing a PDF document preformatted for paper, especially if you want the page to fit vertically too.
Tried that. It wore off within minutes of typing. Sandpaper doesn't work well either; it ruins the texture of the keytops. And whatever chemical abrasive will remove the letters will probably also damage the keytop plastic (I tried acetone and turpentine).
The thermodynamic cost of erasing bits gives a lower bound on the energy dissipation of (non-reversible) computation. Currently computers dissipate energy that is larger by many orders of magnitude, so reversibility is just not a concern. For example, about half the energy in a modern CPU is wasted on leakage across transistors, even if the transistor is not changing its state; that's a property of current chip building technology, and has nothing to do with the reverisibility of the computed function.
> How could one hope to extract a certain few bits from a recording when > the CPU's instruction throughput is many times that?
The few bits you're trying to extract may have an observable influence on global statistics, especially when you can affect the value of some other bits. See for example Boneh and Brumley's timing attack on OpenSSL.
The fallacy in this article is the assumption that NGSCB is perfectly secure and unbeatable. This isn't the case, and in fact there are reasons to believe that at least some of its functions are theoretically impossible.
NGSCB can be broken; you'll just have to go through a lot of trouble to do so (scrape off chip packaging and decode its internals without triggering intrusion detectors, etc.). This is sufficient to stop casual copyright infringement, or to keep your workers at check. But one ought to doubt if the expense of breaking NGSCB isn't worthwhile for online gambling, elections or other applications where the incentives are very high.
Security: they might get authentication right, but forget about privacy:
"Higher levels of security involving encryption should be implemented at the application level."
Uh-huh. As if wireless keyboard manufacturers will bother implementating encryption -- thereby preventing the keyboard from working until proprietary drivers are loaded -- and do it correctly. It's completely unrealistic to lay this burdon of adding proper security on consumer electronic manufacturers. They'll either ignore it or blow it (standard procedure: use single DES with a fixed key; add "secure!" to bullet list; when customers come crying about stolen data, point to license agreement and issue a PR spin).
Note the amusing claim:
"WUSB security will ensure the same level of security as wired USB."
They must mean the same security as 802.11's "Wired Equivalent Privacy" (WEP) -- that is, none at all.
If you like fine lines, try the Pilot G-Tec C4.
At 0.2mm line width, it's the finest-tipped "general purpose" pen I know of. Here's a nice closeup.
Note the very thin neck (about 3.5mm long) near the trip -- it keeps the body of the pen from visually obstructing the point where you're writing, which is very nice when sketching etc. The catch is that this neck is rather delicate, so if the pen falls tip-down on hard surface it is often irreparable bended. Most of my C4 pens have been thus broken before running out (which is not saying a lot, since they pack a lot of ink).
It comes in 10 ink colors, of which my favorite is black (very dark, perfectly consistent). The lines are thin and sharp, and the gel-based ink dries very quickly so there's no smearing. Writing takes virtually no pressure, as gravity alone already suffices to leave a clear and continuous line if you drag the pen across the paper. Coupled with the light plastic construction, this makes for relatively effortless writing. Both pressure and velocity affect line thinkness only mildly (e.g., it doesn't "leak" like the Pilot V5 when held at one spot), so you get very fine and uniform lines. This effectively deprives you of an extra degree of freedom, though I find the tradeoff worthwhile for most applications.
My main gripe is the grip. It is cheap hard plastic (see the closeup), and slip-on rubber grips feel very awkward on such a fine-tipped pen. I tried fitting a G-Tec C4 refill into some better-crafted pen body, but didn't find any good match. Also, the pen clip, made from the same hard plastic, is not very functional as it breaks off easily. The fine innards deserve a better package.
The measures you suggest are ineffective if the (unsecure) application server is broken into. SSH would protect the link, nothing more. If an attacker exploits a Mozilla bug to execute arbitrary code, for instance, he has won -- no need even for root access on the application server. Since the original poster wanted to put the application server outside the firewall, we can only assume that he had these attacks in mind.
The killer right now is letting them use Mozilla and Evolution through X from a server located outside the firewall: very secure and virusless (and cheap!)
So, you're going to let an unsecure box act as an X client for the secure boxes? That would give the unsecure box the power to:
monitor the content of the X displays on the secure boxes
inject keystrokes, e.g., when someone on the secure boxes logs in as root
display arbitrary stuff on the secure boxes (e.g., "System Locked, enter password to unlock").
Unless the X display is used *only* for the specified apps and users are very conscious of what's going on, you're not gaining security much in principle. It's true, however, that most generic attacks won't affect the secure boxes; some more effort by the attacker would be required.
Clarification: by "IP-over-SSH tunneling" I refer to TCP port forwarding through SSH, and the important special case of the forwarding a PPP session through SSH.
This is what I would use to secure a Wi-Fi connection, for instance.
On related news, a basic security flaw in the SSH protocol was recently analyzed by Mihir Bellare et al.
The attack requires a carefully timed chosen-plaintext attack, but seems quite realistic in the setting of IP-over-SSH tunneling. Changes in the SSH protocol appear necessary.
To get your code to run on popular browsers, you need a certiticate (key pair plus some data) issued by a certificate authority that is available in all popular browsers. Otherwise, your users will get security warning popups to the tune of: This applet is signed using a certificate that was issued by an untrusted certificate authority. Run anyway?
As a developer, you can't afford that.
Thawte is one of the few certificate authorities that are in the default installation of all popular browsers. VeriSign is another, and in fact I can't recall any other common CA that's catering to the general public.
The upshot is that VeriSign, which now owns Thawte, has a monopoly on code signing certificates for browsers. They're giving the appearance of competition by selling "lucrative" certs under the VeriSign brand and "economy" certs under the Thawte brand, but technically it's the same product. This is why they can charge $200 for 1-year Thawte certificate, and more for a VeriSign cert, even though effort involved is trivial. It's just like things used to be with domain registration and Network Solutions (which VeriSign also owns now). I don't believe potential liability issues would prevent this price from dropping significantly in the presence of other players.
Given this, the change in Thawte's policy is quite disturbing.
These are excellent questions. I'll try to answer them as far as my knowledge of the field allows, but please bear in mind that a good answer to some of the issues you raised would significantly enhance our state of knowledge.
First, two key facts.
A quantum computer can run any classical algorithm. There is some overhead due the reversibility constraint and due to the practical need for error correction, but it's probably a low-order polynomial overhead at worst. In particular, a quantum computer can run a Universal Turing Machine. So, it's fully programmable in respect to classical programs.
There exists a Universal Quantum Turing Machine that acts analogously to a classical Universal Turing Machine, i.e., lets a fixed quantum computer simulate run any quantum algorithm given a description of that algorithm as additional input. (It does so to finite accuracy, but the error can be made arbitrarily small)
So yes, we're talking about a fully programmable computer. However, this universaily means an increase in the computer size, so for practical reasons you'll see two shortcuts that undermine this universatily.
First, everything that can be done classically is done outside the quantum computer -- a quantum-classical dualism, if you wish. Suppose you have an algorithm that performs operation Q on some register, and applies it 200 times in a loop. You could put the loop counter as part of the quantum computer and program it to do an increment+test+Q operation. However, currently it's much cheaper to put the loop counter outside the quantum computer and simply tell it 200 times to apply a Q operation.
Second, the hardware is made as simple and specialized as possible, and optimized for a specific algorithm.
Now, these shortcuts are clearly present in the tiny quantum computers built so far (latest is IBM's, featuring 8 qubits), and will probably be used for quite some time. But that's mere practice, not theory.
OK, so how do you program this things? All quantum algorithms to date have been expressed using one of two formalisms: either using algebra in the mathematical "Hilbert space" that represents all the states the computer can be in, or using a "quantum circuit" which is just like a normal logical circuit (with gates like AND and NOT), except the gates are different -- in fact the gates are expressed as operations in the Hilbert space, as in the first approach, but it's often easier to see the overall picture if you combine simple gates using the circuit formalism. To be truthful, there's also the "and then you do that N more times, and then you measure first register" type of formalism.:-)
So you see, currently researchers are working at a level way below assembly language, and they're pretty happy about it because the algorithms are very small too. But what about higher-level representations? All efforts I've seen so far use quantum-classical dualism: you write a classical program that manipulates a quantum register (data), but the logic is purely classical. Some do it with a dedicated programming language, some with a class library, but the idea is the same (see a comprehensive list; all of these are mere simulators for now, of course).
Now, this is a very reasonable approach, but it seems rather halfway-there -- wouldn't it beneficial to allow quantum operations in flow control, not only in data? Well, we don't know yet. Currently there are very few "patterns" used in quantum computing, and none of them seems to easier to represent that way. It's hard to design a paradigm, let alone a language, for solving problems that don't yet exist. On the other hand, if we invent such a paradigm it might help us find new quantum algorithms. This is a vast open research area.
As for your speculations on how quantum computers will be used, the answers is yet again that we don't know. Here are the two extreme cases, both easily imagined and consistent with current knowledge. First, it could be that quantum computers will be found to be good for nothing except a few very specialized tasks, and that only a few RSA-cracking devices will be built by intelligence agencies at a prohobitive cost. On the other hand, it could be that a new class of quantum algorithms will be discovered that address more common needs, leading first to something in the college basement and later to a chip in everybody's computer. No one currently knows such these chips can be good for, if at all, though there's some intuition about what's more likely. I do venture to say that which of these possibilities becomes reality depends primarly on usefulness, since long-term prospects for mass-producton seem quite real, given sufficient demand.
I hope this clears things up a bit. I wish I could be more concrete, but it really takes a few hours to get a rough grasp of how these things really work, and a full-semester course to understand the interesting algorithms. Please don't hesitate to e-mail me if you want to discuss this further.
1. There are algorithms for efficient factoring and discrete log, so many public-key cryptosystems are can indeed be broken by a quantum computer. However, there is no known quantum algorithm for lattice-based cryptosystems such as NTRU. Moreover, for private-key cryptosystems all we have is a generic search algorithm that finds the key in time SQRT(2^n) where n is the key length, instead of 2^n for a brute force classical search. Thus by doubling the key length of the cipher, you make the work as hard for a quantum computer as the original cipher was for a classical computer.
2. As pointed out in previous replies, the offset will usually be longer than the data. This follows from a simple counting argument.
3. There is no evidnence that quantum computer can efficiently solve NP-complete problems. In fact, many quantum computing researchers believe there isn't one.
The current quantum algorithms are very tantalizing, but restricted in applicability. We really don't know yet what types of problems will benefit from quantum computing beyond the few known classes.
HDCP is not a public-key cryptosystem. Read the specs. Had the scheme been secure, you would not have been able to verify his knowledge of the master key unless YOU have access to an HDCP device.
Anyway, to run his attack he needs 50 different HDCP devices (to get sufficient data for analysis). He probably doesn't have these, so why do you expect him to have the master key?
Look up my other post to this article for hints about the structure of the attack.
A description of a fatal weakness in HDCP's was published by Scott A. Crosby a few days after the specs was published, and was independently discovered by many others. Crosby's attack appears to have the capabilities claimed by Ferguson and has negligible computational cost (inversion of a 40x40 matrix). It requires the built-in keys of any 40 HDCP devices, but this is presumably easy to achieve in the presence of software-based HDCP implementations).
Thus the new feature of Ferguson's attack is probably a way to extract the keys without actually hacking any device, but rather by talking to intact devices via the normal protocol. While this is interesting, HDCP should already be considered broken in light of known attacks.
The personal computer version ought to fit into a 5.25" drive bay and double as a CD-ROM drive. Most modern CD-ROM drives seem to build enough angular momentum to run a refrigirator for a couple of hours anyway.
But then again, a friend of mine was nearly decapitated by a Toshiba X32 drive with a premature ejection problem.
The paper on which the article is based is Counterfactual Computation by Mitchisony and Jozsa. Full text at the LANL preprint archive. Warning: requires some background in quantum computation.
Of particular interest is Chapter 6, where they say the following: Our starting point was the enticing notion of being able to run a quantum computer `for free'. The quotation marks here were very necessary, however, for it is not at all clear what if anything comes for free. A CF protocol requires the computer to be present, and due time must allowed for the machine not to run.
They go on to explain why any attempt to use the times when the computer is "off" for other computation will ruin the original computation. The bottom line is that the story is fascinating and the model may be useful for analyzing various phenomena, but apparently this trick will not save any physical resources beyond "standard" quantum computation.
Of more pseudo-practical interest is the issue of interaction-free measurement (the "bomb testing problem" mentioned in the paper). For a nice introduction see The Tao of Interaction-Free Measurements.
Slashdot Mirror
a pair of mobiles each with 2 Watts of transmitter output will take three minutes to boil a large free range egg
OK, let's do the math. How much energy does it take to boil an egg? Let's say a "large free range egg" weighs 100g. The egg proteins start coagulating at around 65 degrees celsius, i.e., about 40 degrees above room temperature. Heating up the egg by this much would take 100g*40deg = 4000 calories, by definition of calorie, assuming an egg has specific heat close to that of water (actually it's slightly lower). Converting to joule, that's 4000*4.185 = 16739 joule. Since Watt is joule per second, two 2W transmitters will take 16739/(2*2) seconds, i.e., 69 minutes, to output that amount of energy.
So even under ideal conditions and perfect efficiency, it will take the described setup over an hour (rather than "three minutes") to output sufficient energy. Of course, during that time the egg would give up heat to its environment; and anyway, only a tiny portion of the radiation will be absorbed by the egg (most energy won't even radiate in the egg's direction). Realistically, the egg will never heat up by more than a few degrees.
It still has the lousy 1024x768 XGA display resolution, like all X series ThinkPads. At 12.1" they could pack much more than that at the same DPI as other ThinkPad models (e.g., 1400x1050 in 14.1" and 1600x1200 in 15" for the T series).
My primary potential use for a convertible in tablet mode is as an e-book reader, for reading and annotating those lengthy PDF documents. A width of 768 pixels is just not enough to produce sharp text when viewing a PDF document preformatted for paper, especially if you want the page to fit vertically too.
BUY PRIMER -- take off cap -- spray.
Tried that. It wore off within minutes of typing.
Sandpaper doesn't work well either; it ruins the texture of the keytops. And whatever chemical abrasive will remove the letters will probably also damage the keytop plastic (I tried acetone and turpentine).
My solution? See here.
do the click like the old IBM keyboards, now THAT would be worth the extra money.
Your wishes have been fulfilled.
The thermodynamic cost of erasing bits gives a lower bound on the energy dissipation of (non-reversible) computation. Currently computers dissipate energy that is larger by many orders of magnitude, so reversibility is just not a concern. For example, about half the energy in a modern CPU is wasted on leakage across transistors, even if the transistor is not changing its state; that's a property of current chip building technology, and has nothing to do with the reverisibility of the computed function.
(I'm a co-author of the presentation.)
The web page was extended to include a FAQ discussing the issues brought up here.
> How could one hope to extract a certain few bits from a recording when
> the CPU's instruction throughput is many times that?
The few bits you're trying to extract may have an observable influence on global statistics, especially when you can affect the value of some other bits. See for example Boneh and Brumley's timing attack on OpenSSL.
The fallacy in this article is the assumption that NGSCB is perfectly secure and unbeatable. This isn't the case, and in fact there are reasons to believe that at least some of its functions are theoretically impossible.
NGSCB can be broken; you'll just have to go through a lot of trouble to do so (scrape off chip packaging and decode its internals without triggering intrusion detectors, etc.). This is sufficient to stop casual copyright infringement, or to keep your workers at check. But one ought to doubt if the expense of breaking NGSCB isn't worthwhile for online gambling, elections or other applications where the incentives are very high.
"Higher levels of security involving encryption should be implemented at the application level."
Uh-huh. As if wireless keyboard manufacturers will bother implementating encryption -- thereby preventing the keyboard from working until proprietary drivers are loaded -- and do it correctly. It's completely unrealistic to lay this burdon of adding proper security on consumer electronic manufacturers. They'll either ignore it or blow it (standard procedure: use single DES with a fixed key; add "secure!" to bullet list; when customers come crying about stolen data, point to license agreement and issue a PR spin).
Note the amusing claim:
"WUSB security will ensure the same level of security as wired USB."
They must mean the same security as 802.11's "Wired Equivalent Privacy" (WEP) -- that is, none at all.
Note the very thin neck (about 3.5mm long) near the trip -- it keeps the body of the pen from visually obstructing the point where you're writing, which is very nice when sketching etc. The catch is that this neck is rather delicate, so if the pen falls tip-down on hard surface it is often irreparable bended. Most of my C4 pens have been thus broken before running out (which is not saying a lot, since they pack a lot of ink).
It comes in 10 ink colors, of which my favorite is black (very dark, perfectly consistent). The lines are thin and sharp, and the gel-based ink dries very quickly so there's no smearing. Writing takes virtually no pressure, as gravity alone already suffices to leave a clear and continuous line if you drag the pen across the paper. Coupled with the light plastic construction, this makes for relatively effortless writing. Both pressure and velocity affect line thinkness only mildly (e.g., it doesn't "leak" like the Pilot V5 when held at one spot), so you get very fine and uniform lines. This effectively deprives you of an extra degree of freedom, though I find the tradeoff worthwhile for most applications.
My main gripe is the grip. It is cheap hard plastic (see the closeup), and slip-on rubber grips feel very awkward on such a fine-tipped pen. I tried fitting a G-Tec C4 refill into some better-crafted pen body, but didn't find any good match. Also, the pen clip, made from the same hard plastic, is not very functional as it breaks off easily. The fine innards deserve a better package.
About US$2 a piece, refills available.
The version currently circulating is indeed a draft. The final version, when available, will be placed at my homepage, and specifically here.
-- Eran Tromer
The measures you suggest are ineffective if the (unsecure) application server is broken into. SSH would protect the link, nothing more. If an attacker exploits a Mozilla bug to execute arbitrary code, for instance, he has won -- no need even for root access on the application server. Since the original poster wanted to put the application server outside the firewall, we can only assume that he had these attacks in mind.
Unless the X display is used *only* for the specified apps and users are very conscious of what's going on, you're not gaining security much in principle. It's true, however, that most generic attacks won't affect the secure boxes; some more effort by the attacker would be required.
Clarification: by "IP-over-SSH tunneling" I refer to TCP port forwarding through SSH, and the important special case of the forwarding a PPP session through SSH.
This is what I would use to secure a Wi-Fi connection, for instance.
On related news, a basic security flaw in the SSH protocol was recently analyzed by Mihir Bellare et al.
The attack requires a carefully timed chosen-plaintext attack, but seems quite realistic in the setting of IP-over-SSH tunneling. Changes in the SSH protocol appear necessary.
This applet is signed using a certificate that was issued by an untrusted certificate authority. Run anyway?
As a developer, you can't afford that.
Thawte is one of the few certificate authorities that are in the default installation of all popular browsers. VeriSign is another, and in fact I can't recall any other common CA that's catering to the general public.
The upshot is that VeriSign, which now owns Thawte, has a monopoly on code signing certificates for browsers. They're giving the appearance of competition by selling "lucrative" certs under the VeriSign brand and "economy" certs under the Thawte brand, but technically it's the same product. This is why they can charge $200 for 1-year Thawte certificate, and more for a VeriSign cert, even though effort involved is trivial. It's just like things used to be with domain registration and Network Solutions (which VeriSign also owns now). I don't believe potential liability issues would prevent this price from dropping significantly in the presence of other players.
Given this, the change in Thawte's policy is quite disturbing.
First, two key facts.
So yes, we're talking about a fully programmable computer. However, this universaily means an increase in the computer size, so for practical reasons you'll see two shortcuts that undermine this universatily.
First, everything that can be done classically is done outside the quantum computer -- a quantum-classical dualism, if you wish. Suppose you have an algorithm that performs operation Q on some register, and applies it 200 times in a loop. You could put the loop counter as part of the quantum computer and program it to do an increment+test+Q operation. However, currently it's much cheaper to put the loop counter outside the quantum computer and simply tell it 200 times to apply a Q operation.
Second, the hardware is made as simple and specialized as possible, and optimized for a specific algorithm.
Now, these shortcuts are clearly present in the tiny quantum computers built so far (latest is IBM's, featuring 8 qubits), and will probably be used for quite some time. But that's mere practice, not theory.
OK, so how do you program this things? All quantum algorithms to date have been expressed using one of two formalisms: either using algebra in the mathematical "Hilbert space" that represents all the states the computer can be in, or using a "quantum circuit" which is just like a normal logical circuit (with gates like AND and NOT), except the gates are different -- in fact the gates are expressed as operations in the Hilbert space, as in the first approach, but it's often easier to see the overall picture if you combine simple gates using the circuit formalism. To be truthful, there's also the "and then you do that N more times, and then you measure first register" type of formalism.
So you see, currently researchers are working at a level way below assembly language, and they're pretty happy about it because the algorithms are very small too. But what about higher-level representations? All efforts I've seen so far use quantum-classical dualism: you write a classical program that manipulates a quantum register (data), but the logic is purely classical. Some do it with a dedicated programming language, some with a class library, but the idea is the same (see a comprehensive list; all of these are mere simulators for now, of course).
Now, this is a very reasonable approach, but it seems rather halfway-there -- wouldn't it beneficial to allow quantum operations in flow control, not only in data? Well, we don't know yet. Currently there are very few "patterns" used in quantum computing, and none of them seems to easier to represent that way. It's hard to design a paradigm, let alone a language, for solving problems that don't yet exist. On the other hand, if we invent such a paradigm it might help us find new quantum algorithms. This is a vast open research area.
As for your speculations on how quantum computers will be used, the answers is yet again that we don't know. Here are the two extreme cases, both easily imagined and consistent with current knowledge. First, it could be that quantum computers will be found to be good for nothing except a few very specialized tasks, and that only a few RSA-cracking devices will be built by intelligence agencies at a prohobitive cost. On the other hand, it could be that a new class of quantum algorithms will be discovered that address more common needs, leading first to something in the college basement and later to a chip in everybody's computer. No one currently knows such these chips can be good for, if at all, though there's some intuition about what's more likely. I do venture to say that which of these possibilities becomes reality depends primarly on usefulness, since long-term prospects for mass-producton seem quite real, given sufficient demand.
I hope this clears things up a bit. I wish I could be more concrete, but it really takes a few hours to get a rough grasp of how these things really work, and a full-semester course to understand the interesting algorithms. Please don't hesitate to e-mail me if you want to discuss this further.
There's currently no evidence that quantum computers can break all encryption schemes.
See item 1 in my previous comment.
Wrong on all three accounts, I'm afraid.
1. There are algorithms for efficient factoring and discrete log, so many public-key cryptosystems are can indeed be broken by a quantum computer. However, there is no known quantum algorithm for lattice-based cryptosystems such as NTRU. Moreover, for private-key cryptosystems all we have is a generic search algorithm that finds the key in time SQRT(2^n) where n is the key length, instead of 2^n for a brute force classical search. Thus by doubling the key length of the cipher, you make the work as hard for a quantum computer as the original cipher was for a classical computer.
2. As pointed out in previous replies, the offset will usually be longer than the data. This follows from a simple counting argument.
3. There is no evidnence that quantum computer can efficiently solve NP-complete problems. In fact, many quantum computing researchers believe there isn't one.
The current quantum algorithms are very tantalizing, but restricted in applicability. We really don't know yet what types of problems will benefit from quantum computing beyond the few known classes.
HDCP is not a public-key cryptosystem. Read the specs. Had the scheme been secure, you would not have been able to verify his knowledge of the master key unless YOU have access to an HDCP device.
Anyway, to run his attack he needs 50 different HDCP devices (to get sufficient data for analysis). He probably doesn't have these, so why do you expect him to have the master key?
Look up my other post to this article for hints about the structure of the attack.
Politics aside:
A description of a fatal weakness in HDCP's was published by Scott A. Crosby a few days after the specs was published, and was independently discovered by many others. Crosby's attack appears to have the capabilities claimed by Ferguson and has negligible computational cost (inversion of a 40x40 matrix). It requires the built-in keys of any 40 HDCP devices, but this is presumably easy to achieve in the presence of software-based HDCP implementations).
Thus the new feature of Ferguson's attack is probably a way to extract the keys without actually hacking any device, but rather by talking to intact devices via the normal protocol. While this is interesting, HDCP should already be considered broken in light of known attacks.
The personal computer version ought to fit into a 5.25" drive bay and double as a CD-ROM drive. Most modern CD-ROM drives seem to build enough angular momentum to run a refrigirator for a couple of hours anyway.
But then again, a friend of mine was nearly decapitated by a Toshiba X32 drive with a premature ejection problem.
Full text at the LANL preprint archive.
Warning: requires some background in quantum computation.
Of particular interest is Chapter 6, where they say the following:
Our starting point was the enticing notion of being able to run a quantum computer `for free'. The quotation marks here were very necessary, however, for it is not at all clear what if anything comes for free. A CF protocol requires the computer to be present, and due time must allowed for the machine not to run.
They go on to explain why any attempt to use the times when the computer is "off" for other computation will ruin the original computation. The bottom line is that the story is fascinating and the model may be useful for analyzing various phenomena, but apparently this trick will not save any physical resources beyond "standard" quantum computation.
Of more pseudo-practical interest is the issue of interaction-free measurement (the "bomb testing problem" mentioned in the paper). For a nice introduction see The Tao of Interaction-Free Measurements.