I have a simple encryption/decryption application that I am testing to learn more about security. I found out that if the user modifies the encrypted file, then decryption fails because the hashing algorithm doesn't generate back the original content. What are the common practices that deal with the problem of encrypted files modified by users either intentionally or unintentionally? The only thing I can think of is timestamp checking, but I am not sure how useful that is.

About my last statement, I guess I am not sure if there is a way to trick the OS so that the new timestamp is set back to the exact old time stamp although the content is modified.

  • 4
    What do you want to happen if the user modifies your file? – Dean Harding May 21 '11 at 9:40
  • 1
    Is this question "how to detect if file been tampered with?". If so: just create a hash signature of the contents and use that hash to verify the integrity of the file. – Martin Wickman May 21 '11 at 10:02

Well, any file altered after encryption is going to generate funny results. The only way I would know of detecting such changes would be to store a hash of the encrypted file when you do the encryption, and then compare that hash to the hash of the encrypted file prior to decryption. If there are any changes, the hashes will mismatch, and you'll know that the encrypted file isn't going to return the original results.

Don't rely on file stamps, though; timestamps and other metadata can change simply by moving a file around (either by the user or other processes). (Furthermore, timestamps and metadata can always be changed back, thus fooling the check.)

|improve this answer|||||

Cryptographically sign the file content, for instance using MD5.

The MD5 Message-Digest Algorithm is a widely used cryptographic hash function that produces a 128-bit (16-byte) hash value. Specified in RFC 1321, MD5 has been utilized in a wide variety of security applications, and is also commonly used to check data integrity... An MD5 hash is typically expressed as a hexadecimal number, 32 digits long...

|improve this answer|||||
  • 3
    Only not with MD5... – Shawn D. Dec 17 '11 at 4:23
  • MD5 is broken, but the concept remains the same. – billy.bob May 17 '13 at 15:56
  • Remove redundancy by applying compression on the plaintext before encryption
  • Encrypt
  • Add error-correction blocks to the encrypted datastream.

These three things must be done in this order. They cannot be switched around.

|improve this answer|||||

I strongly suggest you get the book "Applied Cryptography: Protocols, Algorithms, and Source Code in C" by Bruce Schneier.

This is a big fat (and expensive) book, which covers everything from simple introductory concepts through to the complex and ugly.

Even if you only read the first 100 pages, you will have a much better appreciation for the problems you will strike.

As a rough rule of thumb: If you think you know about cryptography - check with an expert :)

|improve this answer|||||

... if the user modifies the encrypted file, then decryption fails ... What are the common practices that deal with the problem of encrypted files modified by users

Smack the user.

Figuratively? Physically? Depends on [how well you know] the user. And how often they cause you this problem.

You can do exactly the same sort of thing with executables that aren't installed in "protected" directories; open them up in, say, Notepad, save them again and, surprise surprise, they don't work any more.

Perhaps the question should be - why are the users even aware this file exists? It's not as if they can do anything [useful] with it. If you save it in "My Documents" and they'll be all over it. Drop it into "%USERPROFILE%\AppData\Roaming\ CompanyName \ AppName \" and they'll never go within a mile of it.

|improve this answer|||||

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