消息认证码可以实现认证 和 检测篡改这两个功能。
密文的传输过程中可能被篡改，这会导致解密后的内容发生变化，从而产生误会。
消息认证码就是可以预防这种情况发生的机制。
使用场景：
假设A在B处购买商品，需要把商品编号abc告诉B.
此处，假设A使用共享密钥加密对消息进行加密。A通过安全的方法将密钥发送给了B.
A使用双方共有的密钥对消息进行加密。
A把密文发送给B,B收到后对密文进行解密，最终得到原本的商品编号abc;
以上是没有出现问题的流程。
回到A正要向B发送密文的时候，假设A发送的密文被X篡改了，而B收到密文后没有意识到这个问题。
假设B对被篡改的密文进行解密，得到消息xyz.
B以为A订购的是编号xyz的商品，于是将错误的商品发送给了A.
如果使用了消息认证码，就能检测出消息已被篡改。
流程：
A正要向B发送密文的时候，A生成了一个用于制作消息认证码的密钥，然后使用安全的方法将密钥发送给了B.
接下来，A使用密文和密钥生成一个值。假设此处生成的一个值是7f05.这个由密钥和密文生成的值就是消息认证码，mac(Message Authentication Code).
A将Mac(7f05)和密文发送给了B.
和A一样，B也需要使用密文和密钥来生成mac,经过对比，B可以确认自己计算出来的7f05和A发来的7f05是否一致。
如果一致，接下来，B只需要使用密钥对密文进行解密即可
最终B成功的取得了A发送过来的商品编号abc.
回到A向B发送密文和消息认证码的时候，假设密文被篡改，B使用该密文计算mac时得到的值是b85c,发现和收到的mac不一致，由此，B意识到密文或者mac，甚至两者都可能遭到了篡改。
于是B废弃了收到的密文和mac，向A提出再次发送的请求。
补充：
由于X没有计算mac的密钥，即使X可以篡改mac,也无法让篡改后的密文变得合理。
所以只要B计算出mac,发现密文对应的mac与自己算出的不同，就能确认通信过程发生了篡改。
只要使用了消息认证码mac，就能预防通信过程中的篡改行为。
然而这种方法也有缺点。
在使用消息认证码的时候，AB双方都可以对消息进行加密并且算出mac。也就是说，无法证明原来的消息是A生成的还是B生成的。
因此如果A是恶意的，他在发出消息后声称，这条消息是B捏造的，而否认自己的行为。如果B是恶意的，他也可能自己准备一条消息，声称，这是A发给我的消息。
使用mac时，生成的以防和检测的一方持有同样的密钥，所以不能确定mac由哪方生成。
这个问题可以用到数字签名解决。
网友评论