Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Let's say I have one server that encrypts a file with a symmetric key, e.g. AES-CBC, and sends it to clients that decrypt it. Does that provide data integrity when decrypted? Or is it possible for someone to tamper with the file while it's still encrypted, and later when the client decrypts it, produce a modified file?

I typically see data integrity and authenticity discussed in terms of using digital signatures or MAC, but never in the context of encryption. I've also seen benchmarks that show encryption being more expensive than hashing, but that's not my main consideration.

UPDATE

I tried an experiment, where I used the openssl tool in Linux to encrypt a file. Then, I tried modifying the file in various ways (changing a byte, deleting a byte, appending a byte). In every case, when I tried decrypting, I would get a "bad decrypt" message. The commands I used were:

openssl enc -aes-128-cbc -in test -out test.enc
openssl enc -d -aes-128-cbc -in test.enc -out test.dec
share|improve this question
1  
Welcome to IT Security Stack Exchange. This site (as all Stack Exchange sites) work better if you put one question in each question, not multiple ones. Note that there also is a sister site about Cryptography, but I would only see the second question (in a slightly adapted form) as fitting there. –  Paŭlo Ebermann Dec 3 '11 at 23:25
    
The issue with symetric encryption is that at least two and ususally more people have a copy of the same key. If many people have a copy of the key, it is not possible to identifty who used a key for encryption. Or for that matter who decrypted it. –  this.josh Dec 4 '11 at 4:30
    
In my case, there's one server that encrypts the file, and many clients that decrypt it. I updated the question to focus on just data integrity. –  88keys Dec 4 '11 at 4:35
    
