Don't like this style? Click here to change it! blue.css
Overview: So far we've only dealt with MACs on plaintext. Of course we want secure channels of communication that are both secret and tamper-free. You have to realize that this problem is surprisingly difficult. Several very natural approaches are just wrong. TL,DR: Encrypt first then authenticate, choose independent keys.
If we want to both encrypt AND authenticate then we've got to be careful. There are three possible ways to set this up:
Independent Keys: Can you come up with a good reason why we don't use the same key for both encryption and authentication?
Let's look at this using four totally secure but generic algorithms, ENC, DEC, MAC, VRFY.
In this case you compute \(c = ENC_k(M)\) and \(t = MAC_{k_2}(M)\) and send \((c,t)\).
On the other side they must do: \(M = DEC_k(c)\) then check \(t == VRFY_{k_2}(M)\) once they know \(M\).
So what's wrong with this scheme? Most MACs are deterministic.
When you send the same message many times your eavesdropper will know because \(t\) will be the same each time.
ALSO the MAC isn't designed for secrecy, so there is no guarantee that the top byte of \(t\) isn't identical to the first byte of \(M\), for instance. So just don't do this one.
In this world you compute \(t = MAC(M)\) then \(c = ENC(M || t)\). Your receiver computes \(M || t = DEC(c)\) then checks that \(t == VRFY(M)\).
The case against this one is a little weaker. In fact Schneier recommends it while Katz recommends against it. The difference is their faith in practicality. Katz loves proofs of security and Schneier loves horse-sense in the trenches utility. In this case I lean towards Katz because I've seen SSL screw this one up and there is little harm to encrypt then authenticate.
Here is the case against authenticating first: there are two sources of error. The decryption could fail with a "bad padding error" or the authentication could fail with tampering. So attackers can carefully time out the differences against certain schemes and pull off a "padding-oracle" attack. This has been plaguing TLS/SSL for decades (See this and this (a nice whiteboard explanation of padding-oracle attacks).
Upshot: don't use this style either.
The winner is this: \( c = ENC_{k}(M)\) then \(t = MAC_{k_2}(c)\) and send \( (c, t) \). On the other side \(t == VRFY_{k_2}(c)\) and if that works \(M = DEC_k(c)\). If the MAC is strongly secure then we are CCA-secure and unforgeable, PROVIDED the keys are random and independent.
Overview: These are more fundamental attacks that border a bit more on network security than crypto but they lead to a principle. Always encrypt what was meant and not just what was said. In order to fight against replays and reflections you should include more than just the message in your MACs.
So we're going for a channel of encrypted and authenticated messages between two people despite adversaries handling the traffic.
We've done top-notch encryption followed by top-notch authentication. So what can go wrong?
Here are three fundamental attacks that our crypto doesn't help with (all related to someone controlling the network between the two parties):
None of these attacks would lead to a failure, all of the messages would be unforged and decrypt correctly.
It leads us to a principle: The Horton Principle: Authenticate what is meant, not what is said.
In this case we can solve these problems by including some extra data with the encrypted messages, a message counter and a direction bit (0 for A to B and 1 for B to A). Then both parties can maintain state and reject messages that don't match up.
I bring it up to round out this short module because encryption is never the full story of security. But it's essential to any secure setup.
Partner-up: Pick one partner, sketch out and (start to) implement a "secure channel" which encrypts, authenticates, and prevents the three re* attacks.