摘要：实际上这一篇和上一篇均可以看作是关于加解密的懒汉入门篇安全加强篇一的后续，只不过侧重点在于安全上。回到上篇结果提到的问题，就是对称加密的安全性要人命，非对称加密的性能非常要人命。元首作为高智商罪犯，这种低级错误是不可能犯的。
为什么标题总是要带上“API安全”关键字呢？因为我想我乐意。
实际上这一篇和上一篇均可以看作是《关于PHP加解密的懒汉入门篇(API安全加强篇一)》》")的后续，只不过侧重点在于安全上。
如果说，你没有看上篇，你一定回去看，不然一定会断篇儿！
为了避免文章陷入过于抽象复杂的理论讲解，所以这次还得借助元首和东线的将领们以及“反派角色”朱可夫同志。
人民好演员列表：男一元首：
男二古德里安：
路人甲曼施坦因：
路人乙冯*博克
“反派”男一
上篇我们知道元首和古德里安翻脸了，然后两个人通过非对称加密技术diss彼此，朱可夫没有私钥只能在路边儿打酱油。
根据事实，我们知道古德里安又重返了东线战场。当初把人撸了下来，现在又得让人去东线救火，反正这脸我是拉不下来，但元首拉的下来。
回到上篇结果提到的问题，就是：对称加密的安全性要人命，非对称加密的性能非常要人命。用我党地话来说就是“不能多快好省”，不符合“可持续发展”，不满足“社会主义主流价值观”。
这篇主要就是说“多快好省”的绿色方案。
让古德里安回东线肯定得是秘密下令的，加密是肯定。但是这个地方一定要值得注意：那就是元首一定得是用古德里安同志的给他公钥进行加密，然后再发送出去，此时这个密文虽然在东线用飞机撒的满地都是，但是只有古德里安同志自己能用藏在自己裤裆里的私钥进行解密后才能得到明文，也就是说这事儿也只有古德里安和元首两个人知道了。
除此之外，还有两种情况，可能爱思考的青年已经考虑到了：
元首是不是可以利用自己的公钥对密文进行加密。但这种做法的最终结果就是这个密文只能用元首的私钥进行解密，但是元首的私钥在元首的裤裆里，别人是无法知道的。元首作为高智商罪犯，这种低级错误是不可能犯的。
元首用自己的私钥对密文进行加密。这个时候就意味着只有持有元首公钥的东线将领们才可以解密这个密文，然而假如元首并不想让其他人知道他天才一般的部署，这种方式就显得有点儿2了。
综上，这种情况下，最正确的方式就是元首利用古德里安的公钥对密文进行加密，然而再撒的满天飞，这会儿只有古德里安能用自己的私钥进行解密。此时，无论是自己家的曼施坦因、冯*博克，还是“反派”的朱可夫，都只能默默当路人甲。
在上述案例中（注意，客户端不要理解为狭义角度的手机客户端！）
元首充当API服务器的角色。
古德里安充当客户端的角色。
曼施坦因、冯*博克充当路人甲客户端角色。
朱可夫充当中间劫持者的角色。
我们回归到现实中，也就是真正搬砖撸代码的现实中。这个时候，如果要对服务器和客户端传输的数据进行非对称加密，那么就得有如下条件：
客户端有自己一对公钥私钥，客户端持有服务器的公钥
服务器有自己一对公钥私钥，服务器持有客户端的公钥
那么问题来了，服务器只有少数一台，客户端成千上万。这会儿摆在搬砖侠们面前的只有两个选择：
客户端的公钥和私钥共用一对，这样服务器只要一个公钥就算是拥有了所有客户端的公钥
客户端的公钥和私钥都是特立独行的，是颜色不一样的烟火。这会儿服务器就苦逼了，必须维护一坨彼此不同的客户端，同时还要建立和不同客户端的对应关系
那么，好了，下面让各位搬砖侠们吃口屎保持一下冷静，我们看看支付宝是怎么做的。当你的系统接入支付宝的时候，支付宝会要求你生成一对你的公私钥，然后私钥你自己藏好了，公钥上传到支付宝（这个过程相当于支付宝有了你的公钥），然后再你上传完你的公钥后，支付宝会返回给你支付宝的公钥。其中当你使用RSA普通版本的时候，所有商户得到的支付宝公钥都是同一个，当你使用RSA2的时候，每个商户收到的支付宝公钥都是不尽相同的。
所以说，怎么做都行，一切都看你选择。
说起支付宝，你们接入的时候都一定看到有个叫做签名验证的功能，我认为这个很重要，是必须值得一提的一件事情。回到元首这里来，我们说元首给古德里安发消息“滚到东线，去库尔斯克棱角部”，正确的做法应该是用古德里安的公钥进行加密，此时该消息只能被古德里安的私钥解密，其他人都只能干瞪眼。如果元首抽风了，用自己的私钥加密了密文，这会儿会是什么情况咧？那就是持有元首公钥的人都可以看到“滚到东线，去库尔斯克棱角部”这条机密消息了，很多人都会发朋友圈或者私聊类似于“听说古德里安要回来了”。其实，用自己私钥解密，然后利用自己公钥解密是一个二逼的行为，但是，这个过程可以用来验签是没有任何问题的。什么是验签？
假如有一天，希姆莱想提前篡位，冒充元首给古德里安发号施令了。此时，古德里安只需要用元首的公钥验证一下命令的签名，一验返回了false，那就说明这坨命令不是来自于元首，这种数据就应该直接扔掉即可！
所以，上面叨逼叨叨逼叨这么久，为的就是得出一个结论，你们理（bei）解（song）一下：
公钥加密，私钥解密
私钥加密，公钥验签
然后我们再往前追溯一下，我们的为什么要用非对称加密？是为了防止对称加密措施密钥的泄漏，而非对称加密不存在密钥泄漏的情况。
但是，非对称加解密的性能以及部署使用方式，非土豪所能及也！那么，有没有办法既能得到鱼，又能得到熊掌咧？
最近开了一个微信公众号:高性能API社区，所有文章都先发这里文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/31423.html
摘要：实际上这一篇和上一篇均可以看作是关于加解密的懒汉入门篇安全加强篇一的后续，只不过侧重点在于安全上。回到上篇结果提到的问题，就是对称加密的安全性要人命，非对称加密的性能非常要人命。元首作为高智商罪犯，这种低级错误是不可能犯的。 为什么标题总是要带上API安全关键字呢？因为我想我乐意。 实际上这一篇和上一篇均可以看作是《关于PHP加解密的懒汉入门篇(API安全加强篇一)》》)的后续，只不过...
摘要：很明显，非对称加密的极大的消耗成了一种瓶颈。其中，利用非对称加密的方案大概就是我前面说的那样，伪代码已经展示过了。 其实，前面两篇翻来覆去只为叨逼叨叨逼叨两件事情： 对称加解密，典型算法有AES、DES、3DES等等 非对称加解密，典型的算法有RSA、DSA、ECDH等等 但是，我知道大家最讨厌在看这种文章的时候冒出来的一坨椭圆曲线、素数、质数等等这样的玩意，反正看也看不懂，理解也...
摘要：由于密钥被暴露了，所以必须换新的密钥，元首这会儿只能走途径告诉古德里安新的密钥，这会儿逗逼的事情来了，如何对密钥进行加密。但是，有一点是值得说明，那就是无论是对称加密还是非对称加密，都顶不住用机器是强行暴力猜解私钥。 懒汉 入门 这两点就足以说明这篇文章不想要着有什么高端大气的技术内容，我跟你讲，全是水。不可能有什么质数素数、椭圆曲线加密、迪菲-赫尔曼什么的，不可能有的。 首先我不...
摘要：这种神奇的算法可以让你服务器和客户端在不传输该对称密钥的情况下就可以通过心有灵犀地方式各自计算出一个对称密钥，而且可以一样，避免了该密钥在网络上流通，而且你可以随意更换，过期时间定为分钟，可谓是狠毒至极我们引入就是为了解决上面的问题。 首先是前段时间我在公众号里被人批（dui）评（gang）了，大概意思就是：你别老整那ECDH又是椭圆又是素数啥的，你就说这玩意实际项目中怎么用就完了，我...
摘要：这种神奇的算法可以让你服务器和客户端在不传输该对称密钥的情况下就可以通过心有灵犀地方式各自计算出一个对称密钥，而且可以一样，避免了该密钥在网络上流通，而且你可以随意更换，过期时间定为分钟，可谓是狠毒至极我们引入就是为了解决上面的问题。 首先是前段时间我在公众号里被人批（dui）评（gang）了，大概意思就是：你别老整那ECDH又是椭圆又是素数啥的，你就说这玩意实际项目中怎么用就完了，我...
阅读 1120·2023-04-26 02:46
阅读 623·2023-04-25 19:38
阅读 638·2021-10-14 09:42
阅读 1234·2021-09-08 09:36
阅读 1353·2019-08-30 15:44
阅读 1318·2019-08-29 17:23
阅读 2236·2019-08-29 15:27
阅读 801·2019-08-29 14:15
