Security - Cannot decrypt... PLZ HELP ME!!!

If it works the way I think it does, there is no failure.. it simply passes the file through the algorithm using the specified key (password). It has no way of knowing what comes out the other end is garbage because the wrong key was used, just like it has no way of knowing if it's good if the right key is used.

To get around this you would have to include a hash or something of that sort and do a comparison after decryption. This would mean you'd also have to decrypt to separate files..

if there was a way for it to do that then a tool could easily be written to do the same thing and crack the password. Looking at the site I think that the data is lost as ccrypt uses a random initialisation vector, so short of recreating those exact conditions re-encryption to get the files back would be difficult, however I might write a little program to brute force that vector, so there is still a chance, give me a couple of days and I'll see what I can do.

Hi all,

first, here are some pertinent facts about ccrypt. Most of this is explained in some detail on its man page.

• Unlike what Steve wrote, ccrypt refuses to decrypt data with a key that does not seem to match. (I agree with John and Tim that this is a useful feature even for "advanced" users, who are just as likely to mistype a password as normal users).
• A technical detail: the password matching feature is not implemented by storing the password (that would be silly), nor by computing a hash of the entire file. Instead, a 32-bit magic number is attached to the *beginning* of the file before encryption. When this magic number is missing upon decryption, then the key was wrong and the file is not decrypted. Because this is detected at the beginning, the decryption can simply be aborted and it is not necessary to first decrypt everything into a separate file.
• the -m option can be used to force decryption with a non-matching password, but in this case ccrypt refuses to overwrite the file and will only decrypt to stdout.
• There is a small probability that ccrypt will accidentally allow a file to be decrypted with a mistyped password. This probability is 2^(-32), or about one in 4 billion.
• even if ccrypt accidentally decrypts a file with the wrong password (probability 2^(-32)), it would still refuse to do so on the next file. The probability that a non-matching password could be used on four consecutive files is 2^(-128). This is astronomically small, much much smaller for example than the probability of a random hardware malfunction.

So, as much as I hate to say it: the problem reported by the original poster should not technically have occurred. There must be some other explanation.

One explanation would be if Toucan passed the "-m" option to ccrypt; this would be an extremely bad idea, like driving without a seatbelt. However, I checked the Toucan 1.2 sources where the call to ccrypt appears in a file called secure-file.h, line 71. There are some things I don't like about this code (passing the password on the command line is not safe, and the double shell escapes make you wonder what happens if the password or filename contains quotes, backslashes, dollar signs, etc). However, the code does not use the "-m" option and therefore no file should have been destroyed.

I realize that "it cannot have happened" is not a very satisfying answer to a problem that in fact happened. But I would be very curious to receive more information about this problem, such as whether it can be reproduced. Perhaps the user didn't really mistype the password, but only thought he had done so? Perhaps the files that are assumed destroyed were in fact decrypted correctly?

-- Peter