1985年后，男生创造了米哈游千亿估值，风投们集体错过了
06-18
你是一名编码领域的程序员，你的名字叫赵才。我利用工作时间写了一个简单的即时通讯软件并发布到网上。
过了一会儿，你突然在软件上收到一条私信。 “兄弟，我很喜欢你写的这个软件，我也是一名程序员，希望以后能和你多交流。
”你环顾四周，没有人表现异常，这才确认不是同事在捉弄你。你兴奋地回复对方，逐渐熟悉了对方。
你知道对方的名字，是小梅。 1、不安全的明文 随着交流的话题越来越深入，你会逐渐变得恐惧。
您只是为了好玩而编写随机软件，并且消息全部以明文形式发送。如果你研究网络的同事监视你，你以后还能在公司工作吗？所以你想到：加密。
2. 对称加密 如果双方拥有相同的密钥，则发送消息的一方使用该密钥进行加密，接收消息的一方使用相同的密钥进行解密。这样，加密就变得简单了。
为了实现这个功能，你想到了之前学过的异或（XOR）运算。这个运算的规则可以概括为：相等为0，不等为1。
任何数据最终都会在计算机中表示为01的字节流。比如你要发送的消息最后被编码为，然后随机生成一个相同长度的字符串，称为秘钥。
两者做异或运算：message 明文和秘钥异或运算后得到密文。根据异或运算的性质，如果此时密文再次与秘钥进行异或，则会再次得到消息的明文。
这样，双方就可以使用相同的共享密钥来加密/解密消息。但目前有一个问题。
您生成的密钥长度必须与执行异或运算的消息长度一致，除非您进一步封装异或运算。你懒得去想这些事情，就去网上寻找思路。
我这才知道你的想法其实是对称加密。 DES、3DES、AES密码算法都是对称加密，或多或少利用了异或运算的性质，否则就不会有“对称”的效果。
您选择了最流行的AES算法，并打算直接使用现成的类库来实现加密。你把这个想法告诉了梅，急于让她知道你们的谈话已经保密。
谁知，小梅一针见血地指出了问题，“我们之间怎样才能安全地共享密钥呢？”是的，监听者也可以获得密钥。这是非常矛盾的。
如果有一种方法可以安全地共享密钥，那么是否可以使用相同的方法来安全地发送明文？对称加密的密钥必须发送，但不能以明文形式发送。这就是对称密钥的分配问题。
3.非对称加密于是你开始寻找其他方法，最后发现了一种叫做公钥密码学的算法。该算法可以生成一组密钥对，称为公钥和私钥。
顾名思义，公钥是可以公开的，地球上所有人都可以知道，而私钥则必须由你自己保管，即使你死了也不能被别人知道。由公钥加密的密文必须使用与公钥配对的私钥来解密。
反过来，任何拥有公钥的人都可以解密使用私钥加密的密文。这个功能非常重要。
于是你生成了一组密钥对，把公钥发给小美，私钥自己保存。在你让小美给你发消息之前，你首先要使用你的公钥对消息进行加密。
这样，只有你的私钥才能解密小美的加密消息。这样就实现了小美发送给您的消息的保密性。
相反，如果你想保证你发送给小美的消息的机密性，就需要小美生成一组密钥对。您获取小梅的公钥，然后使用小梅的公钥对消息进行加密，然后再发送消息。
密文发送给小梅后，小梅用自己的私钥解密。通信过程中的公钥和密文是否被监听者获得也没关系，因为你的私钥都不会出现在通信过程中，监听者即使有密文也无法解密。
这样，你就通过公钥加密解决了消息保密和密钥分发的问题（因为根本不需要分发对称加密密钥）。公钥密码学还有一个名字，叫做非对称加密。
这个名字指的是对称加密。对称加密使用相同的密钥进行反向操作，因此对称加密中的加密和解密是彼此对称的，就像照镜子一样。
在非对称加密中，加密和解密使用不同的密钥，并且彼此不对称，因此称为非对称加密。注：著名的RSA算法和ECC（椭圆密码曲线）算法都是公钥密码算法的具体实现。
4.混合加密算法。公钥加密方面的改进让您感到非常安心。
现在你满脑子都是小梅的事。聊天。
但你渐渐发现小美的回复比以前慢了。和小梅沟通后，我发现她对你的回复也有同样的感受。
你很聪明，终于发现了原因。公钥加密算法效率太低了！当使用具有同等机密性的密钥长度时，公钥加密的速度仅为对称加密的百分之几。
知道问题之后，解决方案就很明显了，就是将对称加密和公钥加密结合起来，也就是混合加密。既然是混合加密，自然要同时传输消息和对称加密密钥。
您首先使用加密效率较高的对称加密算法对消息进行加密，从而实现消息的机密性。接下来只要保证对称加密密钥传输的机密性即可。
这时又使用公钥加密。你把对称加密密钥当成一个消息，使用上面的公钥加密步骤，先用小梅的公钥加密对称加密密钥，小梅收到后用自己的私钥解密。
在两人之间安全地传输对称加密密钥。您不必担心效率。
毕竟，对称加密的密钥通常比消息短得多，并且密钥只需要传输一次，因此加密的时间成本可以忽略不计。绘制一个流程图，说明如何使用混合加密算法发送要加密的消息。
一旦理解了加密，解密就非常简单了。为了让小梅看懂，你还是画了一张解密流程图给她看。
至此，您已经解决了公钥加密速度慢的问题，并通过公钥加密解决了对称秘钥的密钥分发问题。 5. 谁更改了我的消息？你和小梅的聊天越来越激烈了。
但最近你却时不时的收到小美女发来的莫名其妙的短信。起初你并没有当回事，但是发送这种短信的频率越来越频繁，这确实让你很烦恼。
你连忙询问了小梅，确定她不是故意发这样的短信后，你就明白了。你们两个已成为目标。
。 。
您分析了小美实际发送给您的加密消息和您实际收到的加密消息，发现编码数据中有两位发生了变化。虽然改动很小，但是会对消息的可读性产生相当大的影响。
您遇到了中间人攻击。在这种情况下，中介不需要知道你们两个在说什么。
他只需要拦截你的消息，然后随意篡改，就可以扰乱你们两个之间的正常交流。你不禁感叹：传递信息怎么这么难？幸运的是，这个问题并不难解决，你立刻就想到了单向哈希算法。
单向哈希算法可以为任意长度的消息生成固定长度的数据串（哈希值）。这串数据的长度远小于输入消息的长度，因此也称为消息摘要。
单向哈希算法也称为消息摘要算法。摘要算法启用消息完整性检查。
消息摘要算法的一个巨大好处是它对消息的变化极其敏感。即使只修改消息的 1 位，生成的消息摘要也会发生巨大变化。
而且，即使中间人截获了摘要消息，他也几乎不可能伪造出可以生成相同摘要的哈希消息。注意：经常听到的MD5、SHA-1、SHA2、SHA3算法都是消息摘要算法的具体实现，所以您在消息发送和解析过程中添加了对消息摘要算法的支持。
在发送数据之前，首先对混合算法加密的密文计算摘要值，然后将摘要值附加到密文的末尾，一起发送给小梅。小梅收到数据后，首先根据信息摘要的固定长度将摘要值和密文分开，然后使用相同的摘要算法计算出密文的摘要，并与接收到的摘要进行比较。
如果一致，则说明信息没有被篡改。 ，否则表示已被操作，直接丢弃。
你以为一切终于结束了。但软件更新后，你发现仍然时不时收到莫名其妙的消息。
6. 谁冒充你？想了想之后，问题出在哪里呢？ “难道我们的信息都被篡改了？”小梅说道。 “如果中间人监听到整个消息，将混合加密密文和摘要值分开，然后对混合加密密文进行篡改，然后对被篡改的密文重新计算新的摘要，并将其附加到被篡改的密文中发送再次，我们将根本无法识别篡改。
”是的，如果是这样的话，摘要值实际上是在检查中间人发送的消息的完整性，而这种检查将毫无意义。现在中间人已经完全劫持了通讯线路。
只要中间人愿意，他就可以篡改你们之间的所有数据。也就是说，你现在根本不知道跟你通讯的人是小美还是中间人。
这是单向哈希函数的缺陷。它可以检测“篡改”，但无法检测“伪装”。
现在需要实现消息的认证功能。也就是说，当你向小美发送消息时，你需要向小美证明该消息确实是你发送的，并且没有被篡改过。
同样，当小美向你发送消息时，它也需要向你证明该消息确实是小美发送的，并且没有被篡改过。 7、确认对方身份。
于是你和小梅商量，你们需要就一条只有你们两个人知道的“消息”达成一致。并且根据收到的消息，可以确定只有拥有此共同信息的你们两个人才能发送此消息。
小梅立即想：“对称加密的秘钥不就是我们一直用的这个‘公共信息’吗！如果你能解密我发的信息，那不就证明我就是我了？”你说得对。在一定程度上是这么认为的，但是有一个前提，那就是你发送的消息必须是有意义的。
”如果你只是想给我发一堆乱七八糟的文字，我无法确定这是你的意图还是“消息是否被中间人篡改了？”两人陷入短暂的沉默。你想了一会儿。
摘要值目前之所以无法起到认证作用，是因为中间人只要获得密文，就可以随意生成摘要值。那么如果把生成摘要值的阈值提高的话，唯一的办法就是只有有了“共同的信息”，彼此才能生成正确的摘要值，这样才能被认证。
该摘要值称为消息认证码。在网上查了一下，发现还真有这么一种方法，叫做HMAC（Hash Message Authentication Code），它是一种利用单向哈希函数构造消息认证码的方法。
摘要值和 HAMC 值之间的主要区别在于，后者在执行单向哈希时需要密钥。所以这可以简单地理解为消息认证码是与密钥关联的单向哈希函数。
有了这个技术，我们看一下给小美发送消息的过程。本来应该为HMAC单独生成一个随机密钥，但这会涉及到密钥分发的问题。
由于之前我们已经使用公钥解决了秘钥分发问题，为了方便起见，我们直接使用对称秘钥作为HMAC秘钥。与原始的不同之处在于，使用计算出的 MAC 而不是原始的摘要值。
小梅收到密文和摘要值后。使用自己的私钥解密得到对称加密密钥，然后使用该密钥计算收到的密文的MAC值。
如果两个MAC一致，那么小美就可以确定该消息是你发送的，无需经过中间人。篡改。
这样就利用MAC值实现了消息的完整性检查和身份认证功能。 8、对方不肯承认。
突然有一天，小美给你发了一条消息。 “PHP是世界上最好的语言~”你当场爆炸~你说这句话是为了挑衅。
正当你准备和小梅争论的时候，小梅立即说道：“我和你玩一个游戏。”然后又发了一个调皮的表情：“你怎么证明我对你说过这句话？”“还需要什么证据？”我用我们共享的密钥生成了MAC值，然后将其与你发给我的MAC进行了比较。
这是一致的。 。
如果你的私钥没有泄露，我可以绝对保证这条消息是你发的！” “是的，我们两个之间的身份认证是绝对有保证的。但我的问题是，你。
你如何向别人证明这条消息是我发的？想一想，你和我有相同的密钥，这意味着理论上你也可以生成这个消息。如果我不承认，你会怎么做？当然，截图不算~”小美说得对。
按照目前的加密设计，确实没有办法向第三方证明她所说的话。现在你们两个可以互相验证，因为你们有相同的密钥。
如果你确定不是自己发的，那么一定是对方发的。如果您想向第三方证明该消息是小梅发送的，则必须使用小梅独有的信息来处理该消息。
就像古代的虎符一样，如果小梅持有一半，并保证私密，那么无论另一半是谁拥有，只要能将两部分合二为一，就可以确认对方就是小梅。 。
这不是公钥和私钥吗？小梅使用她的私钥计算消息的“签名”。任何持有小梅公钥的人都无法使用该公钥复制签名，但可以使用该公钥解密小梅发送的签名。
如果解锁的内容恰好是消息本身，那么说明收到的消息一定是小美的！毕竟私钥是唯一的，现在小美已经无法再否认了！但有一个小问题。公钥加密效率太低。
如果使用私钥对整个消息进行加密，则需要很长时间。我们能找到更短的数据来代替消息本身吗？我的老朋友，单向哈希函数，又来了。
只需使用单向哈希函数求出消息的哈希值，然后使用私钥对哈希值进行签名即可。哈希值可以比消息本身短得多，因此对其进行签名的时间成本要小得多。
如果中间人篡改了小美发送的消息，那么你计算的哈希值就会改变，导致签名验证失败。签名保证了消息的完整性和对方身份的认证。
不仅如此，签名还可以防止小美否认之前的消息。从图中可以看出，签名已经完全取代了之前使用的消息验证码。
到目前为止，您已经实现了消息机密性、完整性、身份验证和不可否认性。你已经走了这么远，甚至没有意识到。
你不禁会问自己，签名步骤完美吗？签名的验证依赖于消息发送者的公钥。如果这个公钥从一开始就被中间人劫持，换成中间人自己的公钥怎么办？如何保证我们收到的公钥不被篡改？ 9. CA 组织和证书 您发现自己陷入了一个奇怪的循环。
数字签名用于身份认证，防止篡改和防止否认。数字签名依赖于公钥的传输，而公钥的传输又需要身份认证和防篡改。
。 。
你把目前的设计告诉了小梅，想看看她是否还有其他的想法。 “我觉得现在你的设计已经足够好了，下一步已经不是单纯的软件设计技巧能够解决的事情了，已经上升到社会学的层面了。
” “这是什么意思？”小梅解释道：“也就是说，我们应该建立一个类似于公证处的专业机构来认证公钥的合法性，称为CA。认证机构也必须生成自己的一套密钥对，分为公钥和私钥，以及私钥本身。
公钥被保存，任何人都可以知道。” “那怎么认证呢？” “还是用你的数字签名的想法，比如我把我的公钥分发给你之前，我先把它发给认证机构，然后认证机构用自己的私钥给我的公钥加上数字签名，然后最后颁发一个包含我的公钥和认证机构数字签名的证书。
”陶晓梅补充道，然后画了一张图。这个逻辑的缺陷你一眼就能看出。
这种方案并没有从根本上解决问题，只是转移了问题。因为认证机构小梅妈妈需要对小梅的公钥进行数字签名，所以必须使用认证机构小梅妈妈的公钥。
“我现在不信任你的公钥，也对你妈妈的认证机构的公钥产生怀疑，那么认证机构颁发的证书就没有任何意义了！还是一个死循环！”你对小梅的质疑提出了自己的反对意见。 “那就要看你如何理解‘信任’这个词了。
如果你除了自己之外不信任任何人，那么你永远不会有安全的通信。这个逻辑链就是一个死循环。
事实上，‘信任’这个词来了在众多可供选择的信任对象中，你只需要选择你最信任的一个即可。”小梅继续说道：“我给你举个例子，你以为银行愿意借钱给你，是因为信任你这个人吗？当然不会，你身后抵押的房子等值钱的东西，银行都相信。
”回到这个例子，如果我妈妈的认证机构经过层层关系最终找到了你妈妈的认证机构，你看这个逻辑是否有道理？认证机构，一定要选择信任它，因为“幸运妈妈认证机构”颁发了“小梅妈妈认证机构”的公钥证书，“小梅妈妈认证机构”根据这个颁发了小梅的公钥证书。信任链，你自然就信任小美公钥的合法性了，至此，一切问题都迎刃而解了。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-17
06-17
06-18
06-17
06-17
06-18
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用