加密的世界

概要

  数论、加密算法、密码应用，这三个到底是哪个需求先出现的考究无意义。但是数论是加密算法的基础，加密算法又是密码应用的基础。我们可以从数论来切入应用，也可以从应用来找到实现的数论支持。前者是数学系的思路，后者是正常人的思路。我是正常人。

  应用上主要有三个：摘要、加密、认证。

  摘要是对一大段数据生成一个长度较短的数据，这个数据能够代表这一大段数据而一般不会重复。主要用途在下载或传输文件（计算对比双方的摘要是否一样来判断是否出现错误）、密码验证（系统里不存储真实的密码，而是存储密码摘要，登录是计算和对比摘要的过程）。通过摘要并不能复原出原数据，但能代表。涉及到的数论是哈希算法。

  加密是对一段易读数据进行数学变换，变换为另一段表面无意义的数据。加密用来在不安全的信道上进行通信。涉及到的数论是三种各不相同的数论难题：即整数分解、离散对数以及椭圆曲线上的离散对数。加密之所以不怕被人读出来，是因为别人读不出来，别人为什么读不出来就是因为加密的算法使用的数论难题计算的，破解的过程就是解决数论难题的过程。那么既然是数学上的难题，就极少人能解决了（哪个数学家能解决，基本能获大奖）

  认证是验证你是你我是我的过程。在双方通信开始之前，首先得确认对方是我要对话的人。这个现实场景的应用在数论的使用上与密码是一样的。是密码学的另一个应用。

摘要

  摘要的主要算法有MD系列、SHA系列、HMAC、CRC系列。衡量一个摘要算法的好坏只有两个：速度和碰撞。

  现在最广泛使用的MD系列是MD5,也就是MD第5版。是对2/3/4版本的改进升级。同样的SHA也分为SHA0/1/2/3四个系列。算法复杂度一步一步的增强。SHA本身就是对DM4的升级，和MD5一样。所以所有的摘要算法都是基本相同的，所不同的就是算法采用的参数，例如分组长度、每个分组进行操作的步骤，输出摘要的长度等等。

  本质的算法都是将数据分组，然后对每个分组进行数学运算，并且之前分组的运算结果参与之后分组的允许。具体怎么运算（加减异或等）各个算法不同。MD5和SHA已经被山大的王小云教授证明存在碰撞，并且存在方法，但是并没有说明如何生成。事实上基本可以肯定的是所有的摘要算法都存在碰撞（信息论），问题就是怎么生成碰撞。如果真的有人知道如何构造，那么可以这么使用：让用户下载的文件替换为同样摘要值的病毒，用户将会毫不怀疑的执行你的病毒，因为他基本没办法确定到底是病毒还是原来的程序。所以即使有人发现了，或者是某个数学家，或许是政府，也基本会保留用作监听大家通信的黑客手段之一。God bless us。也正是因为如何，我们使用还是安全的，因为起码大众是不知道。

  HMAC则是使用已有的摘要算法（MD5、SHA），但是加入一个秘钥成分。如此，必须得知道秘钥才能计算摘要。这就为通信的可靠性又上了一道保险。

  CRC则是非常常用的摘要算法，但是由于碰撞概率太高，一般用在简单的较小数据的摘要计算上，例如网络通信中的数据包。

加密

  有加密就有解密。业界一般根据加密和解密的秘钥是否一样，将加密算法分为对称性的和非对称性的。对称性的由于要另外找私密的渠道进行秘钥分发，所以使用上很不方便。非对称性加密由于加密和解密秘钥不一样，就可以公布一个加密的秘钥作为公钥，任何人都可以使用这个密钥对数据进行加密，但是只有私钥的持有者可以解密。而反过来只有自己能加密，别人都能解密的使用方式就可以用来验证这个数据确实是由自己发出的。也就是说公布了加密秘钥可以用来加密通信，公布了解密秘钥，就可以用来认证。一个加密算法两种用处，而加解密效率又比对称性加密低，所以公布一个密钥的公钥现在非常流行用来做对称性加密的秘钥交换方式。

  常见的对称性加密算法有DES、3DES、AES。DES（Data Encryption Standard）是早期的数据加密标准，速度较快，适用于加密大量数据的场合。可以用穷举法破解（但你得有那么多计算能力）。3DES（Triple DES）是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。AES（Advanced Encryption Standard）是下一代的加密算法标准，速度快，安全级别高。在实际实现上DES类是分组的，AES是流式的。分组式的由于各个分组不发生交互运算比较脆弱，流式之前的运算结果会影响下面的计算。所以目前普遍认为流式比分组式更安全（但其实就是要穷举多久的问题。。。）。

  常见的非对称性加密算法有RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）。使用最广泛的目前是RSA，RSA算法基于一个十分简单的数论事实：将两个大素数相乘十分容易，但是想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥，而只有自己知道，其他人很难算出来的因式分解就是解密秘钥了。这个算法中，公开的只能是加密秘钥。这也就决定了这个算法不能简单的用于认证，但通过一系列双向交互就可以实现认证和数字签名。其他算法也都是类似的数学问题的求解。

  其实你想要破解这些密码也不是什么难事。比如大素数的乘机，你只需要提前建一个素数相乘的数据库，到时候查询就行了。不过这个数据库可不小喔。用上压缩，再多花点钱买点存储，用点计算能力，就可以用空间显著的换取时间啦~~~~

  对称秘钥的计算速度明显快于非对称秘钥，缺点只是缺少安全的秘钥分发渠道。所以业界普遍使用非对称加密来做认证和生成对称秘钥（也叫会话秘钥），然后双方使用对称密钥进行通信。而由于对称密钥可以靠穷举法进行破解，所以一般的会话管理都会自动的更换会话秘钥，如此看起来一个定期更换会话秘钥的通信是安全的。但是安全永远是相对的。

