Microsoft Creates a Quantum Computer-Proof Version of TLS Encryption Protocol
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.
Especially if the choice is between your data being secure or not.
Taking guns away from the 99% gives the 1% 100% of the power.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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"?
To fight the war on terror, stop being afraid.
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).
"Politicians and diapers must be changed often, and for the same reason."
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?
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...
Are they going with something lattice based?
Hm.. An internet search finds this one: http://research.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...
I haven't understood the problem that deeply but when I do I will post it here.
I think this is the actual publication.
They're using ring learning with errors.
upon the advice of my lawyer, i have no sig at this time
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).