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.

Keith Vaz MP, chairman of the powerful Home Affairs select committee told the BBC: "Such confidential documents should be locked away...they should not be read on trains."

You think?

$dacl = (dir foo.txt).GetAccessControl()
$newRule = New-Object Security.AccessControl.FileSystemAccessRule "keith", Modify, Allow
$modified = $false
$dacl.ModifyAccessRule("Add", $newRule, [ref]$modified)
(dir foo.txt).SetAccessControl($dacl)

All I've got left to explain is the last line of code. It's important to note that when you're tweaking ACLs, there are basically three steps you have to take:

1. Read the ACL from an object.
2. Tweak it however you like.
3. Write the ACL back to the object.

In this last line of code, I'm applying the new, tweaked ACL back to the file foo.txt. At this point the new access control policy takes effect.

Navigate posts in this series: prev

$newRule = New-Object Security.AccessControl.FileSystemAccessRule "keith", Modify, Allow

I pointed out how the "Modify" was automatically converted into an enumeration value, promising that I'd talk more about enumerations later. Well, this value comes from the System.Security.AccessControl.FileSystemRights enumeration. And there's a cool way you can abuse PowerShell to get a quick and dirty listing of an enumeration's values. But to understand how it works, you'll have to bear with me and learn about type-constrained variables in PowerShell, which is a really cool feature unto itself, and one that I use all the time.

While PowerShell doesn't support strong typing in the classic sense of a compiler, it does have a feature that allows you to constrain the type of a variable whenever it's assigned a value. Here's an example:

$a = 42
[Int32] $b = 42
$a = "this works just fine"
$b = "this generates an invalid cast exception"

This syntax allows you to create type-constrained variables. Now when I assign an object to $b, PowerShell will first try to cast that object to System.Int32 (you could also have used "int", by the way). The last line of code above will throw an invalid cast exception. This is a very useful feature, allowing you to get some helpful type checking in your scripts. But this feature also has a nifty side effect that Bruce describes in his book. You can use this to get a quick listing of enumeration values:

$ [Security.AccessControl.FileSystemRights] "foo"
Cannot convert value "foo" to type "System.Security.AccessControl.FileSystemRights"
due to invalid enumeration values. Specify one of the following enumeration values
and try again. The possible enumeration values are "ListDirectory, ReadData,
WriteData, CreateFiles, CreateDirectories, AppendData, ReadExtendedAttributes,
WriteExtendedAttributes, Traverse, ExecuteFile, DeleteSubdirectoriesAndFiles,
ReadAttributes, WriteAttributes, Write, Delete, ReadPermissions, Read,
ReadAndExecute, Modify, ChangePermissions, TakeOwnership, Synchronize, FullControl"
At line:1 char:42
+ [Security.AccessControl.FileSystemRights]  <<<< "foo"

Stay tuned for more!

The whole “Master Splyntr” affair was bumbling about in my brain for days before I realized the connection between the name, and the rat in the Teenage Mutant Ninja Turtles.

The leader of the site, know online as Master Splynter, was in fact FBI cybercrime agent J. Keith Mularski, part of an elite seven-agent cybercrime unit based at the National Cyber Forensics Training Alliance in Pittsburgh. He was not, however, a man-sized rat sensei to a group of turtles who were teenaged mutant ninjas. Would the FBI call that a conflict of interest?

Now I feel compelled to photoshop Agent Mularski AKA Splyntr, over a photo of Master Splinter…but I can’t find Mularski’s visage on the interwebs. If anyone has a photo, and it wouldn’t violate copyright laws, let me know?