认证

  前面说过，加密和认证在数学上用的是同样的算法，只是用法不同。认证主要使用的是非对称性加密。

  由于前面说了，采用素数积的方式只能公布加密秘钥。所以通过公布解密秘钥来做到认证的做法不可取。但是通过加入第三者就可以。这就是秘钥管理系统。最常见的是Kerberos系统。

服务器认证客户端

  由于两个陌生人互相无法立即建立信任，而如果有一个靠谱的人同时认识这两个陌生人并未对方做担保，这两个陌生人就很容易建立信任。这个陌生人就是认证中心。A只要和认证中心能够建立可靠连接，然后向B证明这一点，B就可以信任A。所以一般的做法是，认证中心存储A的公钥，然后给A颁发一个证书，这个证书里有认证中心的标识和A的公钥。当A要同B通信的时候，只需要证明这个证书是真的就好了，而是不是真的B可以去跟认证中心确认。所以，证书一定要防止造假。这个防止造假的核心原理是：A必须事先与认证中间建立非对称通信的信任（通过互相存储公钥），当事先信任的A要访问事先信任的B的时候，A通过信任管道获得许可，而这个许可的内容却是用B的公钥加密的，A只负责转发，并不能查看和伪造许可，B解密只认许可即可。

  当然，这只是Kerberos规定的流程，这个流程可以有无数种设计，但是核心的都是通过非对称加密来完成的。例如chanllenge response可以测试A是否是B所认识的A。B用他所认识的A的公钥加密一个随机的字符串，让A去解密，如果A能解出来就证明是B所认识的A了。

  关于这种公钥的用法，你还可以有无数的想象空间。

数字签名

  还有一种认证叫做数字签名，这个就是典型的使用私钥来加密，使用公钥来解密的应用。这就是分对称加密最有意思的一点，就是加密和解密的秘钥可以互换。我虽然只能公布质数积，但是我不一定要用质数积来加密，我也可以用它来解密。一言完事。

客户端认证服务器

  服务器也可能被伪造，所以客户端访问了假的服务器也是灾难。服务器一般像CA申请一个csr证书文件，这个证书文件是用CA的私钥加密过的。

  PC机的浏览器中一般都预存了很多大型的CA的证书，这个CA的证书都是CA自签名，里面有记录CA的公钥。当遇到持有某未在浏览器的信任CA列表中的CA签名的服务器csr证书文件的时候，客户端的浏览器一般会弹出对话框问你是否相信这个CA签的csr证书，如果你选择相信，你也就同时相信了这个server了。已在信任列表的CA，遇到这些CA签字的csr文件客户端会直接信任。

秘钥交换

常见的秘钥交换方式有两种：

1、公钥加密实现：发送方用接收方的公钥加密自己的密钥，接收方用自己的私钥解密得到发送方的密钥，逆过来亦然，从而实现密钥交换。

2、使用DH算法：前提发送方和接受方协商使用同一个大素数P和生成数g，各自产生的随机数X和Y。发送方将g的X次方mod P产生的数值发送给接收方，接受方将g的Y次方mod P产生的数值发送给发送方，发送方再对接收的结果做X次方运算，接受方对接收的结果做Y次方运算，最终密码形成，密钥交换完成。简单的说，DH算法就是用来做对称加密的秘钥生成交换的。之前这个工作是由非对称加密算法完成的。因此，使用了这个算法，非对称加密算法就失去了存在的基本意义。

SSL/TSL

SSL(Secure Socket Layer)是Netscape公司设计的主要用于WEB的安全传输协议。这种协议在WEB上获得了广泛的应用。

IETF将SSL作了标准化，即RFC2246，并将其称为TLS（Transport Layer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。

  SSL可以用于保密的传输，这样我们与Server之间传输的消息便是“安全的”。SSL协议分为两部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥，这也就是非对称性加密发挥作用的时候。 Record Protocol则定义了传输的格式。

连接建立

  SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个 Clienth*llo来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个Serverh*llo， 这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服 务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会检查该客户端的公钥是否在自己的信任列表中，如果在会话密钥协商成功，双方可以用同一份会话密钥来通信了。

  当然SSH如何验证用户的公钥是否可以用来通信，并不是要全部根据自己的信任列表，通过配置ssh程序，可以即使不在也允许继续通信。甚至可以配置为，不在乎在不在信任列表，收到对方的公钥后问对方几个问题（很多情况下是问密码），如果能答对也授权登录。

安全性

  SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论，目前也有一些成熟的工具如dsniff可以通过man in the middle攻击来截获https的消息。

  从上面的原理可知，SSL的结构是严谨的，问题一般出现在实际不严谨的应用中。常见的攻击就是middle in the middle攻击，它是指在A和B通信的同时，有第三方C处于信道的中间，可以完全听到A与B通信的消息，并可拦截，替换和添加这些消息。

1. SSL可以允许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便无法验证B的公钥和身份的真实性，从而C可以轻易的冒充，用自己的密钥与双方通信，从而窃听到别人谈话的内容。 而为了防止middle in the middle攻击，应该采用有证书的密钥交换算法。

2. 有了证书以后，如果C用自己的证书替换掉原有的证书之后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？

3. 由于美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，如果只采用浏览器自带的加密功能的话，理论上存在被破解可能。