The idea behind quantum crypto is that two people communicating using a quantum channel can be absolutely sure no one is eavesdropping. Heisenberg's uncertainty principle requires anyone measuring a quantum system to disturb it, and that disturbance alerts legitimate users as to the eavesdropper's presence. No disturbance, no eavesdropper -- period.

This month we've seen reports on a new working quantum-key distribution network in Vienna, and a new quantum-key distribution technique out of Britain. Great stuff, but headlines like the BBC's "'Unbreakable' encryption unveiled" are a bit much.

The basic science behind quantum crypto was developed, and prototypes built, in the early 1980s by Charles Bennett and Giles Brassard, and there have been steady advances in engineering since then. I describe basically how it all works in Applied Cryptography, 2nd Edition (pages 554-557). At least one company already sells quantum-key distribution products.

Note that this is totally separate from quantum computing, which also has implications for cryptography. Several groups are working on designing and building a quantum computer, which is fundamentally different from a classical computer. If one were built -- and we're talking science fiction here -- then it could factor numbers and solve discrete-logarithm problems very quickly. In other words, it could break all of our commonly used public-key algorithms. For symmetric cryptography it's not that dire: A quantum computer would effectively halve the key length, so that a 256-bit key would be only as secure as a 128-bit key today. Pretty serious stuff, but years away from being practical. I think the best quantum computer today can factor the number 15.

While I like the science of quantum cryptography -- my undergraduate degree was in physics -- I don't see any commercial value in it. I don't believe it solves any security problem that needs solving. I don't believe that it's worth paying for, and I can't imagine anyone but a few technophiles buying and deploying it. Systems that use it don't magically become unbreakable, because the quantum part doesn't address the weak points of the system.

Security is a chain; it's as strong as the weakest link. Mathematical cryptography, as bad as it sometimes is, is the strongest link in most security chains. Our symmetric and public-key algorithms are pretty good, even though they're not based on much rigorous mathematical theory. The real problems are elsewhere: computer security, network security, user interface and so on.

Cryptography is the one area of security that we can get right. We already have good encryption algorithms, good authentication algorithms and good key-agreement protocols. Maybe quantum cryptography can make that link stronger, but why would anyone bother? There are far more serious security problems to worry about, and it makes much more sense to spend effort securing those.

As I've often said, it's like defending yourself against an approaching attacker by putting a huge stake in the ground. It's useless to argue about whether the stake should be 50 feet tall or 100 feet tall, because either way, the attacker is going to go around it. Even quantum cryptography doesn't "solve" all of cryptography: The keys are exchanged with photons, but a conventional mathematical algorithm takes over for the actual encryption.

I'm always in favor of security research, and I have enjoyed following the developments in quantum cryptography. But as a product, it has no future. It's not that quantum cryptography might be insecure; it's that cryptography is already sufficiently secure.

This essay previously appeared on Wired.com.

EDITED TO ADD (10/21): It's amazing; even reporters responding to my essay get it completely wrong:

Keith Harrison, a cryptographer with HP Laboratories, is quoted by the Telegraph as saying that, as quantum computing becomes commonplace, hackers will use the technology to crack conventional encryption.

"We have to be thinking about solutions to the problems that quantum computing will pose," he told the Telegraph. "The average consumer is going to want to know their own transactions and daily business is secure.

"One way of doing this is to use a one time pad essentially lists of random numbers where one copy of the numbers is held by the person sending the information and an identical copy is held by the person receiving the information. These are completely unbreakable when used properly," he explained.

The critical feature of quantum computing is the unique fact that, if someone tampers with an information feed between two parties, then the nature of the quantum feed changes.

This makes eavesdropping impossible.

No, it wouldn't make eavesdropping impossible. It would make eavesdropping on the communications channel impossible unless someone made an implementation error. (In the 80s, the NSA broke Soviet one-time-pad systems because the Soviets reused the pad.) Eavesdropping via spyware or Trojan or TEMPEST would still be possible.

The idea behind quantum crypto is that two people communicating using a quantum channel can be absolutely sure no one is eavesdropping. Heisenberg's uncertainty principle requires anyone measuring a quantum system to disturb it, and that disturbance alerts legitimate users as to the eavesdropper's presence. No disturbance, no eavesdropper — period.

This month we've seen reports on a new working quantum-key distribution network in Vienna, and a new quantum-key distribution technique out of Britain. Great stuff, but headlines like the BBC's "'Unbreakable' encryption unveiled" are a bit much.

