什么是消息认证码
只是写一些自己工作过程遇到的密码学技术，结合一些资料，做一下总结。如有错误，请嘴下留情！
我们思考一个场景，两个人（系统）之间的对话（请求），如转账（真实转账很复杂，现在只是简单说一个场景）、表白（消息推送）等场景。假如A是一个在文科班的帅哥（本人），一天收到一封表白信，说：“我超喜欢你XXX，可以做我对象吗”，A内心虽然很激动，但是也肯定会疑惑“谁这么有眼光？”，看了一下信封上有没有署名。 很好，有署名，叫王刚。
现在问题来了，现在的情况就有以下几种可能：
- 这封信不是王刚写的，别人冒充的。（消息认证问题）
- 这封信是王刚写的，但是被人改了内容。（消息一致性（完整性）问题）
如果王刚知道消息认证码技术，就不会出现以上的问题。
消息认证码是一种确认完整性并进行认证的技术，Message Authentication Code， 简称MAC（不是唇膏），消息认证码解决的是：消息认证和消息一致性问题。
简单给个定义
输入一段任意长度的消息和一个【发送者和接受者之间共享的密钥】，输出一段固定长度的数据，这个数据就是MAC值。
注意： 这个共享密钥不同的发送者之间一般是不一样的，如果都一样，就没法做消息认证（没法识别是谁发的）。
消息认证码的使用步骤
前置说明：
- B要提前和A约定共享密钥
- MAC计算一般使用单向散列函数来实现，这种称为HMAC。当然，也可以使用分组密码来实现，使用CBC模式，例如AES-CMAC
sequenceDiagram
B->>B: 使用共享密钥，计算需要发送的消息的MAC值
B-->>A: 发送原始消息和MAC值
A->> A: 使用共享密钥，重新计算一次MAC值
A->> A: 比对MAC值
比对MAC值，如果：
- MAC值一致，则证明是王刚发的
- MAC值不一致，则证明不是王刚发的，或者王刚发的内容被中间人篡改了
上面流程还有一个比较步骤没说，就是B发送的消息要带有B的身份信息，否则A无法根据B的身份信息拿到共享密钥。毕竟，谁也没规定，恋爱的时候只能找一个人拿共享密钥是吧。
密钥配送问题
消息认证码技术里面最最最核心的就是共享密钥，如果共享密钥丢失了，那一切就完了。计算机系统中一般不会像A和B收发情书这样面对面沟通共享密钥。计算机系统中把这种双方之间需要沟通确定共享密钥的问题称为密钥配送问题，一般的解决方案有：
- 公钥密码
- Diffie-Hellman密钥交换
- 密钥分配中心
- 当然，线下交换也是可以的
不能解决的问题
对第三方证明
简单来说，就是，A收到B的情书（假设B不是王刚，是个女神，大美女），MAC值计算也认证过了，OK。当A沾沾自喜的时候，C突然冒出来说：“我不信，你怎么证明一定是B亲手写的情书”，A：“怎么不能，MAC值都是对的，只有我和B知道MAC值”，C 毫不客气地说：“那就对了，你也有可能自己冒充B写的，自己写给自己”。
A无法反驳。
是的，这个时候A和B使用的消息认证码技术是没法向第三方证明来源是对方而不是自己，以后写的数字签名技术能解决。
防止否定
也是上面的例子，因为没法向第三方证明来源是对方而不是自己。如果B说：“我就没有写过情书，都是A自导自演”，哈哈哈，丢脸丢死了。毕竟A没法向别人证明一定是B写的，想想都凄凉。
