# Class 14: Encryption and Authentication (Build a secure channel)

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.

### Setting up a secure channel

If we want to both encrypt AND authenticate then we've got to be careful. There are three possible ways to set this up:

1. Encrypt and authenticate
2. Authenticate then encrypt
3. Encrypt then authenticate (do this one)

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.

### Encrypt and Authenticate

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.

### Authenticate then decrypt

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.

### Encrypt then Authenticate

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.

### Secure Channels

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):

• Re-Ordering Attacks: An adversary could take the encrypted messages and play them in a different order.
• Replay Attacks: They could copy an encrypted message and send it again whenever they want.
• Reflection Attacks: A message sent from A to B could be sent back to A rather than passed along to B.

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.

## Mini-project

Partner-up: Pick one partner, sketch out and (start to) implement a "secure channel" which encrypts, authenticates, and prevents the three re* attacks.