@D.W. In the current form, yes. In its first revision, the question contained a question where this would be relevant. (I'm deleting my previous comment now as obsolete, though.) –  Paŭlo Ebermann Dec 4 '11 at 20:45
    
@this.josh: You're referring to authentication, but the question is about integrity. –  mehaase Dec 28 '11 at 15:30
add comment

4 Answers

up vote 11 down vote accepted

Symmetric encryption does not provides integrity. The amount of control that an attacker can have on encrypted data depends on the encryption type; and some specific details of some encryption modes can make the life a bit harder for the attacker if he wants to make surgical modifications. With CBC, the attacker can flip any bit he wishes, provided that he does not mind transforming a dozen other bytes into random junk.

There are recent encryption modes which combine symmetric encryption and checked integrity (with a MAC). These modes ensure both confidentiality and integrity. AES-CBC is not one of them. If you want an encryption mode with integrity, I recommend EAX.

Update: concerning your experiment: CBC is a mode where the source data length must be a multiple of the block cipher block length (16 bytes, for AES). Since an arbitrary input message may have any length, some padding is added: a few bytes, with specific contents such that they can be unambiguously removed upon decryption. In your case, OpenSSL is complaining that, upon decryption, it does not find a proper padding structure. However, if the attacker does not alter the last 32 bytes of the encrypted data, the padding will be undamaged, so alterations of all but the last 32 bytes will remain undetected. And even for the last 32 bytes, there are ways to evade detection with a not-so-small probability.

share|improve this answer
    
I revised my experiment to alter something other than the last 32 bytes, and openssl didn't detect it on decryption. –  88keys Dec 4 '11 at 20:01
add comment

CBC-encryption does not provide data integrity. Here's why:

Fix some key k (unknown to the attacker). Let E(k,-) and D(k,-) be the bare encryption and decryption functions of some block cipher. Let p be some single block of plaintext. I'll denote XOR by +. After fixing some IV, we encrypt as follows:

c = E(k,p + IV).

Then, we send IV and c over the wire. To decrypt, we compute

p = D(k, c) + IV.

(Note that this is equivalent to the statement D(k,c) = IV + p.)

Now, suppose that an attacker knows a single plaintext/ciphertext pair. Let's denote them as p and (IV, c), as above. Now, suppose that the attacker would like to create ciphertext that will decrypt to some other plaintext block of his choosing -- say p'. I claim that (IV + p + p', c) decrypts to p'. Why?

Well, we just follow the decryption procedure above, replacing IV with IV + p + p'. We have

D(k,c) + (IV + p + p') = (IV + p) + (IV + p + p') = p'.

Amusingly, ECB-mode is not vulnerable to this issue (though I don't endorse its use either).

share|improve this answer
    
Great theoretical explanation. –  DreamSonic Oct 13 '13 at 22:05
add comment

Symmetric ciphers do not by themselves provide integrity because they do not detect malicious or accidental modifications to ciphertext; decryption will output something else than the original plaintext and unless this results in some protocol violation for the decrypted payload then you have an integrity problem.

The solution is to wrap plaintext inside packages which include data which can be used to validate the integrity of the package, typically a hash-based checksum (edit: keyed HMAC). This is what is done e.g. for Transport Layer Security.

Here is an example of a plaintext-protection scheme used in a Versile Platform secure byte transport protocol (disclaimer: I am involved in VP development).

Edit: I realized message-encapsulation is overkill for your scenario which involves a complete file, and so you are better off just adding a keyed MAC on the complete ciphertext. For package protected formats, as D.W. points out the details matter, and "checksum" should be performed as a keyed MAC.

share|improve this answer
    
Please see my update above. Do you think there's a "protocol violation" which is causing the decryption to fail? If so, is AES-CBC providing data integrity? –  88keys Dec 4 '11 at 16:59
    
@88keys, as explained in my answer, it might detect some accidental alterations to the ciphertext, but it does not suffice to detect or prevent malicious alterations to the ciphertext. –  D.W. Dec 4 '11 at 20:07
1  
@Versile, a "hash-based checksum" is not sufficient. It falls short on two ends: first, you need to use a message authentication code, not an unkeyed hash; second, normally you should be applying the MAC to the ciphertext, not hashing the plaintext before encryption. Consequently, your second paragraph has bad advice that may lead some readers astray. The details matter here. –  D.W. Dec 4 '11 at 20:08
    
@D.W. thank you for pointing out the imprecise reference to checksums, which should be a MAC. Regarding plaintext vs. ciphertext as MAC input I believe there are several ways to go about it, e.g. the MAC for TLS records takes compressed plaintext as input (RFC 5246, section 6.2.3.1). –  Versile Dec 5 '11 at 11:06
    
@Versile, yes, there are multiple ways to go about it, but some (encrypt-then-authenticate) are safe; others (authenticate-then-encrypt) are not guaranteed to be safe. TLS 1.0 uses authenticate-then-encrypt, which turns out to have subtle vulnerability: see the recent BEAST attack. Consequently, I don't recommend you follow TLS; instead, I recommend you use encrypt-then-authenticate. –  D.W. Dec 5 '11 at 15:47
add comment

AES-CBC encryption does not provide integrity. Depending upon how it is implemented and used, it might happen to detect some accidental modifications to the ciphertext, but it does not defend against malicious tampering with the ciphertext.

Encrypting without authenticating is one of the most common mistakes in the use of cryptography. It has led to serious vulnerabilities in many systems, including ASP.NET, XML encryption, Amazon EC2, JavaServer Faces, Ruby on Rails, OWASP ESAPI, IPSEC, and WEP. See the previous link for more information.

The fix: You should either use an authenticated encryption scheme (not AES-CBC), like EAX, or you should use a message authentication code, like CMAC, in encrypt-then-authenticate mode.

If you are going to be implementing cryptography yourself, I encourage you to read the question here entitled Lessons learned and misconceptions regarding encryption and cryptology to help you avoid some of the most common mistakes. Using encryption without authentication is one of them.

share|improve this answer
    
Very helpful suggestions in the link you provided. –  88keys Dec 4 '11 at 23:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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