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.
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.
TFA doesn't say what they're replacing the integer factorization problem with. Useless.
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.
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.
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.
The reason for using math-based ciphers is to reduce key size--not for storage, but for key exchange.
Ya, right. They'll just track your fucking battery instead.
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 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.
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.
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."
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!
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?
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!”
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)
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
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
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)
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...
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.
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
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.
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?
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.
CFRG meeting. Mixing post-QC RNG into the TLS pre-master secret.
Forward secrecy even if QC cracks RSA or ECC.
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 "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"
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!
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.
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)
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)
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.
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."
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)
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)
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)
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."
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
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"
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.
Learn to love Alaska
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