The basic science behind quantum crypto was developed, and prototypes built, in the early 1980s by Charles Bennett and Giles Brassard, and there have been steady advances in engineering since then. I describe basically how it all works in Applied Cryptography, 2nd Edition (pages 554-557). At least one company already sells quantum-key distribution products.

Note that this is totally separate from quantum computing, which also has implications for cryptography. Several groups are working on designing and building a quantum computer, which is fundamentally different from a classical computer. If one were built — and we're talking science fiction here — then it could factor numbers and solve discrete-logarithm problems very quickly. In other words, it could break all of our commonly used public-key algorithms. For symmetric cryptography it's not that dire: A quantum computer would effectively halve the key length, so that a 256-bit key would be only as secure as a 128-bit key today. Pretty serious stuff, but years away from being practical. I think the best quantum computer today can factor the number 15.

While I like the science of quantum cryptography — my undergraduate degree was in physics — I don't see any commercial value in it. I don't believe it solves any security problem that needs solving. I don't believe that it's worth paying for, and I can't imagine anyone but a few technophiles buying and deploying it. Systems that use it don't magically become unbreakable, because the quantum part doesn't address the weak points of the system.

Security is a chain; it's as strong as the weakest link. Mathematical cryptography, as bad as it sometimes is, is the strongest link in most security chains. Our symmetric and public-key algorithms are pretty good, even though they're not based on much rigorous mathematical theory. The real problems are elsewhere: computer security, network security, user interface and so on.

Cryptography is the one area of security that we can get right. We already have good encryption algorithms, good authentication algorithms and good key-agreement protocols. Maybe quantum cryptography can make that link stronger, but why would anyone bother? There are far more serious security problems to worry about, and it makes much more sense to spend effort securing those.

As I've often said, it's like defending yourself against an approaching attacker by putting a huge stake in the ground. It's useless to argue about whether the stake should be 50 feet tall or 100 feet tall, because either way, the attacker is going to go around it. Even quantum cryptography doesn't "solve" all of cryptography: The keys are exchanged with photons, but a conventional mathematical algorithm takes over for the actual encryption.

I'm always in favor of security research, and I have enjoyed following the developments in quantum cryptography. But as a product, it has no future. It's not that quantum cryptography might be insecure; it's that cryptography is already sufficiently secure.

---

Bruce Schneier is chief security technology officer of BT. His new book is Schneier on Security.

This makes the compliance area rife for scammers, who send letters or emails claiming that businesses owe them penalties or haven’t filed the right forms.

Tony Mancuso at Nolo, the publisher of books about corporate forms and law, writes about how to recognize some of these scams.

One official-looking legal letter came into the controller’s office recently. It was from an “agency” calling itself the Corporate Minutes Compliance Counsel, or somesuch, and it strongly advised (warned, really) that Nolo send the Board a payment of $125 to prepare its state-mandated domestic corporation statement. Failure to do so could result in dire consequences, the letter advised, including a loss of corporate status with the Secretary of State.
Nolo’s controller, who has years of experience with real and bogus corporate service solicitations, shredded this letter immediately.

This scam also seems particularly nasty because not only can the scammers steal money from you, they will get valuable information and insight into your private business!

One smart way to avoid these scams is to check anything suspicious–call your secretary of state office or look up the organization who sends you that nasty letter. Or learn more by reading the full article here.

Blogger: Ramon Krikken

A seemingly innocent question on a mailing list - which I paraphrased for brevity - set in motion a series of events with dire consequences. The specific code, which was generating error messages in a certain software quality assurance tool, happened to be a critical part of the random number generator in a cryptographic library package. By removing this code, the strength of the cryptographic key material was reduced to a point where cracking the key would take minutes instead of decades. The unfortunate thing about cryptography and randomness is that good and bad can be virtually indistinguishable, and in this case the result still looked so random that the problem went unnoticed for about two years. The impact - needing to regenerate two years worth of key material, and casting doubt on encrypted communication and access performed with those keys - has understandably led to some vigorous discussion and finger pointing. Search Google for "debian openssl" for more discussions than I can link to.

The action - making a change without following a standardized process  - is certainly not unique to this situation, and "the system was slow so I turned off this feature", or "I just fiddled around with it and it just started working" are phrases all too commonly heard in many aspects of IT. Some might argue that a commercial development process would likely have prevented this occurrence, but to simply turn this into a comparison of open source and commercial development ignores some very important aspects. There are important lessons to be learned that could benefit any software development process, particularly when process parts are being adapted to encompass ever changing development and security landscapes. In the ideal world, source code would be based on well-documented requirements, consistently structured, well commented, and maintained by easy-to-reach teams that understand the code inside and out. The reality of dealing with the pressure of delivery deadlines, distributed development teams, and code written either long ago or by a third party can make coding a daunting task ... and quality assurance next to impossible, especially if breakdowns in process or communication occur. The myriad of testing tools, sometimes producing output that can run in the hundreds of pages, coupled with a lack of understanding about their testing coverage, doesn't make the task any easier.

