Telnet 协议

可惜，架构设计师和开发人员有时假设认证机制的安全性实际上不是问题，但实际上它是。例如，考虑一下 telnet 协议。大多数 telnet 服务器接收用户名密码作为输入。然后散列密码，或执行一些类似的转换，然后将结果与本地数据库中的比较。问题在于使用 telnet 协议时，密码在网络上以明文传输。任何能够使用包嗅探器在网络线路上侦听的人都可以发现密码。telnet 认证提供了很差的保护，潜在攻击者可以轻易地清除保护。许多著名的协议（包括 FTP、POP3 和 IMAP 的多数版本）都具有类似的破绽百出的认证机制。

其它攻击

任何好的密码散列算法应该是这样的，即使给定一个已知的消息和与它关联的消息散列，也很难找到替代明文的重复散列。对冲突的故意搜索意味着蛮力攻击，这通常很难。当攻击者希望用第二份明文文档产生除了杂乱无意义的字符串之外的东西时，就尤其困难。

另一种对密码散列的攻击比平均蛮力攻击容易实施得多。考虑下列情况：Alice 向 Bob 显示了一份文档和验证文档的密码散列，文档内容是 Alice 同意为每个小饰品付给 Bob 5 美元。Bob 不想在他的服务器中存储该文档，所以他只存储了密码散列。Alice 希望只为每个小饰品付 1 美元，所以她想创建第二份文档，所产生的散列值和 5 美元的那份相同，然后告上法庭，控诉 Bob 多收了她的钱。当她出庭时，Bob 将出示散列值，相信 Alice 的文档不能散列出那个值，因为这不是她显示给他的原始文档。如果其攻击是成功的，Alice 将能够证明她所伪造的文档确实散列出 Bob 存储的值，法庭将判她胜诉。

但她是如何做到这一点的呢？Alice 使用了所谓的 生日攻击。在这种攻击中，她创建了两份文档，一份写着每个小饰品 5 美元，另一份则写着每个小饰品 1 美元。然后，在每份文档中，她标识出 n处可以进行表面更改的地方（例如，那些可以用制表符取代空格的地方）。好的 n值通常是最终散列输出的位长度的一半加 1（所以如果我们指定散列输出的位长度为 m，则 n= m/2+1）。对于 64 位散列算法，她将在每份文档中选择 33 个地方。然后她反复尝试每份文档不同的排列，创建和存储散列值。一般来说，预计她将在散列了大约 2 ^m/2条消息之后找到散列出相同值的两份文档。这比蛮力攻击要有效得多，如果使用蛮力攻击，预计她必须散列的消息数为 2 ^m-1。如果 Alice 执行一次成功的蛮力攻击需要一百万年，那么她也许一周以内就可以完成一次成功的生日攻击。因此，Bob 应该要求 Alice 使用一种算法，它所产生的摘要大小使得她不能在任何合理的时间之内完成生日攻击。

如果希望针对生日攻击获得和针对蛮力攻击一样的安全性，给定一个密钥长度为 p的对称密码，您应该选择提供大小为 p*2的摘要的散列算法。因此，对于具有很高安全性需求级别的应用程序，要求散列算法产生 256 位甚或 512 位的消息摘要是个好主意。

什么是适用的好散列算法呢？

我们特别喜欢 SHA-1。Bruce Schneier 也推荐这个算法。但是如果散列长度必需超过 160 位，SHA-1 还不够。对于大位数散列，尝试使用适合于执行散列法的对称加密术。GOST 散列算法是个好示例，它从 GOST 加密术派生而来，带有 256 位的散列长度。更长的散列长度很可能要求进行一些编码来适应对称加密术。Schneier 在 Applied Cryptography中概述了构建此类算法的构造。SHA-1 或 GOST 散列算法都没有任何知识产权限制。

数字签名

数字签名背后的思想是模仿传统手写签名。该思想是能够以某种方式“签署”一份数字文档，该签名具有和物理签名一样的法律效力。数字签名至少必须和手写签名一样好地满足以下主要目的：

• 签名应该成为可靠性证明。它在一份文档上的存在应该使人信服，某人的签名出现在某文档上是他有意签署的。
• 签名应该不可伪造。因此，在文档上签了名的人应该不能声明这签名不是他们的。
• 在签署文档以后，应该不可能不可检测对文档的更改，否则签名可能是无效的。
• 签名应该不能移动到另一份文档。

即使对于手写签名，这些目标也只是概念上的，并不能真正地反映现实。例如，伪造签名是可能的，尽管很少有人技艺高超，真的能伪造。然而，签名罕有滥用的倾向，这很好地保持了它在法庭的地位。总之，墨水签名已经是足够好的解决方案。

电子签名至少可以做得和物理签名一样好。这个事实经常使人们吃惊，因为他们将这种签名当成是类似于人们经常放置在电子邮件消息末尾的那种签名文件（一串 ASCII）。如果数字签名就是象这样的，那么它们根本就没什么用。很容易从一个文件复制签名，并将它直接添加到另一个文件上以形成一个赝品。也可能轻易地修改一个经过签署的文档，并且谁也不能发现。谢天谢地，数字签名完全不是这样。

大多数数字签名系统将公钥密码术和密码散列算法结合使用。正如我们所解释的，公钥密码系统经常使用接收方公钥来加密消息，然后接收方使用相应的专用密钥解密。专用密钥也能用来对只能用相应公钥解密的消息进行解密。如果某人将他的专用密钥完全保持私有，（您最近没有被黑，不是吗？）能够使用相应公钥解密消息，则构成可疑的人对原始消息进行加密的证明。

数字签名不仅在签署文档的时候有用 — 它们几乎可用于任何认证需求。例如，它们经常与加密联合使用，以便保持数据私有性和数据认证。

用于文档的数字签名经常由对文档的加密散列构成，然后用专用密钥加密散列。结果密文称为签名。任何人都可以通过自行散列文档，然后解密签名（使用公钥或共享秘钥），并比较两个散列来确认签名。如果两个散列相等，则认为签名有效（假设进行确认的人相信他使用的公钥确实属于您）。

签名不必随文档一起存储。同样，签名适用于文档的任何相同的数字副本。签名也可以复制，但是无法使它适用于其它文档，因为最后得到的散列与解密散列不匹配。

数字签名的问题

数字签名的一个问题是认可。人们总是可以声明他们的密钥被盗。但是，数字签名还是作为物理签名的合法替代广泛地得到接受，因为它们至少和物理签名一样接近上面提到的目标。目前至少有 30 个州有数字签名法律，并且更多州很可能立法（如果美国国会没有抢先通过一项国家法律的话）。

大多数公钥算法，包括 RSA 和 ElGamal，可以容易地扩展以支持数字签名。实际上，一个支持这些算法之一的好软件包应该也支持数字签名。我们推荐您将自己喜欢的公钥密码术算法用于数字签名。尝试使用内置原语而不是抛开加密算法和散列函数去构建自己的构造。

下一步是什么？

在未来最重要的主题是密钥管理：如何安全地生成、存储、更改、销毁或传递加密密钥？密码术是一个巨大的领域，但又只是软件安全性的一个方面。甚至我们也不能谎称自己完全了解它。

上一页  [1] [2]