Microsoft Creates a Quantum Computer-Proof Version of TLS Encryption Protocol 128
holy_calamity writes: When (or if) quantum computers become practical they will make existing forms of encryption useless. But now researchers at Microsoft say they have made a quantum-proof version of the TLS encryption protocol we could use to keep online data secure in the quantum computing era. It is based on a mathematical problem very difficult for both conventional and quantum computers to crack. That tougher math means data moved about 20 percent slower in comparisons with conventional TLS, but Microsoft says the design could be practical if properly tuned up for use in the real world.
You forgot to include the quote Re:haha (Score:1)
The new quantum-proof version of TLS generates encryption keys using a different mathematical problem that's believed to be beyond the practical reach of both conventional and quantum computers. [emphasis added]
Okay, now you can "hahahahaha" all you want.
Linux distros secure??? (Score:2)
Well, maybe some of the hardened distros, but your run of the mill distros have so much on them that hasn't been scrubbed from a security standpoint that it makes Windows look merely like swiss cheese instead of confetti.
If you are serious about security but still want a "full featured", not-so-rare-that-almost-nobody-has-heard-about-it, modern OS that runs on and takes advantage of a modern PC, look at either the security-hardened Linux distros, OpenBSD and other security-hardened BSDs, or maybe a custom-s
Re: (Score:1)
Kind of convenient that they make this sort of "breakthrough" right after Windows NSA edition is given away for "free".
Now now, Windows X isn't any more exploitable by the NSA than most previous versions.
I prefer to call it "Windows Madison Avenue version" or "Windows encourage us to give up our privacy for convenience version" or "Windows get us to pay for Microsoft's bandwidth version".
Re: (Score:3, Funny)
I think I deciphered the message hidden within your comment, but as a woman I'm afraid that I cannot be of any help to you.
Your encrypted message was:
Decrypted, it reads:
Maybe somebody else here could be of assistance?
20% slowdown isn't that bad... (Score:5, Insightful)
Re: 20% slowdown isn't that bad... (Score:2)
I bet the NSA is going "FUCK do you know how much these quantum computers cost!?!?"
Re: 20% slowdown isn't that bad... (Score:5, Insightful)
I bet the NSA is going, "Just charge it to the taxpayers."
Re: (Score:1)
Why bother. They can just bypass it in the first place...
Just like any competent cracker has been able to do...
Re: (Score:3, Funny)
Oh so now you're going to play the race card.
Re: (Score:3, Insightful)
Except that since Windows Vista every subsequent OS has been faster on the same hardware.
Re: (Score:2)
Vista wasn't crippled by processor speed, anyway, it was crippled by being installed on low RAM systems. That and having lots of shit services running as default.
I'm still typing from my almost 10 year old Vista system on which I play Elite : Dangerous and a whole host of other new games. The graphics card is newer.
Re: 20% slowdown isn't that bad... (Score:1)
No, most of vistas problems were due to drm. With the release version of vistas playing a music file would reduce reduce network bandwidth by like 80%. This was fixed in a SP but it was available weeks after 7 launched and there was no reason to run vistas.
Re: (Score:2)
I used a late 2009 iMac with 4GB of ram till it died on me a couple months ago. I had XP, win 7, win 8, and win 8.1 on it along with various OS X versions. I'm speaking from experience. Apps themselves got more demaining, yeah, ex: Visual Studio 2013 was essentially unusable though that might have been do to my computers harddrive being flaky or something (it did after all brick on me about 4 months later). Other than that though, I didn't notice any performance changes but got more features in each version
very difficult problems (Score:5, Funny)
It is based on a mathematical problem very difficult for both conventional and quantum computers to crack.
Ah, that would be my federal tax return.
Re: (Score:2)
It is based on a mathematical problem very difficult for both conventional and quantum computers to crack.
Ah, that would be my federal tax return.
Or how to correctly answer your wife/girlfriend when she asks, "Do these jeans make me look fat?"
Re: (Score:1)
It is based on a mathematical problem very difficult for both conventional and quantum computers to crack.
Ah, that would be my federal tax return.
Or how to correctly answer your wife/girlfriend when she asks, "Do these jeans make me look fat?"
I keep telling you. It's your ass making you look fat.
Re: (Score:2)
Congratulations on your new status of 'Single'
Re: (Score:1)
The question is easy to answer correctly. Or truthfully. Just not both.
Re: (Score:2)
No is both correct and truthful. To answer anymore than that one word, you will have to decide if you want to lie or go back to your ex Rosy.
There is no there there (Score:2, Insightful)
TFA doesn't say what they're replacing the integer factorization problem with. Useless.
Re:There is no there there (Score:5, Informative)
I think this is the actual publication [microsoft.com].
They're using ring learning with errors [wikipedia.org].
One time pad (Score:1)
Re: (Score:1)
The reason for using math-based ciphers is to reduce key size--not for storage, but for key exchange.
Re: (Score:2)
OTPs are great. On the other hand, you have to use each pad only once. Ever. So to encrypt 1GB of data, you need 1GB of cryptographically random pad. Which you can never use again. And must be a secret with regards to the rest of the world. And must be present on both the sending and receiving end of the communication.
If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.
The value of a OTP (Score:2)
If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.
The value of a one-time pad is that if you can get data securely to someone else only during certain time periods, you can exchange your pads at that time then you can exchange data securely whenever you want to (well, until you use up your pad).
It's really useful when one party, say, a government, is free to "broadcast" the encrypted information, say, over shortwave radio, and the other party, say, a spy, is only a listener. For the spied-upon country to detect the shortwave radio the spy is using will be
Re: (Score:3)
Right. When was the last time you were physically at GMail world headquarters to share your 1 Petabyte pad (which, by the by, you must never lose yet never copy). Let alone a website you've never used before.
We're talking about practical encryption. One Time Pads have their place. Most people will literally never use one. Almost everybody will use TLS encryption.
Re: (Score:3)
OTPs are great. On the other hand, you have to use each pad only once. Ever. So to encrypt 1GB of data, you need 1GB of cryptographically random pad. Which you can never use again. And must be a secret with regards to the rest of the world. And must be present on both the sending and receiving end of the communication.
If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.
Not quite. You can't repeat the pad the same way ever - that is, you don't want to wrap it or reset to known locations using any kind of protocol. You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap. So you're data limited unless you have an infinite data source.
That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number
Re: (Score:2)
You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap
You're just performing anti-compression / encryption on the pad, which was already perfectly encrypted.
There is literally no security difference between these two pads:
XOJIGQIOJG
XAOAAJAAAIAAAAGAAAAAQAAAAAAIAAAAAAAOAAAAAAAAJAAAAAAAAAG
(for every character you have already decoded, you must skip that many characters before reading the next character from the one-time pad).
The second one is just far less efficient. You can try to recover the efficiency by saying the next time you use that OTP, you use every ch
Re: (Score:2)
You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap
You're just performing anti-compression / encryption on the pad, which was already perfectly encrypted.
There is literally no security difference between these two pads:
XOJIGQIOJG XAOAAJAAAIAAAAGAAAAAQAAAAAAIAAAAAAAOAAAAAAAAJAAAAAAAAAG (for every character you have already decoded, you must skip that many characters before reading the next character from the one-time pad).
There is no requirement to skip a character in one-time pads. You can read sequential bytes without any issue. That said, how you use the one-time pad data can certainly contribute to its worth or worthlessness.
Supposing that the first example is used as is, and the second example all the A's are skipped, that that's correct - there is no difference. However, there is a big difference if in the second example you don't skip the A's - the pad is degrading your security as it's not sufficiently random.
That said, you could probably use a synchronized random number generator as the shared pad data.
That
Re:One time pad (Score:5, Interesting)
That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number data; after which the message is lost to everyone for eternity. This could work for a TLS session where messages are exchanged with only a couple minutes (or preferably seconds) delay so that the buffer does not need to be very big.
That's roughly the definition of a stream cipher (e.g. RC4 or a block cipher in Counter mode). Only a cryptographically secure random number generator works, which is why such a thing is called a stream cipher and not just a "pseudo-random one time pad". In any case it's not a true one time pad because the entropy of the stream of pseudorandom data is limited to the entropy of the internal state of the cipher, and further limited by the entropy of the key. That means stream ciphers can be broken given only the ciphertext, as opposed to using a one time pad. Stream ciphers also share the same weakness as one time pads; reusing the same stream cipher key is just as bad as reusing a one time pad (virtually automatic recovery of all plaintexts encrypted with the same pad/stream).
Re: (Score:2)
That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number data; after which the message is lost to everyone for eternity. This could work for a TLS session where messages are exchanged with only a couple minutes (or preferably seconds) delay so that the buffer does not need to be very big.
That's roughly the definition of a stream cipher (e.g. RC4 or a block cipher in Counter mode). Only a cryptographically secure random number generator works, which is why such a thing is called a stream cipher and not just a "pseudo-random one time pad". In any case it's not a true one time pad because the entropy of the stream of pseudorandom data is limited to the entropy of the internal state of the cipher, and further limited by the entropy of the key. That means stream ciphers can be broken given only the ciphertext, as opposed to using a one time pad. Stream ciphers also share the same weakness as one time pads; reusing the same stream cipher key is just as bad as reusing a one time pad (virtually automatic recovery of all plaintexts encrypted with the same pad/stream).
There's a big difference:
With a normal cipher stream (RC4, etc) it's data that is shared on the fly to create the cipher stream in a shared state (TLS, Diffie-Hellman, etc). The fact that you have to create it on the fly leads to vulnerabilities and MITM attacks.
Conversely with the one-time pad you have all the data pre-shared; in my example of using an RNG (not a PRNG) - it's a synchronized hardware device that is shared. This is why a one-time pad is more secure than any normal cipher stream.
Howe
Re: (Score:1)
That said, you could probably use a synchronized random number generator as the shared pad data.
No; a true OTP is NOT the same as pseudo-random OTP. For an illustration of this concept, let's assume that your adversary knows your algorithm for generating the pads but has no information about the shared secret between you and your partner. To make things easier on your opponent, let's assume that he knows that you plan to encrypt a 1GB plain-text ASCII file.
In the case of a true OTP, you and your partner must share 1GB of data securely. Because the pad is truly random, any 1GB ciphertext is equally
Re: (Score:1)
I am a math geek. I am not now, nor have I ever been, a crypto-geek. I do have a dumb question...
Is it possible, and I will try to explain as well as I can, to have an encrypted file that, when decrypted, becomes an actual encrypted file which requires a password to open? I realize that may be a strange way to think about it.
Let's say that I have a file, a plain text file, and I put it into a password protected .zip file. That new file, the .zip, would then be encrypted, as a whole, into a new file - say fi
Re: (Score:2)
I am a math geek. I am not now, nor have I ever been, a crypto-geek. I do have a dumb question...
Is it possible, and I will try to explain as well as I can, to have an encrypted file that, when decrypted, becomes an actual encrypted file which requires a password to open? I realize that may be a strange way to think about it.
Let's say that I have a file, a plain text file, and I put it into a password protected .zip file. That new file, the .zip, would then be encrypted, as a whole, into a new file - say file.tar.bz. Now, to open it, you would need to have the shared key PLUS you would need to know the password to the encrypted .zip file.
I understand that this has nothing to do with TLS and would be wholly impractical for browsing. However, the talk of encryption made me wonder about this and I have been pondering this for a couple of years now. It means it would be something you have and something you know.
Yes you can encrypt and encrypted file - just as you described. However, you have to use a different crypto keyset to do it or you defeat the encryption by revealing too much information.
I can think of many ways to share the needed password/pass-phrase securely (for certain definitions of securely). Say, five books in a certain order on a bookshelf and calling with a series of numbers which determine with pages and words are used to make up the pass-phrase. A call could be as simple as, "Number 3, 27, 5, 18, number 7, 14, 32, 8. Confirm?" Which would be book number 5, chapter 3, 27th page, fifth and eighteenth words and book seven, chapter fourteen, thirty second and eighth word would be the password. This does not help if there is someone physically present.
That was done extensively throughout the Cold War, and is a common use of OTP. It's highly secure, and very difficult to break due to that exact kind of thing.
Anyhow, there may be some need to change the file type at the recipient's end because decrypting the file.tar.bz file will not necessarily mean that the file has the appropriate .zip extension but, well, that is pretty trivial.
What am I missing? This, obviously, has absolutely no value in the real world for almost every single person on the planet. I could see it being useful for TLAs or those who are trying to subvert their government (for a variety of reasons which may be good or bad).
To start, most software detects file types based on the content, not the file names. They may use a file extension as a basic filter, but often that's more of a user-
Re: (Score:1)
Thank you much. Now to find a way to combine a couple of apps and make it do this on its own. It sounds like an enjoyable project. I can, likely, find OSS to include as a way of saving a bunch of time. Basically, my thinking is more for a single person to use it. They can create a file, such as a plain text, encrypt it, take the resulting file and encrypt that into an AES encrypted RAR file that needs a password.
So, in order to open the file, they will have to know the password for the compressed and encryp
Re: (Score:2)
No; a true OTP is NOT the same as pseudo-random OTP.
I said using an RNG not a PRNG.
A synchronized RNG is generated by synchronizing the clocks on the hardware, and initial seed data. True, it's not a fully random RNG, but it is sufficient for the needs of a OTP crypt/decrypt function as I described.
I also never said it was perfect; just theorizing on a way that you could do it with shared hardware instead of having to share an enormous file.
In reality, nobody uses a OTP because if you can securely communicate the length of the pad, you can just as easily communicate the entire message. What is used instead is public-key encryption where your partner can encrypt a message, but only you can decrypt it.
And yes, OTP has been used to securely communicate many things. In many senses, the Enigma machine is a OTP kind
The problem with one-time pads (Score:1)
The problem with one-time pads is securely exchanging the key and protecting it between the time of exchange and time of use.
If I want to open an account with an online bank or shop at an online store with no local brick-and-mortar location, either I have to drive/fly/whatever out to their nearest location or we have to agree on some mutually-trustworthy person to transport the key between us.
I guess we could agree to transport the key across the Internet, but to do so without weakening security would mean
Re: (Score:2)
Heh, that's what you don't understand. It's one time pads all the way down!!
Re: (Score:1)
While I have a basic understanding about one-time pads and how they work, I realize that there must be something wrong with this idea but I don't know enough to figure out what.
There are vast amounts of publicly available documents on the Internet. Why can't Alice and Bob agree that they will use the text of the first article posted on Slashdot after noon Central Standard Time each day that they have a message to send as their one time pad? In that way avoid the issue of having to transfer the pad between
Re: (Score:2)
While I have a basic understanding about one-time pads and how they work, I realize that there must be something wrong with this idea but I don't know enough to figure out what.
There are vast amounts of publicly available documents on the Internet. Why can't Alice and Bob agree that they will use the text of the first article posted on Slashdot after noon Central Standard Time each day that they have a message to send as their one time pad?
That isn't a One-Time Pad. In OTP the pad is secret; in the scenario you just described, the content of the "pad" is public. The encryption key is thus not the pad itself, but rather just the identification of the pad ("1st article on Slashdot after noon CST"). Putting aside the fact that an article has relatively low entropy per character, someone with access to just one cyphertext could conceivably test it against a large database of likely public documents and identify the pad simply by looking for a doc
Re: (Score:2)
The problem is that your OTP needs to be random and text is far from random. A lot of things are known about the data in text, such as the range of possible byte values and the frequency with which different characters are used. These sorts of problems will make your encrypted text extremely vulnerable to statistical analysis.
Re: (Score:3)
What you've described has been known for centuries as a "book cipher". Benedict Arnold used one during the American Revolutionary War to protect his treasonous communication with England.
Anyway, there's a really fun way to beat this kind of encryption today. If Mallory can get Alice or Bob to send a copy of BLACK_SQUARE.BMP, it's literally game over. Imagine XORing your key against a bunch of binary zeros. The result is a big patch of the cleartext version of the data that is your key. Google will find
Re: (Score:1)
Re: (Score:2)
Because then your compression function effectively becomes your encryption function. And it wasn't designed for security.
Keep in mind these are simple issues to identify and exploit. All these "what-if" scenarios have been played out repeatedly, which is why the standard response is always "use a proven secure algorithm, don't roll your own cryptographic solution." It's easier, less bug prone,and the security has been analyzed by more qualified people than you can afford. Any known weaknesses have already b
Re: (Score:2)
Why can't Alice and Bob agree that they will use the text of the first article posted on Slashdot after noon Central Standard Time each day that they have a message to send as their one time pad? In that way avoid the issue of having to transfer the pad between themselves in advance and they have a new text available daily.
How is Alice supposed to inform Bob of this scheme in the first place?
If I am intercepting their communications, I will know of their scheme and have the same access to Slashdot at noon CST to obtain their daily key just as well as they can.
If Alice and Bob do have some "magic" method to communicate this scheme, then why should they bother with the encryption scheme in the first place? Just use the "magic" method they would have used for all their communications since it clearly must be secure, right?
Re: (Score:2)
To ensure privacy and anonymity? A one time pad gives two people, a project or an entire nation privacy. Constant fixed site messages (embassy, political leader, bank) still gets the full privacy and understands the total lack of all anonymity.
The Soviet Union faced this question in the 1950's. They understood that their complex communications networks had no privacy or anonymity.
The UK and US had mapped out their global networ
Re: (Score:2)
You still haven't answered the question to the problem at hand.
How do you securely exchange a one time pad in the first place, if all of your communications are being monitored?
That is the one and only thing public key crypto does. Nothing secret needs exchanged, and the only thing needing exchanged is perfectly fine to be public knowledge as it doesn't let an attacker do anything.
(Well, it would let the attacker send you an encrypted message that only you can read - but that's not a risk, that's precisely
Re: (Score:2)
With anonymity lost, it is then just a race to get to the hardware and plain text as the common computer is often used to create the messages.
Thats the honey pot in modern crypto, making random people reach out and swap keys. If they slip up or can be induced to make a mistake... or the open developer was a gov/mil front?
It depends where a gov has placed its ski
Re: (Score:2)
A lot to reply to, and a lot of conflicting concepts even though you are essentially correct regarding each of them.
First, encryption alone isn't related to identification/anonymity. Those are two separate things each needing addressed.
In fact even with public key crypto, reverse encryption (aka signing) isn't required to use, but is the only method for true identification on top of the encryption.
For communications to be secured, only the requirement of 3rd parties being unable to read it is assumed. Ide
Re: (Score:2)
If Alice and Bob do have some "magic" method to communicate this scheme, then why should they bother with the encryption scheme in the first place?
Alice and Bob have a steganography system they believe to be unbeatable that can't be unbeatable if it is used for larger communications. But works for indicating which "pad" to use. One could presume that the steganography and pad selection was set up before the interception began. Such a system would not work well for a new communication path, but for paths that were secure when set up, than are later insecure.
What algorithm/primitive? (Score:3)
They went into Shor's Algorithm, ECC, and such... but the article doesn't seem to show what algorithm they decided to go with that is resistant to quantum factoring.
Are they going with something lattice based?
Would be nice to have more details on what they came up with... 20% performance can be important, but what is more important is how the algorithm resists different attacks.
Re: (Score:2)
> 20% performance can be important
why?
Re: (Score:3)
High volume server farms doing lots of web transactions. A 20% addition might mean having to have that many more servers behind the load balancer to handle the algorithm's added CPU load.
However, if it does protect against an up and coming attack, that penalty might not seem as bad compared to a protocol break.
Re: (Score:3)
20% is roughly the CPU speedup realized in just one year. It feels really insignificant. Also, I haven't read the FA, but making something harder to break to the tune of only one year's CPU speed advance isn't quite the same thing as making it quantum computer proof, even if someone expects commercial quantum computers in a year :-)
Re: (Score:2)
The problem is that quantum computers are theoretically able to break encryption instantaneously. This isn't 20% slower than instantaneous it's 20% slower to encrypt/decrypt when you have the key. The comparison being that a dead bolt and a regular lock takes twice as long to lock and unlock but that doesn't speak to how much longer it takes to cut through the door.
Re:What algorithm/primitive? (Score:4, Informative)
Are they going with something lattice based?
Hm.. An internet search finds this one: http://research.microsoft.com/... [microsoft.com]
The headline is "Post-quantum key exchange for the TLS protocol from the ring learning with errors problem", so it doesn't seem to have strictly to do with a lattice-based problem if it's the algorithm that was meant in the article above.
And this is an explanation: http://csrc.nist.gov/groups/ST... [nist.gov]
I haven't understood the problem that deeply but when I do I will post it here.
Re: (Score:2)
Re: (Score:3)
Shor's algorithm only is usable with asymmetric algorithms, so AES isn't really affected. The part that is affected is only done during the handshaking process, so if the parent is right and long lived connections [1] are used, this might soften the blow somewhat.
[1]: I've wondered about a trade-off of space for CPU and having the TLS protocol negotiate a master session keystream (pretty much a sequence of interim symmetric keys that gets consumed to make session keys, and when the last one gets consumed,
Re: (Score:2)
Re: (Score:2)
Well, I did read TFA... (Score:4, Insightful)
This article is about a waste of time.
Microsoft has developed an encryption method resistant to quantum computers, it claims. Alright? What is that method? How does it differ from current encryption techniques? Why is that well suited to encrypting against quantum computers? How did you come to that conclusion, given that you don't have one to test against? Are we just supposed to believe Microsoft when they say "Trust us, this is secure"?
Re: (Score:2)
Are we just supposed to believe Microsoft when they say "Trust us, this is secure"?
Yes, it's secure because they will give all of your data to the NSA for safekeeping.
Re: (Score:1)
Now that sounds like a Genuine Advantage!®
Re:Well, I did read TFA... (Score:5, Insightful)
This article is about a waste of time. Microsoft has developed an encryption method resistant to quantum computers, it claims. Alright? What is that method? How does it differ from current encryption techniques? Why is that well suited to encrypting against quantum computers? How did you come to that conclusion, given that you don't have one to test against? Are we just supposed to believe Microsoft when they say "Trust us, this is secure"?
No of course not. You're meant to read this article, understand that it's an example of bad science journalism, and because of your innate geekiness and intellectual curiosity you should use the power of Google or Bing to find the scientific research in question:
http://csrc.nist.gov/groups/ST... [nist.gov]
Re:Well, I did read TFA... (Score:5, Informative)
What is that method? How does it differ from current encryption techniques? Why is that well suited to encrypting against quantum computers? How did you come to that conclusion, given that you don't have one to test against?
I'm one of the authors of the research that was discussed. Unfortunately, the MIT Technology Review article doesn't contain much detail. Here's a link to our research paper: https://eprint.iacr.org/2014/5... [iacr.org].
The scheme uses a mathematical primitive called the "ring learning with errors (RLWE) problem". Rather than multiplying large prime numbers together like in RSA encryption or using points on a curve like in elliptic curve cryptography, here the mathematical operation is based on multiplying polynomials together, and then adding small random noise. An analog of this is solving systems of linear equations: if you took first year linear algebra, you might remember that if I give you a matrix A and a vector b, you can use Gaussian elimination (row reduction) to find a vector x such that Ax=b. But it turns out that if I add a small random noise vector e, and give you A and (Ax+e), it becomes much harder to find x. Our work is about actually using RLWE, seeing how to design a key exchange protocol that's suitable for use in SSL/TLS and then implementing and testing it. (Here are some slides from a recent talk I gave about the research, which try to explain the problem in more detail: http://files.douglas.stebila.c... [stebila.ca])
RLWE isn't our invention -- we build on existing research by Regev, Peikert, and others, and RLWE has been studied for a few years now. RSA and elliptic curve cryptography can be broken by quantum computers because they have a certain periodic structure that can be easily detected by a quantum computer using a quantum algorithm invented by Shor. But RLWE, and several related problems, don't seem to be susceptible to Shor's algorithm, nor to any of the other quantum algorithms that give an exponential speedup over normal classical computers. No one in the research community today knows if RLWE is hard for quantum computers, but right now people accept it as a promising candidate, and it is being explored for a variety of uses. If after years of cryptanalytic research no one manages to break it, then it may achieve the corresponding levels of confidence that the research community has in the difficulty of currently accepted problems, like factoring or elliptic curve discrete log.
Re: (Score:2)
Much appreciated.
Re: (Score:2)
Re: (Score:3)
Perhaps you're mistaking RSA with DSA.
DSA and ECDSA do share a lot. To construct both of these algorithms, you start with an abelian group (a set of elements (e.g. integers; one of these becomes your public key) plus a "group operation" (e.g. multiplication)) and a "trapdoor operation" which is easy to calculate in one direction, but believed to be hard to calculate in reverse. The trapdoor operation is a repeated application of the group operation.
With DSA, the abelien group is a set of integers between 1
Ya right (Score:2)
QCs will _not_ make existing crypto useless (Score:5, Informative)
When (or if) quantum computers become practical they will make existing forms of encryption useless.
Uh, no. It will only make breaking certain popular public-key cryptosystems practical. There are quantum-safe public-key systems, and most symmetric ones are also safe (at best, using a quantum computer with symmetric systems is equivalent to halving the key size — with an obvious way to compensate).
Re: (Score:3)
A large number of people religiously state Software Patents are evil and should never be permitted. If the claims by Microsoft are true, then a Patent should be granted for this "mathematical" discovery. It is a significant improvement in security over existing encryption, and so deserves Patent protection.
Except math is explicitly forbidden from being patented.
I think that Patents should only protect PUBLICLY AVAILABLE products. In this case Microsoft can sell IIS Server / Edge Web browser ($0 cost) with enhanced encryption and the Patent will protect them from competition. Patent Trolls should be destroyed. They way to do this is to only allow legal action if you actually sell a product and other companies are reducing your sales or profits. If there is no reduction in sales or profits, your maximum gain from a Patent should be limited to $0.
They only way you destroy patent trolls is by tying money earned from the patented invention to the cost of developing the patented invention along with some percentage of profits. Thereby, if it costs $1 to create the patented invention you get to hold the patent until you earn $1 and the percentage of profits, which would happen really quickly (sell it one time); it it costs $1000 or $1,000,000 then you would hold it longer - e.g the market decides h
Our snake oil is so secure... How secure is it? (Score:2)
It is so secure that a machine that hasn't been invented cannot break the code! However, with an abacus, all bets are off.
Link to the research paper (Score:5, Informative)
I'm one of the authors of the research that was described in the article. Here's a link to our research paper for more information: https://eprint.iacr.org/2014/5... [iacr.org]
Re: (Score:2)
The elliptic curve standard that was potentially undermined by the NSA is the Dual Elliptic Curve Deterministic Random Bit Generator ("Dual_EC_DRBG"). The weakness is specifically related to the design of Dual_EC_DRBG, and elliptic curve Diffie-Hellman is not affected by that problem. ECDH can be used with a variety of parameters. The nistp256 parameters currently used in TLS were generated by NIST and NSA in the late 1990s; there are no known insecurities in nistp256, but the generation method is not fu
Re:Link to the research paper (Score:4, Interesting)
True, authentication still relies on existing certificate authorities. Authentication has to come from some pre-existing trust relationship, and CAs -- for all their problems -- do make the web work. In TLS in general, including our post-quantum work, you only have to trust the CA up to when you start your communication (they could impersonate the server to you). Assuming you actually did connect to the right server, then after the communication is done the CA is not able to read the encrypted data you sent or received. So yes, there's trust in a middleman, but only for a limited time. Hopefully orthogonal technologies, like Certificate Transparency and DANE, will reduce the reliance on CAs.
William Whyte presented on this at the last IETF (Score:1)
CFRG meeting. Mixing post-QC RNG into the TLS pre-master secret.
Forward secrecy even if QC cracks RSA or ECC.
Please, Slashdot (Score:1)
When TFA doesn't even mention the name of the underlying algorithm, could you at least skim through TFSlides and link to Wikipedia [wikipedia.org]? Would spare all of us the guesswork next time.