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?
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.
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.
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.
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.
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.
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.
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.
– Maarten Bodewes
Mar 02 '15 at 10:23
ccrypt without revealing the (strong) password then you should not lose any sleep over it.
– Maarten Bodewes
Mar 03 '15 at 16:56