Secure encryption and decryption of files and streams

Frequently Asked Questions

I often receive questions from users about ccrypt. On this page, I am posting (an edited version of) some of the interesting questions I got, along with my answers.

Maintainer: Peter Selinger. Created: Dec 13, 2002. Updated: Jan 17, 2007.

Back to main ccrypt page.


1. Lost or forgotten passwords

Question: Help! I encrypted a very important file, but then I forgot the key. Is there any way I can recover my data?

Answer: No, you can't decrypt your data without the key. That is the whole point of encryption! Your only hope is to try different keys until you find the correct one. The program ccguess, distributed with ccrypt, can assist you in doing so if you remember parts of your original key, or you think you might have mistyped it when encrypting.

Question: I used ccrypt to encrypt a file, and now I am trying to decrypt it and it is not working. I am sure I have the correct key, because I wrote it down. Any ideas?

Answer: There are several possibilities. (1) You mistyped the key when you encrypted the file. In this case, you can try a number of similar keys until you find the correct one. You can even write a program to do this for you. (2) The first 32 bytes of the file were corrupted somehow (e.g. overwritten). In this case, try decrypting it with the "-m" option (but make a backup copy of the file). This might allow you to recover at least those parts of your file that were not corrupted. (3) Maybe ccrypt is looking at the wrong file. For instance, if you have "archive.tar" but also "archive.tar.cpt", and you type "ccdecrypt archive.tar", it might try to decrypt the wrong one.

Question: I recently moved to Windows XP. I have a couple of archives that were crypt-ed using UNIX crypt, but there are some that I cannot decrypt because I have forgotten the key. Is there any way I can extract this from the encrypted files?

Answer: Yes. UNIX crypt has been broken, and it is possible to discover both the key and the text. I don't know anything about the details; you have to experiment yourself. Look at http://axion.physics.ubc.ca/cbw.html or type "breaking unix crypt" into google. I don't know if there is any off-the-shelf Windows software available for doing this; you might have to do it on unix.

2. Crash recovery

Question: I lost a 50MB gzipped file by having a system crash in the middle of decrypting it. Is there any way I can recover my data?

Answer: If you had a system crash in the middle of encryption or decryption, and no backup copy of your file, you should be able to manually recover most of your data as follows: decrypt the corrupted file with the -m option; this will decrypt the part of the file which has already been encrypted (and produce garbage for the remaining part). You can then restore the original file manually by piecing the two parts together. This method loses between 32-63 bytes where the two parts (encrypted and unencrypted) meet, but it is better than nothing.

Question: Could you add an option which would make ccrypt create a temporary file (as gzip does), instead of overwriting the original one. I would think this feature should be very easy to add. The security added by overwriting the original file is not very critical to me, and probably to some other users. The risk of losing data, however, is real; especially for long files.

Answer: This feature was added in release 1.4.

3. Compatibility

Question: Is ccrypt platform independent?

Answer: Yes. Ccrypt works on Linux, Windows, Macintosh OS-X, Unix, Android, and in principle, on many other platforms.

Question: There are different programs that say "AES encryption utility", but they are usually not compatible with each other; if I encrypt data with one of them, I cannot decrypt it with another. Why is this? Is ccrypt compatible with other programs?

Answer: The Advanced Encryption Standard (AES) is a block cipher, not a file format. Encryption utilities that use AES can differ in a number of ways, for instance in the way that a key (that the user types) is converted into an internal format. There are some other potential differences as well. Ccrypt, unfortunately, uses its own file format and is not compatible with any other programs that I know of. It is, however, platform independent.

By the way, ccrypt was written before the AES standard was set. Ccrypt uses the Rijndael cipher, which was later chosen as the AES by the U.S. government.

4. Passwords and hashing

Question: What keywords can ccrypt accept? Specifically with the --keyfile option. Are all characters legal? Such as semicolons, colons, percents, etc.

