Network Working Group                                     R. Zuccherato
Request for Comments: 2785                         Entrust Technologies
Category: Informational                                      March 2000
        
Network Working Group                                     R. Zuccherato
Request for Comments: 2785                         Entrust Technologies
Category: Informational                                      March 2000
        

Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME

避免S/MIME Diffie-Hellman密钥协商方法“小子组”攻击的方法

Status of this Memo

本备忘录的状况

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2000). All Rights Reserved.

版权所有(C)互联网协会(2000年)。版权所有。

Abstract

摘要

In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks.

在某些情况下,在大素数p的素数阶子群中使用Diffie-Hellman密钥协商方案容易受到某些称为“小子群”攻击的攻击。但是,存在防止这些攻击的方法。本文档将描述与S/MIME版本3的实现相关的情况,其中需要保护,以及可用于防止这些攻击的方法。

1. Introduction
1. 介绍

This document will describe those situations in which protection from "small-subgroup" type attacks is necessary when using Diffie-Hellman key agreement [RFC2631] in implementations of S/MIME version 3 [RFC2630, RFC2633]. Thus, the ephemeral-static and static-static modes of Diffie-Hellman will be focused on. Some possible non-S/MIME usages of CMS are also considered, though with less emphasis than the cases arising in S/MIME. The situations for which protection is necessary are those in which an attacker could determine a substantial portion (i.e. more than a few bits) of a user's private key.

本文档将描述在S/MIME版本3[RFC2630,RFC2633]的实现中使用Diffie-Hellman密钥协议[RFC2631]时,需要防止“小子组”类型攻击的情况。因此,Diffie Hellman的短暂静态和静态模式将被重点关注。还考虑了CMS的一些可能的非S/MIME用法,尽管其强调程度不如S/MIME中出现的情况。需要保护的情况是攻击者可以确定用户私钥的大部分(即超过几位)的情况。

Protecting oneself from these attacks involves certain costs. These costs may include additional processing time either when a public key is certified or a shared secret key is derived, increased parameter generation time, and possibly the licensing of encumbered

保护自己免受这些攻击需要付出一定的代价。这些成本可能包括认证公钥或导出共享密钥时的额外处理时间、增加的参数生成时间,以及可能的担保密钥的许可

technologies. All of these factors must be considered when deciding whether or not to protect oneself from these attacks, or whether to engineer the application so that protection is not necessary.

技术。在决定是否保护自己免受这些攻击时,或者是否对应用程序进行设计以使其不需要保护时,必须考虑所有这些因素。

We will not consider "attacks" where the other party in the key agreement merely forces the shared secret value to be "weak" (i.e. from a small set of possible values) without attempting to compromise the private key. It is not worth the effort to attempt to prevent these attacks since the other party in the key agreement gets the shared secret and can simply make the plaintext public.

我们不会考虑在密钥协议中的另一方仅仅迫使共享秘密值“弱”(即从一小组可能的值)而不试图危及私钥的“攻击”。试图阻止这些攻击是不值得的,因为密钥协议中的另一方获得了共享秘密,并且可以简单地公开明文。

The methods described in this memo may also be used to provide protection from similar attacks on elliptic curve based Diffie-Hellman.

本备忘录中描述的方法也可用于保护基于椭圆曲线的Diffie-Hellman免受类似攻击。

1.1 Notation
1.1 符号

In this document we will use the same notation as in [RFC2631]. In particular the shared secret ZZ is generated as follows:

在本文件中,我们将使用与[RFC2631]中相同的符号。具体而言,共享秘密ZZ生成如下:

      ZZ = g ^ (xb * xa) mod p
        
      ZZ = g ^ (xb * xa) mod p
        

Note that the individual parties actually perform the computations:

请注意,各方实际执行计算:

      ZZ = (yb ^ xa)  mod p  = (ya ^ xb)  mod p
        
      ZZ = (yb ^ xa)  mod p  = (ya ^ xb)  mod p
        

where ^ denotes exponentiation.

其中^表示幂运算。

      ya is Party A's public key; ya = g ^ xa mod p
      yb is Party B's public key; yb = g ^ xb mod p
      xa is Party A's private key; xa is in the interval [2, (q - 2)]
      xb is Party B's private key; xb is in the interval [2, (q - 2)]
      p is a large prime
      g = h^((p-1)/q) mod p, where
      h is any integer with 1 < h < p-1 such that h^((p-1)/q) mod p > 1
            (g has order q mod p)
      q is a large prime
      j a large integer such that p=q*j + 1
        
      ya is Party A's public key; ya = g ^ xa mod p
      yb is Party B's public key; yb = g ^ xb mod p
      xa is Party A's private key; xa is in the interval [2, (q - 2)]
      xb is Party B's private key; xb is in the interval [2, (q - 2)]
      p is a large prime
      g = h^((p-1)/q) mod p, where
      h is any integer with 1 < h < p-1 such that h^((p-1)/q) mod p > 1
            (g has order q mod p)
      q is a large prime
      j a large integer such that p=q*j + 1
        

In this discussion, a "static" public key is one that is certified and is used for more than one key agreement, and an "ephemeral" public key is one that is not certified but is used only one time.

在此讨论中,“静态”公钥是经过认证并用于多个密钥协议的公钥,“临时”公钥是未经认证但仅使用一次的公钥。

The order of an integer y modulo p is the smallest value of x greater than 1 such that y^x mod p = 1.

整数y模p的阶数是x大于1的最小值,因此y^x模p=1。

1.2 Brief Description of Attack
1.2 攻击简介

For a complete description of these attacks see [LAW] and [LIM].

有关这些攻击的完整描述,请参见[LAW]和[LIM]。

If the other party in an execution of the Diffie-Hellman key agreement method has a public key not of the form described above, but of small order (where small means less than q) then he/she may be able to obtain information about the user's private key. In particular, if information on whether or not a given decryption was successful is available, if ciphertext encrypted with the agreed upon key is available, or if a MAC computed with the agreed upon key is available, information about the user's private key can be obtained.

如果执行Diffie-Hellman密钥协议方法的另一方具有不是上述形式的公钥,而是小数量的公钥(其中小数量意味着小于q),则他/她可能能够获得关于用户私钥的信息。特别地,如果关于给定解密是否成功的信息可用,如果使用约定密钥加密的密文可用,或者如果使用约定密钥计算的MAC可用,则可以获得关于用户私钥的信息。

Assume Party A has a valid public key ya and that Party B has a public key yb that is not of the form described in Section 1.1, rather yb has order r, where r is much less than q. Thus yb^r=1 mod p. Now, when Party A produces ZZ as yb^xa mod p, there will only be r possible values for ZZ instead of q-3 possible values. At this point Party B does not know the value ZZ, but may be able to exhaustively search for it.

假设甲方有一个有效的公钥ya,而乙方有一个公钥yb,其形式与第1.1节所述不同,而yb的顺序为r,其中r远小于q。因此yb^r=1模p。现在,当甲方以yb^xa mod p的形式生产ZZ时,ZZ的可能值将只有r,而不是q-3。此时,乙方不知道ZZ的值,但可能能够彻底搜索该值。

If Party A encrypts plaintext with this value and makes that ciphertext available to Party B, Party B only needs to exhaustively search through r possibilities to determine which key produced the ciphertext. When the correct one is found, this gives information about the value of xa modulo r. Similarly, if Party A uses ZZ to decrypt a ciphertext and Party B is able to determine whether or not decryption was performed correctly, then information about xa can be obtained. The actual number of messages that must be sent or received for these attacks to be successful will depend on the structure of the prime p. However, it is not unreasonable to expect that the entire private key could be determined after as few as one hundred messages.

如果甲方使用该值对明文进行加密并使该密文可供乙方使用,乙方只需彻底搜索r个可能性,以确定产生该密文的密钥。当找到正确的值时,这将提供有关xa模r值的信息。类似地,如果甲方使用ZZ解密密文,并且乙方能够确定解密是否正确执行,则可以获得关于xa的信息。要使这些攻击成功,必须发送或接收的消息的实际数量将取决于prime p的结构。然而,期望仅在一百条消息之后就可以确定整个私钥并不是不合理的。

A similar attack can be mounted if Party B chooses a public key of the form yb=g^xb*f, where f is an element of small order. In this situation Party A will compute ZZ=yb^xa=g^(xa*xb)*f^xa mod p. Again, Party B can compute g^(xa*xb) and can therefore exhaust the small number of possible values of f^xa mod p to determine information about xa.

如果乙方选择形式为yb=g^xb*f的公钥,其中f是小阶元素,则可发起类似的攻击。在这种情况下,甲方将计算ZZ=yb^xa=g^(xa*xb)*f^xa mod p。同样,乙方可以计算g^(xa*xb),因此可以使用少量可能的f^xa mod p值来确定关于xa的信息。

An attack is also possible if Party B has a public key yb of order r where r factors into small integers but is not necessarily a small integer itself. In this case, the attacker needs to know the value ZZ computed by Party A. From this value Party B can solve for Party A's private key modulo r using the Pohlig-Hellman [PH] algorithm.

如果乙方拥有r阶公钥yb,其中r因子为小整数,但不一定是小整数,则也可能发生攻击。在这种情况下,攻击者需要知道甲方计算的ZZ值。根据该值,乙方可以使用Pohlig-Hellman[PH]算法求解甲方的私钥模r。

However, this attack is not as practical as the cases already presented, where information about the private key is recovered from the *use* of ZZ, rather than ZZ itself, by exhaustive search.

然而,这种攻击不像已经介绍的情况那样实用,在这种情况下,通过彻底搜索,从“使用”ZZ而不是ZZ本身恢复有关私钥的信息。

2. Situations Where Protection Is Necessary
2. 需要保护的情况

This section describes the situations in which the sender of a message should obtain protection against this type of attack and also those situations in which the receiver of a message should obtain protection. Each entity may decide independently whether it requires protection from these attacks.

本节描述了消息发送方应获得针对此类攻击的保护的情况,以及消息接收方应获得保护的情况。每个实体都可以独立决定是否需要保护免受这些攻击。

This discussion assumes that the recipient's key pair is static, as is always the case in [RFC2631].

本讨论假设收件人的密钥对是静态的,就像[RFC2631]中的情况一样。

2.1 Message Sender
2.1 消息发送者

This section describes situations in which the message sender should be protected.

本节介绍应保护邮件发件人的情况。

If the sender's key is ephemeral, (i.e. ephemeral-static Diffie-Hellman is being used), then no protection is necessary. In this situation only the recipients of the message can obtain the plaintext and corresponding ciphertext and therefore determine information about the private key using the "small-subgroup" attacks. However, the recipients can always decrypt the message and since the sender's key is ephemeral, even if the recipient can learn the entire private key no other messages are at risk. Notice here that if two or more recipients have selected the same domain parameters (p,q,g) then the same ephemeral public key can be used for all of them. Since the key is ephemeral and only associated with a message that the recipients can already decrypt, no interesting attacks are possible.

如果发送方的密钥是短暂的(即使用短暂的静态Diffie Hellman),则无需保护。在这种情况下,只有消息的接收者才能获得明文和相应的密文,从而使用“小子组”攻击确定有关私钥的信息。但是,收件人始终可以解密邮件,并且由于发件人的密钥是短暂的,因此即使收件人可以了解整个私钥,其他邮件也不会有风险。请注意,如果两个或多个收件人选择了相同的域参数(p、q、g),则相同的临时公钥可用于所有这些域参数。由于密钥是短暂的,并且只与收件人已经可以解密的消息关联,因此不可能发生有趣的攻击。

If the sender's key is static (i.e. static-static Diffie-Hellman is being used), then protection is necessary because in this situation a recipient mounting a small-subgroup attack may be able to obtain the plaintext from another recipient (perhaps one with a valid public key also controlled by the recipient) and therefore could obtain information about the private key. Moreover, the attacker does not need to know the plaintext to test whether a key is correct, provided that the plaintext has sufficient redundancy (e.g., ASCII). This information could then be used to attack other messages protected with the same static key.

如果发送方的密钥是静态的(即使用静态Diffie-Hellman),则需要进行保护,因为在这种情况下,发起小规模子组攻击的接收方可能能够从另一个接收方(可能是具有有效公钥的接收方)获得明文因此可以获取有关私钥的信息。此外,如果明文具有足够的冗余(例如ASCII),攻击者不需要知道明文来测试密钥是否正确。然后,此信息可用于攻击使用相同静态密钥保护的其他消息。

2.2 Message Recipient
2.2 邮件收件人

This section describes situations in which the message recipient should be protected.

本节介绍应保护邮件收件人的情况。

If absolutely no information on the decryption of the ciphertext is available to any other party than the recipient, then protection is not necessary because this attack requires information on whether the decryption was successful to be sent to the attacker. So, no protective measures are necessary if the implementation ensures that no information about the decryption can leak out. However, protection may be warranted if human users may give this information to the sender via out of band means (e.g. through telephone conversations).

如果收件人以外的任何其他方完全没有关于密文解密的信息,则无需进行保护,因为此攻击需要有关解密是否成功发送给攻击者的信息。因此,如果实现确保解密信息不会泄漏,则无需采取保护措施。但是,如果人类用户可以通过带外方式(例如通过电话对话)向发送者提供此信息,则可能需要保护。

If information on the decryption is available to any other party, then protection is necessary. In particular, protection is necessary if any protocol event allows any other party to conclude that decryption was successful. Such events include replies and returning signed receipts.

如果解密信息可供任何其他方使用,则需要保护。特别是,如果任何协议事件允许任何其他方得出解密成功的结论,则需要进行保护。此类事件包括回复和返回签名收据。

3. Methods Of Protection
3. 保护方法

This section describes five protective measures that senders and recipients of messages can use to protect themselves from "small-subgroup" attacks.

本节介绍五种保护措施,邮件的发件人和收件人可以使用这些措施来保护自己免受“小子组”攻击。

Implementers should note that some of the procedures described in this section may be the subject of patents or pending patents.

实施者应注意,本节中描述的一些程序可能是专利或未决专利的主题。

3.1 Public Key Validation
3.1 公钥验证

This method is described in Section 2.1.5 of [RFC2631], and its description is repeated here. If this method is used, it should be used to validate public keys of the other party prior to computing the shared secret ZZ. The public key to be validated is y.

[RFC2631]第2.1.5节对该方法进行了描述,此处重复其描述。如果使用此方法,则应在计算共享密钥ZZ之前使用此方法验证另一方的公钥。要验证的公钥是y。

1. Verify that y lies within the interval [2,p-1]. If it does not, the key is invalid. 2. Compute y^q mod p. If the result == 1, the key is valid. Otherwise the key is invalid.

1. 确认y位于区间[2,p-1]内。如果没有,则密钥无效。2.计算y^q模p。如果结果==1,则该键有效。否则,密钥无效。

3.2 CA Performs Public Key Validation
3.2 CA执行公钥验证

The Certification Authority (CA) could perform the Public Key Validation method described in Section 3.1 prior to signing and issuing a certificate containing a Diffie-Hellman public key. In this way, any party using the public key can be assured that a

在签署和颁发包含Diffie-Hellman公钥的证书之前,证书颁发机构(CA)可以执行第3.1节中描述的公钥验证方法。这样,使用公钥的任何一方都可以确保

trusted third party has already performed the key validation process. This method is only viable for static public keys. When Static-Static Diffie-Hellman is employed, both the sender and recipient are protected when the CA has performed public key validation. However, when Ephemeral-Static Diffie-Hellman is employed, only the sender can be protected by having the CA perform public key validation. Since the sender generates an ephemeral public key, the CA cannot perform the validation on that public key.

受信任的第三方已执行密钥验证过程。此方法仅适用于静态公钥。当使用静态Diffie-Hellman时,当CA执行公钥验证时,发送方和接收方都受到保护。然而,当使用临时静态Diffie-Hellman时,只有发送方可以通过让CA执行公钥验证来保护。由于发送方生成临时公钥,CA无法对该公钥执行验证。

In the case of a static public key a method must exist to assure the user that the CA has actually performed this verification. The CA can notify certificate users that it has performed the validation by reference to the CA's Certificate Policy (CP) and Certification Practice Statement (CPS) [RFC2527] or through extensions in the certificate.

在静态公钥的情况下,必须存在一种方法来确保用户CA已实际执行此验证。CA可通过参考CA的证书政策(CP)和认证实践声明(CPS)[RFC2527]或通过证书中的扩展通知证书用户其已执行验证。

3.3 Choice of Prime p
3.3 素数p的选择

The prime p could be chosen such that p-1=2*q*k where k is a large prime or is the product of large primes (large means greater than or equal to q). This will prevent an attacker from being able to find an element (other than 1 and p-1) of small order modulo p, thus thwarting the small-subgroup attack. One method to produce primes of this form is to run the prime generation algorithm multiple times until an appropriate prime is obtained. As an example, the value of k could be tested for primality. If k is prime, then the value of p could be accepted, otherwise the prime generation algorithm would be run again, until a value of p is produced with k prime.

可以选择素数p,使得p-1=2*q*k,其中k是大素数或是大素数的乘积(大意味着大于或等于q)。这将防止攻击者能够找到小阶模p的元素(1和p-1除外),从而挫败小子组攻击。产生这种形式素数的一种方法是多次运行素数生成算法,直到获得合适的素数。例如,可以测试k值的素性。如果k是素数,则可以接受p的值,否则将再次运行素数生成算法,直到用k素数生成p的值。

However, since with primes of this form there is still an element of order 2 (i.e. p-1), one bit of the private key could still be lost. Thus, this method may not be appropriate in circumstances where the loss of a single bit of the private key is a concern.

然而,由于这种形式的素数仍然有一个2阶元素(即p-1),因此私钥的一位仍然可能丢失。因此,在关注私钥的单个比特的丢失的情况下,该方法可能不合适。

Another method to produce primes of this form is to choose the prime p such that p = 2*q*k + 1 where k is small (i.e. only a few bits). In this case, the leakage due to a small subgroup attack will be only a few bits. Again, this would not be appropriate for circumstances where the loss of even a few bits of the private key is a concern. In this approach, q is large. Note that in DSA, q is limited to 160 bits for performance reasons, but need not be the case for Diffie-Hellman.

产生这种形式素数的另一种方法是选择素数p,使得p=2*q*k+1,其中k很小(即,只有几位)。在这种情况下,由于小的子组攻击而导致的泄漏将仅为几位。同样,这也不适用于担心私钥丢失的情况。在这种方法中,q很大。请注意,在DSA中,出于性能原因,q限制为160位,但Diffie-Hellman不一定如此。

Additionally, other methods (i.e. public key validation) can be combined with this method in order to prevent the loss of a few bits of the private key.

此外,可以将其他方法(即公钥验证)与该方法相结合,以防止私钥的一些位丢失。

3.4 Compatible Cofactor Exponentiation
3.4 相容余因子指数化

This method of protection is specified in [P1363] and [KALISKI]. It involves modifying the computation of ZZ by including j (the cofactor) in the computations and is compatible with ordinary Diffie-Hellman when both parties' public keys are valid. If a party's public key is invalid, then the resulting ZZ will either be 1 or an element of order q; the small subgroup elements will either be detected or cancelled. This method requires that gcd(j,q)=1.

[P1363]和[KALISKI]中规定了这种保护方法。它涉及通过在计算中包含j(辅因子)来修改ZZ的计算,并且当双方的公钥有效时,它与普通Diffie-Hellman兼容。如果一方的公钥无效,则结果ZZ将为1或顺序q的元素;将检测或取消小的子组元素。该方法要求gcd(j,q)=1。

Instead of computing ZZ as ZZ=yb^xa mod p, Party A would compute it as ZZ=(yb^j)^c mod p where c=j^(-1)*xa mod q. (Similarly for Party B.)

甲方不计算ZZ为ZZ=yb^xa mod p,而是将其计算为ZZ=(yb^j)^c mod p,其中c=j^(-1)*xa mod q。(乙方亦同)

If the resulting value ZZ satisfies ZZ==1, then the key agreement should be abandoned because the public key being used is invalid.

如果结果值ZZ满足ZZ==1,则应放弃密钥协议,因为所使用的公钥无效。

Note that when j is larger than q, as is usually the case with Diffie-Hellman, this method is less efficient than the method of Section 3.1.

请注意,当j大于q时,如Diffie-Hellman通常的情况,该方法的效率低于第3.1节的方法。

3.5 Non-compatible Cofactor Exponentiation
3.5 非相容辅因子指数化

This method of protection is specified in [P1363]. Similar to the method of Section 3.4, it involves modifying the computation of ZZ by including j (the cofactor) in the computations. If a party's public key is invalid, then the resulting ZZ will either be 1 or an element of order q; the small subgroup elements will either be detected or cancelled. This method requires that gcd(j,q)=1.

[P1363]中规定了这种保护方法。与第3.4节的方法类似,它涉及通过在计算中包含j(辅因子)来修改ZZ的计算。如果一方的公钥无效,则结果ZZ将为1或顺序q的元素;将检测或取消小的子组元素。该方法要求gcd(j,q)=1。

Instead of computing ZZ as ZZ=yb^xa mod p, Party A would compute it as ZZ=(yb^j)^xa mod p. (Similarly for Party B.) However, with this method the resulting ZZ value is different from what is computed in [RFC2631] and therefore is not interoperable with implementations conformant to [RFC2631].

甲方不将ZZ计算为ZZ=yb^xa mod p,而将其计算为ZZ=(yb^j)^xa mod p。(同样适用于乙方)但是,使用该方法所得的ZZ值与[RFC2631]中计算的值不同,因此与符合[RFC2631]的实现不可互操作。

If the resulting value ZZ satisfies ZZ==1, then the key agreement should be abandoned because the public key being used is invalid.

如果结果值ZZ满足ZZ==1,则应放弃密钥协议,因为所使用的公钥无效。

Note that when j is larger than q, as is usually the case with Diffie-Hellman, this method is less efficient than the method of Section 3.1.

请注意,当j大于q时,如Diffie-Hellman通常的情况,该方法的效率低于第3.1节的方法。

4. Ephemeral-Ephemeral Key Agreement
4. 临时密钥协议

This situation is when both the sender and recipient of a message are using ephemeral keys. While this situation is not possible in S/MIME, it might be used in other protocol environments. Thus we will briefly discuss protection for this case as well.

这种情况是当消息的发送者和接收者都使用临时密钥时。虽然这种情况在S/MIME中是不可能的,但也可以在其他协议环境中使用。因此,我们也将简要讨论这种情况下的保护。

Implementers should note that some of the procedures described in this section may be the subject of patents or pending patents.

实施者应注意,本节中描述的一些程序可能是专利或未决专利的主题。

Ephemeral-ephemeral key agreement gives an attacker more flexibility since both parties' public keys can be changed and they can be coerced into computing the same key from a small space. However, in the ephemeral-static case, only the sender's public key can be changed, and only the recipient can be coerced by an outside attacker into computing a key from a small space.

临时密钥协议为攻击者提供了更大的灵活性,因为双方的公钥都可以更改,并且可以强制他们从一个小空间计算相同的密钥。然而,在短暂的静态情况下,只有发送方的公钥可以更改,只有接收方可以被外部攻击者强制从一个小空间计算密钥。

Thus, in some ephemeral-ephemeral key agreements protection may be necessary for both entities. One possibility is that the attacker could modify both parties' public key so as to make their shared key predictable. For example, the attacker could replace both ya and yb with some element of small order, say -1. Then, with a certain probability, both the sender and receiver would compute the same shared value that comes from some small, easily exhaustible set.

因此,在一些临时密钥协议中,两个实体都可能需要保护。一种可能性是攻击者可以修改双方的公钥,以使其共享密钥可预测。例如,攻击者可以用少量元素(例如-1)替换ya和yb。然后,在一定的概率下,发送方和接收方都会计算来自某个小的、容易耗尽的集合的相同共享值。

Note that in this situation if protection was obtained from the methods of Section 3.3, then each user must ensure that the other party's public key does not come from the small set of elements of small order. This can be done either by checking a list of such elements, or by additionally applying the methods of Sections 3.1, 3.4 or 3.5.

请注意,在这种情况下,如果通过第3.3节的方法获得保护,则每个用户必须确保另一方的公钥不来自小顺序的小元素集。这可以通过检查此类元素的列表来实现,也可以通过另外应用第3.1、3.4或3.5节的方法来实现。

Protection from these attacks is not necessary however if the other party's ephemeral public key has been authenticated. The authentication may be in the form of a signature, MAC, or any other integrity protection mechanism. An example of this is in the Station-To-Station protocol [STS]. Since the owner authenticates the public key, a third party cannot modify it and therefore cannot mount an attack. Thus, the only person that could attack an entity's private key is the other authenticated entity in the key agreement. However, since both public keys are ephemeral, they only protect the current session that the attacker would have access to anyway.

但是,如果另一方的临时公钥已通过身份验证,则无需保护其免受这些攻击。认证可以是签名、MAC或任何其他完整性保护机制的形式。这方面的一个例子是站对站协议[STS]。由于所有者对公钥进行身份验证,第三方无法修改公钥,因此无法发起攻击。因此,唯一可以攻击实体私钥的人是密钥协议中的另一个经过身份验证的实体。但是,由于这两个公钥都是短暂的,因此它们只保护攻击者无论如何都可以访问的当前会话。

5. Security Considerations
5. 安全考虑

This entire document addresses security considerations in the implementation of Diffie-Hellman key agreement.

整个文档解决了Diffie-Hellman密钥协议实施过程中的安全问题。

6. Intellectual Property Rights
6. 知识产权

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息,请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。

7. References
7. 工具书类

[KALISKI] B.S. Kaliski, Jr., "Compatible cofactor multiplication for Diffie-Hellman primitives", Electronics Letters, vol. 34, no. 25, December 10, 1998, pp. 2396-2397.

[KALISKI]B.S.KALISKI,Jr.,“Diffie-Hellman基元的相容辅因子乘法”,《电子通讯》,第34卷,第25期,1998年12月10日,第2396-2397页。

[LAW] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, "An efficient protocol for authenticated key agreement", Technical report CORR 98-05, University of Waterloo, 1998.

L. Law,A. Menezes,M. Qu,J. Solinas和S. Vanstone,“认证密钥协议的有效协议”,技术报告CORR 98-05,滑铁卢大学,1998。

[LIM] C.H. Lim and P.J. Lee, "A key recovery attack on discrete log- based schemes using a prime order subgroup", B.S. Kaliski, Jr., editor, Advances in Cryptology - Crypto '97, Lecture Notes in Computer Science, vol. 1295, 1997, Springer-Verlag, pp. 249-263.

[LIM]C.H.LIM和P.J.Lee,“使用素数阶子群对离散的基于日志的方案的密钥恢复攻击”,B.S.Kaliski,Jr.,编辑,《密码学的进展-加密'97》,计算机科学讲稿,第1295卷,1997年,Springer Verlag,第249-263页。

[P1363] IEEE P1363, Standard Specifications for Public Key Cryptography, 1998, work in progress.

[P1363]IEEE P1363,公钥密码的标准规范,1998,正在进行中。

[PH] S.C Pohlig and M.E. Hellman, "An improved algorithm for computing logarithms over GF(p) and its cryptographic significance", IEEE Transactions on Information Theory, vol. 24, 1972, pp. 106-110.

[PH]S.C Pohlig和M.E.Hellman,“计算GF(p)上对数的改进算法及其密码学意义”,《IEEE信息论学报》,1972年第24卷,第106-110页。

[RFC2527] Chokhani, S. and W. Ford, "Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices Framework", RFC 2527, March 1999.

[RFC2527]Chokhani,S.和W.Ford,“互联网X.509公钥基础设施、证书政策和认证实践框架”,RFC 2527,1999年3月。

[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.

[RFC2630]Housley,R.,“加密消息语法”,RFC2630,1999年6月。

[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.

[RFC2631]Rescorla,E.,“Diffie-Hellman密钥协商方法”,RFC 26311999年6月。

[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

[RFC2633]Ramsdell,B.,“S/MIME版本3消息规范”,RFC 2633,1999年6月。

[STS] W. Diffie, P.C. van Oorschot and M. Wiener, "Authentication and authenticated key exchanges", Designs, Codes and Cryptography, vol. 2, 1992, pp. 107-125.

[STS]W.Diffie,P.C.van Oorschot和M.Wiener,“认证和认证密钥交换”,设计、代码和密码学,第2卷,1992年,第107-125页。

8. Author's Address
8. 作者地址

Robert Zuccherato Entrust Technologies 750 Heron Road Ottawa, Ontario Canada K1V 1A7

加拿大安大略省渥太华Heron路750号罗伯特·祖切拉托委托技术公司K1V 1A7

   EMail: robert.zuccherato@entrust.com
        
   EMail: robert.zuccherato@entrust.com
        
9. Full Copyright Statement
9. 完整版权声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

版权所有(C)互联网协会(2000年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。