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.

I've been reading up on Authenticated Encryption with Associated Data. The linked RFC states:

Authenticated encryption is a form of encryption that, in addition to providing confidentiality for the plaintext that is encrypted, provides a way to check its integrity and authenticity.

My understanding is that simply encrypting the data, even using a symmetric shared key, with something like AES or 3DES should be sufficient to verify the data has not been tampered with in transit. If it had been, the message simply would not decrypt.

So, why is a separate authentication necessary? In what situation would you need to have a separate authentication (even using plain HMAC with encryption)?

share|improve this question

migrated from programmers.stackexchange.com Apr 1 '13 at 18:52

This question came from our site for professional programmers interested in conceptual questions about software development.

3  
If I remember my cryptography correctly, encryption without authentication does not protect communications from a replay attack. –  Peter Smith Apr 1 '13 at 14:26

4 Answers 4

up vote 5 down vote accepted

Encryption DOES NOT automatically protect the data against modification.

For example, let's say we have a stream cipher that is simply a PRNG (random number generator), where the key is the seed. Encryption works by generating random numbers in sequence (the keystream) and exclusing-or'ing them with the plaintext. If an attacker knows some plaintext and ciphertext bytes at a particular point, he can xor them together to recover the keystream for those bytes. From there, he can simply pick some new plaintext bytes and xor them with the keystream.

Often the attacker need not know the plaintext to achieve something. Let's take an example where an attacker simply needs to corrupt one particular field in a packet's internal data. He does not know what its value is, but he doesn't need to. Simply by replacing those bytes of ciphertext with random numbers, he has changed the plaintext.

This is particularly interesting in block ciphers where padding is used, as it opens us up to padding oracle attacks. These attacks involve tweaking ciphertext in a way that alters the padding string, and observing the result. Other attacks such as BEAST and the Lucky Thirteen Attack involve modification of ciphertext in a similar way. These tend to rely on the fact that some implementations blindly decrypt data before performing any kind of integrity checks.

Additionally, it may be possible to re-send an encrypted packet, which might cause some behaviour on the client or server. An example of this might be a command to toggle the enabled state of the firewall. This is called a replay attack, and encryption on its own will not protect against it. In fact, integrity checks often don't fix this problem either.

There are, in fact, three primary properties that are desirable in a secure communications scheme:

  • Confidentiality - The ability to prevent eavesdroppers from discovering the plaintext message, or information about the plaintext message (e.g. hamming weight).
  • Integrity - The ability to prevent an active attacker from modifying the message without the legitimate users noticing. This is usually provided via a Message Integrity Code (MIC).
  • Authenticity - The ability to prove that a message was generated by a particular party, and prevent forgery of new messages. This is usually provided via a Message Authentication Code (MAC). Note that authenticity automatically implies integrity.

The fact that the MAC and MIC can be provided by a single appropriately chosen HMAC hash scheme (sometimes called a MAIC) in certain circumstances is completely incidental. The semantic difference between integrity and authenticity is a real one, in that you can have integrity without authenticity, and such a system may still present problems.

The real distinction between integrity and authenticity is a tricky one to define, as Thomas Pornin pointed out to me in chat:

There's a tricky definition point there. Integrity is that you get the "right data", but according to what notion of "right" ? How comes the data from the attacker is not "right" ? If you answer "because that's from the attacker, not from the right client" then you are doing authentication...

It's a bit of a grey-area, but either way we can all agree that authentication is important.

An alternative to using a separate MAC / MIC is to use an authenticated block cipher mode, such as Gallois/Counter Mode (GCM) or EAX mode.

share|improve this answer
    
There are actually four primary properties. The fourth is availability. It doesn't matter how well you do on the other three pillars if an attacker can take your service down at will so no one can use it. Excellent answer though! –  Rein Henrichs Apr 2 '13 at 2:35
    
Thank-you for the incredibly detailed response. In my particular use case, the data is not particularly sensitive, so an HMAC to verify authenticity (integrity?) is likely sufficient. This is great information though. –  Jonathan Apr 2 '13 at 11:17

Encryption make sure the data can't be read or tampered with. Authentication makes sure you know where the data came from.

A more practical view: My bank uses an Encrypted link (https) between my web browser and it's web sever, but without Authentication it doesn't let me see what isn't in my bank account.

share|improve this answer
2  
That's a different kind of authentication. –  delnan Apr 1 '13 at 13:54
1  
The authentication is what allows you to know for sure that you are talking about your account to your bank, and not actually to some random cybercriminal. You might want to know that sort of thing… –  Donal Fellows Apr 1 '13 at 16:57

The addition of authentication would prevent an unauthorized user from submitting data encrypted with the (stolen) symmetric shared key, basically adding an additional secret to the mix.

share|improve this answer

As far as I know, AES and 3DES are block ciphers used in conjunction with some mode, like CTR, CBC and those modes(alone) are only semantically secure under adversaries that can only eavesdrop. If adversary can tamper data being transmitted, we must ensure integrity and it cannot be guaranteed from the above constructions. Auth. encryption guarantees that adversary that can tamper your data, won't be able to create encrypted data that properly decodes to valid plain text. In other words, the output of a auth.encryption scheme is either a valid plain text, or a symbol that represents invalid output. If you get the symbol that represents invalid output, you know data was modified.

share|improve this answer

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.