ccrypt

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.

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.

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: Ccrypt does not use AES (the Advanced Encryption Standard). Ccrypt uses the Rijndael cipher with a block size of 256 bits. On the other hand, AES (which was standardized after ccrypt was first published) uses a version of the Rijndael cipher with a block size of 128 bits. Therefore, ccrypt is not compatible with AES, nor with any other programs that I know of. Ccrypt is, however, platform independent - a file encrypted on one operating system can be decrypted on another.

An additional issue is that AES is a block cipher, not a file format. Therefore, even if several different encryption tools use AES, they can still differ in a number of incompatible ways. One potential difference is the way that a key (that the user types) is converted into an internal format. There are some other potential differences as well.

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 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.

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

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

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.

Question: Does ccrypt implement an authenticated encryption scheme to protect the integrity of the encrypted data?

Answer: No. Encryption (secrecy) and authentication (integrity) are two different things. Ccrypt is an encryption program. Its purpose it to keep your data secret. It does not attempt to provide data integrity, i.e., it will not attempt to detect whether the ciphertext was modified after encryption. For example, if someone truncates the encrypted data, the corresponding decrypted data will also be truncated, but otherwise unchanged.

If your application requires data integrity as well as secrecy, this can be achieved by other methods. One such method is to prepend a cryptographic hash (for instance, an SHA-1 hash) to the data before encryption, and then check the integrity of the hash after decryption.

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.

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.

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.

        ccrypt h:\data\*.*

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/*.*

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]

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.