转载大牛所写内容，MAC 消息验证编码的使用和相关概念非我所写，我只是备忘查看，并加注解一些红色字体内容_mac 字体验证 表结构

信息安全基础知识 MAC消息验证码及密钥管理问题

版权声明：本文为博主原创文章，未经博主允许不得转载。 原文地址https://blog.csdn.net/a359680405/article/details/41518685

       假设Alice和Bob共享一个密钥，并采用对称秘钥加/解密法，Alice想给Bob发送一条加密消息，而Bob将会知道它是Alice发的，因为这个约定好的对称共享秘钥只有Alice和Bob两个人知道而已。如果Alice用对称秘钥加密函数加密某条消息数据的话，非常简单，只需将他们的共享密钥作为加密密钥即可，但是如我们所讲的，这种方法并不能提供任何信息未被篡改的真正保证。我们需要一种新的工具，即消息验证码（message authentication codes,MAC）。MAC是一种特殊的摘要算法，但是它在计算的时候还要采用一个密钥，因此HMAC函数同时依赖于所使用的密钥以及要加密的数据信息。实际上MAC通常是根据摘要算法构造得出的。<可以理解为 MAC码值=HMAC函数（共享秘钥,散列函数即摘要算法MD5或SHA等作用于（消息数据）） 用的是一个共享秘钥加密算法,指的是HMAC函数中的秘钥参数是同一个，切记HMAC加密算法是一个单向加密算法函数，HMAC算法函数不可逆，即只能用于加密数据，其不可逆指的是没有对应的解密算法，可以理解为HAMC是一个特殊类型的HASH值函数，只不过这个HASH函数工作需要一个秘钥值而已，这个秘钥值参数一旦指定了，则要想再次使用该函数加密同一个数据要得到相同的HASH散列码结果的话，这个秘钥参数就不能改变。HMAC=HASH MESSAGE AUTHENTICATION CODE=哈希 消息 认证 码之意

MAC散列码值=HMAC函数（共享秘钥,消息数据）

      尽管存在许多基于各种摘要算法来构造MAC的尝试，但是因特网安全团体就一种构造方法达成了一致，它被称做HMAC[Krawzyk1997]，这种方法描述了如何基于满足某种合理假定摘要来创建具有可证明的安全特性的MAC。SSLv3中使用的是一中HMAC的变种，而真正的HMAC在TLS中使用。

      密钥管理的问题 
      Alice 拿到我们的消息，使用共享密钥利用对称秘钥加密算法对正文消息信息进行加密，再在消息数据包中添加一个也是基于该密钥+消息正文利用HMAC(共享秘钥，消息正文)构造的一个 MAC摘要值 并将其发送给 Bob,该MAC码值作为防篡改验证码。她知道只有 Bob 也有该共享密钥能够利用该共享密钥采用对称秘钥解密法解密并阅读这条信息正文，因为 Bob 有解密函数要使用所需要的密钥。类似的，Bob 知道发送这条消息的只有 Alice，因为只有 Alice 才具有创建相应MAC散列值所需要的密钥。这样，Bob 就可以知道是 Alice 发送的信息，而且还未被篡改，因为只有秘钥正确Bob利用HAMC(共享秘钥，前面解密出来的消息正文值)得出来的MAC值才能和Alice发送的Alice在本地未发送前通过HAMC(共享秘钥，未加密的消息正文值)所计算出来的并后续发送给Bob的Mac码是一致的这是HASH函数的天性，同一个消息利用同一个HASH函数计算出来的摘要值必然相等，相等说明消息未被篡改，且此时说明发送方和接受方在HMAC函数中使用了同一个秘钥，而且这个秘钥仅仅在此二人之间共享说明二者的身份认证有效都是合法通信和数据持有参与人。 
      那么，我们就有了所需要的一切，是吗？不。与每个人进行通信，仍然存在与其共享密钥的问题。周围有这么多密钥需要处理非常不方便。<设想一下如果有两个人那么需要交换1个密钥，如果有三个人则需要交换3个密钥，如果有n个人，这时就需要n（n-1）/2个密钥>但更重要的是，这意味着为了进行密钥交换，你实际上必须要与每一个与之通信的人会面。这为通过因特网并不安全，除非你个人已经与供应商碰过面。这里面不便之处就是密钥管理的问题。

      <因为Alice与Bob要共享密钥，但是A和B没有碰过面，那么就要有一方要发送密钥给另一方，但是这个密钥是需要保密的，不能在网络上直接传送。所以就涉及到了密钥的管理问题。有人会说，直接传送能怎么样呢，这就会遭受密钥被攻击者截获（端认证没有被保证），消息被截获并且泄露。MAC=message authentication code  值只能保证消息不被篡改，密钥用来保护消息不被泄露明文，密钥用来对消息进行了加密使得明文得以被加密保护。>