啥叫非对称加密呀?

 

在很久很久以前,天和地还没有分开,有个......

 

等下!串台了!

 

咳咳,我们的主人公是两个人,一位叫塞维尔拉维奇冯部罗丹奥尼尔丁吉利特罗夫斯基,还有一位叫艾亚索菲斯泰洛括沃蓝齐斯米莉倪芭浩汉斯汀。

 

为了方便记忆,简化下,两位好盆友,一个叫小红,一个叫小蓝。

 

世界上最远的距离,不是你离我十万八千里,我却得不到你。而是你就在我隔壁,我家却没网。

 

二人经常通过网络联系,互称知己。谈天论地,虽然二人初中都没有毕业;谈山河日月,即使二人都是标准肥宅;谈女朋友,纵使两个人都是单身贵族。

 

             

 

一天,二人谈到些有趣的隐私问题,哈哈大笑。键盘都笑出了帕金森,屏幕晃出了飞蚊症。

 

突然,小蓝的脑子里猛地出现了一个诡异的笑声。就像有人咬着牙,用力把气从肚子里面顶出来似的。小蓝浑身一抖,不再笑了。

 

二人聊天记录:

蓝:兄弟!

红:What's the matter, man?

蓝:你觉得这真的是我们两个人的对话吗?

红:啥意思?兄弟,我胆小,你表吓我~

蓝:不是,我是说,我们的聊天信息都是通过网络发送的,你说会不会有人在中间截获了我们的消息,一边看一边乐呢?

红:啥!!!你是说除了你我之外,还有人知道我一个七尺男儿喜欢粉红独角兽!!!

蓝:........好吧,虽然例子有点怪,但就是这个意思。

红:........那咋办,我没隐私了都。

 

              

蓝:我有个解决办法。

红:啥?

蓝:我们给信息加密,加密解密的密码只有我们两个知道。每次发送数据前,数据先加密,接收方收到后,再用密码解密。这样就可以得到原来的消息了,而且传输过程中,信息是加密的,即使被人截取,他也看不懂,拿我们没法子。

红:好办法,就这么办!

蓝:嗯嗯,我现在就去写加密解密算法,等会密码发你。

 

(他们口中说的密码,也就是我们熟知的“密钥”。额......请注意,这里念yue,四声,而不是念yao。千万别在别人读成mi yue时笑对面是文盲,等你百度完后就笑不出了。如果你认为百度也是文盲除外。)

                

 

风吹了柳絮,雨浸了嫩芽。总之长叙短说,一周过去了,小红还没有收到小蓝的加密算法,更不用说密钥了。

 

红:兄弟,咋回事!还没写完?

蓝:那倒不是,当天就写完了,只是......

红:只是啥?裤子都脱了,你不说了?

蓝:汗......,有些问题,你别急,听我慢慢说。一开始,我们想要达到的目标是这种:

              

 

红:没错,每次发送消息前,先用只有我们两个人知道的密钥对数据进行加密。发送过去后,在用同样的密钥进行解密,从而拿到数据。因为密钥只有我们两个知道,所以能够达到信息的安全传输。有什么问题?

蓝:......怎样确保,密钥只要我们两个知道?

红:......

 

这的确是个问题,既然消息在传输过程中有可能被人劫持,那告诉对方的密钥又为什么不可以呢。如果密钥被劫持了,别人也可以解密消息,完全达不到开始的目的了。

 

红:我去找你?我们面对面的说密钥,这样就能确保只有我们两个知道了。

蓝:是可以解决问题。但还有新的问题,我还有美国,新加坡,马来西亚,泰国......各国的朋友。我想和他们联系,还得先环游世界面对面和他们约定密钥。如果麻烦到这种程度,那信息就让别人劫持去算了。

红:......

 

小红再一次陷入沉默。

 

蓝:不仅如此,还有个问题。我们两个人联系,需要一个只有我们两个人知道的密钥,当我和小绿联系的时候,我就会又有一个只有我和小绿知道的密钥。你和小绿联系时也是这样,我们三个人每个人保留着两把密钥。当我们的朋友圈变大后,每个人手里都要有和其他人数相同的密钥个数。如果朋友圈里有N个人,那整个朋友圈需要保存N * (N - 1)个密钥,对于密钥的分配和管理还是个不小的问题呢。   

                 

 

加密密钥同时也被用作解密密钥,这种加密技术在密码学中叫做对称加密技术(或者传统加密技术)。通过二人的对话,我们可发现了对称加密技术的缺点:

1.首次通信协商共同密钥时不安全。

2.总密钥数量较大时难以管理。

 

说了对称加密,非对称加密的概念也就呼之欲出了吧,就是加密密钥和解密密钥不同的加密技术。请继续收看二位青年的故事。

 

从那之后,红蓝二人再也没有在网络上联系过。大约过了两周后,蓝主动联系红。

蓝:hey, 哥们,我知道怎么办了!

红:啥?啥怎么办?

蓝:你喝假酒了吗!当然是怎样安全传输消息啦!

红:真的!啥办法?

蓝:加密!

红:......不还是一样吗,我们已经否定这种方案了呀。

蓝:这次不一样,你听我说......

bla,bla,bla............

小红听后两眼放光:六啊,这你都能想出来!

 

小蓝的解释大概是这样的:

每个人手中拿着两个密钥,其中一个是对外公开的,任何人都知道,称之为公钥。还有一个是只有自己知道的密钥,称之为私钥。用公钥加密的信息,只能通过私钥解密出来。反过来,用私钥加密的消息,只能用对应的公钥解密出来。当小红需要向小蓝发消息时,先从小蓝那拿到“公钥”,用小蓝的“公钥”对数据进行加密,然后发送给小蓝。小蓝拿到数据后,用自己的“私钥”对数据进行解密,得到消息。这种办法从始至终都未向他人公开过自己的私钥,包括发数据的人,而能够解密公钥的,也只有自己的私钥,完美的想法。

 

