消息认证码和认证加密
消息认证码
消息认证码(Message Authentication Code)是一种确认完整性并进行认证的技术。但是消息认证码并不能保证消息的机密性。
A将生成消息认证码的
对称密钥，以安全的方式发送给B。(就当做是面对面交流转手给B) A将明文消息和对称密钥一起哈希算一遍，最后得到消息认证码。 A把明文消息和消息认证码一起发给B。
B把明文消息和
对称密钥用同样的哈希算法算一遍，然后把计算的消息认证码和A发过来的消息认证码两者进行对比，如果一样则认为是没有被篡改过的。
如果不一致则认为此次发送的消息不正确，不是假冒就是篡改，B会丢了包让A再发一次。
消息认证码是存在密钥分配问题的，也就是怎样安全的将对称密钥送到对方手里。这里讲概念时忽略这个问题。
从上面可以看出，消息认证码的输入包括任意长度的消息和一个发送者与接收者之间共享的密钥(对称密钥)，它可以输出固定长度的数据，这个数据就是消息认证码的值。
认证加密
认证加密是将对称密码和消息认证码相结合，同时满足机密性、完整性、认证三大功能的机制。
A准备一下加密消息的
对称密钥1和用来生成消息认证码的对称密钥2，然后以安全的方式发送给B。(就当做是面对面交流转手给B) A用加密明文消息的对称密钥1进行加密，得到密文，然后把密文和对称密钥2一起哈希算一遍，最后得到消息认证码。 A把密文和消息认证码一起发给B。
B把密文和
对称密钥2用同样的哈希算法算一遍，然后把计算的消息认证码和A发过来的消息认证码两者进行对比。
如果一样则认为是没有被篡改过的，就可以再用
对称密钥1放心的去解密密文。
如果不一致则认为此次发送的消息不正确，不是假冒就是篡改，B会丢了包让A再发一次。
后面统一使用认证加密来说明消息认证的过程。
消息认证码如何预防假冒和篡改
消息认证码的特点之一就是认证机制，假冒和篡改都可以识别出来。
防止假冒
假如X冒充A给B发送消息，X想自己搞2个对称密钥，但是X没有用于生成消息认证码的
对称密钥2，无法生成正确的消息认证码，即使以X自己的方式生成所谓的消息认证码，B也会将密文和对称密钥2hash一下，验证出消息认证码不一致，所以X没法冒充A发消息搞事情，这样能防止假冒。
防止篡改
A给B发消息，X想把A的消息篡改一下再发出去，结果…
1.如果只篡改密文，X自己发个消息用自己的密钥加密成密文X，B去验证消息认证码，把密文X和对称密钥2哈希一下，发现算出来的的消息认证码和发来的不一致，毕竟X是没有对称密钥2的，这造不了假，收到的消息不对，丢了吧。
2.如果只篡改消息认证码，通过密文和对称密钥2进行hash就知道消息认证码是错的，丢了吧。
3.如果想要把密文和消息认证码都篡改，这也是不可能的，绕不开对称密钥2。
不能防止事后否认
消息认证码可以防止假冒和篡改，但是没法防止事后否认。
比如A向B借了1000块钱，B经过一些列认证后把钱借给了A。
还钱的时候…
A：我没有找你借钱啊！
B：怎么可能，我验证了，确实是你的密文和对称密钥2hash出来的消息认证码，这肯定没错。
A：你怎么知道你存储的对称密钥2没有泄露呢？也许你泄露了，别人假冒我找你借钱呢！
为了防止事后否认，那就需要数字签名来解决，我们下一章会讲数字签名。
为什么要将密钥和密文hash来确定消息认证码？
我们需要防止密钥推测攻击，即根据消息认证码推测出通信双方使用的
对称密钥2，如果能推测出对称密钥2，就能进行篡改和假冒等攻击。这里用hash其实就是利用单向散列函数的单向性和抗碰撞性来保证消息认证码无法推测出对称密钥2的。
对称密码就能加密传输，为什么还要用消息认证码？
如果只是用对称加密，假如发送方给接收方的值是一段随机比特序列呢？比如3F5D6F…，结果接收方解密出来就懵了，这看起来乱七八糟该不会是其他人恶搞发送的吧？
如果使用消息认证码，即使是发送随机比特序列，也能进行正确的认证。
重放攻击
即使用了消息认证码，中间人还是可以使坏，那就是重放攻击。
A给B发送消息，X能窃听，但就是不想修改，因为一旦修改B就会验证出消息认证码不对。那么X就多发几次这个消息。
A：“我是A，借我1000块…” ----->B
X发送10次A的消息给B ----->B
B: “好的，给你1000块…” ----->A
B: “好的，给你1000块…” ----->A
B: “好的，给你1000块…” ----->A
B: “好的，给你1000块…” ----->A
B: “好的，给你1000块…” ----->A
B: “好的，给你1000块…” ----->A
B: “好的，给你1000块…” ----->A
B: “好的，给你1000块…” ----->A
B: “好的，给你1000块…” ----->A
B: “好的，给你1000块…” ----->A
这样B就给了A10000块，就把A给整懵了。
如果是银行之间转账，X想把
bank1银行的钱转到自己在bank2银行的的XCount账户中，从bank1转账1000块，然后重放攻击10次，结果就转了10000块到bank2银行，然后取出来，这“钱生钱”也太快了吧？
防重放方案
防重放有几种方法
1.序号递增
双方约定发送消息时添加一个递增的序号，计算消息认证码的时候也放进去一起hash，这样X就不知道这个序号也不知道递增多少，无法计算包括随机数的消息认证码，就没法进行重放攻击了。2.时间戳
双方约定一下发送消息时包含当前的时间，如果解密消息里是同一个时间，那这个就是重复消息，直接丢弃，这样就能防御重放攻击。但是这也有弊端，必须要求发送者和接收者的时间保持一致，而且还要考虑通信过程中的延迟，又必须得在时间的判断上留下缓冲，于是多多少少还是有可以进行重放攻击的空间的。3.nonce
在通信之前双方先协商，然后接收方先向发送方发送一个一次性随机数，这个随机数称为nonce。发送方在消息中放入这个nonce，并计算消息认证码。接收方接收消息后，该nonce就无效了，后续受到重放攻击的消息直接丢弃即可。但是协商也有一定的数据量，需要一点带宽和时间的代价。
