 1/draftietfsmimesmallsubgroup01.txt 20060205 01:53:46.000000000 +0100
+++ 2/draftietfsmimesmallsubgroup02.txt 20060205 01:53:47.000000000 +0100
@@ 1,17 +1,17 @@
Internet Draft R. Zuccherato(Entrust Technologies)
S/MIME Working Group June 1999
+S/MIME Working Group November 1999
expires in six months
Methods for Avoiding the "SmallSubgroup" Attacks on the DiffieHellman
Key Agreement Method for S/MIME

+
Status of this Memo
This document is an InternetDraft and is in full conformance with
all provisions of Section 10 of RFC2026.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as InternetDrafts.
@@ 43,31 +43,35 @@
"smallsubgroup" type attacks are required when using DiffieHellman key
agreement [x942] in implementations of S/MIME version 3 [CMS, MSG].
Thus, the ephemeralstatic modes of DiffieHellman will be focused on.
The situations that require protection are those in which an attacker
could determine a substantial portion (i.e. more than a few bits) of a
user's private key.
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, increased key size, and possibly the licensing of
+generation time, and possibly the licensing of encumbered technologies.
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 required.
+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 required.
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). 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.
+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 draft may also be used to provide
+protection from similar attacks on elliptic curve based DiffieHellman.
1.1 Notation
In this document we will use the same notation as in [x942]. In
particular the shared secret ZZ is generated as follows:
ZZ = g ^ (xb * xa) mod p
Note that the individual parties actually perform the computations:
@@ 88,36 +92,38 @@
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.
1.2 Brief Description of Attack
For a complete description of these attacks see [LAW] and [LIM].
+For a complete description of these attacks see [LAW98] and [LIM].
If the other party in an execution of the DiffieHellman 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, or if
ciphertext encrypted with the agreed upon key is available, information
about the user's private key can be obtained.
+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.
Assume Party A has a properly formatted 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<