I would like to know how secure is ccrypt to encrypt files (like images, videos and other non-plain text data) using single password of 20+ chars length.

It uses Rijndael with 256-bit block size and 256-bit key size.

Is there any better alternative to encrypt files of this kind or is it secure enough?

  • $\begingroup$ What are you really trying to do? Encrypt files programmatically? What are you then doing with the files? $\endgroup$ – mikeazo Feb 27 '15 at 14:28
  • 1
    $\begingroup$ Secure enough for what? What are you doing with the files? ccrypt uses CFB mode, so there is no authentication. That to me is a big negative. Personally, I'd use GPG and do something similar to the last example here. $\endgroup$ – mikeazo Feb 27 '15 at 15:56
  • $\begingroup$ I've made an answer based on a study of the protocol. Could you have a look at it? Usually software recommendations are off topic here, but the well known container formats for PGP and CMS are the most likely candidates. There are also projects like Fernet and RNCrypt you could consider, although those are mainly libraries, not CLI's. Basically ccrypt is AES in CFB mode + proprietary key derivation - in that sense it's secure. $\endgroup$ – Maarten Bodewes Mar 5 '15 at 9:55

The following is an analysis of the CCrypt protocol described here. Note that this breakdown of ccrypt mostly focuses on possible weaknesses that may also be present in other protocols.

Key derivation

ccrypt does not apply a well known Password Based Key Derivation function. As no salt is applied rainbow tables can be constructed (although the generated keys must still be validated against the ciphertext by at least a single Rijndael decrypt).

Dictionary attacks are made easy as no work factor or iteration count is used by the protocol; CCrypt even contains code to perform a targeted search for passwords that are close to a given password. Initial verification of the resulting key can be performed against the magic after the IV is decrypted with the resulting $R$. That said, the resulting key is well randomized using all available characters, even if the protocol is relatively unorthodox.

Nonce & IV generation

The file encryption does not contain an authentication tag. Therefore anybody can create bogus messages. Messages may be swapped as well to fool the user into decrypting the wrong message. You just need a copy of the IV for an existing ciphertext for this. Non-authenticated encryption can be OK for providing confidentiality for stored ciphertext, as long as the user is aware of it. In general it is hard to protect against an adversary swapping ciphertext, even if integrity protection and authentication is added to the ciphertext. A warning with regard to the lack of integrity protection and authentication is included in the description of ccrypt.

The nonce is not fully random. If the input for the nonce generation can be made identical (mainly time-of-day in seconds & microseconds, process ID and count should be relatively easy to repeat) then an identical key stream will be generated for identical passwords. In that case high amounts of information about the plaintext could be retrieved by XOR-ing multiple ciphertext against each other (at least for initial block and possibly blocks of ciphertext). The lack of a secure random number generator on many platforms has been indicated as the reason for this design choice.

Password validation

There is an almost negligible chance of $1\over{2^{32}}$ (because the magic is 32 bits) that the wrong password is accepted to decrypt a ciphertext. This could however be exploited by an attacker claiming to have a correct password for a file.

Cipher usage

CCrypt uses it's own C source code for the Rijndael implementation, although it seems directly derived from the C code for the NIST competition. It is unknown if this implementation is secure against side channel attacks. It doesn't matter as much as CCrypt is mainly used to encrypt files locally.

Full block CFB is used as mode of operation. This is known to be a secure mode. An IV is generated and the highest block size and key size are used. So there are likely no big issues with how the Rijndael cipher is deployed.

Password security

As with any scheme to perform PBE (Password Based Encryption) the security of ccrypt is highly dependent on the quality of your password. A disadvantage of a scheme that only relies on symmetric encryption primitives is that you need to supply your password both for encryption and for decryption. For OpenPGP you would only require your password to unlock the private key during decryption.


In conclusion the key derivation scheme and the nonce generation are not standardized and leave something to be desired. The password is however hashed in such a way that it is unlikely that any entropy in it is lost. Rijndael - not AES - is deployed correctly so the protocol seems secure. The project only has one author as this time, but Peter seems to be responding to requests.

It would be advisable to make sure that nobody else is logged in when encrypting / decrypting your data as the implementation does not seem to be tested against side channel attacks. Furthermore, as the documentation indicates, you should not assume this protocol offers integrity protection or authentication of the plain- and ciphertext.

| improve this answer | |
  • $\begingroup$ Because the system random number generator isn't used and the c-code should be efficient, the ccrypt encryption is probably pretty fast, even though the 256 bit block size, 256 bit key and non-optimized Rijndael cipher will take more time than plain optimized AES-128. $\endgroup$ – Maarten Bodewes Mar 2 '15 at 10:23
  • $\begingroup$ Anything missing from my answer Jan? Sorry about the amount of text, I first had to figure out the design & then implement it from source, then write an analysis :) Conclusion of conclusion, if you gave ciphertext to an attacker which you generated using ccrypt without revealing the (strong) password then you should not lose any sleep over it. $\endgroup$ – Maarten Bodewes Mar 3 '15 at 16:56
  • $\begingroup$ Well there's a meet-in-the-middle attack on the KDF bringing preimage resistance down to $2^{128}$. $\endgroup$ – forest May 14 '18 at 2:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.