Answer: In principle all characters are fine for keywords, except null '\0' characters. In practice, you also can't have newline ('\n' or '\r') characters, not because ccrypt can't handle them, but because there is (usually) no way of entering them. There might be some other characters that your operating system doesn't let you enter (or tries to change). Printable ASCII characters are definitely fine.

Of course, there are no restrictions at all on the actual data to be encrypted.

Question: The ccrypt man page states that "Keywords can consist of any number of characters, and all characters are significant (although ccrypt internally hashes the key to 256 bits)." Could you clarify what hash algorithm you are using? Details: I'm using ccrypt to encrypt my daily CD backup, so I need to enter the same long password everyday (to the backup script I wrote). To avoid mistakes, I decided to check that password against a hash (instead of using double entry which is annoying and not 100% reliable) which is permanently stored in a file accessed by the backup script. Now I'm thinking: if ccrypt uses the same hash algorithm that I am using (SHA) then I am actually storing my encryption key in that file! What a joke "security" that would be!

Answer: Ccrypt uses a hashing algorithm based on AES (i.e., on the Rijndael block cipher). It is not one of the standard hashing algorithms such as SHA1. Thus, for your application, you should be fine. From the viewpoint of security, it does not matter much which hashing algorithm is used, as long as it is collision-free.

5. Security

Question: We are thinking of using ccrypt in our company to encrypt our data. Is ccrypt still a strong encryption that is very hard to break?

