IEEE P1363.2 / D2000-11-06
IEEE P1363.2 / D2000-11-09 (strawman draft)
Standard Specifications
for Public Key Cryptography:
Password-based Techniques
Abstract. This standard specifies additional public-key cryptographic techniques beyond those in IEEE Std
1363-2000. It is intended as a companion standard to IEEE Std 1363-2000.
Keywords. Public-key cryptography; password; authentication; key agreement;
Copyright © 2000 by the Institute of Electrical and Electronics Engineers, Inc.
345 East 47th Street
New York, NY 10017, USA
All rights reserved.
This is an unapproved draft of a proposed IEEE Standard, subject to change. Permission is hereby granted
for IEEE Standards Committee participants to reproduce this document for purposes of IEEE
standardization activities. No other use is encouraged at this time. Other entities seeking permission to
reproduce portions of this document for these or other uses should contact the document editor and the
IEEE P1363 Working Group Chair, and must contact the IEEE Standards Department for the appropriate
license. Use of information contained in the unapproved draft is at your own risk.
IEEE Standards Department
Copyright and Permissions
445 Hoes Lane, P. O. Box 1331
Piscataway, NJ 08855-1331, USA
EDITOR’S NOTE—This draft is intended to provide a basis for discussing the document structure that can best present
techniques within the scope of this project. To illustrate the issues in constructing this document, it has been helpful to
include specific examples of techniques, to provide a concrete basis for discussion of structure and presentation issues.
The primitives, protocols, and schemes described herein may be extensively changed or deleted, and serve largely as
placeholders in this document to illustrate some of the range and variety of techniques that may eventually be included
in P1363.2. For this draft, the editor is primarily encouraging comments and discussion of how the document can best
describe such techniques as a class, rather than on the technical details, accuracy, or merits of any specific example.
Other comments and suggestions are welcome too. The document editor is David Jablon, who can be reached at
<dpj@world.std.com>.
1
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
Introduction
EDITOR’S NOTE—To be added in a subsequent draft.
Contents
1. OVERVIEW ............................................................................................................................................. 4
1.1 SCOPE .................................................................................................................................................... 4
1.2 PURPOSE................................................................................................................................................ 4
1.3 ORGANIZATION OF THE DOCUMENT....................................................................................................... 4
2. REFERENCES ......................................................................................................................................... 5
3. DEFINITIONS .......................................................................................................................................... 5
4. TYPES OF CRYPTOGRAPHIC TECHNIQUES ................................................................................. 5
4.1 GENERAL MODEL .................................................................................................................................. 5
4.2 PRIMITIVES ............................................................................................................................................ 6
4.3 SCHEMES ............................................................................................................................................... 6
4.4 ADDITIONAL METHODS ......................................................................................................................... 7
4.5 PROTOCOLS ........................................................................................................................................... 7
4.6 TABLE SUMMARY .................................................................................................................................. 8
5. MATHEMATICAL CONVENTIONS ................................................................................................... 9
6. PRIMITIVES BASED ON THE DISCRETE LOGARITHM PROBLEM ......................................... 9
6.1 THE DL SETTING ................................................................................................................................... 9
6.1.1 Notation ......................................................................................................................................... 9
6.1.2 DL domain parameters ................................................................................................................ 10
6.1.3 DL password-entangled key pairs .................................................. Error! Bookmark not defined.
6.2 PRIMITIVES .......................................................................................................................................... 10
6.2.1 DLAVDP-1 .................................................................................................................................. 10
6.2.2 DLPESVDP-SPEKE .................................................................................................................... 11
6.2.3 DLPESVDP-PAK ........................................................................................................................ 11
7. PRIMITIVES BASED ON THE ELLIPTIC CURVE DISCRETE LOGARITHM PROBLEM .... 12
7.2 PRIMITIVES .......................................................................................................................................... 12
7.2.1 ECAVDP-1 .................................................................................................................................. 12
7.2.2 ECPESVDP-SPEKE .................................................................................................................... 12
7.2.3 ECPESVDP-PAK ........................................................................................................................ 13
8. PRIMITIVES BASED ON THE INTEGER FACTORIZATION PROBLEM ................................ 13
9. PASSWORD-AUTHENTICATED KEY AGREEMENT PROTOCOLS ......................................... 13
9.1 GENERAL MODEL ................................................................................................................................ 13
9.2 DL/ECSTPAKAP-SPEKE .................................................................................................................. 14
9.3 DL/ECSTPAKAP-PAK ...................................................................................................................... 15
9.4 DL/ECATPAKAP-SPEKE ................................................................................................................. 15
9.5 DL/ECATPAKAP-PAK ..................................................................................................................... 16
9.6 DL/ECPAKDP-1 ................................................................................................................................ 16
9.6.1 Key negotiation for Alice ............................................................................................................. 16
9.6.2 Key negotiation for Bob............................................................................................................... 16
2
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
9.6.3 Key confirmation for Alice .......................................................................................................... 16
9.6.4 Key confirmation for Bob ............................................................................................................ 16
9.6.5 Notes ............................................................................................................................................ 17
13. AUXILIARY FUNCTIONS ................................................................................................................. 17
ANNEX A (INFORMATIVE) NUMBER-THEORETIC BACKGROUND ......................................... 17
ANNEX B (NORMATIVE) CONFORMANCE ...................................................................................... 17
ANNEX C (INFORMATIVE) RATIONALE .......................................................................................... 17
ANNEX D (INFORMATIVE) SECURITY CONSIDERATIONS ......................................................... 17
ANNEX E (INFORMATIVE) FORMATS............................................................................................... 17
ANNEX F (INFORMATIVE) BIBLIOGRAPHY ................................................................................... 17
3
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
1. Overview
EDITOR’S NOTE—References to IEEE P1363a and P1363b should be replaced if and when those standards are
published; description of the IEEE P1363 project as “work in progress” should be updated accordingly.
1.1 Scope
Specifications of common public-key cryptographic techniques for performing password-based
authentication and key exchange, supplemental to the techniques considered in IEEE STD 1363-2000 and
IEEE P1363a. Specifications of primitives, schemes, and protocols designed to safely utilize passwords
and other low-grade secrets as a basis for securing electronic transactions. Class of computers and
communications systems are not restricted.
EDITOR’S NOTE—Reword as full sentences and revise description of scope to reflect final document content.
1.2 Purpose
Ensuring privacy and authenticity in personal electronic transactions is a process that necessarily involves
human beings. Memorized secrets are an important factor in human authentication. Many common
cryptographic methods for authentication require large, random high-grade secret keys, yet, the secrets that
human beings can conveniently memorize and reliably reproduce tend to be low-grade secrets. Passwords
are widely used low-grade secrets that are typically not-so-random and relatively small, and introduce risks
of brute-force attack when inappropriately used as cryptographic keys.
P1363.2 will specify public-key cryptographic techniques specifically designed to safely perform passwordbased authentication and key exchange. These techniques provide a way to authenticate people and
distribute high-quality cryptographic keys for people, while preventing off-line brute-force attacks
associated with passwords. A resulting high quality key may be more confidently used in combination with
other cryptographic methods, such as symmetric encryption methods and public-key encryption,
identification, and digital signature methods. P1363.2 will provide a reference for a variety of such
password-based techniques within a suitable framework.
EDITOR’S NOTE—Change "will specify" and "will provide" to current tense in final document.
It is not the purpose of this document to mandate any particular set of password-based techniques or
security requirements (including key sizes). Rather, the purpose is to provide: (1) a reference for
specification of a variety of techniques from which applications may select, (2) the appropriate theoretic
background, and (3) extensive discussion of security and implementation considerations so that a solution
provider can choose appropriate security requirements.
1.3 Organization of the Document
This standard is written as a standalone document, independent of IEEE STD 1363-2000, but heavily referencing
material in that document. Some familiarity with IEEE STD 1363-2000 is assumed. Significant background material
from and techniques defined in IEEE STD 1363-2000 are referenced here.
EDITOR’S NOTE—Question: Should this document stand alone, or should it require Std 1363-2000?
EDITOR’S NOTE—Describe difference in structure to accommodate protocols.
4
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
—
—
—
—
—
—
—
Section 3, “Definitions”
Section 4, “Types of Cryptographic Techniques”
Section 5, “Mathematical Conventions”
Section 6, “Primitives Based on the Discrete Logarithm Problem”
Section 7, “Primitives Based on the Elliptic Curve Discrete Logarithm Problem”
Section 8, “Primitives Based on the Integer Factorization Problem”
Section 9, “Protocols”
The following annexes are updated:
—
—
—
—
—
Annex A (Informative), “Number-Theoretic Background”
Annex B (Normative), “Conformance”
Annex C (Informative), “Rationale”
Annex D (Informative), “Security Considerations”
Annex F (Informative), “Bibliography”
EDITOR’S NOTE—Material for other sections and annexes may be added in subsequent drafts.
2. References
3. Definitions
password entangled key set is a set containing a password (a low-grade secret), a high-grade secret private
key, and public key that is constructed in a manner that incorporates the password and the high-grade secret.
EDITOR’S NOTE—Working group comment on this definition is encouraged.
4. Types of Cryptographic Techniques
4.1 General Model
As stated in Section 1, the purpose of this standard is to provide a reference for specifications of a variety of
password-based public-key cryptographic techniques from which applications may select. Therefore, it is
desirable to define these techniques in a framework that would allow selection of techniques appropriate for
particular applications. Different types of cryptographic techniques can be viewed abstractly according to
the following general model, including primitives, schemes, protocols, and additional methods, the
definitions of which are in P1363 and are repeated here.
—
Primitives: Basic mathematical operations. Historically, they were discovered based on numbertheoretic hard problems. Primitives are not meant to achieve security just by themselves, but they
serve as building blocks for schemes.
—
Additional Methods: Other components of schemes and protocols. These include encoding methods
for schemes, key derivation functions, mask generation functions, hash functions, and other
techniques that provide security based on a broad blend of cryptographic analytic assumptions
beyond number theory.
5
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
—
Schemes: A collection of related operations combining primitives and additional methods (see
===edit===). Schemes can provide complexity-theoretic security, which is enhanced when they are
appropriately applied in protocols.
EDITOR’S NOTE—Replace all "===" sections with specific references someday.
—
Protocols: Sequences of operations to be performed by multiple parties to achieve some security
goal. Protocols can achieve desired security for applications if implemented correctly.
From an implementation viewpoint, primitives can be viewed as low-level implementations (e.g.,
implemented within cryptographic accelerators, or software modules), schemes and additional methods can
be viewed as medium-level implementations (e.g., implemented within cryptographic service libraries), and
protocols can be viewed as high-level implementations (e.g., implemented within entire sets of
applications).
In a departure from the general model of P1363, this standard defines protocols. This is because passwordbased public-key techniques require interaction between multiple participants, and the nature of the
interaction is important for protocol security. This document will describe the requirements for protocols at
an abstract level, and will not specify data transmission formats and techniques, as they tend to be
application-specific and hence are outside the scope of the standard.
General frameworks for primitives, additional methods, schemes, and protocols are provided in Sections
4.2, 4.3, 4.4, and 4.5 and specific techniques are defined in Sections ===edit=== 6 through 14. This
document will also reference techniques defined in P1363 as components for constructing cryptographic
schemes and protocols. Annex D ===edit=== discusses security considerations related to how the
techniques can be used in applications to achieve certain security attributes.
4.2 Primitives
For a general definition of "Primitive" and the format of a Primitive specification, the reader should refer to
P1363 section 4.2.
The following types of primitives are defined in this standard:
—
—
Xxx (XXXP), a component of the Xxx scheme.
Xxx (XXXP), a component of Xxx, and Xxx schemes.
EDITOR’S NOTE—Replace all "xxx" values with actual names someday.
Primitive specifications are functional specifications, not interface specifications. The format of inputs and
outputs and the procedure by which an implementation of a scheme is invoked are outside the scope of this
standard. See Annex E for more information on input and output formats.
4.3 Schemes
For a general definition of "Scheme" and the general format of a Scheme specification, the reader should
refer to P1363 section 4.3.
In a departure from P1363, schemes for selecting a private key and for obtaining another party’s public key
are used in different ways. Private keys may be selected based, in part, on a password. Public keys utilized
in this standard are typically ephemeral, and have indeterminate ownership, whereas in P1363, a party
6
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
typically needs to be assured of the true ownership of public keys. Ownership of keys in this standard is
typically only established within a larger password-based protocol.
The following types of schemes are defined in this standard:
—
Xxx Schemes (XXXS), in which xxx. The xxx may then be used for xxx (see Section xxx for the
definition of xxx).
Scheme specifications are functional specifications, not interface specifications. The format of inputs and
outputs and the procedure by which an implementation of a scheme is invoked are outside the scope of this
standard. See Annex E for more information on input and output formats.
4.4 Additional Methods
For a general definition of "Scheme" and the general format of a scheme specification, the reader should
refer to P1363 section 4.3.
This standard specifies the following additional methods:
—
Xxx Methods, which are components of xxx schemes.
—
—
Xxx Methods for Xxx (XXX)
Xxx Functions (XXXF), which are a component of xxx schemes.
—
Xxx Xxx Function (XXXF), which is used in XXX
The specified additional methods are strongly recommended for use in the schemes and protocols. The use
of an inadequate xxx method, xxx function, or xxx function may compromise the security of the scheme in
which it is used. Therefore, any implementation which chooses not to follow the recommended additional
methods for a particular scheme or protocol should perform its own thorough security analysis of the
resulting scheme.
4.5 Protocols
The following types of protocols are defined in this standard:
—
Password Authenticated Key Agreement Protocols (PAKAP), in which two parties use their
password and/or password verification data and possibly other information to agree on a shared
secret key. The shared secret key may then be used for entity authentication, symmetric
cryptography, and a wide variety of purposes.
EDITOR’S NOTE—Question: Should we include or exclude the following two categories of AP and IRP? Note that
they can be defined as higher level protocols that simply use PAKAP.
—
Authentication Protocols (AP), in which one party creates a proof that it knows a password or related
data, the proof is embodied in a message that is sent to another party, and the other party can verify
the proof using the password or related data.
—
Information Retrieval Protocol (IRP), in which one party can transmit an encrypted message to a
recipient, such that only the recipient can decrypt the message by using its password. Information
7
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
Retrieval Protocols may be used for securely retrieving remotely stored private keys to be used in
asymmetric cryptography.
Protocols in this standard are presented in a general form based on certain primitives, schemes, and
additional methods, such as xxx methods. For example, an xxx protocol is based on an xxx primitive, an
xxx scheme, and an appropriate xxx method.
Protocols also include key management operations, such as selecting a private key or obtaining another
party’s public key. For proper security, a party needs to be assured of the true owners of the keys and
domain parameters and of their validity. Generation of domain parameters and keys needs to performed
properly, and in some cases validation may need to be performed. While outside the scope of this standard,
proper key management is essential for security. It is addressed in more detail in Annex D.
EDITOR’S NOTE—Should this document also refer to P1363b as needed for validation methods?
The specification of a protocol consists of the following information:
—
—
—
protocol options, such as choices for primitives, schemes, and additional methods
one or more operations, depending on the protocol, expressed as a series of steps
conformance region recommendations for implementations conforming with the scheme (see Annex
B for more on conformance)
A protocol is different than a scheme in that it refers to messages that flow to and from other parties, where
the messages are outputs from or inputs to specific steps of the protocol. The required ordering of steps and
message flows is an important part of a protocol specification.
EDITOR’S NOTE—Comment: I think [the "required ordering" point] needs to be a little clearer. After our earlier
discussions, I was thinking about the fact that for a signature scheme for instance, there are multiple parties with an
ordering of their operations – first a signature, then a verification. Perhaps a protocol is different in that there is more
than one pass for at least one participant?
As with schemes and primitives, the protocol specifications are functional specifications, not interface
specifications. As such, the format of inputs and outputs and the procedure by which an implementation of a
protocol is invoked are outside the scope of this standard. See Annex E for more information on input and
output formats.
4.6 Table Summary
This section gives a summary of all the schemes and protocols in this standard, together with the primitives
and additional methods that are invoked within a scheme or protocol.
Scheme or Protocol
Primitives
Additional Methods
password-based key agreement
DL/ECSPBKA-1
DLAED-1 and xxx
or
ECAED-1 and xxx
8
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
5. Mathematical Conventions
For mathematical conventions, including description of our notation, representation of bit strings, octet
strings, finite field elements, and data type conversions, the reader is referred to P1363 section 5. For
convenient reference, an outline of this section is reproduced here.
P1363 Outline: 5. Mathematical Conventions
EDITOR’S NOTE—Reproduce relevant parts of P1363 outline here.
5.1 MATHEMATICAL NOTATION
5.2 BIT STRINGS AND OCTET STRINGS
5.3 FINITE FIELDS
5.3.1 Prime Finite Fields
5.3.2 Characteristic Two Finite Fields
5.4 ELLIPTIC CURVES AND POINTS
5.5 DATA TYPE CONVERSION
5.5.1 Converting Between Integers and Bit Strings (I2BSP and BS2IP)
5.5.2 Converting Between Bit Strings and Octet Strings (BS2OSP and OS2BSP)
5.5.3 Converting between Integers and Octet Strings (I2OSP and OS2IP)
5.5.4 Converting between Finite Field Elements and Octet Strings (FE2OSP and OS2FEP)
5.5.5 Converting Finite Field Elements to Integers (FE2IP)
6. Primitives Based on the Discrete Logarithm Problem
This section specifies the family of cryptographic primitives based on the discrete logarithm problem over
finite fields, also known as the DL family. We will also use the abbreviations PE for "password-entangled",
and EC for "elliptic curve". The reader is referred to P1363 section 6 for more information, an outline of
which is presented here.
P1363 Outline: 6. Primitives Based on the Discrete Logarithm Problem
EDITOR’S NOTE—Reproduce relevant parts of P1363 outline here.
6.1 THE DL SETTING
6.1.1 Notation
6.1.2 DL Domain Parameters
6.2 PRIMITIVES
6.1 The DL Setting
6.1.1 Notation
The list below introduces the notation used in Sections 6, 9, and 10. It is meant as a reference guide only;
for complete definitions of the terms listed, refer to the appropriate text. Some other symbols are also used
occasionally; they are introduced in the text where appropriate.
q
r
g
k
The size of the field used (part of the DL domain parameters)
A prime divisor of q - 1 and the order of g (part of the DL domain parameters)
An element of the field GF(q) generating a multiplicative subgroup of order r (part of the DL
domain parameters)
The value (q - 1)/r, sometimes called the cofactor (part of the DL domain parameters)
9
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
s, u, s', u' DL private keys, integers, corresponding to public keys w, v, w', and v', respectively
w, v, w', v' DL public keys, elements of GF(q), corresponding to public keys w, v, w', and v', respectively
(s, w), (u, v)
DL key pairs, ===
z, z1, z2
Shared secret values, elements of GF(q), ===
K
Shared secret key agreed upon by a key agreement scheme
f
Message representative, an integer, computed by a message encoding operation
H( )
===

