Products > Security

Encrypted file and unencrypted copy together, can password be calculated?

(1/11) > >>

Infraviolet:
With classical ciphers if one had the plain text and the cipher text together then by comparing them, one could easily deduce the key, a "crib" attack in the case where part of the message was known. This was partly how enigma was cracked, by exploiting phrases that Bletchley park knew would be included within messages, such as one german observation post which sent almost every day a message "nothing to report", alongside using the fact enigma could never encrypt a letter as itself.

In the case of modern symmettric cryptography, does this still apply? If a file, and an encrypted copy of that file made with something like gpg's symmetric encryption (aes256) command, or a folder and an encrypted 7z (again aes256) copy of that folder are together, does calculating the key become possible? If not, why not? Remember, passwords often get reused, despite it being bad practice, perhaps much more often fro encrypting specific files than for login passwords, so if this weakness does exist than anyone who's ever encrypted a not-very-secret file and an attacker somehow sees both the original file and its encrypted copy, could work out the password and then use it to decrypt more private files for which the person may have used the same password as the key.

I'm not attempting to do this, it is well beyond my skill level or needs to actual reverse engineer a password from the "plaintext and ciphertext together" situation, but I would like to understand whether the existence of such a weakness is actually a serious possibility, or if something is done by gpg/7z/the underlying aes algorithm , to make it genuinely, or nearly, impossible.

Thanks

JohanH:
My understanding is that it's very hard. I'm not into cryptography or ciphers other than as a user, so I don't really have any deeper information. But this is a topic that has been discussed frequently, so searching gives some answers.

Here is one:
https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks/64079#64079

ejeffrey:
No, all modern symmetric ciphers are designed to be resistant to this, so called "known plain-text attacks" and it's basically step one of the cryptanalysis for any new cipher.

In fact, ciphers are additionally expected to be resistant to "chosen plain text attacks" such that even if the attacker can trick you into encrypting maliciously chosen data and then revealing the encrypted ciphertext, the attacker still isn't able to recover they key much easier than brute force.

These analysis are usually done on reduced versions of ciphers with shorter keys and fewer rounds.  So generally they will talk about this as a security parameter: how much you have to weaken the cipher before there is a known attack. 

asymmetric ciphers (such as RSA) generally *do* have at least chosen plaintext attacks.  For instance, if you could get someone to encrypt "1" or "0" that might reveal the key.  This is one of many reasons why asymmetric ciphers aren't used by themselves, but only for key exchange.  The key can be chosen randomly and make sure it doesn't exploit known weak inputs.

Infraviolet:
Thanks for clarifying that.

Kjelt:
Indeed nearly impossible (takes at this moment millions of years of attempts) unless the quantum computer is mature. Then all possible combinations can be done at once hence reducing finding the key quickly.

If the quantum computer will become mature and would be capable of doing this, then all encrypted messages from the past could also be decrypted almost instantaneous.
There are law enforcement agencies and national security agencies already storing as much encrypted content from criminals and opposing countries as possible in the hope they can soon decipher them with these new computers.

So there are now new quantum resistant encryption standards being developed.
Especially for government and military applications where the data could be sensitive in tens of years when made publicly this is a hot potatoe.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod