这是有关密码术三篇文章中的第二篇，在这篇文章中，Gary 和 John 讨论了应该考虑使用哪些历经考验和测试的加密技术，以及使用它们的原因。

在上一部分中，我们介绍了密码术背后的思想，并说明了为什么它在开发安全性关键型代码时非常有用。从上一篇中学到的最重要的一课就是永远不要使用自己的密码算法。最好的办法是从密码术专家花费多年发明和测试的经验中借鉴大量好的想法。

在选择密码解决方案时，开发者要做出的一个最常见的决定是使用对称密钥算法（例如 DES）还是公钥密码术（例如 RSA 或 ECC）。在本专栏中，我们提供了两种算法的快速介绍，并为您提供在每种算法之间取舍时所涉及到的一些最常见的好处与弊端。（请记住，尽管我们时常应用和分析使用密码术的软件，但我们并不是密码专家。如果有任何疑问，请查询其它信息。）

对称密码术
密码术的对称算法主要用于数据的机密性，它的副作用是数据完整性。通信双方在计算中使用它们共享的单一密钥。必须保证共享密钥的安全才能确保加密文本的机密性。

在对称密码中，同一个密钥用在加密和解密明文消息中。消息和密钥是以加密算法的输入提供的，产生可以在非安全媒体（例如因特网）上安全发送的密文。在另一方，解密算法（必定与加密算法紧密相关）使用密文和相同的秘钥作为输入，然后恢复原始消息。

下面的图 1中显示了对称算法的高级概述。

由于对称密码通信中的双方都必须具有相同的密钥，并且密钥必须保密，所以需要进行周密的安排来安全地分发秘钥。密钥一旦泄露，这种算法就失去了它的所有威 力。分发密钥的一个方式是将它复制到软盘上，然后交付给希望与之安全通信的那个人。这种密钥分发方法中的薄弱性在于对称算法的最大缺点 -- 一旦丢失磁盘，就失去所有安全性。

Diffie-Hellman 是一种众所周知的协议，用于在非安全媒体上分发对称密钥（请参阅参考资料）。然而在使用这些协议时，必须知道正确身份验证的需求。与远程服务器安全地交换密钥当然是有可能的，但并不保证（除非您要求）您是在向正确的实体发送密钥。可能与直觉相反，为对称密码交换秘钥的最常见方法是通过使用公钥密码术执行的（在下面讨论）。

对称算法的类型
对称算法的两个主要类别是块密码和流密码。 块密码将消息分为固定长度的块（最常用的块为 40、56、64 或 128 位）。输出的长度通常与明文的长度相同。如果明文与块长度（即块长度的整个数字因子）不是完全对齐的话，通常就会用附加无用数据的手段来填充至正确长度。 加密算法本身主要负责所有的填充操作。与块密码相对应，流密码在任何时侯都是加密单一的位。流密码比块密码要快得多，但我们经常使用的最广为人知的以及研 究最为透彻的对称算法是块密码。

要从最简单的角度来理解块密码，就是每一块数据都是单独加密的。据说这种类型的密码是以电子代码书 (ECB) 方式工作的。要事先警告一下，这种方法明显会带来一些安全性风险。例如，假设数据文件中每一块的长度是 64 位，每块都单独加密。每次加密 64 位的明文字符串 "security"（假设每个字符 8 位）时，都将加密成相同长度的密码文本字符串。如果攻击者看到样本消息的明文，而消息包括的字 "security" 恰巧与 64 位的边界对齐，那么每条带有这样对齐的 "security" 的消息就立刻对攻击者是透明的。

一些信息，例如编码特定的字的方法，在某些情况下可能对攻击者大有帮助。在一次攻击中，通过将以前记录的块插入新消息，坏人在不知道用来加密信息的密钥的 情况下就可以修改加密过的数据。为更深入地进行探讨，请考虑一个付款系统，在这个系统中，存款以严格加密的块密码格式被发送。在我们的示例中，前 128 位代表将钱存入的帐号。余下的消息将存款金额、发送消息的时间，以及某些其它信息进行编码。如果攻击者知道前 128 位代表的是帐号，并且如果攻击者恰巧还知道目标帐号加密成一个特定的字符串，他就可以修改正在发送的消息，将存款转向目标帐户。攻击通过用攻击者自己的帐 号（也是以加密格式）来替代加密格式表示的实际帐号进行。真糟糕！

严格地说，流密码由于其设计方式而不受这种“替换”问题的影响。但并不是说块密码就一无是处了。可以修改块密码来降低我们上面所说明的风险。要避免这种问题，有几种不同的策略。例如，以密码块链接 (CBC) 方式，仍然是一次加密一块，但每块的明文在加密前要经过与前一块密码文本的 XOR 运算。这是块密码普遍使用的一种方式。实际上，CBC 方式是许多块密码的缺省方式。另一种方式称为计数器方 式，它使用任意但可重新产生的数字顺序作为密码算法的额外输入。特定的顺序不是很要紧。通常按时间取得的伪随机的序列就足够了。在加密前，计数器与明文进 行混合。使用任何这类方法时，计数器不能经常重复某个数字，否则优点就不存在了。通过确保使相应的密文块不同，在块密码中使用 CBC 或计数器方式可以帮助降低一条消息（或在多条消息之间）中相同明文块多处出现时所遇到的风险。

在大多数情况下，我们讨论过的几种方式都正确置入算法实现中，因此可以选择在特定应用程序中使用哪种方式。通常我们建议您使用 ECB 方式，但您需要根据环境来选择方式。每种方式都有其自己的安全性内涵。CBC 代表的是个比较可行的解决方案，但攻击者可能将一些无用信息放在加密消息结尾或将它引入到消息中间。可以使用两种预防手段来避免类似问题。首先，务必要知 道哪里是消息的结尾。在消息开始处对这类信息编码，或让它在协议中隐含起来。确保在继续之前，接受方检查了长度信息。其次，向数据添加某种类型的校验和， 这样可以检测到在消息中间进行修改的情况。（密码校验和非常适合于这个目的，我们将在以后的主题“密码散列算法”中讨论它们。）这些预防措施有助于消除篡 改的问题。

对称算法的安全性
如果不考虑保证秘钥安全的问题，对称块密码的安全性就取决于两个主要因素。第一个，也是最重要的因素是算法的质量。第二个因素，也是不太重要的因素是所使用密钥的长度。

块长度也可能是一个因素。64 位的块可能不够安全，但 128 位的块应该非常合适。

研究社区已经做了大量开发安全对称密码的工作。但演示密码安全性仍然是个极其困难的问题。没有一种实际的密码算法是绝对安全的。

有一种完美的加密算法存在，称为“一次性密码本”。使用这种算法的情况下，n 位的明文消息与 n 位的随机数字执行 XOR 操作（产生 n 位的密文）。在这种情况下，如果拦截到 64 位消息，并且如果密钥是真正随机的，所有 264 个可能的位串都是同样有可能的。除了其原始长度之外，密码文本中没有信息可以泄露明文的任何结构。在一次性密码本中，永远不能重用相同的密钥，否则这种方 案的安全性就不存在了。另外，与任何对称算法一样，它有一个相当严重的密钥分发问题。由于必需的密钥长度太大，所以通常认为一次性密码本是不实用的。想象 一下尝试在吉位每秒能力的网络上使用一次性密码本来加密数据！但磁盘空间越来越便宜。随着带宽和存储器的价格继续回落，一次性密码本可能会变得比较普遍。

密文总会泄露有关原始明文的信息，这些信息在不需要拥有密钥的情况下就可以找到。攻击者的一个难题是识别泄露的信息。

所有密码算法的重要目标是使密码破译变得极其困难。其它重要目标包括速度和内存最小化。不幸的是，使密码破译困难并不是那么容易做到的。有经验的密码专家 要设计一种能适应所有已知形式的攻击的算法并非不可能。再说，针对完全未知类型的攻击设计算法要困难得多。许多人都相信，但没有人能肯定地说，美国国家安 全署 (NSA) 已研制出了针对常规块密码的复杂攻击，但他们还没有和其它国家分享这一成果。另外，没有传言说哪种针对任何算法的类型的攻击将在近期内被发现。密码专家所 能做到的就是分析与已知攻击相关的密码，然后用那种方法来判定它们。

在谈到密钥长度的问题时，通常认为 128 位对于需要在一般人类寿命期内进行保护的消息就足够了（当然，除蛮力攻击外，假设没有其它攻击能够对一种算法实施）。另外，认为 112 位已足够。为保证安全，需要考虑 256 位，相信这种长度的密钥在宇宙有限时间内对于由任何现有计算材料组成的计算机来说都足够安全，即使使用蛮力攻击，发现密钥的可能性也是非常小的。从另一角度考虑，64 位密钥对于高安全性的应用程序来说也太小了。据 Schneier 说，早在 1995 年就曾有人希望花 1000 亿美元来在一分钟内破解 64 位密钥。如今有一些计算资源能够在一年内完全破解这样的密钥。而 40 位密钥比没有任何安全性好不了多少。

数据加密标准 (DES) 和高级加密标准 (AES)
对称算法的使用相当广泛，科学家们已经对它们进行了深入研究。事实上有几百种这样的算法，其中有些很好，有些就不行。最常用的对称算法是数据加密标准 (DES)，一种使用 56 位密钥的块密码。它是由 IBM（及一些伙伴）在 NSA 指导之下创建的，已成为多年来美国政府的标准。

许多现代密码都是以 DES 为模式的，但很少密码能够象 DES 那样经受得住密码破译。DES 的主要问题是其密钥长度很短，完全不适合于当今的形势。

有可能使密钥长度很短的 DES 更安全，但这不是随意就能做到的。一种（不好）的想法是许多人尝试应用 DES 两次 -- 称为双重加密。 在这种方案情况下，使用一个密钥为消息加密一次，然后使用另一个密钥再次加密（密文到修改过的密文）。一种非常精明的攻击最后证明这种双重加密并不比单重 加密更好。实际上，使用某种类型的密码情况下，多重加密可能并不比单重加密好（一种称为封闭式密码的类别）。应避免使用封闭式密码，因为它们更容易遭到攻 击。

尽管双重加密不是非常有效，但证明三重加密则有效得多，与许多天真的人曾对双重加密寄予的希望一样。例如，56 位 DES 在三重加密后，产生 112 位长度，相信这种长度对于任何应用程序来说都已经足够了。三重加密的 DES，或者简称三重 DES（通常写成 3DES）是一种流行的现代对称块算法。

但三重 DES 不是包治百病的万灵药。三重 DES 的一个问题是它的速度或有关速度的不足。部分是由于速度的原因，美国商务部的国家标准和技术协会发起了高级加密标准 (AES) 的角逐。到目前为止，NIST 选择了五种算法作为该标准的最终入围者。将在 2000 年年底之前宣布它们当中的获胜者。

AES 角逐的一个风险是所有算法都是相对比较新的。这些候选算法在短时间内没有得到详细检验，无法与对多年来一直使用的 DES 进行的深入检验相比。不过，仍然有些人相信 NSA 在 DES 中放置的隐蔽的“后门”会带来一些风险，使它们易于受到攻击。这些人似乎更欢迎 NSA 没有插手的标准（然而，NSA 与 NIST 仍然有相当密切的关系）。事实上，除了相对较短的生命期，AES 获胜者的算法（在下 50 年中使用）至少大概与 DES 有史以来的算法一样好。

尽管三重 DES 有一些性能问题，但目前它还是倍受推崇的解决方案。这种算法一个最大的好处是它是免费使用的。可以从因特网上下载几种 DES 好的实现。AES 获胜者也将免费使用，并至少提供一种免费的参考实现。五个候选算法中有许多已经是免费的。对于多数应用程序来说，AES 候选算法比 DES 要快很多。

有大量商业对称算法也可以使用。因为这些算法是专有的，所以往往无法仔细分析它们，至少无法在公开情况下。但也有一些专有算法提供了良好的安全性，并且能相当有效地运行。不过我们暂时没有找到任何压倒多数的理由向大多数应用程序推荐除三重 DES 以外的其它任何标准，以及在宣布了 AES 获胜者之后不推荐 AES 获胜者的理由。

对称密钥解决方案的一个问题是每一对通信代理都需要唯一密钥。这样就出现了在有许多用户的情况下管理密钥的难题。每一对唯一通信实体都需要唯一密钥！为了 绕过这个问题，有一些设计者转而使用密钥派生算法。这种想法是使用主密钥来为每个通信对派生出一个唯一密钥。大多数情况下，密钥派生使用唯一的用户标识信 息（例如用户序列号）来转换主密钥。这种方案的固有风险是显而易见的。如果泄露了主密钥，所有希望就破灭了。实际上，即使可能只破译了一个派生密钥，也会 为攻击者提供足够多的主密钥信息。如果不考虑这种风险，许多系统都依靠带有密钥派生的对称算法来控制密码成本。

在相关实践中，设计者对于两个代理之间所有加密的通信通常利用会话密钥而不是使用同一个对称密钥。在上述派生的密钥中，它的想法是使用主密钥为每个通信对 使用会话密钥，可能它本身就是从全局主密钥中派生出的。在泄露会话密钥的情况下，系统可以继续派用场。再次重申，从主通信对密钥中派生会话密钥的想法仍然 会对整个系统带来风险。

公钥密码术
我们在前面一节提到过，对称密码术最大的一个问题就是密钥分发问题。困难在于解决如何在非安全媒体上与远程方安全地交换秘钥。公钥密码术完全不存在密钥交换问题。在公钥系统中，用于密码操作的是一对密钥，而不是单一密钥的副本。两个密钥中有一个是公开可用的，称为公钥。这个密钥可以自由地散发、放在网页上、广播等等。公钥用于加密消息。另一个密钥与第一个不同，必须保持私密。它称为私钥，用于解密消息。私钥的安全性与对称算法中的密钥安全性一样重要。这两种算法方式的根本差异在于：在公钥密码术中，永远不需要与任何人共享私钥，因此就完全避免了密钥分发问题。

在公钥系统中，发送方使用接收方的公钥来为消息加密。受到算法缺点的限制，在假设算法正确实现的情况下，唯一能解密使用这种方法加密的消息的人应该是拥有 相关私钥的那个人。这个系统与任何人都可以向其中投信的邮箱类似。在这种相似情况下，没有人可以轻易地从信箱中取邮件，除非他们拥有能够开启邮箱的那个小 心保管的秘钥。

下面的图 2中显示了公钥密码术的图形概述，说明 Alice 向 Bob 发送消息时发生了什么事。

公钥算法的致命弱点是，相对于对称密钥算法来说，消息的加密和解密往往相当慢。通常情况下，公钥算法的软件实现通常比 DES 要慢上 100 倍，当每个都以硬件实现时更要慢 1,000 倍。出于这种原因，使用公钥密码术以及时的方式加密大消息并不实际。

幸运的是，加密较小的消息在可接受的范围内看上去适合。因此，人们常常将对称密钥和公钥算法混合在一起使用。在这种混合情况下，大多数通信都是使用相当快 的对称算法进行的。但交换对称密钥这个高风险部分，利用公钥算法。我们在上面指出过，这是避免密钥分发问题最好的方式。它还能解决对称密钥那一节结束时说 明的密钥派生风险（至少适用于具有合适计算资源的平台）。既然已经有一种可信赖的方法可用于在合理的时间内分发密钥，我们没有理由转而使用密钥派生并承担 相关的风险。

让我们考虑 Alic 启动与 Bob 的通信时希望使用的混合方法。Alice 和 Bob 将经常使用对称密码（例如三重 DES）进行通信。但在使用密码前，他们首先需要在会话期间一直交换秘钥。他们需要共享的秘钥称为会话密钥。希望 Alice 使用随机的安全源生成这个密钥，而不是设计有缺陷的派生算法。（有关随机的详细信息，请参阅developerWorks上随机数生成的系列文章。）要使会话密钥以安全方式传递给 Bob，Alice 使用公钥密码术。她首先查找 Bob 的公钥，并使用它来加密会话密钥。将产生的密文发送给 Bob。Bob 使用他的私钥解密密文，这样就获得了会话密钥的副本。所有后续通信都是使用三重 DES 和会话密钥（共享秘密）来进行的。

RSA 算法
最有名的公钥算法是 RSA 算法。RSA 背后的一般思想从选取两个大质数 p 和 q 开始。这些数字保持机密状态，但可以发布它们的乘积 n 和一些额外的信息。发布的信息用于加密消息。因为涉及到了数学计算，所以只有知道 p 和 q 的人才能够解密消息。通常 p、q 和 n 都是具有几百个数字的罕见大质数。

人们认为 RSA 算法的安全性与将 n 进行因式分解获得 p 和 q 的难度是一样大的。将大数字进行因式分解相当困难，尽管这种通常能被人接受的说法从未被确切地证实过。然而，RSA 已经过了将近 20 年公众的反复检查，因此人们从中获得了信心。

许多人凭直觉相信有一些非常大的质数，因此不断推论 RSA 系统将会有很多问题。为什么攻击者无法为所有可能的密钥只创建一个数据库呢？每个可能的密钥都可能用蛮力攻击方法尝试出来。坏消息是这种类型的攻击是可能的。但好消息是质数比大多数人猜测的要多得多。长度达 512 位的质数有大约 10¹⁵¹个，这意味着有足够的长为 512 位的质数可以指定给有限的 10⁷⁴个素数的每个原子，而这些质数不会有任何重复。

使用 RSA 的情况下，安全性主要依赖于将两个质数的组合进行因式分解的难度有多大。请回忆一下，在对称加密系统中，我们说过 256 位的密钥已经足够大，能够在无限的时间里为所有应用程序提供安全性了。使用 RSA 和其它公钥加密系统时，同样的推论并不成立。实际上，很难说出未来 50 年后公钥系统长度是多少才最适合，永远不要介意今后的道路上会发生什么事。很明显，256 位数表示可能的 RSA 密钥要小于 2²⁵⁶，因为不是每个数都是质数。所以，空间大小比蛮力攻击所需要的要小一些。实际上，最终将 256 位数直接进行因式分解不需要过多资源。最后，将公钥长度与对称密钥长度直接做对比就象将苹果和桔子进行比较。

我们担心的一个主要问题是无法预见研究者在因式分解技术中利用哪些好处。许多年前，相信没有人曾有足够的资源来对 125 位的数字进行因式分解。现在任何愿意花费几个月时间和几百万美元的人都可以对 512 位数进行因式分解。作为一名尽职的安全性怀疑论者，在可预见的未来，您应该使用不小于 2048 位的密钥。即，如果数据需要在长时间（例如两年或两年以上）内保持安全，使用 2048 位密钥。目前，1024 位密钥也可以用于其它用途。但要记住，短短几年之内，即使 1024 位密钥也有可能被轻松因式分解。如果您是在 2005 年看到这篇文章的话，应该通过检查来确保对于实际使用的 2048 位密钥仍然被认为是足够的，因为它们那时可能会不够！

使用非常长的密钥有什么坏处吗？在公钥密码术的情况下，所需的密钥越长，生成它所花费的时间就越长。当提供给您一个非常巨大（例如 100,00 位）的密钥时，您很可能不希望等待那么长的时间来生成一个密钥。目前，在大多数机器上生成 2048 位的密钥需要几分钟的时间。即使那么小的密钥都增加了一般用户愿意等待的极限。

与 RSA 相关的还有一些非技术性问题。最突出的是 RSA 当前是受美国专利保护的。RSA 的使用需要许可证。令人欣慰的是，这种专利状况将有所改变。RSA 算法的专利到 2000 年 9 月 20 日到期，并且不能延期。在读这篇文章的时侯，这种算法可能已经进入公共领域了。

同时，已在公共领域中的 ElGamal 算法无疑是个很好的替代算法。曾一度怀疑过这种算法是不是受美国专利保护的，但这种有疑问的专利于 1997 年进入公共领域。ElGamal 基于离散对数问题，后者的难度至少能跟因式分解相提并论，因此这种算法应该提供与 RSA 类似的安全性。目前我们相信这两种算法（RSA 和 ElGamal）都是高安全性通信可用的最佳选择。其它算法，包括椭圆曲线密码术，都没有象 RSA 和 ElGamal 那样从数学角度进行深入研究。

对公钥的攻击
公钥密码系统容易受到某些明文选择攻击，特别是在只能发送有少量可能的消息时（例如，受程序设计的限制）。对称算法往往比较不容易受这种攻击的影响。好消息是，在我们上面描述过的那种混合方法中，如果只使用公钥密码术来加密会话密钥，就无须担心那么多了。

另一种相当容易对大多数公钥密码系统产生影响的攻击是“中间人”(man-in-the-middle) 攻击。请再次考虑 Bob 和 Alice 进行通信的情况。假设 Pete 能够拦截公钥的交换。Pete 向 Alice 发送他自己的密钥，但将它错误地表示成 Bob 的密钥。他还向 Bob 发送了自己的密钥，错误地表示成 Alice 的密钥。现在 Pete 拦截 Alice 和 Bob 之间的所有通信。如果 Alice 在一个已泄露的系统上向 Bob 发送了一条消息，即使她认为使用的是 Bob 的公钥加密的消息，实际上使用的是 Pete 的公钥。Pete 获得消息后解密并进行存储，这样他就可以稍后读这条消息了。然后，他使用 Bob 的公钥加密消息，继续将它发送给 Bob。Bob 获得消息后能够为它译码，但不知道它实际上是来自 Pete 而非 Alice。

