由于我们逐步在Kubernetes安全系列文章中分析出来要对敏感数据进行加密，而Kubernetes本身在Secret中对数据只是做了base64的编码，因此在Master node的内存中，以及etcd中，数据都基本以明文方式存储，我们都认可这是非常不安全的。
因此安全概述的第二篇文章，笔者打算围绕非对称加密来展开，因为对称加密从安全的角度有诸多隐患，比如秘钥如何安全存储的问题，秘钥如何定期更新的问题，以及如何保证秘钥安全的问题，逐步就会演变成先有鸡还是先有蛋的问题。而对称加密针对这些问题给出了解决方案。
在介绍对称加密之前，我们先来聊点轻松的，读者可以考虑一下这个问题：如何设计一套加密算法？这可不是什么脑经急转弯之类的问题，而是为了让大家能够透过现象看到冰山下的本质问题。从笔者有限的知识的角度，其实设计加密算法本身并不复杂，但是设计一套安全的加密算法会非常的困难。虽然笔者没有那个能力去设计一套足够安全的加密算法，但是对这个话题的探讨可以有助于我们在选择合适加密算法的时候，有更好的视角。
选择总是困难的，特别是从一堆优秀的选项中选择一个好的算法来解决我们的业务问题。中国人讲以史为鉴，古人智慧的结晶放到当代依然掷地有声。这很大一部分原因是人类在慢慢的历史长河中，即便是外部的世界发生的巨大的变化，技术每年指数级发展，但人类自身的变化不大，特别是智商的增量可以说是微乎其微。我觉得这其实回答了为啥我们日常的工作和生活，经验主义占据主流。对于安全来说，研究过去失败的数据泄露案例，系统被攻破的安全案例依然是我们解决从多个备选算法中选择“可信和安全”选项的重要依据。
时光飞逝，转眼间几百年就过去了，历史已经埋葬了很多女王和领主，文明的发展促进了科技的进步（反过来好像也成立），今天我们获取信息的方式已经发生巨变。我们有更强的服务器，我们有更快的网络，我们也有无处不在的连接，但道高一尺魔高一丈依然存在，技术的发展的反面就是恶意攻击者手上的工具更加强大了，更加无孔不入了。
他们可能出现在任何地方：我们在星巴克办公连接了公共的WIFI，连接各个设备的路由器，以及对外提供服务的各种前台和后台服务器，运行数据库的数据库服务器，以及文件服务器等。并且随着科技的进步，这些恶意攻击者可以在相同时间内窃取到更多我们的机密信息。比如钓鱼网站，当我们请求某个网站（假冒）的时候，http请求被路由到恶意的假冒网站，不光请求报文可能被纳秒级别复制到数据库，并且请求可能会被修改，这一切发生的如此之快我们作为用户可能都感觉不到。
加密技术的发展和国家安全的需求是强相关的，特别是两次世界大战直接促进了加密技术的繁冗。战争结束后，被用作军事用途的加密技术逐步渗透的民用领域，密码技术逐渐从少数涉密的政府工作人员参与，逐步开发人大学和科研团体，现在密码的算法可以被公开的讨论和学习。这背后的原因是：人们逐步认识到，提升算法的安全性考闭门造车根本不现实，而应该将算法公开出来让大家学习和讨论，并提供反馈建议。笔者这里想强调的是，加密的安全性不是考算法来保证，而是要靠“秘钥”来保证，算法是公开的，而秘钥是通信双方需要协商并达成共识的。
注：算法本身有很多种方式被“攻破”，比如：1，秘钥被泄漏；2，暴力破解，通过穷举的方式通过除秘钥之外的手段解密密文；3，在没有秘钥的情况下，可以通过观察密文的模式，来猜测和验证明文，逐步缩小尝试的范围。
而保证秘钥安全这个事情，就是著名的柯克霍夫原理，加密系统的安全，取决于秘钥的安全，而不是算法的安全。我们以AES算法为例，这个算法源自于美国国家标准与技术研究院（NIST）举办的加密安全竞赛，通过将全球的密码学专家，爱好者，数学天才组织在一起，逐步的选出大家都认可的“安全”的算法，而AES算法就来自于这个挑战赛的优胜者。
最后，我们总结一下柯克霍夫原则，笔者认为这是理解安全的根本：对于加密算法来说，不要愚蠢的认为可以通过对恶意攻击者隐藏算法来实现信息通信安全，因为算法信息最终会被公开；我们应该从一开始就开放算法，让恶意攻击者帮我们验证算法的缺陷，来完善我们的算法。
读者可能会问，如果对敌人开放算法，那我们的主角爱丽丝女王和鲍勃领主如何能安全的八卦呢？背后的原理其实不难理解，秘钥才是这场安全八卦的核心。我们通过秘钥来对数据进行加密，那么线路上传输的就是密文，即便是恶意攻击者截获了密文，在可观的时间范围内，将密文解密的成本太高，几乎不太现实。这就是笔者一直反复在各种场合强调的：我们提到的所有加密算法，其实都可以被公开学习研究和使用；而保障机密性的核心是算法使用的秘钥，这才是我们作为机密管理的主角。
好了，有了上边的这些铺垫之后，我们来看看本篇文章的要介绍的第二个加密算法：非对称加密。
我们接安全概述（1），女王和领主有了对称加密的加持，开心的在王国中各种八卦，但是有一天，斯塔克领主屁股上有个痣的八卦信息在王国中不胫而走，但是女王只把这个信息告诉了鲍勃领主了啊。女王百思不得其解，因为她非常信任领主鲍勃，因此女王判断是因为她和领主鲍勃使用的秘钥可能被泄漏了，因此女王赶紧和鲍勃领主来了一次线下聚会，更新了秘钥。但聪明的女王发现这不可持续啊，她不光和领主鲍勃维护有一个私钥，还和斯塔克领主维持的另外一个私钥，以及和其他100多个大大小小的城堡主有相同的场景，如果要这么干，哪里有时间八卦，光线下约会更新秘钥都占满了女王繁忙的闲暇时间。
女王爱丽斯遇到的问题和我们日常生活中遇到的问题很相似，考虑到数据安全，国家已经要求所有网站都使用https协议，而https协议就需要双方针对某个事情达成共识，如果像女王这样，我们在访问某个网站之前先要和网站来个线下相会，那肯定不行。女王需要更好的加密算法来继续开心的八卦，而几百年后的我们也需要更好的办法来安全的访问网站。
大约在1970年底，一种被称之为“非对称加密”或者“公私私钥加密”的算法被发明，而在此之前，历史上很长一段时间，这个问题并没有什么好的解决办法，这个问题也被定义为哪个年代的世纪难题啊。非对称加密简直就是人如其名啊，和对称加密最大的不同是：非对称加密使用不同的秘钥来分别进行加密和解密。理解非对称加密算法的核心是理解如何解决秘钥交换的问题，请继续阅读。
第一个被公开发表的key（秘钥）交换算法叫DH（Diffie-Hellman）秘钥交换算法，这个算法要解决的核心问题就是在两个通信的参与者之间建立”共识“（也就是秘钥），然后这个工时间就可以被用作对称加密的秘钥等等。由于DH算法的原理非常的数学化，为了让读者的体验更好，我们来类比一下，核心是让大家理解这个”共识“（key，秘钥，笔者后边会在这三个词之间互换）如何被建立。
和很多算法的工作原理类似，采用DH算法达成共识之前，参与者之间必须已经有某些大家都知道的”信息“，比如说爱丽斯女王和鲍勃领主都知道斯塔克领主屁股上有个痣，我们用黑色的方块表示（这就是参与者之间持有的共识信息）。接着爱丽斯女王和领主鲍勃会选择一个随机数（女王的随机数用黑色的三角形△表示，领主的随机数用黑色的星星✨表示），这些随机数是领主和女王私钥，因此必须保证私密并安全保存，如下图所示：
有了私钥之后，爱丽斯女王和领主鲍勃把私钥和黑色的方块（两人的共识）组合起来，结果就是两人分别形成了一个特殊的形状，如下图所示：
这个组合后特殊的形状我们叫公钥，公钥可以在参与者之间共享。从上图笔者希望读者能理解非对称加密也叫”公钥"加密算法的原因，因为算法需要1对秘钥：一个私钥和一个公钥。通信的参与者之间有了对方的公钥之后，事情就变得容易了（八卦变得容易了），爱丽斯女王将鲍勃领主的公钥和自己的私钥组合，鲍勃领主将爱丽斯女王的公钥和自己的私钥组合，结果是两边的形状完全一致，如下图所示：
通信的参与者有了共享的信息后，就可以基于不同的业务场景来使用这个共享的秘钥信息，比如在对称加密的场景下。笔者需要特别提醒大家的是：DH算法在实际场景中非常的不安全，特别是和我们会在后边介绍RSA算法比较起来。具体来说，由于爱丽斯女王接受任意的公钥作为领主鲍勃的公钥使用，因此理论上我（云攀）可以把鲍勃领主的公钥替换成我的公钥，这样我就可以截获爱丽斯女王发给领主鲍勃的八卦信息。
我们把这种安全风险称作是：MITM（man-in-the-middle）攻击，也叫中间人攻击。要预防这种攻击，就需要有一种机制能够证明公钥是鲍勃的，这看起来又回到了先有鸡还是先有蛋的场景。因为我们引入DH算法的目的是为了解决如何在领主和女王之间达成某种“共识”，现在问题变成了女王需要知道自己受到的公钥是领主的公钥，女王如何能认识呢？其实做不到，因此DH算法解决的是如何共享秘钥的这个问题，并没有解决这个公钥一定是领主鲍勃的这样的问题。
不用担心，我们会在后续的文章中带着大家解决这个问题。好了，今天的文章就这么多了。可能读者会觉得安全相关的文章都很短小精悍，其实笔者为了大家的学习那是操碎了心啊，全本本身就是个复杂的话题，几千字的文章我相信第一没有人看，第二很容易就失去焦点，咱还是一点一点来，千里之行始于足下。
下一篇文章我们来介绍RSA算法，一种在Kubernetes平台上，以及很多场景下被广泛使用的加密算法，敬请期待！