Looking at how this specific event unfolded can lead us down many paths of analysis, all of which will provide valuable information in attempting to determine a root cause. Unfortunately - and this is something that is also not unique to any specific kind of environment - not all parties involved are neutral, and there can also be a tendency to fixate on symptoms rather than the cause. One reason for this may be the assumption that it's possible to fix specific process parts without necessarily re-evaluating the process as a whole; another is that risks and the resulting need for assurance, including process assurance, may be underestimated. Looking at the failures in the flaw finding process purportedly followed in the Therac 25 accidents it's easy to see how this can result in unacceptable consequences. And while likely not resulting in loss of life, the potential economic loss associated with a failure of a cryptographic module suggests that a critical security component can't be treated like just any other piece of software.

How ever unfortunate, this event presents a good opportunity to take a moment and look at our own development processes. Particularly as we start to embrace service orientation, where we loosely couple different business functions while relying on centralized, and often externally developed, security and reliability services, we increase the possibility of creating situations such as this. Using a risk-based process, and testing and revisiting the process itself to ensure it stays current, will be vital in providing appropriate levels of software, system, and information assurance. Building a high-assurance component using a low-assurance process just isn't worth the risk.

Blogger: Ramon Krikken

A seemingly innocent question on a mailing list - which I paraphrased for brevity - set in motion a series of events with dire consequences. The specific code, which was generating error messages in a certain software quality assurance tool, happened to be a critical part of the random number generator in a cryptographic library package. By removing this code, the strength of the cryptographic key material was reduced to a point where cracking the key would take minutes instead of decades. The unfortunate thing about cryptography and randomness is that good and bad can be virtually indistinguishable, and in this case the result still looked so random that the problem went unnoticed for about two years. The impact - needing to regenerate two years worth of key material, and casting doubt on encrypted communication and access performed with those keys - has understandably led to some vigorous discussion and finger pointing. Search Google for "debian openssl" for more discussions than I can link to.

The action - making a change without following a standardized process  - is certainly not unique to this situation, and "the system was slow so I turned off this feature", or "I just fiddled around with it and it just started working" are phrases all too commonly heard in many aspects of IT. Some might argue that a commercial development process would likely have prevented this occurrence, but to simply turn this into a comparison of open source and commercial development ignores some very important aspects. There are important lessons to be learned that could benefit any software development process, particularly when process parts are being adapted to encompass ever changing development and security landscapes. In the ideal world, source code would be based on well-documented requirements, consistently structured, well commented, and maintained by easy-to-reach teams that understand the code inside and out. The reality of dealing with the pressure of delivery deadlines, distributed development teams, and code written either long ago or by a third party can make coding a daunting task ... and quality assurance next to impossible, especially if breakdowns in process or communication occur. The myriad of testing tools, sometimes producing output that can run in the hundreds of pages, coupled with a lack of understanding about their testing coverage, doesn't make the task any easier.

Looking at how this specific event unfolded can lead us down many paths of analysis, all of which will provide valuable information in attempting to determine a root cause. Unfortunately - and this is something that is also not unique to any specific kind of environment - not all parties involved are neutral, and there can also be a tendency to fixate on symptoms rather than the cause. One reason for this may be the assumption that it's possible to fix specific process parts without necessarily re-evaluating the process as a whole; another is that risks and the resulting need for assurance, including process assurance, may be underestimated. Looking at the failures in the flaw finding process purportedly followed in the Therac 25 accidents it's easy to see how this can result in unacceptable consequences. And while likely not resulting in loss of life, the potential economic loss associated with a failure of a cryptographic module suggests that a critical security component can't be treated like just any other piece of software.

How ever unfortunate, this event presents a good opportunity to take a moment and look at our own development processes. Particularly as we start to embrace service orientation, where we loosely couple different business functions while relying on centralized, and often externally developed, security and reliability services, we increase the possibility of creating situations such as this. Using a risk-based process, and testing and revisiting the process itself to ensure it stays current, will be vital in providing appropriate levels of software, system, and information assurance. Building a high-assurance component using a low-assurance process just isn't worth the risk.