I’ve been reading up on file encryption lately, and In many places I’ve seen warnings that encrypted files are susceptible to decryption by people so inclined regardless of encryption algorithm strength.
However, I can’t get my head around how someone would go about attempting to decrypt an encrypted file.
For example, lets say you’ve got an encrypted file and you’d like to know it’s contents. You have no idea what the key used to encrypt the file is, nor the encryption algorithm used. What do you do? (Assume for this example that the encryption algorithm is a symmetric-key algorithm such as AES-256, I.E. a file encrypted with key which requires said key to decrypt it).
Additionally, how would your approach change if you knew the encryption algorithm used? (Assume in this case that the encryption algorithm used is AES-256, with a random key + salt).
There’s two ways to answer this question, in the literal sense of how a perfect crypto system is attacked, and how real world systems are attacked. One of the biggest problems you’ll find as you begin to learn more about cryptography is that selecting algorithms is the easy part. It’s how you manage those keys that becomes impossibly difficult.
The way in which you attack the basic primitives depends on the type of algorithm. In the case of data encrypted by symmetric ciphers like AES you use Brute force attacks. That is, you effectively try every key possible, until you find the right one. Unfortunately, barring changes in the laws of physics trying every possible 256-bit key can’t be done. From Wikipedia:
"A device that could check a billion billion (10^18) AES keys per second would in theory require about 3×10^51 years to exhaust the 256-bit key space"The problem with your question about coming across a seemingly encrypted file, with no knowledge of the methods used, is that it’s a bit of a hard problem known as a Distinguishing Attack. One of the requirements of all modern algorithms is that their output should be indistinguishable from random data. If I encrypt something under both AES and Twofish, and then give you some random data, absent any other information like headers, there’s no way for you to tell them apart. That being said….
You asked how knowledge of the algorithm changes the approach. One assumption cryptographers usually make is that knowledge of the algorithm shouldn’t affect security at all, it should all depend on the secret key. Usually whatever protocol you’re working with will tell you the algorithm specifications. If this wasn’t public, interoprobility would be a nightmare. Cipher Suites, for example, are sets of algorithms that protocols like SSL support. NIST FIPS and the NSA Suite B are algorithms that have been standardized by the Federal Government, that most everyone follows.
In practice though, most crypto-systems have much larger problems.
Bad random number generation: Cryptography requires very good, unpredictable random number generators. Bad random number generators can completely collapse security, as in the case of Netscape’s SSL implementation. You also have examples like the Debian RNG bug, where a developer changed code to satisfy a memory leak warning, which ultimately led to Debian generating the same certificate keys for every system.
Timing Attacks: Certain operations take longer to execute on a computer than others. Sometimes, attackers can observe this latency and deduce secret values. This has been demonstrated by remotely recovering a server’s private key over a local network.
Attacks against the host: One way to attack a cryptosystem is to attack the host. By cooling memory, its contents can be preserved and inspected in a machine you control.
Rubber hose cryptanalysis: Maybe one of the easiest attacks, you threaten the party with physical harm or incarceration unless they reveal the key. There has been a lot of interesting case law on whether or not courts can force you to reveal crypto keys.