a low-grade secret. Suggested constructions for  might include a hash of a password, or a hash
of a message containing a user name, user password, server name, and salt value.
NOTES
1—When keys from two parties are involved in a primitive or scheme, the symbols s, u, w, v are used to denote the
party’s own keys, and the symbols s, u, w, v are used to denote the other party’s keys.
2—Multiplication of field elements, as well as multiplication of integers, is denoted by , although this symbol may be
omitted when such omission does not cause ambiguity. The notation such as exp(w, c), where w is a field element and
c is an integer, will be used to denote raising w to the power c. The more traditional notation w c will be used if w is an
integer.
3—Throughout this section, operations on finite field elements and integers are being used. Care needs to be exercised
to distinguish integers from field elements, as operations on integers and field elements are denoted by the same
symbols. See Section 5.3 for more information on finite fields.
6.1.2 DL domain parameters
===
6.1.3 DL password-entangled key sets
For a given set of DL domain parameters a DL password entangled key set consists of a "short" password ,
a DLPE private key s, which is an integer in the range [1..q-1] and a DLPE public key w which is an
element of GF(p)*, where w is defined as follows:
DLPE-SPEKE
w = (H(1,)r)s
DLPE-PAK:
w = gs * H(1,)r
DLPE-PAKR:
w = gs * vq * H(1,), where v is a random element of GF(p)*
6.2 Primitives
===
6.2.1 DLAVDP-1
DLAVDP-1 is Discrete Logarithm Arbitrary Value Derivation Primitive, version 1. It is based on the work
of [===]. The primitive generates a random element of a group to be used as a generator of a discrete
logarithm key agreement scheme. It can be invoked in the scheme DL/ECSPBKA-1. DLAVDP-1
corresponds to step ===fill in number=== of DL/ECSPBKA-1.
Input:
10
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
—
—
the DLPE domain parameters q and r
the randomizer, which is an integer u where 1  u < r
Assumptions: DL domain parameters q and r are valid
Output:
—
the arbitrary element, which is an integer i where 1  i  q-1
Operation. The random group element is computed by the following or an equivalent sequence of steps:
1. Compute a field element i=uk
2. Output i
Conformance region recommendation. A conformance region should include:
—
at least one valid set of DL domain parameters q, r and g
6.2.2 DLPESVDP-SPEKE
DLPESVDP-SPEKE is Discrete Logarithm Password-Entangled Secret Value Derivation Primitive, SPEKE
version. It is based on the work of [===]. This primitive derives a shared secret value from one party’s
public key and another party’s private key, where the keys have the same DLPE domain parameters. If two
parties correctly execute this primitive with corresponding keys as inputs, they will produce the same
output. This primitive may be invoked by a scheme to derive a shared secret key; specifically, it may be
used with the protocols DLPEKAP-1 and DLPEKAP-2. It assumes that the input keys are valid.
Input:
- the DLPE domain parameters, q, r, and k associated with the keys s and w'
- the party's own private key s and password .
- the other party's DLPE public key w'.
Assumptions: Private key s, DL domain parameters q, r, and k are valid; w' in GF(q), gcd(k, r)=1
Output: The derived shared secret value, which is a nonzero field element z  GF(q)
Operation: The shared secret value z shall be computed by the following or an equivalent sequence of
steps:
1. If w' = 0 output "invalid public key".
2. Compute a field element z=((w')r)s.
3. Output z as the shared secret value.
6.2.3 DLPESVDP-PAK
DLPESVDP-PAK is Discrete Logarithm Password-Entangled Secret Value Derivation Primitive, PAK
version. It is based on the work of [===]. This primitive derives a shared secret value from one party's
public key and another party's private key, where the keys have the same DLPE domain parameters. If two
parties correctly execute this primitive with corresponding keys as inputs, they will produce the same
output. This primitive may be invoked by a scheme to derive a shared secret key; specifically, it may be
used with the schemes DLPEKAS-1 and DLPEKAS-2. It assumes that the input keys are valid
Input:
- the DLPE domain parameters, q, r, g associated with the keys s and w'
- the party's own private key s and password 
- the other party's DLPE public key w'
11
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
Assumptions: Private key s, DL domain parameters p, q, r, g, are valid, w' in GF(p)
Output: The derived shared value, which is a nonzero field element z in GF(p)
Operation: The shared secret value z shall be computed by the following or an equivalent sequence of
steps:
1. If w' = 0 output "invalid public key"
2. Compute a field element z=(w'/H(1, )r)s
3. Output z
7. Primitives Based on the Elliptic Curve Discrete Logarithm Problem
This section specifies the family of cryptographic primitives based on the discrete logarithm problem over
elliptic curve groups, also known as the EC family. The reader is referred to P1363 section 7 for more
information, an outline of which is presented here.
P1363 Outline: 7. Primitives Based on the Elliptic Curve Discrete Logarithm Problem
7.1 THE EC SETTING
7.1.1 Notation
7.1.2 EC Domain Parameters
7.1.3 EC Key Pairs
7.2 PRIMITIVES
EDITOR’S NOTE—Reproduce relevant parts of P1363 outline here.
7.2 Primitives
7.2.1 ECAVDP-1
ECAVDP-1 is Elliptic Curve Arbitrary Value Derivation Primitive, version 1. The primitive generates an
element of ===
Input:
—
the EC domain parameters q, a, b, r and G
—
the randomizer, which is an integer u where 1  u < r
Assumptions: EC domain parameters q, a, b, r and G are valid
Output:
—
the arbitrary value, which is an integer i where 1  i < q
Operation.
Conformance region recommendation. A conformance region should include:
—
at least one valid set of EC domain parameters q, a, b, r and G
7.2.2 ECPESVDP-SPEKE
ECPESVDP-SPEKE is Elliptic Curve Password-Entangled Secret Value Derivation Primitive, SPEKE
version. ===
12
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
7.2.3 ECPESVDP-PAK
ECPESVDP-SPEKE is Elliptic Curve Password-Entangled Secret Value Derivation Primitive, SPEKE
version. ===
8. Primitives Based on the Integer Factorization Problem
This section specifies the family of cryptographic primitives based on the integer factorization problem,
also known as the IF family. The reader is referred to P1363 section 8 for more information, an outline of
which is presented here.
P1363 Outline: 8. Primitives Based on the Integer Factorization Problem
8.1 THE IF SETTING
8.1.1 Notation
8.1.2 Domain Parameters in the IF Family
8.1.3 Keys in the IF Family
8.2 PRIMITIVES
8.2.1 IF Private Key Operation
EDITOR’S NOTE—Reproduce relevant parts of P1363 outline here.
9. Password-Authenticated Key Agreement Protocols
The general model for key agreement protocols is given in Section 9.1. === edit === xxx specific schemes
and their allowable options are given in Sections 9.2, 9.3, and 9.4.
The password-authenticated key agreement protocols described here include a variety of methods, such as
protocols where both parties contribute ephemeral random data to a mutually derived key, and static key
distribution protocols where one party transmits a predetermined key to another.
9.1 General Model
All key exchange protocols defined in this section have the following form:
1.
2.
3.
4.
Two parties exchange messages where at least one message contains a password-entangled public
keys === built using message generation schemes.
(Optional.) Validate the messages and associated set of domain parameters, if any. If validation
fails, output “invalid” and stop. (Note 2.)
Apply a key generation scheme utilizing data from the received messages.
Output the negotiated shared key.
Message and key generation schemes will incorporate certain cryptographic operations to the message, the
public key, and the encoding parameters, if any, to produce the message, or the negotiated key.
EDITOR’S NOTE—Comment: We should probably explicitly define at the beginning what message generation
schemes and key generation schemes are.
A message generation operation has the following form:
1.
Select a valid private key (together with its set of domain parameters, if any) for the operation.
13
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
2.
3.
Apply certain cryptographic operations to the private key, and the encoding parameters, if any, and to
the received message, if any, to construct the message.
Output the message or “invalid” according to the result of step 2.
A key generation operation has the following form:
1.
2.
3.
Select a valid private key (together with its set of domain parameters, if any) for the operation.
Apply certain cryptographic operations to the received messages, the private key, and the encoding
parameters, if any, to generate or recover a key.
Output the key or “invalid” according to the result of step 2.
NOTES
1—(Authentication of ownership.) The process of obtaining the recipient’s public key (step 1 of encryption) may
involve authentication of ownership of the public key, as further described in D.3.2 and D.5.3.4. This may be achieved
by verifying a certificate or by other means. The means by which the key (or the certificate containing it) is obtained
may vary, and may include the recipient sending the key to the sender, or the sender obtaining the key from a third
party or from a local database.
2—(Domain parameter and key validation.) Since the underlying primitives generally assume that the domain
parameters (if any) and public key are valid, the result of a primitive may be undefined otherwise. Consequently, it is
recommended that the sender validate the public key (and its associated set of domain parameters, if any) in step 1,
unless the risk of operating on invalid domain parameters or keys is mitigated by other means, as discussed further in
D.3.3 and D.5.3.5. Examples of “other means” include validation within the supporting key management.
3—(Error conditions.) The sender’s and recipient’s steps may produce errors under certain conditions, such as the
following:
—
—
—
—
—
public key not found in sender’s step 1
public key not valid in sender’s step 2
message, encoding parameters, or public key not supported in sender’s step 3
private key not found in recipient’s step 1
message, encoding parameters, or private key not supported in recipient’s step 2
Such error conditions should be detected and handled appropriately by an implementation, but the specific methods for
detecting and handling them is outside of the scope of this standard.
9.2 DL/ECSTPAKAP-SPEKE
DL/ECSTPAKAP is Discrete Logarithm and Elliptic Curve Symmetric Trust Password-Authenticated Key
Agreement Protocol, version SPEKE. It is based on the work of [Jab96].
This protocol uses a password to derive the generator for a Diffie-Hellman key exchange.
Alice, Bob:
A.1) outbound m1 = g()^x
B.1) inbound m2
B.2) K = m2^x
Notes:
The method is symmetric, in that the roles of Alice and Bob are identical. The relative order of steps A.1
and B.1 is not specified.
This protocol has the following form:
14
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
Uses specified fixed group parameters. DL: {k, q} q = kr+1, EC: {q, k, r} ===
Uses a primitive to derive a base element from a password.
Uses a primitive to obtain a random exponent in a specified range.
Uses a primitive to derive an outbound message from base group element and random exponent.
Transmits the outbound message to another party.
Receives an inbound message from the other party.
Optionally validates the inbound message, and aborts if invalid.
Uses a primitive to derive a negotiated key from random exponent and the inbound message.
Optionally validates the negotiated key, and aborts if invalid.
Constraints on key confirmation
The inbound key confirmation message must not be derivable from an earlier outbound key confirmation
message.
EDITOR’S NOTE—How does one demonstrate this? There should probably be a pointer to a section where this is
discussed.
No constraint on when outbound message may be sent. m1 may be sent, either before step B.1, or after step
B.2.
Notes
The range of random exponent may be restricted to a subset of numbers in a range, as in the even numbers
between 0 and xxx. In this case, the validation step may be different. For example, when using a group of
order 2q, and even exponents, one of two validation steps may be used, to check whether the inbound
message is the identity element, or to check whether the negotiated key is the identity element.
Qualified configurations
Group of order kq, base of order kq, exponent in range of even numbers, abort if kth power of inbound
message == identity.
Group of order kq, base of order kq, exponent in range of even numbers, abort if kth power of negotiated
key == identity.
Group of order 2q, base of order 2q, exponent in range of even numbers, abort if inbound message ==
identity.
Group of order 2q, base of order 2q, exponent in range of even numbers, abort if negotiated key == identity.
Group of order q, base of order q, abort if inbound message == identity.
Group of order q, base of order q, abort if negotiated key == identity.
9.3 DL/ECSTPAKAP-PAK
DL/ECSTPAKAP is Discrete Logarithm and Elliptic Curve Symmetric Trust Password-Authenticated Key
Agreement Protocol, PAK version.. It is based on the work of [xxx].
9.4 DL/ECATPAKAP-SPEKE
15
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
DL/ECATPAKAP-SPEKE is Discrete Logarithm and Elliptic Curve Asymmetric Trust PasswordAuthenticated Key Agreement Protocol, SPEKE version.. It is based on the work of [xxx].
9.5 DL/ECATPAKAP-PAK
9.6 DL/ECPAKDP-1
DL/ECPAKDP-1 is the Discrete-Logarithm and Elliptic Curve Password-Authenticated Key Distribution
Protocol, version 1.
This protocol uses a password to derive the generator for a modified form of Diffie-Hellman key exchange.
One party, Bob, determines the key to be distributed to the other party, Alice.
This protocol has the following form. Alice transmits a message incorporating a password-derived base
raised to a random exponent. The exponent acts as a blinding factor, so that Bob cannot determine the
password. Bob returns the value raised again to another random exponent, and returns the result to Alice.
Alice removes the blinding factor from the result by raising the returned value to the inverse power of her
random exponent, and retrieves the distributed key.
9.6.1 Key negotiation for Alice
A.1) outbound m1 = g(P)^x
A.2) inbound m2
A.3) K = m2^(1/x)
Use a primitive to derive a base element from a password.
Use a random exponent in a specific range.
Uses a primitive to derive outbound message from base element and random exponent.
Uses a primitive to derive a negotiated key from random element and a challenge message.
Uses a primitive to invert the random exponent.
9.6.2 Key negotiation for Bob
A.1) inbound m1
A.2) outbound m2 = m1^x
B.1) K = g(P)^x
Use a random exponent in a specific range.
Uses a primitive to derive outbound message from inbound message and random exponent.
(Optional) Use a primitive to derive a base element from a password.
(Optional) Use a primitive to derive key from base element and random exponent.
9.6.3 Key confirmation for Alice
Alice must verify an inbound key confirmation message from Bob before she sends her outbound key
confirmation message to Bob.
A.1) verify inbound proofB(K)
A.2) send outbound proofA(K)
9.6.4 Key confirmation for Bob
16
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
IEEE P1363.2 / D2000-11-06
Bob must send an outbound key confirmation message before he can expect to receive an incoming key
confirmation message from Alice.
A.1) send outbound proofB(K)
A.2) receive inbound proofA(K)
A.3) verify inbound proofA(K)
EDITOR’S NOTE—Should talk about static vs. ephemeral exponents, and static vs. ephemeral key confirmation
messages.
9.6.5 Notes
Note that Bob may omit step 3, if he does not need to use the value of K. This may be the case when Bob's
exponent is a fixed value, corresponding to a fixed value for K. Bob may store a verifier for K.
13. Auxiliary Functions
EDITOR’S NOTE—TBD.
Annex A (Informative) Number-Theoretic Background
EDITOR’S NOTE—TBD.
Annex B (Normative) Conformance
EDITOR’S NOTE—TBD.
Annex C (Informative) Rationale
EDITOR’S NOTE—TBD.
Annex D (Informative) Security Considerations
EDITOR’S NOTE—TBD.
Annex E (Informative) Formats
EDITOR’S NOTE—TBD.
Annex F (Informative) Bibliography
EDITOR’S NOTE—TBD.
17
Copyright © 2000 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.