As far as I understand the code of ccencrypt() within src/ccryptlib.c, this tool does not implement an authenticated encryption scheme and thus does protect the integrity of the encrypted data.
Yes, that is correct. The documentation also says this. From the man page: "On the other hand, ccrypt does not attempt to provide data integrity, i.e., it will not attempt to detect whether the ciphertext was modified after encryption. In particular, encrypted data can be truncated, leaving the corresponding decrypted data also truncated, but otherwise consistent. If one needs to ensure data integrity as well as secrecy, this can be achieved by other methods. The recommended method is to prepend a cryptographic hash (for instance, an SHA-1 hash) to the data before encryption."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This must be some kind of joke. This problem should be mentioned directly on the website and in the security section of the FAQs. Instead you hide this crucial information in the manpages in a section that starts with the false claim that "ccrypt is believed to provide very strong cryptographic security". Actually, I dispute this claim as providing integrity guarantees is part of providing very strong cryptographic security.
As I see it right now, ccrypt is outdated cryptographic software that hides its defects in technical sections of its manpages and is misleading in its communication. As such it should not be used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have added this question to the FAQ. The reason it was not there is that nobody has asked this question before. Perhaps not everybody skips the documentation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps people expect the author of an encryption tool to provide a proper solution. I was personally asked by a colleague if it is okay to use your application and I had to advise against it. You expect end users to know their way around cryptography which is a false assumption.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I still think that your FAQs are misleading. The answer to the 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?" should be a "No."
The response to the question "Does ccrypt implement an authenticated encryption scheme to protect the integrity of the encrypted data? " implies that not providing integrity protection is not a big deal and your suggestion to add an outdated SHA-1 hash at the beginning of the encrypted content is asking your users to actually implement a layman's MAC-then-encrypt AE scheme, but without even using a proper MAC. This is so utterly wrong.
A proper solution would be to just implement Rijndael-GCM if you feel inclined to stick with that weird algorithm choice from the early 2000s.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At this point you are just flaming me. Here is the definition of "Encryption" from Wikipedia. The information you seem to be misunderstanding is right there in the 4th sentence:
"In cryptography, encryption is the process of encoding information. This process converts the original representation of the information, known as plaintext, into an alternative form known as ciphertext. Ideally, only authorized parties can decipher a ciphertext back to plaintext and access the original information. Encryption does not itself prevent interference but denies the intelligible content to a would-be interceptor."
I understand that there are lots of things you can do with cryptography, besides encryption. For example, ccrypt also does not provide: digital signatures (proving who encrypted the data), non-repudiation (making sure whoever encrypted the data cannot afterwards deny it), key management, integrity, time stamping, and many other things. It is a tool for encryption. It follows the Unix philosophy of "doing only one thing, and doing it well". If you are looking for a cryptographic swiss army knife, you should use a tool such as GPG, which can pretty much do anything, but is correspondingly more difficult to use.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that is correct. The documentation also says this. From the man page: "On the other hand, ccrypt does not attempt to provide data integrity, i.e., it will not attempt to detect whether the ciphertext was modified after encryption. In particular, encrypted data can be truncated, leaving the corresponding decrypted data also truncated, but otherwise consistent. If one needs to ensure data integrity as well as secrecy, this can be achieved by other methods. The recommended method is to prepend a cryptographic hash (for instance, an SHA-1 hash) to the data before encryption."
As this is not a bug report, I am closing it.
This must be some kind of joke. This problem should be mentioned directly on the website and in the security section of the FAQs. Instead you hide this crucial information in the manpages in a section that starts with the false claim that "ccrypt is believed to provide very strong cryptographic security". Actually, I dispute this claim as providing integrity guarantees is part of providing very strong cryptographic security.
As I see it right now, ccrypt is outdated cryptographic software that hides its defects in technical sections of its manpages and is misleading in its communication. As such it should not be used.
I have added this question to the FAQ. The reason it was not there is that nobody has asked this question before. Perhaps not everybody skips the documentation.
Perhaps people expect the author of an encryption tool to provide a proper solution. I was personally asked by a colleague if it is okay to use your application and I had to advise against it. You expect end users to know their way around cryptography which is a false assumption.
I still think that your FAQs are misleading. The answer to the 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?" should be a "No."
The response to the question "Does ccrypt implement an authenticated encryption scheme to protect the integrity of the encrypted data? " implies that not providing integrity protection is not a big deal and your suggestion to add an outdated SHA-1 hash at the beginning of the encrypted content is asking your users to actually implement a layman's MAC-then-encrypt AE scheme, but without even using a proper MAC. This is so utterly wrong.
A proper solution would be to just implement Rijndael-GCM if you feel inclined to stick with that weird algorithm choice from the early 2000s.
At this point you are just flaming me. Here is the definition of "Encryption" from Wikipedia. The information you seem to be misunderstanding is right there in the 4th sentence:
"In cryptography, encryption is the process of encoding information. This process converts the original representation of the information, known as plaintext, into an alternative form known as ciphertext. Ideally, only authorized parties can decipher a ciphertext back to plaintext and access the original information. Encryption does not itself prevent interference but denies the intelligible content to a would-be interceptor."
I understand that there are lots of things you can do with cryptography, besides encryption. For example, ccrypt also does not provide: digital signatures (proving who encrypted the data), non-repudiation (making sure whoever encrypted the data cannot afterwards deny it), key management, integrity, time stamping, and many other things. It is a tool for encryption. It follows the Unix philosophy of "doing only one thing, and doing it well". If you are looking for a cryptographic swiss army knife, you should use a tool such as GPG, which can pretty much do anything, but is correspondingly more difficult to use.
I will end the discussion here and just proceed to advise anyone who is asking against using ccrypt.