Encrypt-then-Mac

本文约定如下：
M：明文数据
E：加密函数
H：hash函数
MAC：MAC函数
C：密文

标准密码学中，对 认证+加密 算法，有如下四种处理方式：
1：Hash-then-Encrypt
2：Mac-then-Encrypt
3：Encrypt-then-Mac
4：Encrypt-and-Mac

1：Hash-then-Encrypt，是先对数据进行hash运算，然后添加在数据末尾，最后使用加密算法进行加密，用公式就是 C = E(key, M || H(M))，显然他具有保密性和数据完整性。他需要一个key。

2：Mac-then-Encrypt，与 Hash-then-Encrypt 基本相同，不同点就是hash函数被替换为Mac函数，TLS协议中，指的的HMAC（没见过用CMAC的）。公示 C = E(key1, M || MAC(key2, M))。像HMAC这样的MAC，是需要key的，所以Mac-then-Encrypt是需要2个key的。对于熟悉TLS的人来说，这个应该是最熟悉的加密模式了。

3：Encrypt-then-Mac，与上面那个相反，先MAC后加密，先说公式，
C1 = E(key1, M)
C2 = MAC(key2, C1)
C = C1 || C2
这个模式普遍用于IPSEC中。

4：至于Encrypt-and-Mac，这个普遍用于SSH中，公式
C = E(key1, M) || MAC(key2, M)

他们各自对应的接收端的解密认证，逆过来曹组就可以了，这里不再赘述。

rfc7366 中规定了 Encrypt-then-Mac 在TLS、DTLS协议中的使用。

Once the use of encrypt-then-MAC has been negotiated, processing of
TLS/DTLS packets switches from the standard:
encrypt( data || MAC || pad )
to the new:
encrypt( data || pad ) || MAC

至于这么计算MAC，这么计算pad，一切如原先的协议规定一致，没有变化。当然，GCM模式加密本身自带了认证功能，所以一般只有CBC模式下，才会开启这个功能。所以，Encrypt-then-Mac在TLS协议中存在时间估计不会太长。

RFC中还规定，在renegotiation中，不能由当前的Encrypt-then-Mac降级到Mac-then-Encrypt，因为安全人员认为Encrypt-then-Mac比Mac-then-Encrypt安全的多，第一次我手都能使用更安全的Encrypt-then-Mac，renegotiation时肯定也会支持。

对于是否启用Encrypt-then-Mac，由两方hello报文中的拓展协商决定。