I think you misunderstood a bit. What I meant was that given that quantum computing can render any cryptosystem based on factorization obsolete, but that it doesn't really help on any other cryptosystems, we should really worry more about things that can affect those other cryptosystems instead.
The nanoscale processors to which I am referring are not QCs at all... just simple RISC machines. Their power lies in sheer numbers... if you have a roomful of those little suckers (read: more processors than you can possibly imagine), you can crack pretty much anything you want. Granted, if the public has such powerful machines too they can use more and more complex encryption algorithms (read: larger keysizes), but the NSA will always have the money and resources to build something bigger that can crack that too. If they do things really cleverly, the nanoscale manufacturing robots would just keep building and building and building, adding more and more processors to the network 24 hours a day, with only a miniscule cost in raw materials required. That's the power of molecular manufacturing; once you set things in motion, the systems build themselves, and practically for free.
The public can only play leapfrog with the NSA to a certain point... a nanometer scale CPU is basically as small as you can get, and the only way to make a more powerful machine is to network more processors together. It's not very feasible for Joe Public to have a computer the size of a gymnasium that could run an encryption algorithm that the NSA couldn't crack without a computer the size of a city, as Joe Public simply doesn't have the space and other resources required (especially money). If you start building a computer that big in your backyard (assuming you have one... many urbanites don't), Someone In Power is going to notice, and probably is going to come and ask you why the heck you think you need a computer that big. I wouldn't be surprised at that point if supercomputers were to become classed as munitions, like strong crypto is now.
I think we have to be more worried about the advances in nanotechnology rather than quantum computing. Like others have said, quantum computing could kill cryptosystems based on products of large primes, but it seems it wouldn't neccessarily help on something like DES with a super wicked-huge keysize.
In Nanosystems, Drexler showed that it is possible to create a nanometer scale CPU that runs at 1 GHz, but fits into a 400 nm cube. According to my handy dandy TI pocket calculator, that means we could fit approximately 4.03225 * 10^13 of those little CPUs in a one inch square (which isn't exactly true, as you would have to connect them all, give them memory to use, etc., which I have not allowed for, but it gives you a very loose, ballpark figure), and that's only putting them one layer deep. Think about that. OVER FORTY TRILLION CPUs, all running at 1 GHz, all networked together, doing a distributed attack on a keyspace, and all of it fits in a square inch. With one of those suckers, you could crack any current encryption scheme using brute force, and it would most likely take less than a second (or at least, so I guess).
Granted, eventually the public would have such machines at their disposal (although we're talking a long way off here, as it would be quite a while before even a prototype could be built), but the NSA would always have the ability to build them much much much bigger (if they already have rooms full of Crays, imagine rooms full of these nanoprocessors!), and you know that they definitely would have them first, being that the kind of money it would take to design such a beast would be prohibitive for anyone else. By the time the design is done, surely we will have molecular manufacturing, and such a machine will cost nearly nothing to build, and the NSA could start churning them out by the thousands. Scary.
I think people really aren't seeing the point to MainWin, Wind/U, and other such products. The main argument that people seem to be making here against these products is that it presents people with a really bad porting strategy, because of dependence on Microsoft's architecture, performance hits, etc. While I do agree with all of this, people seem to not realize that there are good things about it too, and I'm going to tell you why. I'm going to illustrate this with a personal example here. Over the summer I worked as a summer student for a company that started off a couple of years ago making a product for Windows. However, after a couple of years of success in the market (number one market share), some VERY important customers (read: big cellular tech companies) indicated that they would like to see Solaris and HP/UX versions of our software. Up until then they had been using tools which had been very inferior to our product, and they wanted to get their hands on what we had to offer. However, they were not about to go restructuring their whole network and switch from UNIX to Windows just to get our tools. So it was decided that our company damn well better give them what they wanted, because these companies's business is VERY important to our parent company, as even though these companies might only buy 100 copies of our software, they use our software to write code for the gazillions of dollars in chips that they buy from our parent company, so even though we could end up losing money on the software itself, the cost recouped in chip sales would blow that away. So, ok, our company now has to do UNIX ports. However, the program has already been written to use MFC. Ideally if you knew you were going to do a port you would design your code with an appropriate abstraction layer so that you could do a proper job of the port, but when they wrote the program they hadn't had any indication that they would have to do this. What's more is that the company is pretty small... 30 people. The company doesn't have the resources to devote to rearchitecting the entire program so that "proper" ports can be made. What's more is that they have deadlines still to meet for their Windows product line, and those have to be met at the same time... they can't be holding up production. So what do they do? They buy Bristol's Wind/U to do the port. In theory this allows you to just drop in your Win32 code and recompile it, and voila you have a UNIX solution. In practice this doesn't happen, as the Wind/U toolkit has bugs, and in our case there were lots of Intel/Windows specific assumptions made when the program was written, and these things all had to be worked around or fixed. But the result was that in less than four months a team of three developers (two of which were just summer co-ops, of which I was one) managed to port a 300,000 line program, and what's more, we managed to fix bugs that were in the original release, as well as add some UNIX specific behaviour and functionality (which you can't do if you just emulate a program under Wine). If we had tried to rearchitect the whole thing, it probably would have taken at least twice the number of people and taken probably more than three times as long. To be honest, those factors would likely have prevented the thing from EVER being ported. The company (which does tend to be Windows-centric unfortunately), would probably just have told those customers to go invest in some Windows hardware and hope they listened. Products like MainWin and Wind/U will allow products to be ported that would otherwise never get ported at all. I don't know about the rest of you, but I would say that's a good thing. It's better to have a port even though it may not be optimally architected, than to have no port at all.
Slashdot Mirror
I think you misunderstood a bit. What I meant was that given that quantum computing can render any cryptosystem based on factorization obsolete, but that it doesn't really help on any other cryptosystems, we should really worry more about things that can affect those other cryptosystems instead.
The nanoscale processors to which I am referring are not QCs at all... just simple RISC machines. Their power lies in sheer numbers... if you have a roomful of those little suckers (read: more processors than you can possibly imagine), you can crack pretty much anything you want. Granted, if the public has such powerful machines too they can use more and more complex encryption algorithms (read: larger keysizes), but the NSA will always have the money and resources to build something bigger that can crack that too. If they do things really cleverly, the nanoscale manufacturing robots would just keep building and building and building, adding more and more processors to the network 24 hours a day, with only a miniscule cost in raw materials required. That's the power of molecular manufacturing; once you set things in motion, the systems build themselves, and practically for free.
The public can only play leapfrog with the NSA to a certain point... a nanometer scale CPU is basically as small as you can get, and the only way to make a more powerful machine is to network more processors together. It's not very feasible for Joe Public to have a computer the size of a gymnasium that could run an encryption algorithm that the NSA couldn't crack without a computer the size of a city, as Joe Public simply doesn't have the space and other resources required (especially money). If you start building a computer that big in your backyard (assuming you have one... many urbanites don't), Someone In Power is going to notice, and probably is going to come and ask you why the heck you think you need a computer that big. I wouldn't be surprised at that point if supercomputers were to become classed as munitions, like strong crypto is now.
Mechanik
I think we have to be more worried about the advances in nanotechnology rather than quantum computing. Like others have said, quantum computing could kill cryptosystems based on products of large primes, but it seems it wouldn't neccessarily help on something like DES with a super wicked-huge keysize.
In Nanosystems, Drexler showed that it is possible to create a nanometer scale CPU that runs at 1 GHz, but fits into a 400 nm cube. According to my handy dandy TI pocket calculator, that means we could fit approximately 4.03225 * 10^13 of those little CPUs in a one inch square (which isn't exactly true, as you would have to connect them all, give them memory to use, etc., which I have not allowed for, but it gives you a very loose, ballpark figure), and that's only putting them one layer deep. Think about that. OVER FORTY TRILLION CPUs, all running at 1 GHz, all networked together, doing a distributed attack on a keyspace, and all of it fits in a square inch. With one of those suckers, you could crack any current encryption scheme using brute force, and it would most likely take less than a second (or at least, so I guess).
Granted, eventually the public would have such machines at their disposal (although we're talking a long way off here, as it would be quite a while before even a prototype could be built), but the NSA would always have the ability to build them much much much bigger (if they already have rooms full of Crays, imagine rooms full of these nanoprocessors!), and you know that they definitely would have them first, being that the kind of money it would take to design such a beast would be prohibitive for anyone else. By the time the design is done, surely we will have molecular manufacturing, and such a machine will cost nearly nothing to build, and the NSA could start churning them out by the thousands. Scary.
Mechanik
Sorry about the lack of paragraphs there. Should have used Plain Old Text.
I think people really aren't seeing the point to MainWin, Wind/U, and other such products. The main argument that people seem to be making here against these products is that it presents people with a really bad porting strategy, because of dependence on Microsoft's architecture, performance hits, etc. While I do agree with all of this, people seem to not realize that there are good things about it too, and I'm going to tell you why. I'm going to illustrate this with a personal example here. Over the summer I worked as a summer student for a company that started off a couple of years ago making a product for Windows. However, after a couple of years of success in the market (number one market share), some VERY important customers (read: big cellular tech companies) indicated that they would like to see Solaris and HP/UX versions of our software. Up until then they had been using tools which had been very inferior to our product, and they wanted to get their hands on what we had to offer. However, they were not about to go restructuring their whole network and switch from UNIX to Windows just to get our tools. So it was decided that our company damn well better give them what they wanted, because these companies's business is VERY important to our parent company, as even though these companies might only buy 100 copies of our software, they use our software to write code for the gazillions of dollars in chips that they buy from our parent company, so even though we could end up losing money on the software itself, the cost recouped in chip sales would blow that away. So, ok, our company now has to do UNIX ports. However, the program has already been written to use MFC. Ideally if you knew you were going to do a port you would design your code with an appropriate abstraction layer so that you could do a proper job of the port, but when they wrote the program they hadn't had any indication that they would have to do this. What's more is that the company is pretty small... 30 people. The company doesn't have the resources to devote to rearchitecting the entire program so that "proper" ports can be made. What's more is that they have deadlines still to meet for their Windows product line, and those have to be met at the same time... they can't be holding up production. So what do they do? They buy Bristol's Wind/U to do the port. In theory this allows you to just drop in your Win32 code and recompile it, and voila you have a UNIX solution. In practice this doesn't happen, as the Wind/U toolkit has bugs, and in our case there were lots of Intel/Windows specific assumptions made when the program was written, and these things all had to be worked around or fixed. But the result was that in less than four months a team of three developers (two of which were just summer co-ops, of which I was one) managed to port a 300,000 line program, and what's more, we managed to fix bugs that were in the original release, as well as add some UNIX specific behaviour and functionality (which you can't do if you just emulate a program under Wine). If we had tried to rearchitect the whole thing, it probably would have taken at least twice the number of people and taken probably more than three times as long. To be honest, those factors would likely have prevented the thing from EVER being ported. The company (which does tend to be Windows-centric unfortunately), would probably just have told those customers to go invest in some Windows hardware and hope they listened. Products like MainWin and Wind/U will allow products to be ported that would otherwise never get ported at all. I don't know about the rest of you, but I would say that's a good thing. It's better to have a port even though it may not be optimally architected, than to have no port at all.