反过来相同,小蓝先拿到小红的公钥,对数据进行加密后返回,小红拿自己私钥解密得到数据。(因为例子中公钥的功能是对数据加密,所以用一把小锁来指代,形象些~)

 

但是不久后,红蓝二人又有了新的问题——非对称加密对数据操作过于复杂,处理时间太长,这大大降低了传输的效率。不过很好解决,既然我们可以保证安全传输了,那也就是我们开头说的对称加密的密钥也就可以通过非对称加密来传输,密钥安全到达后,之后的消息发送就可以回头使用对称加密的技术啦。

 

也就是说,我们首次通信用非对称加密传送密钥,之后通过密钥使用对称加密技术进行联系,完美的优化。

 

有人说,公钥加密的数据,只能靠自己的私钥解密,这种技术实现起来真的容易吗?其实,如果大家对“欧拉定理”有些许的了解,就知道,这不是想象中那么不可能的事情。正推没问题,如果想要反推私钥的话,难度是不能想象的了。

 

对称加密技术的弊端得到了解决,首先,私钥不会公开,也不需要传输,保证了他的安全性。其次,无论朋友圈怎样变大,每个人只需要两个密钥——公钥和私钥。

 

其实到这里,非对称加密的基本原理也就说完了。如果意犹未尽,那可以继续往下看红蓝二人的不服人生,来看下目前效果无可挑剔的非对称加密有何不妥之处。

 

 

总之生活就是这样好吧,每当你觉得你战胜了它,沾沾自喜的时候。它就会跳出来对你说:“刚才是逗你玩的,现在来真的喽~”。

 

虽然你很不爽它可以控制一切的能力,但它是因人而生的。再不堪它的调戏,我们也要摆好姿态,回首怼它:“我承认我玩不过你,但是,你过来啊!”

 

这次的玩法是这样的:

我们上面的例子里有个黑衣人,蒙着面,罩着头,很流弊的样子。就是一会儿哈哈大笑,一会儿黑人问号的那个家伙。看他是怎样玩的。

 

你不是弄了个非对称加密吗,好啊,看我怎么用你的技术,反破你的技术。啥叫以牙还牙,啥叫聪明反被聪明误。

 

所有人都有了自己的公钥和私钥,黑衣人也不例外。在一次红给蓝发消息的过程中,黑哥秀了一把。

 

首先,红从蓝那里拿蓝的公钥,中间被黑哥拦截了下来,然后黑哥将自己的公钥发给了红,蓝的公钥被留了下来。(不留也没事,毕竟公钥是公开的,黑哥只是为了蓝的公钥到不了红手中。)

 

这里问题就来了,红拿到的是黑的公钥,并用黑的公钥对数据进行了加密,之后传了回去。

 

黑再次劫持数据,用自己的私钥解了密。小蓝那边怎么办呢?数据反正我已经拿到了,我再用蓝的公钥对数据进行加密,发给蓝。那这两个小傻瓜就会被蒙在鼓里了,自己的数据泄露了,还一副什么事情都没有发生的样子。

 

这套操作神吧!


              

魔高一尺,道高一丈。现在的问题变成了——我怎样确定拿到的公钥是我想拿的。

 

知道怎么解决吗?别急慢慢听我给你说。

 

依旧是那个例子,小蓝给小红发送自己的公钥。

 

首先,小蓝将自己的公钥和自己的个人信息合并,通过Hash算法生成一段消息摘要。

 

Hash算法中,最被我们熟知的要数MD5吧,简单介绍下,如果原文章被改动了一小部分,哪怕是一个标点符号,再用同样的Hash算法推导出的结果也会发生翻天覆地地变化。通过结果的比较,我们就知道数据是否被改动过。

 

还没完,这期间,我们需要引入个第三方——CA(Certificate Authority)证书颁发机构。它充当认证中心的作用,在我们之间做裁判。上面我生成的消息摘要,请CA帮忙用它的私钥对数据进行加密,生成的东西我们叫“数字签名”。

 

     

 

还有还有,我们再把最开始的公钥及个人信息 和 刚刚生成的数字签名合并,合并之后的东西我们叫做数字证书。                                                                                 

然后把数字证书发给红,红拿到数据后。执行两步操作:

 

1.用CA的公钥解密数字签名,得到消息摘要。

2.用蓝同样的Hash算法处理公钥及个人信息,生成消息摘要。

 

通过比较两个消息摘要是否相同,来判断数据有没有被别人动过手脚。(妙吗~)

 

                       

 

这里可能还有个问题,要疯了是不是,怎么那么多问题。

 

怎样确定你拿到的CA的公钥是CA的?

 

!!!!!!!!!!!!问题竟然回到了初始点。一个鸡生蛋,蛋生鸡的问题!!!

 

其实,CA也有自己的证书证明自己的身份,然后证明CA身份的上层CA也有自己的证书,证明证明CA身份的CA的CA也有自己证书......没尽头吗!!!

 

有,食物链的终端是“操作系统/浏览器”预置的顶层CA证书,就默认你信任他们了。

 

(你如果连操作系统都不信的话,那......计算机拯救不了你了~)

 

(后记:关于数字签名的那部分,也可以通过自己的私钥对明文进行加密,接收方用发送方的公钥解密。之后再进行对比,如果有差异,就认为数据可能中途被修改了。)

 

打完收工,结束。

 

(撰写不妥之处,欢迎点出。)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章