Often the fact that you communicated with a certain individual is suspicious enough, especially if encryption was used. You don't necessarily need to know what was said to learn a lot of useful information.
I don't think the reviewer did a very fair comparison. Most significantly, he should have used similar data cards- preferably using cards over USB. The AT&T and Verizon cards were larger, and probably able to pick up weaker signals better. They also included built-in batteries, which greatly impacted the laptop battery life test.
I'm also a little skeptical of his bandwidth testing method. I've never heard the Alken site, and the tests I did right now on my own system aren't even close to my actual performance (although, maybe they're justing getting slammed with traffic). It would have been interesting to see if signal strength played a factor as well.
In any case, most people I've heard from have had exactly the opposite results. Usually Sprint is the fastest, with Verizon not far behind and AT&T bringing up the rear. Sprint also has considerably more 3G coverage than the other two carriers. Without saying anything about their customer service, I think Sprint is the clear choice when it comes to data plans.
I take it you haven't tried Netflix's Watch Now. You get surprisingly good quality video from cable modem speed internet. I don't think I've ever had to wait more than 10 seconds at the beginning of playback for it to finish buffering. No, its not quite DVD quality, but it's better than SDTV. That's probably good enough for most people.
I think streaming video would work, from a technical perspective, for a lot of people today. I think it hasn't caught on yet because 1) the current lack of an easy way to watch these videos on TV (hence the STB) and 2) the movie/TV selection isn't great.
nTru has signing and encryption algorithms based on the shortest vector problem, which I believe is NP-hard. I don't know if they have a reductionist proof, or if its just based on SVP like RSA is based on factoring. But, they're probably the way to go if someone were to develop a working quantum computer tomorrow.
There's certainly no reason to go back to one-time pads. Basically all of the symmetric encryption algorithms are (mostly) quantum resistant. But, you do get a square root speed-up for attacking symmetric systems by using Grover's algorithm on a quantum computer. So, if you want to make sure you're still safe, you have to double your key length. That's not so bad, and certainly much better than using one-time pads.
And, as you said, there are asymmetric algorithms that should be resistant to quantum computers. McEliece is an early public key encryption algorithm (with sort of ridiculous key lengths) which is probably safe, although you can't do signatures with it in a reasonable way. Then, there's nTru's work, which is probably what we'd use if someone figured out how to build a quantum computer tomorrow. They have encryption and signing algorithms that are reasonably fast.
It's way too early to make predictions based on trends. Quantum computing is in its infancy. We haven't even built anything that could/should really be called a working quantum computer (yes, I know we factored 15). We're going to see revolutionary changes to the field, not just evolutionary. So, every once in a while we're going to see great leaps forward, followed by a period where people just improve upon that idea. Its going to take a lot of revolutionary ideas to get a practical quantum computer, and its nearly impossible to say how long it will take to think of them. Just look at fusion, which now I don't even think anyone bothers to say is "40 years off".
Bruce didn't actually write that article. He only linked to it on his blog, which isn't particularly relevant. And, although Bruce is a brilliant cryptographer, he doesn't know squat about quantum computers, nor does the person that wrote that article. One of the most glaring errors is corrected in comment posted on the article page. Besides that, his argument isn't completely sound. The biggest problem with quantum computers isn't managing to build one with a tons of quantum gates, it's getting the error rate down on the components. If you do that, you ought to be able to build as many gates as you want with enough effort and money. The author's argument seems akin to saying we couldn't possibly build a 100-billion transistor count processor today. We could, its just going to be very expensive and you're not going to mass-produce it.
Right now a lot of people working in the field say quantum computers are about 40 years off. The scary thing though is how its likely to play out. For a few decades quantum computers will likely remain "40 years off" (in the fusion sense), but then someone is going to figure out how to get the error rates below threshold, and then quantum computers will be only 10 years away. That doesn't give us much time to stop using our favorite public key algorithms. That's too bad for nTru; (they have a public key system that is likely resistant to quantum computers), their patents will be long expired.
I, for one, think we should ask Ms. Pikser (the lawyer who filed the complaint) why she thinks the work is copyrightable, even though it was made by the government. The DMCA notice conveniently says her email address is mpikser@reedsmith.com. For good measure we should probably all ask her. You know, just so we can compare responses...
You know, I can understand why you'd say that from my initial post, but I think the other two posts were perfectly reasonable. At least, the second one was. The previous response to you was a little less civil.
I certainly realized my posts would encourage an angry response or two. I don't think they should have, but I knew it was likely. Perhaps that makes me a troll. If so, I can deal with that. I tend to play devil's advocate, and I like that role. I still claim that I made arguable, but valid, points. But, if you really think that I'm just spouting off meaningless garbage that couldn't possibly have any value, then we're obviously not going to have any kind of meaningful conversation.
I'm not sure why you think I'm a RIAA troll (or what you mean by phony, for that matter). I don't think I was particularly supportive of the RIAA. Yes, I'm defending Jacobson. You can argue with the data that he received, but I'm still convinced his conclusions are correct. That doesn't mean there aren't other possibilities, but Jacobson came to the overwhelmingly likely conclusions.
Now, if you didn't go out and look for someone to basically testify to what Pouwelse said that's one thing. If he approached you and said "I'd love to rip into Jacobson" then maybe I was being a bit harsh on you. I suspect that wasn't the case, but its certainly a possibility. But, I would think a certain amount of witness coaching went on- you telling him what you're looking for and him telling you what he's willing to say. In and of itself, that's fine. But, if that did go on, it seems a little disingenuous to say "I didn't say that- the expert did."
In any case, while you're probably a perfectly nice person in "real life", you were unnecessarily rude and arrogant when you examined Jacobson. In particular I'm thinking back to your little vocabulary quiz.
I had another post in this thread. I'm actually genuinely curious to read any response you might have to that one.
Thanks for the link and the excerpts. I hadn't read some of those documents before. I didn't go back and reread his actual deposition, but I'm pretty sure he said something to the effect of that he assumed the data from MediaSentry was accurate when he conducted his analysis. I remember that because I recall a bunch of slashdot comments jumping on him for that, because he didn't have any real reason to believe that information was true. I don't think that's necessarily a problem, although you'd need someone from MediaSentry to testify to the veracity of the data.
Nothing in your post indicated that he actually testified that he knew the data from MediaSentry was correct.
He apparently mispoke (or, more likely, miswrote) in his affidavit when he said he would testify to MediaSentry's procedures. As it turns out, he didn't testify to the procedures in his deposition (at least, I don't see where he did), nor did he say the information was necessarily accurate. I assume MediaSentry's stuff was entered into evidence, so presumably someone from MediaSentry validated it. If not, then it really seems like Jacobson's testimony lacks foundation, and shouldn't have been allowed in the first place. But, that's not Jacobson's fault.
Perhaps the affidavit is misleading. But, at worst it made the defense think Jacobson was going to testify about something that he never did. So, maybe they did a bit more preparation than necessary. It seems like they would have had to do it anyway, since I know I would have challenged MediaSentry's information, not Jacobson's interpretation. What harm do you think came from that line in the affidavit?
Jacobson didn't say that MediaSentry's methods were correct. He said he assumed they were correct. There's a huge difference here. On cross he did downplay things like spoofing, just as he should have.
I'm a card carrying member of the ACLU and, for the most part, I hate how the RIAA conducted themselves, but this is pretty ridiculous. Jacobson's testimony was perfectly fine. There's certainly room to question the accuracy of the data given to him, and to a lesser extent, some room to dispute how conclusive his findings were, but this is way beyond that. I realize NewCountryLawyer is just zealously defending his client, and that he isn't terribly knowledgeable about this stuff, but I have to say I've pretty much lost all remaining respect I had for him. There are ways to rebut Jacobson's testimony that are honest and (mostly) convincing- but this isn't it.
Read the article. It says that federal government network traffic will be monitored by the NSA, instead of just being monitored by the individual agencies. Are you planning to send a lot of messages from a government-operated computer network that you don't want anyone to read? If you are, why weren't you just as concerned about that agency's monitoring system catching you?
Now, if you do work for the feds and you don't want the NSA to see exactly what you're doing online, your suggested tools won't help you too much. You need to make sure the communications protocol you're using with the other system is using encryption. That is, you visit SSL/TLS enabled websites. I suppose you could use PGP/GPG encryption for e-mails, but that is unlikely to work in most situations. Its mostly too bad webmail services don't use SSL/TLS for anything but sending login information.
NIST is still has a large role in US government computer security efforts. While NIST's recommendations are advisory in nature, OMB says NIST's recommendations are mandatory in systems that fall outside the realm of national security (the NSA deals with those systems).
The summary (and the article) makes this program sound a lot more secret than it is. This has been in the works for a while, pretty openly in fact. A lot of people in the civilian sector of the government knew this was coming down several months ago. I'm not really sure how its going to work technically, nor do I think DHS or the NSA know either. A lot of network traffic, particularly things of a sensitive nature, is encrypted. I don't think civilian agencies are going to want to start handing decryption keys to DHS or even NSA (and no, the NSA can't just crack the crypto algorithms, nor do they have a quantum computer in their basement). In any case, this will probably be a pain for the working people at government agencies, but there's probably nothing to be worried about.
You're actually missing one of the funny parts of the review. Neils Ferguson, a researcher at Microsoft, is one of the people that found the potential security flaw. It was probably Microsoft's decision to implement the RBG that caused him to start looking at it.
Slashdot Mirror
Often the fact that you communicated with a certain individual is suspicious enough, especially if encryption was used. You don't necessarily need to know what was said to learn a lot of useful information.
I don't think the reviewer did a very fair comparison. Most significantly, he should have used similar data cards- preferably using cards over USB. The AT&T and Verizon cards were larger, and probably able to pick up weaker signals better. They also included built-in batteries, which greatly impacted the laptop battery life test.
I'm also a little skeptical of his bandwidth testing method. I've never heard the Alken site, and the tests I did right now on my own system aren't even close to my actual performance (although, maybe they're justing getting slammed with traffic). It would have been interesting to see if signal strength played a factor as well.
In any case, most people I've heard from have had exactly the opposite results. Usually Sprint is the fastest, with Verizon not far behind and AT&T bringing up the rear. Sprint also has considerably more 3G coverage than the other two carriers. Without saying anything about their customer service, I think Sprint is the clear choice when it comes to data plans.
I take it you haven't tried Netflix's Watch Now. You get surprisingly good quality video from cable modem speed internet. I don't think I've ever had to wait more than 10 seconds at the beginning of playback for it to finish buffering. No, its not quite DVD quality, but it's better than SDTV. That's probably good enough for most people. I think streaming video would work, from a technical perspective, for a lot of people today. I think it hasn't caught on yet because 1) the current lack of an easy way to watch these videos on TV (hence the STB) and 2) the movie/TV selection isn't great.
nTru has signing and encryption algorithms based on the shortest vector problem, which I believe is NP-hard. I don't know if they have a reductionist proof, or if its just based on SVP like RSA is based on factoring. But, they're probably the way to go if someone were to develop a working quantum computer tomorrow.
There's certainly no reason to go back to one-time pads. Basically all of the symmetric encryption algorithms are (mostly) quantum resistant. But, you do get a square root speed-up for attacking symmetric systems by using Grover's algorithm on a quantum computer. So, if you want to make sure you're still safe, you have to double your key length. That's not so bad, and certainly much better than using one-time pads. And, as you said, there are asymmetric algorithms that should be resistant to quantum computers. McEliece is an early public key encryption algorithm (with sort of ridiculous key lengths) which is probably safe, although you can't do signatures with it in a reasonable way. Then, there's nTru's work, which is probably what we'd use if someone figured out how to build a quantum computer tomorrow. They have encryption and signing algorithms that are reasonably fast.
It's way too early to make predictions based on trends. Quantum computing is in its infancy. We haven't even built anything that could/should really be called a working quantum computer (yes, I know we factored 15). We're going to see revolutionary changes to the field, not just evolutionary. So, every once in a while we're going to see great leaps forward, followed by a period where people just improve upon that idea. Its going to take a lot of revolutionary ideas to get a practical quantum computer, and its nearly impossible to say how long it will take to think of them. Just look at fusion, which now I don't even think anyone bothers to say is "40 years off".
Bruce didn't actually write that article. He only linked to it on his blog, which isn't particularly relevant. And, although Bruce is a brilliant cryptographer, he doesn't know squat about quantum computers, nor does the person that wrote that article. One of the most glaring errors is corrected in comment posted on the article page. Besides that, his argument isn't completely sound. The biggest problem with quantum computers isn't managing to build one with a tons of quantum gates, it's getting the error rate down on the components. If you do that, you ought to be able to build as many gates as you want with enough effort and money. The author's argument seems akin to saying we couldn't possibly build a 100-billion transistor count processor today. We could, its just going to be very expensive and you're not going to mass-produce it.
Right now a lot of people working in the field say quantum computers are about 40 years off. The scary thing though is how its likely to play out. For a few decades quantum computers will likely remain "40 years off" (in the fusion sense), but then someone is going to figure out how to get the error rates below threshold, and then quantum computers will be only 10 years away. That doesn't give us much time to stop using our favorite public key algorithms. That's too bad for nTru; (they have a public key system that is likely resistant to quantum computers), their patents will be long expired.
I, for one, think we should ask Ms. Pikser (the lawyer who filed the complaint) why she thinks the work is copyrightable, even though it was made by the government. The DMCA notice conveniently says her email address is mpikser@reedsmith.com. For good measure we should probably all ask her. You know, just so we can compare responses...
You know, I can understand why you'd say that from my initial post, but I think the other two posts were perfectly reasonable. At least, the second one was. The previous response to you was a little less civil.
I certainly realized my posts would encourage an angry response or two. I don't think they should have, but I knew it was likely. Perhaps that makes me a troll. If so, I can deal with that. I tend to play devil's advocate, and I like that role. I still claim that I made arguable, but valid, points. But, if you really think that I'm just spouting off meaningless garbage that couldn't possibly have any value, then we're obviously not going to have any kind of meaningful conversation.
I'm not sure why you think I'm a RIAA troll (or what you mean by phony, for that matter). I don't think I was particularly supportive of the RIAA. Yes, I'm defending Jacobson. You can argue with the data that he received, but I'm still convinced his conclusions are correct. That doesn't mean there aren't other possibilities, but Jacobson came to the overwhelmingly likely conclusions.
Now, if you didn't go out and look for someone to basically testify to what Pouwelse said that's one thing. If he approached you and said "I'd love to rip into Jacobson" then maybe I was being a bit harsh on you. I suspect that wasn't the case, but its certainly a possibility. But, I would think a certain amount of witness coaching went on- you telling him what you're looking for and him telling you what he's willing to say. In and of itself, that's fine. But, if that did go on, it seems a little disingenuous to say "I didn't say that- the expert did."
In any case, while you're probably a perfectly nice person in "real life", you were unnecessarily rude and arrogant when you examined Jacobson. In particular I'm thinking back to your little vocabulary quiz.
I had another post in this thread. I'm actually genuinely curious to read any response you might have to that one.
Thanks for the link and the excerpts. I hadn't read some of those documents before. I didn't go back and reread his actual deposition, but I'm pretty sure he said something to the effect of that he assumed the data from MediaSentry was accurate when he conducted his analysis. I remember that because I recall a bunch of slashdot comments jumping on him for that, because he didn't have any real reason to believe that information was true. I don't think that's necessarily a problem, although you'd need someone from MediaSentry to testify to the veracity of the data.
Nothing in your post indicated that he actually testified that he knew the data from MediaSentry was correct.
He apparently mispoke (or, more likely, miswrote) in his affidavit when he said he would testify to MediaSentry's procedures. As it turns out, he didn't testify to the procedures in his deposition (at least, I don't see where he did), nor did he say the information was necessarily accurate. I assume MediaSentry's stuff was entered into evidence, so presumably someone from MediaSentry validated it. If not, then it really seems like Jacobson's testimony lacks foundation, and shouldn't have been allowed in the first place. But, that's not Jacobson's fault.
Perhaps the affidavit is misleading. But, at worst it made the defense think Jacobson was going to testify about something that he never did. So, maybe they did a bit more preparation than necessary. It seems like they would have had to do it anyway, since I know I would have challenged MediaSentry's information, not Jacobson's interpretation. What harm do you think came from that line in the affidavit?
Jacobson didn't say that MediaSentry's methods were correct. He said he assumed they were correct. There's a huge difference here. On cross he did downplay things like spoofing, just as he should have. I'm a card carrying member of the ACLU and, for the most part, I hate how the RIAA conducted themselves, but this is pretty ridiculous. Jacobson's testimony was perfectly fine. There's certainly room to question the accuracy of the data given to him, and to a lesser extent, some room to dispute how conclusive his findings were, but this is way beyond that. I realize NewCountryLawyer is just zealously defending his client, and that he isn't terribly knowledgeable about this stuff, but I have to say I've pretty much lost all remaining respect I had for him. There are ways to rebut Jacobson's testimony that are honest and (mostly) convincing- but this isn't it.
Read the article. It says that federal government network traffic will be monitored by the NSA, instead of just being monitored by the individual agencies. Are you planning to send a lot of messages from a government-operated computer network that you don't want anyone to read? If you are, why weren't you just as concerned about that agency's monitoring system catching you? Now, if you do work for the feds and you don't want the NSA to see exactly what you're doing online, your suggested tools won't help you too much. You need to make sure the communications protocol you're using with the other system is using encryption. That is, you visit SSL/TLS enabled websites. I suppose you could use PGP/GPG encryption for e-mails, but that is unlikely to work in most situations. Its mostly too bad webmail services don't use SSL/TLS for anything but sending login information.
NIST is still has a large role in US government computer security efforts. While NIST's recommendations are advisory in nature, OMB says NIST's recommendations are mandatory in systems that fall outside the realm of national security (the NSA deals with those systems).
The summary (and the article) makes this program sound a lot more secret than it is. This has been in the works for a while, pretty openly in fact. A lot of people in the civilian sector of the government knew this was coming down several months ago. I'm not really sure how its going to work technically, nor do I think DHS or the NSA know either. A lot of network traffic, particularly things of a sensitive nature, is encrypted. I don't think civilian agencies are going to want to start handing decryption keys to DHS or even NSA (and no, the NSA can't just crack the crypto algorithms, nor do they have a quantum computer in their basement). In any case, this will probably be a pain for the working people at government agencies, but there's probably nothing to be worried about.
You're actually missing one of the funny parts of the review. Neils Ferguson, a researcher at Microsoft, is one of the people that found the potential security flaw. It was probably Microsoft's decision to implement the RBG that caused him to start looking at it.