Slashdot Mirror


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.

128 comments

  1. 20% slowdown isn't that bad... by XxtraLarGe · · Score: 4, Insightful

    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.
    1. Re: 20% slowdown isn't that bad... by binarylarry · · Score: 1

      I bet the NSA is going "FUCK do you know how much these quantum computers cost!?!?"

      --
      Mod me down, my New Earth Global Warmingist friends!
    2. Re: 20% slowdown isn't that bad... by Krishnoid · · Score: 4, Insightful

      I bet the NSA is going, "Just charge it to the taxpayers."

    3. Re:20% slowdown isn't that bad... by ILongForDarkness · · Score: 2, Insightful

      Except that since Windows Vista every subsequent OS has been faster on the same hardware.

    4. Re: 20% slowdown isn't that bad... by Anonymous Coward · · Score: 1

      Why bother. They can just bypass it in the first place...

      Just like any competent cracker has been able to do...

    5. Re:20% slowdown isn't that bad... by Smauler · · Score: 1

      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.

    6. Re:20% slowdown isn't that bad... by Anonymous Coward · · Score: 0

      Lies. I upgrade from 7 to 10, and my computer slowed down some. Not enough to warrant reverting, but enough to be noticeable.

    7. Re: 20% slowdown isn't that bad... by afidel · · Score: 0

      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.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    8. Re: 20% slowdown isn't that bad... by binarylarry · · Score: 2, Funny

      Oh so now you're going to play the race card.

      --
      Mod me down, my New Earth Global Warmingist friends!
    9. Re: 20% slowdown isn't that bad... by Anonymous Coward · · Score: 0

      reduce network bandwidth by like 80%

      That was on Gigabit Ethernet, asshole.

    10. Re:20% slowdown isn't that bad... by Anonymous Coward · · Score: 0

      Shut the fuck up, shill. Nobody's buying it.

    11. Re:20% slowdown isn't that bad... by ILongForDarkness · · Score: 1

      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 on the same hardware.

  2. very difficult problems by davidwr · · 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.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
    1. Re:very difficult problems by fahrbot-bot · · 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?"

      --
      It must have been something you assimilated. . . .
    2. Re: very difficult problems by Anonymous Coward · · Score: 0

      no that is exactly the kind of question that
      makes quantum computing "work".... uncertainty and the answer changing over you look and all....

    3. Re:very difficult problems by Anonymous Coward · · 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.

    4. Re:very difficult problems by Anonymous Coward · · Score: 1

      The question is easy to answer correctly. Or truthfully. Just not both.

    5. Re:very difficult problems by bjwest · · Score: 1

      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.

      --

      --- Keep the choice with the user..
    6. Re:very difficult problems by disposable60 · · Score: 1

      Congratulations on your new status of 'Single'

      --
      You're looking for quotes? See my journal.
  3. There is no there there by Anonymous Coward · · Score: 2, Insightful

    TFA doesn't say what they're replacing the integer factorization problem with. Useless.

    1. Re:There is no there there by compro01 · · Score: 4, Informative
      --
      upon the advice of my lawyer, i have no sig at this time
  4. One time pad by currently_awake · · Score: 0

    The reason for using math based cyphers is to reduce memory usage. You have a few hundred bytes and can generate the encryption key to encode/decode the message with it. Using math makes your encryption weak to advances in computers and algorithms, where using a one time pad stored in your petabyte file server is possible now, and the NSA would have to hack your computers or break in (for physical access) or control the companies that make your hardware and software to beat that.

    1. Re:One time pad by Anonymous Coward · · Score: 1

      The reason for using math-based ciphers is to reduce key size--not for storage, but for key exchange.

    2. Re:One time pad by Anonymous Coward · · Score: 0

      Right.... because I have a one time pad and store it and then I encrypt things without math using it, which is already making a lot of sense. Then I send the data to somebody and uh, they uh... wait what?

    3. Re:One time pad by nrjyzerbuny · · 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.

    4. Re:One time pad by Anonymous Coward · · Score: 0

      One time pads do not provide data integrity and any know data in a packet can be deliberately changed.

      Distribution of one-time pads is most definitely difficult and expensive.

    5. Re:One time pad by Anonymous Coward · · Score: 0

      Not entirely. Math based cyphers is needed if you want it to be asymmetric.
      Your gigantic pad need to be copied to the person that you should communicate with, that means that you need to establish a secure transportation method to get it over.
      Why not just send your critical data that route instead of the pad?
      With an asymmetric algorithm you can just send out the public key and not care whatever nutjob sends you encrypted shit as long as the one with sensitive data also uses it.

    6. Re:One time pad by Anonymous Coward · · Score: 0

      You you would, because time passes. Fool.

      I can trade 1PB today, and then *drumroll* travel somewhere else and suddenly have a need to be secure with the person I was *previously* secure with.

      This is perfect for that. So your comment was lacking in context, notably time.

    7. Re:One time pad by innocent_white_lamb · · 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 themselves in advance and they have a new text available daily.

      Can someone explain to me why this isn't secure, assuming that the bad don't know that this is the text that they use for their one-time pad? If someone is going to beat it out of one of them, they will could beat a pre-exchanged one-time pad out of them too, so that can't be it.

      --
      If you're a zombie and you know it, bite your friend!
    8. Re:One time pad by TemporalBeing · · 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.

      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 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.

      --
      Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
    9. Re:One time pad by JesseMcDonald · · 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?

      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 document which decrypts the cyphertext into something intelligible. Given a couple of cyphertexts they could derive the rule you use to select your "pads". In a true OTP setup there is no way to determine whether a given pad decrypts the cyphertext since every possible plaintext has an equally plausible random pad, and even knowing both cyphertext and plaintext for the same message gets you no closer to being able to decode future messages.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    10. Re:One time pad by amRadioHed · · Score: 1

      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.

      --
      We hope your rules and wisdom choke you / Now we are one in everlasting peace
    11. Re:One time pad by Anonymous Coward · · Score: 0

      With a one-time pad you simply XOR the pad with the plaintext. If you XOR a plaintext message with a pad that is also effectively regular plaintext, the XORd bits, especially the 8th bit, will follow typical patterns of text messages.

      In addition to being only used once, a one-time pad must also be generated from a truly random number generator. (If it was only a CSPRNG then of course the pad is only as strong as the CSPRNG.)

      Plus, the problem with OTPs is _exchanging_ them. Notwithstanding the above issues, all the NSA has to do is watch Alice & Bob and they'll see that they each pull down that Slashdot article every day. Or at least see that they access Slashdot.

      Now, you can try to get more sophisticated here. Maybe they use Tor, but then the security reduces to whatever Tor is.

      Basically, various OTP schemes invariably depart from the standard OTP scheme. Once you do that, the proof of security of OTPs goes out the window. Then you're simply reinventing the wheel, and doing it much more poorly than experts.

      If anybody says, "just use a one-time pad", you immediately should recognize that they're an idiot. An idiot not because they're wrong per se, but because they're either oblivious to their ignorance, or confident in their ignorance.

    12. Re:One time pad by Your.Master · · Score: 1

      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 character that would *not* be encoded under the first use. But that's the same as having a second pad, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, in terms of both storage and security (what are the odds of that being the truly random result :) ?).

      That said, you could probably use a synchronized random number generator as the shared pad data.

      That's what mathematical ciphers do -- they establish a synchronized pseudo-random number generator. A synchronized truly random number generator is almost a contradiction in terms, although quantum encryption does provide a way to transmit truly random information to exactly one recipient, which is pretty much a synchronized true RNG.

    13. Re:One time pad by plover · · Score: 2

      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 that faster than you can.

      I did this to a friend who had the same idea in a "you'll never guess my encryption" challenge. After getting him to download a copy of BLACK.GIF, I stared at the intercepted results for many seconds longer than I should have. It output a repeating string of something like SLASHDOTTODHSALS, so I said that's your key. He was arguing because his key was SLASHDOT, and his "algorithm" was to invert the letters of the key word and append a copy to the end of the key. My mind boggled because I was expecting encryption, not immediate success at recovering his key and data.

      Now, let's say you're smart enough to avoid encrypting BLACK_SQUARE.BMP. I can still achieve most of the same results by predicting that your data stream will contain "Host:", "Content-Type:", "Accept: text/plain", "User-Agent:", "HTML", "BODY", and other such 'cribs' (I was all set up to apply this logic to the intercepted message from my friend mentioned above.) By matching fragments of my guesses with your message, I can look to see if I recover legible text. It only takes a surprisingly small amount of recovered text to be able to identify the source.

      --
      John
    14. Re:One time pad by Your.Master · · Score: 2

      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.

    15. Re:One time pad by dissy · · Score: 1

      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?

    16. Re:One time pad by Anonymous Coward · · Score: 0

      Couldn't the last part of the message tell the receiver what the next pad will be? "First article of New York Times on (date)" The last part of the next message says, "Luke chapter (number) from the King James Bible"....etc.

    17. Re:One time pad by Anonymous Coward · · Score: 0

      If the digits in irrational/transcendental numbers don't repeat, could you encode a message using the digits of SQRT(x), where x is not a perfect square, then at the end of that message, indicate a different irrational number SQRT(y) for the next message, etc?

    18. Re:One time pad by DamnStupidElf · · Score: 4, 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).

    19. Re:One time pad by AHuxley · · Score: 1

      Re "If I am intercepting their communications, I will know of their scheme"
      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 networks and was been decrypting in real time. The solution was the one time pad in the mid 1950's with total communications discipline to stop network chatter by staff . The networks where again totally private. Speed and scale was lost. Over a short time the Soviet Union returned to more traditional crypto methods and lost all its communications systems to the NSA and GCHQ.
      Australia has the same issue after the 1970's. Too many different telcos on its internal networks are near mil networks. Try domestically developed quantum crypto on its different networks so it can secure everything mil on telco grade networks that are shared along networks.
      Secure codes and unlimited data flow is the prize but can it be trusted?
      So expect to see a lot of US backed brands, efforts, products to ensure other nations ever escape the NSA again.
      Nations, people, political leaders, brands now have a real insight into how the NSA worked over decades, the brands the US used and methods to ensure junk global standards.
      One time pad, number stations have a role, domestically developed quantum crypto could be be useful if a nation can really "test" it ;)
      But to trust another nation big brands with domestic crypto beyond low valued shared projects would be difficult.

      --
      Domestic spying is now "Benign Information Gathering"
    20. Re:One time pad by Sulik · · Score: 1

      Why not just increase the entropy by just using a compressed version of the text, eg: instead of using the text of the first article, zip it, and use that as the pad (removing headers etc). Or use some compressed H.264 youtube videos as the pad (arithmetic coding pretty much guarantees a relatively high entropy).

      --
      Help! I am a self-aware entity trapped in an abstract function!
    21. Re:One time pad by TemporalBeing · · Score: 1

      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.

      However, the problem with using an RNG is that the clocks can skew between the two devices over time. So it's not a very good source.

      --
      Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
    22. Re:One time pad by TemporalBeing · · Score: 1

      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's what mathematical ciphers do -- they establish a synchronized pseudo-random number generator. A synchronized truly random number generator is almost a contradiction in terms, although quantum encryption does provide a way to transmit truly random information to exactly one recipient, which is pretty much a synchronized true RNG.

      I did not say using a PRNG, but an RNG - think RSA token. We have plenty of synchronized hardware-based RNGs that we use for authentication. You would just need to up the rate of the number generation, which may make it harder to maintain synchronization. RSA tokens are good for a couple years, but only generate numbers every 60 seconds.

      --
      Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
    23. Re:One time pad by johnwallace123 · · 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 likely, so your opponent must consider every combination of 1GB, meaning 2^(8e10) equally likely ciphertexts. This is basically secure for all eternity. Also complicating the matter is that for a given ciphertext, all plaintexts are equally likely. So, the opponent doesn't know if you said "Attack the beach at noon" or "Attack the beach at dawn" or "jcfpeb k,spq djte96bslg1Hw"

      Now, in the case of a pseudo-random OTP, let's assume that the seed of your PRNG is 32 bits, so you only have to share a very small secret securely. However, there are now only 2^(32) possible ciphertexts that the opponent needs to check. This is a much more practical problem, and he can use some simple checks to see if the decrypted message "makes sense", and choose the most likely plaintext.

      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. Of course, this is a few orders of magnitude harder than symmetric encryption, which is why you'll typically use the public-key encryption to share a disposable secret key, which is then used to seed a symmetric encryption method (your pseudo-random OTP would be one of those). In reality, this is still pretty secure, as the key is typically in the range of 128+ bits, meaning a key space of 2^128 for a brute-force attack, which is still pretty infeasible. However, it is not completely 100% secure against any decryption as a One-Time pad is.

    24. Re:One time pad by KGIII · · 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 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.

      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.

      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).

      --
      "So long and thanks for all the fish."
    25. Re:One time pad by dissy · · Score: 1

      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 how encryption should work)

    26. Re:One time pad by TemporalBeing · · Score: 1

      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 of system using a hardware dataset as the pad; it's no considered such because it didn't do the normal XOR operation associated with OTP functionality, but is also has the same flaws.

      In reality, OTP is used with a large dataset to securely communicate messages when you want to ensure that no MITM attack can be possible, and you may have multiple receivers. OTP was a common means of communication for the Cold War - know what book to pick up, page to start with, etc. It's a very secure means of communication; and it still used for secure communications today.

      Like it or not, any means of setting up a security context (Diffie-Hellman, TLS, etc) is susceptible to MITM attacks (during the security context creation, and therefore extending to the rest of the session) due to the simple fact that you have to dynamically create the security context. The only resolution to that is an OTP security context.

      --
      Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
    27. Re:One time pad by TemporalBeing · · 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 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-interface kind of thing than anything else. So changing the file type is not really a help of any kind, it barely even obfuscates things - smart filters will adjust accordingly, and we've seen those plenty in email systems that appropriately detects "piz" files a "zip" files, etc.

      --
      Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
    28. Re:One time pad by KGIII · · 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 encrypted .RAR file. Once they decrypt it they will need a key, I am thinking PGP should suit, and they will need to use that key to decrypt that file - it may even be password protected a second time and it probably would end up being that way by default.

      I think I might bust out CodeLite (I have been toying with the IDE, getting used to its tools, layout, and work space) and grab a couple of app sources from GitHub or SourceForge. Then I can wrap them (hopefully) and turn it into a single application that makes it easy for non-geeks to use. Exchanging the password(s) should be fairly easy and, I suspect, it would mean it was much more difficult to be seen by spying eyes. I could see it coming in handy.

      When I was first thinking about it, I was considering it for use with stenography encrypted images where messages are encoded in the image source. Having pondered it, over a couple of months now, I have since thought that it may have uses outside of stenography and folks might be interested in that.

      I do not see this as a project that will need much maintaining. Just a simple alpha, a beta, and a single point release and it should be pretty good. I might even be inclined to do it in Java so that it *should* work on every major OS out there. I am not fluent in Java but I know my way around. I could use the practice and it might be nice to familiarize myself with the Eclipse Java IDE.

      Finally, thank you again. My attempt to Google did not reveal any applications out there that already do this. I am unable to be certain because I am not sure what keywords I would need to use. Another part of me pondered its validity as a web service. I am not sure I want the responsibility for such. I am retired, happily, and do not want to be beholden to anyone and an online service would, most certainly, mean a greater level of attention was needed.

      --
      "So long and thanks for all the fish."
    29. Re:One time pad by plover · · Score: 1

      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 been identified and fixed.

      --
      John
    30. Re:One time pad by AHuxley · · Score: 1

      Thats where https://en.wikipedia.org/wiki/... can help. Why are two ip's swapping neatly formatted random yet standard formatted code blocks?
      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 skills. In watching all staff, NGO, embassy workers, tourist visa holders and/or all internet communications.
      Can a nation track both people and online code use 24/7?

      --
      Domestic spying is now "Benign Information Gathering"
    31. Re:One time pad by AK+Marc · · Score: 1

      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.

    32. Re:One time pad by Anonymous Coward · · Score: 0

      You can take a file that is already encrypted and encrypt it a second time creating a second layer of protection. But one needs to be careful in the process. If the inner encryption layer creates header info that is the same every time or is easily guessable (such as message length, a version number for the encryption algorithm used, an ID for the key that encrypted it, etc.) an attacker can use that information to facilitate a "known plaintext attack" against the outer encryption layer.

    33. Re:One time pad by dissy · · Score: 1

      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. Identifying one or all parties (or not being able to) isn't typically addressed under the umbrella of encryption, so it isn't too surprising that point isn't addressed.

      Second, while there is a race to the bottom so far as hardware (or even software) speed goes towards brute forcing any form of encryption, this has actually always been true (even before encryption!) and is just one of those details we "gloss over" in a high level discussion of the topic.

      A method of encryption, mathematically speaking, is always a ratio of two numbers: How long it takes to encrypt/decrypt with the proper credentials, and how long it takes to brute force without the credentials (usually mean time, but mean and average can usually be provided)

      The same is true for things like locks and safes/vaults. They have a rating of how much time would be required to brute force them, either in blowtorching the thing open or simply trying each combination if it is lacking any form of protection to slow that down - typically which ever method would be fastest.

      In the case of encryption, let's take AES-128 as an example, it requires 2^126 operations to brute force (well, last I checked)
      A Pentium Pro at 200 Mhz required something like 16 or 18 clock cycles per byte of data, which at that speed would have taken a couple billion years to reach mean brute force time.

      Clearly our desktops today are much much faster than that, and Government super computers even more so, so the time needed for that many operations is greatly reduced - but still not zero.

      NIST typically approves encryption methods that have at least a 20 year mean time to brute force, with the expectation that you have upgraded your encryption method long before that 20 year time is up, and that it isn't worth it to an attacker to hold on to 20 year old data to await the time they can brute force it faster.

      Clearly those assumptions are not always true given projects like Tempora that you linked (and I assume most if not all super-power governments have something similar)
      But that doesn't indicate a failing of the encryption, it only indicates the initial assumptions made when choosing a type of encryption failed.

      It's more comparible to buying a water-resistant watch and then either taking it into the ocean while deep diving (failure of the user choosing the encryption), or perhaps being hit with an unexpected multi-day typhoon (failure forced upon the user)
      In both cases that poor watch likely isn't going to hold up, and also in both cases the watch was never manufactured nor claimed to be able to in the given conditions.

      Back on topic, it just indicates we are at a special point in time where a lot of our existing encryption methods won't last long enough for the uses we put to them, be it by ignorance of how and what the encryption actually was made to do, or in ignorance of the current state of technology being used against it.

      Lastly, when it comes to "slipping up", there are of course many ways to do so (the old saying about trying to make something idiot proof produces better idiots comes to mind)

      An encryption method is just a mathematical formula, and many are actual proofs, not just some guesses being made in how they operate.
      However the software you use is different, it is an implementation of that encryption method.
      If an implementation doesn't completely match the math proof (be it a bug, typo, or intentional backdoor) that isn't necessarily an indicator that the encryption

  5. You forgot to include the quote Re:haha by davidwr · · 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.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
    1. Re:You forgot to include the quote Re:haha by Anonymous Coward · · Score: 0, Flamebait

      Who needs either one?

      Windows is so full of holes that anybody seems able to get any data they want - encryption or not.

      Windows just seem to allow ANYBODY to bypass their "security" at will.

      So the laughter would seem appropriate at any time the words "Windows" and "security" occur together.

    2. Re:You forgot to include the quote Re:haha by davidwr · · 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".

      --
      Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
    3. Re: You forgot to include the quote Re:haha by Anonymous Coward · · Score: 0

      Agreed...it doesn't matter how good the encryption is if they just upload your key straight to the NSA anyway!

    4. Re:You forgot to include the quote Re:haha by Anonymous Coward · · Score: 0

      Windows X isn't any more exploitable by the NSA than most previous versions

      Sure it is. Instead of having to collect data from many individuals, they just have Microsoft hand it all over.

    5. Re:You forgot to include the quote Re:haha by Anonymous Coward · · Score: 0

      It looks like the Micro$hit shills have mod points.

  6. What algorithm/primitive? by mlts · · Score: 2

    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.

    1. Re:What algorithm/primitive? by robi5 · · Score: 1

      > 20% performance can be important

      why?

    2. Re:What algorithm/primitive? by mlts · · Score: 2

      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.

    3. Re:What algorithm/primitive? by robi5 · · Score: 2

      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 :-)

    4. Re:What algorithm/primitive? by datokrat · · Score: 4, Informative

      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.

    5. Re:What algorithm/primitive? by Anonymous Coward · · Score: 0

      That 20% increase has nothing to do with the difficulty of cracking it, just the increased computing power needed to use it relative to a current comparable system. The new system would take at least the same amount of time to crack with a regular or quantum computer that a current comparable system would take against a regular computer.

    6. Re:What algorithm/primitive? by Bengie · · Score: 1

      It only affects the handshakes, then it's all AES. Stop making lots of connections and use long lived connections. But like you said, how are the measuring it. 20% just for the handshake or 20% on average per web request?

    7. Re:What algorithm/primitive? by im_thatoneguy · · Score: 1

      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.

    8. Re:What algorithm/primitive? by mlts · · Score: 2

      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, perform another handshake and fill up both sides with temporary keys again.) The downside is that the web server would have to store about 1-4k worth of data per machine connecting for a short amount of time, but the upside is less time for negotiations.

    9. Re:What algorithm/primitive? by Bengie · · Score: 1

      In theory you only ever need one symmetric key assuming you have a strong cipher like AES and you assume the handshake can't be broken.

    10. Re:What algorithm/primitive? by Anonymous Coward · · Score: 0

      If you had RTFA the 20% is the increase in how long it takes to move the data.

    11. Re:What algorithm/primitive? by Anonymous Coward · · Score: 0

      And you assume that neither end-point will become compromised at any point in the future, by an adversary that is tracking all encrypted communications you make.

    12. Re:What algorithm/primitive? by Bengie · · Score: 1

      One per "per connection" was implied. The other person talked about using many keys per connection and storing "1k-4k" of data per machine connected.

  7. Well, I did read TFA... by laughingcoyote · · 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"?

    --
    To fight the war on terror, stop being afraid.
    1. Re:Well, I did read TFA... by Anonymous Coward · · Score: 0

      Why should we believe quantum computing can crack existing TLS when no one has been able to demonstrate it?

    2. Re:Well, I did read TFA... by Thelasko · · Score: 1

      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.

      --
      One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
    3. Re:Well, I did read TFA... by Anonymous Coward · · Score: 0

      Yes, you are supposed to believe and Trust Microsoft. Now go and install Windows 10.

    4. Re:Well, I did read TFA... by Anonymous Coward · · Score: 0

      There are plenty of well-known problems thought resistant to quantum computers. Google for "quantum computer trapdoor functions".

      But "thought resistant to quantum computers" is short-hand for "proven resistant to known quantum algorithms". The catch is that quantum algorithmic theory is still relatively young, and new classes of algorithms may yet be discovered.

      Any algorithm thought resistant to quantum computers is similar to cryptographic algorithms devised in the 1970s and 1980s. That is, they may eventually be broken completely using new techniques, or there may be subtle weakness that could be exploited to break them in practice.

    5. Re:Well, I did read TFA... by ljw1004 · · 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"?

      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...

    6. Re:Well, I did read TFA... by stebilad · · 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....

      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...)

      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.

    7. Re:Well, I did read TFA... by Anonymous Coward · · Score: 0

      Not that it's relevant but I used to work at RSA Security.
      I don't know how many other people realize, but the only difference between RSA and elliptic curve is the equation you use for the curve.
      Elliptic curve obviously uses the equation for an ellipse. RSA uses the equation y = n / x.
      In both cases you're trying to find points on the curve where x and y are integers.
      Just thought I'd mention it.

    8. Re:Well, I did read TFA... by laughingcoyote · · Score: 1

      Much appreciated.

      --
      To fight the war on terror, stop being afraid.
    9. Re:Well, I did read TFA... by Anonymous Coward · · Score: 0

      Ha ha ha. I love it when a anti-Microsoft troll gets severed.

    10. Re:Well, I did read TFA... by flopsquad · · Score: 1

      Thanks for posting this explanation!

      --
      Nothing posted to /. has ever been legal advice, including this.
    11. Re:Well, I did read TFA... by Anonymous Coward · · Score: 0

      What a tool.

    12. Re:Well, I did read TFA... by gurnec · · Score: 2

      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 and p-1 (p is prime), the group operation is integer multiplication modulus p, and the trapdoor operation is integer exponentiation modulus p. (Note that exponentiation is repeated multiplication.)

      With ECDSA, the abelien group is the set of points on an elliptic curve over a finite field, the group operation is something called "point addition", and the trapdoor operation is something called "scalar multiplication" (which is just repeated point additions).

      The rest of the DSA and ECDSA algorithm is the same, and can be defined by steps such as "repeat the group operation x times" which is performed using one of the two group operations above depending on which algorithm is being used.

      RSA on the other hand is a completely different beast, and not at all similar to ECDSA.

      the only difference between RSA and elliptic curve is the equation you use for the curve.

      ECDSA uses a curve. Neither RSA nor DSA uses any form of curves or points.

      Elliptic curve obviously uses the equation for an ellipse.

      Elliptic curve crypto uses the equation for, well... an elliptic curve. An ellipse (oval), despite the similar name, is an entirely different equation.

    13. Re:Well, I did read TFA... by Anonymous Coward · · Score: 0

      Thank you. Informative comments like this are why I read Slashdot.

    14. Re:Well, I did read TFA... by KGIII · · Score: 1

      Now that sounds like a Genuine Advantage!®

      --
      "So long and thanks for all the fish."
  8. Ya right by AndyKron · · Score: 2

    Ya, right. They'll just track your fucking battery instead.

  9. Just like script was supposed to be asic proof.. by Anonymous Coward · · Score: 0

    Just like script was supposed to be asic proof..

  10. Yeah, OK by Anonymous Coward · · Score: 0

    Because we all know how well Microsoft secures things against traditional computers right?

  11. The problem with one-time pads by davidwr · · 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 using another one-time pad or similarly-long key to protect the one-time-pad in transit. And around and around we go.

    Now, what MIGHT be feasible would be for my bank to ship me a one-time "pad on a chip" that is sealed in a tamper-evident package and have me ship them a different one-time pad in a similar package. The "tamper-evident"-ness of the package would have to be foolproof of course, and there are probably a few other steps I'm leaving out, but you could, theoretically, exchange one-time pads at a distance without having to resort to quantum computers, meeting in person, or particularly trusting your courier. This wouldn't guarantee the pads wouldn't be lost-in-transit, only that they wouldn't be compromised-in-transit.

    No, doing things with keys that can either be generated and securely exchanged on the fly or with keys that are public/private is much more practical.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
    1. Re:The problem with one-time pads by Smauler · · Score: 1

      Heh, that's what you don't understand. It's one time pads all the way down!!

  12. The value of a OTP by davidwr · · 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 very difficult, especially if it's in a country where such things aren't outlawed (scratch North Korea). If the spy can sneak into the country with his one-time-pad (say, maybe it's buried in a hearing aid or something) then he's good to go.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  13. Your friends will love this! by Anonymous Coward · · Score: 0

    The super awesome part is that Microsoft automatically shares your encryption keys with your Skype friends so that they can read your https traffic too!

  14. QCs will _not_ make existing crypto useless by Prune · · Score: 4, 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).

    --
    "Politicians and diapers must be changed often, and for the same reason."
    1. Re:QCs will _not_ make existing crypto useless by Anonymous Coward · · Score: 0

      I have a symmetric key system from the ancient days that is completely resistant to quantum attacks by trivial proof.

      For when you REALLY need to keep the NSA out.

    2. Re:QCs will _not_ make existing crypto useless by Anonymous Coward · · Score: 0

      Yes, yes, one time pad is perfect. Trouble is delivering that OTP safely.

  15. Re:haha by Anonymous Coward · · 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:

    hahah hahahah hahahah hahahah ... hahahah hahahahahaha hahaha

    Decrypted, it reads:

    HELP. VERY THIRSTY. SEND JUICY PENISES. OUT.

    Maybe somebody else here could be of assistance?

  16. The bad side of this by Anonymous Coward · · Score: 0

    Is it needs to show you loads of ads in order to protect your data, albeit add free wil be available at a litle extra cost.

  17. Microsoft... by Anonymous Coward · · Score: 0

    ... THE trusted name in Computer Security.

  18. SOFTWARE PATENT SHOULD BE GRANTED by Anonymous Coward · · Score: 0

    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.

    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.

    1. Re:SOFTWARE PATENT SHOULD BE GRANTED by TemporalBeing · · Score: 2

      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 how long you get to hold it; outright sale of the patented invention to a third party would nullify the patent itself since you would have recouped the costs, and the prime motivator for patents is therefore enforced - that inventors be encouraged to invent new things - while equally destroying the troll market.

      --
      Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
  19. Our snake oil is so secure... How secure is it? by fustakrakich · · 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.

    --
    “He’s not deformed, he’s just drunk!”
  20. Link to paper by Anonymous Coward · · Score: 0

    http://research.microsoft.com/pubs/226372/postquantTLS.pdf

    Post-quantum key exchange for the TLS protocol from the ring learning with errors problem

    Abstract
    Lattice-based cryptographic primitives are believed to offer resilience against attacks by quantum
    computers. We demonstrate the practicality of post-quantum key exchange by constructing ciphersuites
    for the Transport Layer Security (TLS) protocol that provide key exchange based on the ring learning
    with errors (R-LWE) problem; we accompany these ciphersuites with a rigorous proof of security. Our
    approach ties lattice-based key exchange together with traditional authentication using RSA or elliptic
    curve digital signatures: the post-quantum key exchange provides forward secrecy against future quantum
    attackers, while authentication can be provided using RSA keys that are issued by today’s commercial
    certificate authorities, smoothing the path to adoption.
    Our cryptographically secure implementation, aimed at the 128-bit security level, reveals that the
    performance price when switching from non-quantum-safe key exchange is not too high. With our R-LWE
    ciphersuites integrated into the OpenSSL library and using the Apache web server on a 2-core desktop
    computer, we could serve 506 RLWE-ECDSA-AES128-GCM-SHA256 HTTPS connections per second for a 10 KiB
    payload. Compared to elliptic curve Diffie–Hellman, this means an 8 KiB increased handshake size and a
    reduction in throughput of only 21%. This demonstrates that post-quantum key-exchange can already be
    considered practical.

  21. You'd have to be a total fool... by Anonymous Coward · · Score: 0

    ... to believe that Quantum Computers don't already exist in the wilds of this planet.

    Remember the Connection Machine? Massively parallel production computer that
    sported 65,536 processors in the very early 90's. Its job was to relate huge piles of data
    in realtime, like the motion of air molecules under helicopter blades. American Express
    had one to analyse buying patterns. Then nothing--the company that made them literally
    evapourated. The Wikipedia page for this remarkable technology is downright embarassing.

    Guess what the Connection Machine's OS was called?

    PRISM.

    No shit.

  22. Link to the research paper by stebilad · · 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...

    1. Re:Link to the research paper by Anonymous Coward · · Score: 0

      Even if the cryptography is great , the authentication relies on existing certificate issuing authorities. So we have to trust the authority, seems problematic as it has been in the past and present. Isn't there a better solution than having this middleman we have to trust?

    2. Re:Link to the research paper by Anonymous Coward · · Score: 0

      Yeah and the paper compares it to a "elliptic curve Diffie--Hellman" which we all know is only insecure because the NSA paid RSA to use this algorithm pre-set with known seeds that could be cracked.

    3. Re:Link to the research paper by stebilad · · 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.

    4. Re:Link to the research paper by stebilad · · 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 fully documented, so the IETF is planning to move to alternative elliptic curve parameters, like Dan Bernstein's curve25519 or the Brainpool random curves or the new Microsoft FourQ curve. Regardless of the parameter choice, however, ECDH would be breakable by Shor's algorithm running on a quantum computer.

  23. Already practical? by Anonymous Coward · · Score: 0

    "Microsoft says the design could be practical if properly tuned up for use in the real world."

    If it's only 20% slower than the existing algorithm, it already sounds quite practical for use. Unless I'm missing something, like the NSA whispering to Microsoft that it needs to keep this under wraps for now with claims it's impractical in the real world for Reasons.

  24. Linux distros secure??? by davidwr · · 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-stripped-down version of Windows with all unnecessary services turned off AND having it sitting behind a special-purpose, minimalist, hardened firewall appliance. Oh wait, that wouldn't be a "full featured OS", nevermind.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
    1. Re:Linux distros secure??? by Anonymous Coward · · Score: 0

      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-stripped-down version of Windows with all unnecessary services turned off AND having it sitting behind a special-purpose, minimalist, hardened firewall appliance. Oh wait, that wouldn't be a "full featured OS", nevermind.

      How long have you worked for Microsoft? You should be looking for a job because layoffs are coming.

      Cyberspace is already on Linux. Slashdot is CentOS.

      http://toolbar.netcraft.com/site_report/

      Go look at www.microsoft.com, www.apple.com, www.amazon.com, www.google.com and keep going.. you will hit www.freebsd.org and it will run on FreeBSD because BSD does rock. BSD being cool is why Mac OS X is literally FreeBSD and so is the Playstation 4 along with Netflix etc.

      I won't waste time explaining 1 by 1 of each individual Windows nerd that buys a PC.

      http://www.top500.org/statistics/details/osfam/1
      You think somehow Linux is obscure? You want to think so, right?

      http://www.extremetech.com/extreme/155392-international-space-station-switches-from-windows-to-linux-for-improved-reliability
      Eventually you run out of stupid shit to say, or is stupidity literally infinite?

      Try again. Windows is death knell.

    2. Re: Linux distros secure??? by Anonymous Coward · · Score: 0

      Do they have native, supported Instagram, Facebook and Twitter on all those platforms?

      Unless your grandmother can use the OS and install all the major / popular apps, it's always going to be windows/mac. Otherwise, BlackBerry10 would have much more market share.

      The number of people using Linux and FreeBSD desktops are far less than servers.

      And there's no desktop linux that's even close to taking a stab at Windows.

      All I can think is that you're in lala land.

      Everyone likes to forget a properly configured windows machine is on par with Linux to exploit. Just that usability trumps security for most people.

    3. Re: Linux distros secure??? by Anonymous Coward · · Score: 0

      Do they have native, supported Instagram, Facebook and Twitter on all those platforms?

      Instagram is retarded. Facebook is retarded. Twitter is retarded. You seem stupid.
      That being said, yes...
      https://play.google.com/store/apps/details?id=com.instagram.android&hl=en
      https://play.google.com/store/apps/details?id=com.facebook.katana&hl=en
      https://play.google.com/store/apps/details?id=com.twitter.android&hl=en

      Those third party data-mining companies are surely ready to give you "a helping hand" on every platform. Especially since Android is #1. They wouldn't be full sneak-qualified if they didn't. All are available in any web browser as well. But you said native. Like "native social media" matters fucking shit.

      Unless your grandmother can use the OS and install all the major / popular apps, it's always going to be windows/mac. Otherwise, BlackBerry10 would have much more market share.

      Grandmothers have problems in Windows too. Sort of peculiar you left that part out right? Would a grandmother have a router? Would a grandmother have a SmartTV? Guess what dickehead, grandma already has Linux.

      And there's no desktop linux that's even close to taking a stab at Windows.

      Every desktop Linux crushes Windows. Every single one of them. This is surely factored in when supercomputers choose which OS (hi, top500.org), when large fortune 500's consider which OS (oh hi, Amazon), when search engines choose which OS (hi Google), when International Space Stations run on Linux..
      http://www.extremetech.com/extreme/155392-international-space-station-switches-from-windows-to-linux-for-improved-reliability

      KDE is way fucking cooler to use than Mac OS X or Windows desktop environment. And, you have many options with Linux. Nobody ever cried about a start button in Linux. You seem to be trying to make the point that low-tech old ladies or stupid people in general need a retarded easy to use operating system. Well, then don't uninstall Windows if you're an idiot.

      All I can think is that you're in lala land.

      The deal is I have used every OS for decades including 8 bit OS's. Even prior to 8 bit OS's. I was there, already checking out what's cool and what isn't. You on the other hand are a dickhead. Are you by any chance Indian tech support for a specific operating sytem or something? More likely, you are teenage.

      Everyone likes to forget a properly configured windows machine is on par with Linux to exploit. Just that usability trumps security for most people.

      http://www.computerworld.com/article/2467360/cybercrime-hacking/it-s-time-to-get-rid-of-windows.html
      http://www.thewindowsclub.com/botnet-removal-tools-windows
      http://www.enterprisenetworkingplanet.com/netsecur/you-can-never-really-get-rid-of-botnets.html

      I'm not even about to read those, they are just proof of concept.

      Linux is absolutely fun to use. The bash shell in Mac is the same bash shell as Linux/BSD. If you can use a Mac, you can use Linux. There are some differences in file structures. I prefer KDE's GUI over Mac OS X's GUI.

      Windows is not even in the picture. It is retarded. 3.1 was retarded and Windows 10 is even more retarded not to mention you are hacked as soon as you install it. Want to block an update? By Pro edition. "pro". as if Windows is anything but "pro gypsy".

      You're done kid. Roasted and toasted. You won't be back.

  25. William Whyte presented on this at the last IETF by rich_salz · · Score: 1

    CFRG meeting. Mixing post-QC RNG into the TLS pre-master secret.
    Forward secrecy even if QC cracks RSA or ECC.

  26. Like with anything Microsoft by Anonymous Coward · · Score: 0

    Like with anything Microsoft, I just wait on the nice folks at TPB to crack it.

  27. Not necessary by Anonymous Coward · · Score: 0

    Except time works in your favor, you exchange the key at t=0, you update it regularly via the encrypted link, and to intercept this, an attacker needs to catch the first key exchange and all subsequent communications since they might include a new key update.

    Since you don't know who your target is until t=n (sometime later), you would have to man-in-the-middle everyone all the time.

    And to defeat that man- in-the-middle attack a simple adhoc key exchange, e.g. send it via email, and let the key update once.

    So now your attacker needs to also catch all email too, post it to a forum, .... they need to intercept all those comms too.... send it by post, they need to intercept that too. You can see how it would be impractical to do this.

    Really the certificate authorities have been shown to be NSA fronts and NSA/GCHQ were able to intercept tens of millions of TLS sessions, so the system needs to change to eliminate the certificate authority.

  28. Please, Slashdot by Anonymous Coward · · 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? Would spare all of us the guesswork next time.

  29. Secure? by Anonymous Coward · · Score: 0

    What is going to happen when the FBI ask MS to give them the code to make modifications before it is compiled? As with Vista+, MS will bend over and say Please Insert!