这里的主要问题是 Alice 没办法确定她得到的密钥实际上是属于 Bob 的。有一些方法可以避免这种问题，但它们通常需要公钥基础设施 (PKI) 的存在。在常规 PKI 中，一个可信第三方保持对每个人密钥的跟踪。这个可信第三方的公钥尽可能广泛地使用，因此很容易进行验证。以后，类似于这种可信第三方密钥可能嵌在软件中。

PKI 方式能够避免“中间人”攻击，因为心存怀疑的用户可以使用密码协议来与第三方联系（通常称作认证中心），并请求它告诉他接收到谁的密钥。这可以通过使用对有关该机构广为人知的公用信息的引用来进行验证。

PKI 策略在使用复杂协议的情况下能很好地使用。然而也有些缺点。首先，每个人如何确定他们是否能够信任声称是可信的机构？其次，如果某人能够，假设通过“黑”掉站点，假冒机构怎么办？第二种风险是个大问题。

最大的认证中心之一是 VeriSign 公司（请参阅参考资料）。VeriSign 在确定信任某个人并向他颁发公钥标识之前，通过执行对他的背景检查来散布信任。（奇怪的是，使用这种模型，一个希望得到信任的人要为这种信任付钱！）问题是早期的身份检查是很比较马虎的。在 VeriSign 推出了他们的服务以后，很快就有一些人开始注册假身份了。例如，有人在网络上假扮比尔盖茨。要避免这种问题，可能最好的方式是通过人来交换密钥，或者通过您完全信任的媒体来执行。如果您能准确地辨别对方的声音，那么有时打个电话就足够了。

除了松懈的身份问题以外，验证是用户问题。问题是，在实际中，人们通常不会费心检查可信的第三方给予的结果。这个问题广泛存在，特别是在“安全的”网站中使用时。

您的定单安全吗？
以下是一个常见的情景。假设您想从 Amazon.com 购买一些书籍。当使用 Netscape 进行浏览时，就会注意到在浏览器的左下角有个小小的锁图标从“未锁定”切换为“锁定”状态，表明您正通过加密的通道在与 Amazon.com 进行通信。您是吗？不一定。这把锁只说明您正在加密的通道上与某个人进行通信。可以通过单击锁，然后单击“查看证书”来找出谁是所声称的可信第三方。如果您不受“中间人”攻击（类似于 Web 电子欺骗）的影响，就会看到 Amazon.com 的信息显示在证书窗口中。但如果有“中间人”攻击，或者如果某些第二方完全改变了 Amazon.com 的外观和操作，并且您实际上根本不在与 Amazon.com 进行通信的话，将看到不同的信息。通过实际上的检查，就能够非常确定您是否在与希望的那方进行通信。不幸的是，在现实当中，大多数人从来不检查这些信息！他们只看是不是有锁，有的话就觉得是安全的。如果您不检查证书，就无法对始发方的安全性有任何把握。

这个问题在公钥密码术的实际实现中到处都有。例如，许多对 Netscape 安全性套接字层 (SSL)，一种用在 Netscape 和许多其它应用程序中基于公钥的库，的使用都受到“不检查您正在连接的对象”问题的影响。人们觉得安全是因为他们使用 SSL 来加密数据，但他们没有意识到确认问题仍然存在。

除非应用程序具有可靠的公钥分发手段，例如亲自传送，否则盲目地相信您拥有正确的公钥是很不可取的。不要试图使用被动的 Netscape 解决方案，来自可信机构的数据只需要单击图标就能获得。将信息放在用户的视图中。当然，它是另一个对话框，对于用户来说也是问题。但希望用户理解检查对话框的重要性，并且在阅读过之后才取消它。即使这样，您至少在您那一方也要做些努力。我们坚决相信所有针对 etscape 的“中间人”攻击更多地是 Netscape 的责任而非最终用户的责任，因为 Netscape 不会努力使用户确认正在与他们通信的是什么人。如果有 "in your face" 对话框，那么在我们看来，责任就转移给了用户。如果不阅读对话框的内容就取消它，用户就是在冒险。

参考资料

• 请参阅developerWorks上有关密码术这一系列的第一篇文章“让您的软件运作起来：要隐藏的每样东西”。
• 了解有关Diffie-Hellman 协议的详细信息。
• 阅读 Bruce Schneier 所著的Applied Cryptography。
• 访问Reliable Software Technologies网站。
• 有关 VeriSign 的详细信息，请访问他们的网站。