数字签名，私匙与公匙

[TOC]
最近，总是碰到公匙和私匙的概念，通过下面的应用情景举例，可以很好的理解公匙和私匙的前世今生。

概述

我制作了两把钥匙，一把公匙，一把私匙。私匙我自己保留，公匙送给我的好朋友们。

场景一：

小杨单打写信给好朋友科比，落款为我自己的名字小杨单打。
评述：这封信在途中可能被他人窃取并修改内容，于是小杨单打将内容用私匙加密。

场景二：

小杨单打用私匙将内容加密，科比用公匙解密，看到了落款人是小杨单打。
评述：很多人都有公匙，但是他们没有私匙，所以即使可以看到信的内容，也无法修改内容。

场景三：

詹姆斯为了离间我和科比的关系，自己制作了私匙和公匙，并用新制造的公匙换掉了
科比那儿原有的公匙，詹姆斯然后用写了一封信，落款是小杨单打。用私匙加密后寄给科比，科比
不知道自己的公匙被换了，以为这封信还是小杨单打写的。
评述：为了解决这问题，小杨单打于是决定每次都把自己的公匙告诉全世界，这样就伪造不了，但
是这样十分麻烦，詹姆斯随时会替换，科比只能每次收到信都去小杨单打的服务器更新一次自己的
公匙，显然这样太麻烦了，因为科比的好友太多了，有几亿人，不可能记下所有几亿人的ip地
址，于是出现了专门的认证机构。

场景四：

公共认证中心CA，小杨单打将自己的信息和公匙交给CA，CA用自己的私匙对其加密，然后
生成数字证书交给小杨单打，小杨单打写信给科比，将数字证书放在前面，这样科比收到信息后只需要拿
到正确的CA公匙就能拿到小杨单打的公匙。

真实应用https协议：

服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户
端，客户端浏览器中的“证书管理器”有受信任根证书颁发机构（CA）列表，客户端会根据这张
列表查找CA公匙（这里CA的公匙也可能被替换，此时系统安全已经沦陷。。。）。找到公匙后，
解读数字证书的信息，若解读到的信息记录的网址和浏览的网址不一致，说明浏览的网站用了别
人的证书，浏览器会发出警告。还有可能在信任列表中找不到公匙，说明该证书是由其他CA颁发
的，浏览器会发出另外一种警告。

场景五：

小杨单打用hash函数作用原文，得到摘要，将摘要和原文一起用私匙加密发给科比，科比再
收到后，用公匙解密，用hash函数作用原文，得到摘要与原摘要比对，可以知道信件信息没有被
更改（完整性）。（CA过程已省略）。这是有必要的，否则会出现场景六。

场景六：

詹姆斯用将小杨单打寄出的信件拦截，随意修改内容后发给科比，虽然他不知道修改后的语义（破坏性
工作），但是科比收到后，原文的语义发生了不可预料的变化。

参考原文：http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html