Answer: Yes, it is. Ccrypt uses strong 256-bit encryption which is currently considered to be unbreakable. Technically speaking, ccrypt uses the Rijndael block cipher. Rijndael was also chosen for the "Advanced Encryption Standard" (AES) by the U.S. government (see http://www.nist.gov/aes/). However, there is one difference between ccrypt and AES: ccrypt uses the 256-bit block size allowed by the Rijndael cipher, whereas the AES standard currently only covers the 128-bit block size. This does not mean that ccrypt is less secure than AES, only that it is not technically covered by the AES standard. Thus, it would be wrong to say that ccrypt is an "AES" encryption tool. Nevertheless, the cipher used by ccrypt is under much public scrutiny and, supposing that it were ever broken, this would be widely publicized immediately. As of this writing, this cipher has not been broken, and the experts think that it will be good for at least several decades.

Question: When ccrypt encrypts a file, what does it do with the "original", unencrypted file? When all the data has been encrypted, and it is going to be written, does it replace the original file? In the exact same sectors of the disk? And if so, is that enough? I think I've read about companies that dig up files that have been (the sectors) overwritten several times.

Answer: ccrypt by default overwrites the file. On a normal filesystem on a normal harddrive, this will cause the actual contents to be overwritten (i.e., the same sectors). (If you use an unusual device, like a tape drive, I am not sure what happens). This means that for most practical purposes, the original file contents are gone (i.e., cannot be read by software any more). However, this does not protect you against possible hardware attacks; a forensic investigator might be able to to a physical analysis of your hard disk surface and find traces of files that have been overwritten. No software could possibly prevent this; if you want to erase files irrecoverably, you'd probably have to send your hard drive through a mechanical shredder.

There are also some other ways in which parts of your original file may still exist after you have encrypted it: parts might exist in memory, and if you use virtual memory (also known as swap space), then this might again leak onto the hard drive. Also, journaling filesystems (such as ext3) might keep copies of parts of your data in unexpected places where they cannot be easily overwritten. In summary, ccrypt offers cryptographic security, but not physical security.

There are some tools available which can presumably physically erase files (or entire partitions) from harddrives. One such tool is wipe (http://wipe.sourceforge.net/). As the author of ccrypt, I neither endorse nor recommend using this tool, I am simply telling you of its existence (in fact I have never tried it myself). I am not a forensic expert and I am in no position to judge the extent to which this actually works. One could use wipe in conjunction with ccrypt by doing something like this:

  ccrypt < filename > filename.cpt
  wipe filename
Presumably, on certain file systems, this would physically erase your plaintext after encrypting it. However, I emphasize that ccrypt itself does not provide physical security, and all of the above caveats about memory leaks, journaling filesystems, etc, still apply.

Question: This is a technical question on ccrypt's security. By storing a magic number (in the first four bytes of the encrypted file I believe) part of the plaintext is known. So, I wonder, could this be exploited in a known plaintext attack, or is the amount of known plaintext simply too small? The magic number also speeds up exhaustive key search. Of course, the key space is so big that it still remains a giant job to do. Alternatively, would it be a good idea to verify key correctness using a hash of the plaintext instead of using the magic number? This would require that the entire decryption is done before key correctness can be verified, which is a lot slower, but seems more common practice than using a magic number.

Answer: Yes, you are right - the use of a magic number in ccrypt does indeed lead to a small amount of known plaintext. However, I do not think this leads to a significant decrease in security. By this I mean the following statement: "if there exists an attack on ccrypt with magic number, then there also exists an attack (not significantly harder than the first attack) on ccrypt without magic number".

My reasoning is as follows. Suppose ccrypt is used to encrypt the following types of files:

  • ASCII text
  • gzipped files
  • tar archives
  • jpeg files
For each of these file types, an attacker can easily decide whether or not a given key matches by decrypting a single block (namely, the first block of the file). In effect, the above file types already have a lot of known plaintext: For ASCII files, all the high bits are 0, for gzipped files, the first four characters are <1f 8b 08 00>, and similarly for the other file types. Thus, an attacker can verify key correctness with the same amount of effort (decrypting a single block), whether or not we include a magic number.

If we used a hash of the entire file to verify key correctness, this would significantly slow down authorized decryption, while not slowing down unauthorized decryption. Thus, this would not be a beneficial thing to do.

Or to put it another way: if AES were vulnerable to known plaintext attacks, we should not be using it in the first place. But AES is currently believed to be resistant to such attacks.

There is one caveat: The above argument does not quite apply if the type of files that are encrypted are statistically indistinguishable from random data. (For instance, this happens if you double-encrypt a file, with two different keys). In this case, the known plaintext provided by the magic number could potentially speed up decryption. However, this speedup is by a factor of at most 2^32. This is because our known plaintext consists of 32 bits. In other words, the known plaintext reduces the available key space by a factor of 2^32 (approximately one in 2^32 keys will pass the test). Given the fact that the size of the key space is 2^256, this is not significant: it reduces the key space from 2^256 down to 2^224, which is not significant. (Already a key space of 2^128 is considered bullet-proof today, and for the next 30 years).

Moreover, if we verified key correctness using a hash of the plaintext instead of using the magic number (as you suggest), then this will only be marginally more secure than using a magic number. The increase of security in this case depends on the average size of the encrypted file. If the average file consists of, say, 1000 blocks (32kB), then key verification would require decrypting 1000 blocks for each key, instead of 1 block for each key. This represents a slow-down of factor 1000 or about 2^10, which is dwindlingly small number compared to 2^32 and 2^256.

To summarize: on random data, the magic number leads to a speedup of cryptanalysis by factor 2^32 in the worst case. On non-random data (such as, most typical files), there is no speedup at all.

6. Maximum file size and disk resources

Question: I am about to use ccrypt to encrypt my backup files (tar.gz files). Could you tell me if there is a maximum file size that may be encrypted? When I ran ccrypt on some very large files (between 2 and 4 GB), I got the following error: Value too large for defined data type or Invalid argument.

Answer: As of release 1.4, ccrypt can handle files of any size (provided that your file system can handle them). Some problems used to remain with the Windows (cygwin) version, but this has been fixed in release 1.7. Large file support in AIX was added in binary release 1.7-2 (AIX only).

Question: I saw that ccrypt doesn't use much memory, then I assume it uses disk ressources somewhere?

Answer: Ccrypt uses very little memory and disk space, because by default, it overwrites files in place. Since it encrypts data a few bytes at a time, it does not need to read the entire file into memory. For this reason, it uses no additional disk space, very little memory, and does not write temporary data to disk.

However, if you use the --tmpfiles option, then ccrypt will use a temporary file rather than overwriting the original file in place. In this case, you need enough free disk space to hold the largest file you are encrypting.

7. Programming

Question: You provide a command line interface of ccrypt. I was wondering if there was a programmatic interface available for C or C++.

Answer: Yes. Get the source code (version 1.3 or later), and look at the file ccryptlib.h. Ccryptlib provides an interface that can be used by other programs, similar to what is provided by zlib for compression. You also need ccryptlib.c, rijndael.c/h, and tables.c/h (generated by maketables.c).

If you are going to use code from ccrypt (including ccryptlib.c) in any of your programs, please keep in mind that the ccrypt code is licensed under the GNU General Public License. You can use this code in any way you want, but any software based on this code must itself be distributed under the GNU General Public License. In particular, you can only use ccrypt code in open source projects. For full details, please see the file COPYING.

8 Ccrypt and rsync

Question: I want to back up encrypted compressed tar files on a remote server, using rsync. But the encryption destroys any similarities in the files, so that rsync has to copy the entire file, rather than just the differences. How can I work around this?

Answer: A possible solution is to calculate the "diff" of the current backup against the previous one at the local site, and then to store the encrypted compressed "diff" file on the remote server. For example, one could do a full backup once per week, and back up a "diff" file daily. Note that one should compute the "diff" of the uncompressed tar files, because compression, like encryption, will obscure similarities in the data.

9. Windows specific issues

Question: I am running ccrypt in Windows, and the following command does not work:
        ccrypt h:\data\*.*
The program replies "no such file or directory". What's wrong?

Answer: I don't know why this happens; maybe it is a bug in cygwin. It seems that wildcard expansion does not interact properly with backslash conversion. Each of the following two commands will work as expected:

        ccrypt h:\data\file.txt
        ccrypt h:/data/*.*
Also note that, unlike the usual DOS convention, ccrypt interprets the pattern "*.*" to match only filenames that contain a period ".". If you want to encrypt all files, you should use "*" instead.

Question: I am trying to recursively encrypt an entire directory in Windows, but the following command only encrypts the files in the top-level directory. Is the "-r" option not working?
        ccrypt -r C:/My_Directory/*.*

Answer: Ccrypt interprets the pattern "*.*" to match only filenames that contain a period ".". Many directory names don't contain a period, and so ccrypt ignores them if you specify "*.*". The correct syntax is either

        ccrypt -r C:/My_Directory/
        ccrypt -r C:/My_Directory/*

Question: I am running ccrypt in Windows, and I noticed that the -E option does not work. Is it possible to read the password from an environment variable under Windows?

Answer: Yes, it is possible, but the name of the environment variable must be in capitals. For example:

        $ secretpassword=xxx
        $ ccrypt -e -E secretpassword
        [does not work]
        $ ccrypt -e -E SECRETPASSWORD
	[works fine]
(Thanks to Gert-Jan Vons for pointing out this issue).

Question: I recently installed Norton Internet Security. When I used ccrypt to encrypt a file, I was prompted for the key, and entered it. After entering the key the second time, Norton informed me that ccrypt was attempting to contact a DNS server. Is ccrypt supposed to do this? If so, why?

Answer: The encryption algorithm used by ccrypt needs a unique initial "seed" value. This value need not be random, but it must be unique. Ccrypt generates it by hashing a combination of the hostname, the current time, and other similar information. Obtaining the hostname under Linux does not require a network connection, but for some reason, the Windows operating system wants to contact a DNS (domain name) server to obtain the hostname. I am not sure why this is so, but I suspect it has something to do with the fact that Windows does not have a proper notion of "host". It is also possible that this behavior is caused by the Unix emulation layer (Cygwin), and not by Windows itself.

In any case, this DNS request is harmless. There should be no harm in denying it (except your seed may be a little less unique), and there is certainly no harm in allowing it.

Back to main ccrypt page.
Back to Peter Selinger's Homepage: [home]

Peter Selinger / Department of Mathematics and Statistics / Dalhousie University
selinger@users.sourceforge.net / PGP key