Find encryption algorithm knowing input, output and secret Today on my PC I found some old backups; they contain also some pictures I encrypted years ago with a smartphone running Windows Mobile but I don't remember the application I used to cipher them.

I'm quite lucky, because I found a picture on the backup both in original and encrypted version. Is there any way of finding the algorithm/application to decrypt them knowing:


The original "plain" file (es. MyPicture.jpg, 7176 bytes)
The encrypted file (es. MyPicture.jpg.pmf, 7176 bytes, same size of the original)
The secret password I used to encrypt them (it's a 10 characters string)


I also tried to search on Google for the PMF extension but unfortunately I didn't find any helpful information.
Chances of finding the algorithm

It is relatively unlikely that you will find an answer. Ciphertext itself has been designed to be indistinguishable from random bytes (well, for modes based on block ciphers anyway).

The Kerckhoff's principle indicates that the encryption algorithm should not be depended on to keep the plaintext secret. But that doesn't mean that it is necessarily easy to find the algorithm; if the algorithm is used as as secret it may be impossible to find. Kerchhoff just states that it is unsuitable as a key because it will likely be leaked. 

Although encoding modes, modes of operation, padding modes and ciphers have been standardized, there are a lot of them and the complexity of finding an exact match rises quickly, and you don't even know the key used.

Of course, if you don't have any experience doing this your chances decrease, as it is easy to make mistakes and e.g. overlook a possible solution or correct answer.

If a modern cipher was used

As a header is missing, it seems you're dealing with a file that is directly encrypted. AES is always a pretty good bet, and the mode is probably that of a stream cipher (CTR, CFB) as ECB and CBC would add padding. CBC ciphertext stealing is hardly used and requires at least one block, while files can be any size. Encryption / container protocols such as OpenPGP/ZIP/whatever can be safely skipped as they would expand the file size.

The really tricky part is how the password was transformed into a key. Normally you would use a PBKDF - a password based key derivation function - to derive a key from a password. However, a PBKDF requires a salt and iteration count. Generally those are stored with the ciphertext, but as your ciphertext size did not expand on the plaintext size, the salt is missing in action, making PBKDF less likely. You could try AES using the password directly as a key, extended with zero's on the right hand size.

Generally modes require an IV, so you may want to try an all zero IV instead of the normal one. Obviously the IV is not prefixed or, indeed, the ciphertext size would have expanded.

When trying to find the algorithm compare the beginning 8 bytes of the file, decrypting e.g. 32 bytes. Do not use padding when decrypting, as that will simply fail. If you have a match then use that information to continue.

Some other legacy options

As this is clearly not a standardized format the encryption can be literally anything, including classical ciphers. I'd certainly try e.g. the Vigenère cipher, using XOR with a repeated password in ASCII.

Another option is e.g. (PHP) mcrypt in ECB / CBC mode using two-key triple DES. Expand the key to 16 bytes by adding zero bytes at the end and then decrypt with an all zero IV. Blowfish, another 64 bit block cipher, may also be an option. Some bad libraries such as mcrypt do not pad if the plaintext is a multiple of the block size, and your (encrypted) image size is a multiple of 8 bytes (64 bit), but not 16 bytes (128 bit).

Trying RC4, another common cipher, could also be a good idea. It is a stream cipher that takes a key of configurable size. It doesn't take an IV; the key is supposed to be random each time (generally this can be established by simply concatenating the original key bytes and the IV bytes and use that as a key).