Академический Документы
Профессиональный Документы
Культура Документы
1IEEE
2PvarDesignation™/DvarDraftNumber
3DrafttxtTrialUsetxtGorRPorSTD for
4varTitlePAR
6varCommittee Committee
11This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to
12change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be
13utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards
14Committee participants to reproduce this document for purposes of international standardization
15consideration. Prior to adoption of this document, in whole or in part, by another standards development
16organization, permission must first be obtained from the IEEE Standards Activities Department
17(stds.ipr@ieee.org). Other entities seeking permission to reproduce this document, in whole or in part, must
18also obtain permission from the IEEE Standards Activities Department.
19IEEE Standards Activities Department
20445 Hoes Lane
21Piscataway, NJ 08854, USA
1Abstract: <Select this text and type or paste Abstract—contents of the Scope may be used>
2Keywords: <Select this text and type or paste keywords>
3
4
1Introduction
5Notice to users
12Copyrights
13This document is copyrighted by the IEEE. It is made available for a wide variety of both public and
14private uses. These include both use, by reference, in laws and regulations, and use in private self-
15regulation, standardization, and the promotion of engineering practices and methods. By making this
16document available for use and adoption by public authorities and private users, the IEEE does not waive
17any rights in copyright to this document.
26For more information about the IEEE Standards Association or the IEEE standards development process,
27visit the IEEE-SA web site at http://standards.ieee.org.
28Errata
29Errata, if any, for this and all other standards can be accessed at the following URL:
30http://standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL
31for errata periodically.
2 iv
3 Copyright © <year> IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Interpretations
2Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/
3index.html.
4Patents
5Attention is called to the possibility that implementation of thistxtTrialUsetxtGorRPorSTD may require use
6of subject matter covered by patent rights. By publication of thistxtTrialUsetxtGorRPorSTD, no position is
7taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE is not
8responsible for identifying Essential Patent Claims for which a license may be required, for conducting
9inquiries into the legal validity or scope of Patents Claims or determining whether any licensing terms or
10conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
11agreements are reasonable or non-discriminatory. Users of thistxtTrialUsetxtGorRPorSTD are expressly
12advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is
13entirely their own responsibility. Further information may be obtained from the IEEE Standards
14Association.
15Participants
16At the time this drafttxtTrialUsetxtGorRPorSTD was submitted to the IEEE-SA Standards Board for
17approval, the varWorkingGroup Working Group had the following membership:
18 varWkGrpChair, Chair
19 varWkGrpViceChair, Vice Chair
20
21Participant1 24Participant4 27Participant7
22Participant2 25Participant5 28Participant8
23Participant3 26Participant6 29Participant9
30
31
32The following members of the [individual/entity] balloting committee voted on
33thistxtTrialUsetxtGorRPorSTD. Balloters may have voted for approval, disapproval, or abstention.
34
35(to be supplied by IEEE)
36
37Participant1 40Participant4 43Participant7
38Participant2 41Participant5 44Participant8
39Participant3 42Participant6 45Participant9
46
47
2 v
3 Copyright © <year> IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Contents
2<After draft body is complete, select this text and click Insert Special->Add (Table of) Contents>
2 vi
3 Copyright © <year> IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1
1DrafttxtTrialUsetxtGorRPorSTD for
2varTitlePAR
4Standard Specifications
5for Public Key Cryptography
6
10Review all security considerations and update with results since 2004.
12Fix bibliography to be in IEEE style; fix references to bibliography to be automatically generated and
13hyperlinked
14Fix PAR so title is consistent – Standard for Public Key Cryptography or Standard Specifications for?
15
16Abstract. This standard specifies common public-key cryptographic techniques, including mathematical
17primitives for secret value (key) derivation, public-key encryption, and digital signatures, and
18cryptographic schemes based on those primitives. It also specifies related cryptographic parameters, public
19keys and private keys. The purpose of this standard is to provide a reference for specifications of a variety
20of techniques from which applications may select.
22
2
1
6This is an unapproved draft of a proposed IEEE Standard, subject to change. Permission is hereby granted
7for IEEE Standards Committee participants to reproduce this document for purposes of IEEE
8standardization activities. If this document is to be submitted to ISO or IEC, notification shall be given to
9IEEE Copyright Administrator. Permission is also granted for member bodies and technical committees of
10ISO and IEC to reproduce this document for purposes of developing a national position. Other entities
11seeking permission to reproduce portions of this document for these or other uses must contact the IEEE
12Standards Department for the appropriate license. Use of information contained in the unapproved draft is
13at your own risk.
18
19Comments and suggestions are welcome. Please contact the chair, Ari Singer, at singerar@pb.com.
2
1 IEEE P1363/D1-pre, June 2009
1Introduction
2(This introduction is not part of IEEE P1363, Standards Specifications for Public-Key Cryptography).
3The P1363 project started as the "Standard for Rivest-Shamir-Adleman, Diffie-Hellman, and Related
4Public-Key Cryptography" with its first meeting in January 1994, following a strategic initiative by the
5Microprocessor Standards Committee to develop standards for cryptography.
6P1363's scope broadened with the inclusion of elliptic curve cryptosystems as "related" cryptography, and
7later the title was changed to the current one to reflect the breadth of the effort. In mid-1996, the working
8group decided to include three families of techniques, based on three different hard problems—integer
9factorization, discrete logarithms over finite fields, and elliptic curve discrete logarithms. By late 1996, the
10set of techniques was fairly stable, with "additional" techniques deferred to the P1363a project. Std 1363
11issued in 2000 and Std 1363a in 2004. This document combines the base standard and its amendment, and
12also includes some modifications and additional techniques to reflect new security results since the two
13standards issued.
14The P1363 working group is grateful to the many experts who have contributed to the standard, and
15particularly to those whose development of public-key technology over the past two decades has provided
16the foundation for information security in the next century.
17The active participants in the P1363 working group at the time this document was completed and balloted
18were as follows:
19
20In addition, the working group would like to thank the following people for their contributions to the
21standard
22Editor’s note: Should this include the list of people thanked in the original standard?
23
24The working group apologizes for any inadvertent omissions from the above list. Please note that inclusion
25of a person’s name on the above two lists does not imply that the person agrees with all the materials in the
26standard.
2 1
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Contents
21. Overview....................................................................................................................................................13
3 1.1 Scope...................................................................................................................................................13
4 1.2 Purpose................................................................................................................................................13
5 1.3 Organization of the Document............................................................................................................13
6 1.3.1 Structure of the Main Document......................................................................13
7 1.3.2 Structure of the Annexes..................................................................................14
82. Normative references..................................................................................................................................15
93. Definitions..................................................................................................................................................15
2 2
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 6.2.7 DLSP-NR..........................................................................................................48
2 6.2.8 DLVP-NR.........................................................................................................49
3 6.2.9 DLSP-DSA.......................................................................................................50
4 6.2.10 DLVP-DSA.....................................................................................................51
5 6.2.11 DLPSP-NR2/PV.............................................................................................52
6 6.2.12 DLSP-NR2......................................................................................................52
7 6.2.13 DLVP-NR2.....................................................................................................53
8 6.2.14 DLSP-PV........................................................................................................54
9 6.2.15 DLVP-PV.......................................................................................................55
1 8.2.11 IFDP-OU.........................................................................................................87
2 8.2.12 IFSP-ESIGN...................................................................................................87
3 8.2.13 IFVP-ESIGN...................................................................................................88
2 4
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 5
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
116. New.........................................................................................................................................................163
2 16.1 PSEC-KEM.....................................................................................................................................163
2 7
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 8
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 9
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
39
2 10
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
11. Overview
21.1 Scope
3Specifications of common public-key cryptographic techniques, including mathematical primitives for
4secret value (key) derivation, public-key encryption, and digital signatures, and cryptographic schemes
5based on those primitives. Specifications of related cryptographic parameters, public keys and private keys.
6Class of computer and communications systems is not restricted.
71.2 Purpose
8The transition from paper to electronic media brings with it the need for electronic privacy and authenticity.
9Public-key cryptography offers fundamental technology addressing this need. Many alternative public-key
10techniques have been proposed, each with its own benefits. However, there has been no single,
11comprehensive reference defining a full range of common public-key techniques covering key agreement,
12public-key encryption, digital signatures, and identification from several families, such as discrete
13logarithms, integer factorization, and elliptic curves.
14It is not the purpose of this project to mandate any particular set of public-key techniques, or particular
15attributes of public-key techniques such as key sizes. Rather, the purpose is to provide a reference for
16specifications of a variety of techniques from which applications may select.
2 11
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 Clause 13 defines key derivation functions for key agreement schemes in Clause 9.
2 Clause 14 defines certain auxiliary functions supporting the techniques in Clauses 12 and 13.
4The annexes provide background and helpful information for the users of the standard and include the
5following clauses.
6
7 Annex A (Informative) Number-Theoretic Background
8 Annex B (Normative)Conformance
9 Annex C (Informative) Rationale
10 Annex D (Informative) Security Considerations
11 Annex E (Informative) Formats
12 Annex F (Informative) Bibliography
2 12
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
9FIPS PUB 46-3, Data Encryption Standard (DES), Federal Information Processing Standards Publication
1046-3, U.S. Department of Commerce/National Institute of Standards and Technology, October 1999. 1
11FIPS PUB 81, DES Modes of Operation, Federal Information Processing Standards Publication 81, U.S.
12Department of Commerce/National Institute of Standards and Technology, December 1980.
13FIPS PUB 180-2, Secure Hash Standard, Federal Information Processing Standards Publication 180-2, U.S.
14Department of Commerce/National Institute of Standards and Technology, August 1, 2002.
15FIPS PUB 197, Advanced Encryption Standard (AES), Federal Information Processing Standards
16Publication 197, U.S. Department of Commerce/National Institute of Standards and Technology,
17November 2001.
18FIPS PUB 198, The Keyed-Hash Message Authentication Code (HMAC), Federal Information Processing
19Standards Publication 198, U.S. Department of Commerce/National Institute of Standards and Technology,
20March 2002.
233. Definitions
24For the purposes of this drafttxtTrialUsetxtGorRPorSTD, the following terms and definitions apply. The
25Authoritative Dictionary of IEEE Standards Terms should be referenced for terms not defined in this
26clause.
283.authentication of ownership: the assurance that a given, identified party intends to be associated with a
29given public key. May also include assurance that the party possesses the corresponding private key (see
30D.3.2. for more information).
313.binary field: a finite field containing 2m elements for some integer m > 0. Also known as characteristic
32two finite field.
21 FIPS publications are available from the National Technical Information Service (NTIS), U.S.
3Department of Commerce, 5285 Port Royal Rd., Springfield, VA 22161 (http://www.ntis.gov/) and/or from
4the Federal Information Processing Standards Publications web site at http://www.itl.nist.gov/fipspubs/.
5 13
6 Copyright © 1999 IEEE. All rights reserved.
7 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
23.bit string: an ordered sequence of bits (0's and 1's). A bit and a bit string of length 1 are equivalent for
3all purposes of this standard.
53.ciphertext: the result of applying encryption to a message. Contrast: plaintext. See also: encryption.
63.conformance region: a set of inputs to a primitive or a scheme operation for which an implementation
7operates in accordance with the specification of the primitive or scheme operation (see B.1 for more
8information).
93.cryptographic family: there are three families of techniques presented in this standard, based on the
10underlying hard problem: discrete logarithm over finite fields (DL), discrete logarithm over elliptic curve
11groups (EC), and integer factorization (IF).
123.decrypt: to produce plaintext from ciphertext. Contrast: encrypt. See also: ciphertext; encryption;
13plaintext.
143.digital signature: a digital string for providing authentication. Commonly, in public-key cryptography,
15it is a digital string that binds a public key to a message in the following way: only the person knowing the
16message and the corresponding private key can produce the string, and anyone knowing the message and
17the public key can verify that the string was properly produced. A digital signature may or may not contain
18the information necessary to recover the message itself. See also: digital signature scheme: public key;
19public-key cryptography; private key; signature scheme with appendix; signature scheme with message
20recovery.
213.digital signature scheme: a method for providing authentication. In public-key cryptography, this
22method can be used to generate a digital signature on a message with a private key in such a way that
23anyone knowing the corresponding public key can verify that the digital signature was properly produced.
24See also: digital signature; public key; public-key cryptography; private key; signature scheme with
25appendix; signature scheme with message recovery.
263.domain parameters: a set of mathematical objects, such as fields or groups, and other information,
27defining the context in which public/private key pairs exist. More than one key pair may share the same
28domain parameters. Not all cryptographic families have domain parameters. See also: public/private key
29pair; valid domain parameters.
303.domain parameter validation: the process of ensuring or verifying that a set of domain parameters is
31valid. See also: domain parameters; key validation; valid domain parameters.
323.encrypt: to produce ciphertext from plaintext. Contrast: decrypt. See also: ciphertext; encryption;
33plaintext.
343.encryption scheme: a method for providing privacy. In public-key cryptography, this method can be
35used to modify a message with the help of a public key to produce what is known as ciphertext in such a
36way that only the holder of the corresponding private key can recover the original message from the
37ciphertext. See also: ciphertext; plaintext; private key; public key; public-key cryptography.
2 14
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
13.field: a setting in which the usual mathematical operations (addition, subtraction, multiplication, and
2division by nonzero quantities) are possible and obey the usual rules (such as the commutative, associative,
3and distributive laws). A DL or EC scheme is always based on computations in a field. See [Kob94] for a
4precise mathematical definition.
53.finite field: a field in which there are only a finite number of quantities. The DL and EC schemes are
6always implemented over finite fields. See Clause 5 for a description of the particular finite fields used in
7this standard.
83.first bit: the leading bit of a bit string or an octet. For example, the first bit of 0110111 is 0. Contrast:
9last bit. Syn: most significant bit; leftmost bit. See also: bit string; octet.
103.first octet: the leading octet of an octet string. For example, the first octet of 1c 76 3b e4 is 1c. Contrast:
11last octet. Syn: most significant octet; leftmost octet. See also: octet; octet string.
123.key agreement: a method by which two entities, using each other's public keys and their own private
13keys, agree on a common secret key that only they know. The secret key is then commonly used in some
14symmetric cryptography technique. See also: private key; public key; secret key; symmetric cryptography.
153.key confirmation: the assurance provided to each party participating in a key agreement protocol that
16the other party is capable of computing the agreed-upon key, and that it is the same for both parties (see
17D.5.1.3 for more information). See also: key agreement.
183.key derivation: the process of deriving a secret key from a secret value. See also: secret key; secret
19value.
213.key validation: the process of ensuring or verifying that a key or a key pair is valid. See also: domain
22parameter validation; public/private key pair; valid key; valid key pair.
233.last bit: The trailing bit of a bit string or an octet. For example, the last bit of 0110111 is 1. Contrast:
24first bit. Syn: least significant bit; rightmost bit. See also: first bit; octet.
253.last octet: The trailing octet of an octet string. For example, the last octet of 1c 76 3b e4 is e4. Contrast:
26first octet. Syn: least significant octet; rightmost octet. See also: octet; octet string.
283.length: (1) Length of a bit string is the number of bits in the string. (2) Length of an octet string is the
29number of octets in the string. (3) Length in bits of a nonnegative integer n is log2 (n + 1) (i.e., the
30number of bits in the integer’s binary representation). (4) Length in octets of a nonnegative integer n is
31log256 (n + 1) (i.e., the number of digits in the integer’s representation base 256). For example, the
32length in bits of the integer 500 is 9, whereas its length in octets is 2.
363.message representative: a mathematical value for use in a cryptographic primitive, computed from a
37message that is input to an encryption or a digital signature scheme. See also: encryption scheme; digital
38signature scheme.
2 15
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
23.octet: A bit string of length 8. An octet has an integer value between 0 and 255 when interpreted as a
3representation of an integer in base 2. An octet can also be represented by a hexadecimal string of length 2,
4where the hexadecimal string is the representation of its integer value base 16. For example, the integer
5value of the octet 10011101 is 157; its hexadecimal representation is 9d. See also: bit string.
73.odd-charateristic extension field: a finite field containing pm elements for some integer m > 1 where p
8is an odd prime number. For the purposes of this standard, it will be assumed that m > 1 when the term
9“odd-characteristic extension field” is given.
113.plaintext: a message before encryption has been applied to it; the opposite of ciphertext. Contrast:
12ciphertext. See also: encryption.
133.prime field: a finite field of p elements, where p is an odd prime number. Also known as prime finite
14field.
153.private key: The private element of the public/private key pair. (Note that for convenience of
16implementation, some components of the public key may be included in the private key as well.) See also:
17public/private key pair; valid key
183.public key: the public element of the public/private key pair. See also: public/private key pair; valid key.
193.public-key cryptography: methods that allow parties to communicate securely without having prior
20shared secrets, usually through the use of public/private key pairs. Contrast: symmetric cryptography. See
21also: public/private key pair.
223.public/private key pair: a pair of cryptographic keys used in public-key cryptography, consisting of a
23public key and a private key that correspond to each other by some mathematical relation. The public key
24is commonly available to a wide audience and can be used to encrypt messages or verify digital signatures;
25the private key is held by one entity and not revealed to anyone--it is used to decrypt messages encrypted
26with the public key and/or produce signatures that can verified with the public key. A public/private key
27pair can also be used in key agreement. In some cases, a public/private key pair can only exist in the
28context of domain parameters. See also: digital signature; domain parameters; encryption; key agreement;
29public-key cryptography; valid key; valid key pair.
323.root: if f (x) is a polynomial, then its root is a value r of the variable x such that f (r) = 0.
333.secret key: a key used in symmetric cryptography; commonly needs to be known to all parties involved,
34but cannot be known to an adversary. Contrast: public/private key pair. See also: key agreement; shared
35secret key; symmetric cryptography.
363.secret value: a value that can be used to derive a secret key, but typically cannot by itself be used as a
37secret key. See also: secret key.
383.shared secret key: a secret key shared by two parties, usually derived as a result of a key agreement
39scheme. See also: key agreement; secret key.
2 16
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
13.shared secret value: a secret value shared by two parties, usually during a key agreement scheme. See
2also: key agreement; secret value.
43.signature scheme with appendix: a digital signature scheme that requires the signed message as input to
5the verification algorithm. Contrast: signature scheme with message recovery. See also: digital signature;
6digital signature scheme.
73.signature scheme giving message recovery: a digital signature scheme where the signature contains
8enough information for recovery of part or all of the message that is signed. Contrast: signature scheme
9with appendix. See also: digital signature; digital signature scheme.
103.signature verification: the process of verifying a digital signature. See also: digital signature; digital
11signature scheme.
123.symmetric cryptography: methods that allow parties to communicate securely only when they already
13share some prior secrets, such as the secret key. Contrast: public-key cryptography. See also: secret key.
143.valid domain parameters: a set of domain parameters that satisfies the specific mathematical definition
15for the set of domain parameters of its family. While a set of mathematical objects may have the general
16structure of a set of domain parameters, it may not actually satisfy the definition (for example, it may be
17internally inconsistent) and thus not be valid. See also: domain parameters; public/private key pair; valid
18key; valid key pair; validation.
193.valid key: a key (public or private) that satisfies the specific mathematical definition for the keys of its
20family, possibly in the context of its set of domain parameters. While some mathematical objects may have
21the general structure of keys, they may not actually lie in the appropriate set (for example, they may not lie
22in the appropriate subgroup of a group or be out of the bounds allowed by the domain parameters) and thus
23not be valid keys. See also: domain parameters; public/private key pair; valid domain parameters; valid
24key pair; validation.
253.valid key pair: a public/private key pair that satisfies the specific mathematical definition for the key
26pairs of its family, possibly in the context of its set of domain parameters. While a pair of mathematical
27objects may have the general structure of a key pair, the keys may not actually lie in the appropriate sets
28(for example, they may not lie in the appropriate subgroup of a group or be out of the bounds allowed by
29the domain parameters) or may not correspond to each other; such a pair is thus not a valid key pair. See
30also: domain parameters; public/private key pair; valid domain parameters; valid key; validation.
2 17
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
10
11 Primitives – basic mathematical operations. Historically, they were discovered based on number-
12 theoretic hard problems. Primitives are not meant to achieve security just by themselves, but they
13 serve as building blocks for schemes.
14
15 Schemes – a collection of related operations combining primitives and additional methods (Clause
16 4.4). Schemes can provide complexity-theoretic security which is enhanced when they are
17 appropriately applied in protocols.
18
19 Protocols – sequences of operations to be performed by multiple parties to achieve some security
20 goal. Protocols can achieve desired security for applications if implemented correctly.
21From an implementation viewpoint, primitives can be viewed as low-level implementations (e.g.,
22implemented within cryptographic accelerators, or software modules), schemes can be viewed as medium-
23level implementations (e.g., implemented within cryptographic service libraries), and protocols can be
24viewed as high-level implementations (e.g., implemented within entire sets of applications).
25General frameworks for primitives, schemes, and additional methods are provided in Clauses 4.2, 4.3, and
264.4, and specific techniques are defined in Clauses 6 through 14. This standard, however, does not define
27protocols, mainly because they tend to be application-specific and hence are outside the scope of the
28standard. Nevertheless, the techniques defined in this standard are key components for constructing various
29cryptographic protocols. Also, Annex D discusses security considerations related to how the techniques can
30be used in protocols to achieve certain security attributes.
314.2 Primitives
32The following types of primitives are defined in this standard:
33
34 Secret Value Derivation Primitives (SVDP), components of key agreement schemes
35
36 Pre-Signature Primitives (PSP), Signature Primitives (SP) and Verification Primitives (VP),
37 components of signature schemes
2 18
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 Encryption Primitives (EP) and Decryption Primitives (DP), components of encryption schemes
3Primitives in this standard are presented as mathematical operations, and they are not meant to provide
4security by themselves. For example, it may be easy to compute message-signature pairs that a signature
5verification primitive would find consistent with a public key. This is no assurance, however, that the
6signature was produced on the message by the owner of the corresponding private key. Such assurance can
7only be provided by a properly implemented signature scheme, which uses the primitive along with other
8operations.
9Primitives assume that their inputs satisfy certain assumptions, as listed with the specification of each
10primitive. An implementation of a primitive is unconstrained on an input not satisfying the assumptions, as
11long as it does not adversely affect future operation of the implementation; the implementation may or may
12not return an error condition. For example, an implementation of a signature primitive may return
13something that looks like a signature even if its input was not a valid private key. It may also reject the
14input. It is up to the user of the primitive to guarantee that the input will satisfy the constraints or to include
15the relevant checks. For example, the user may choose to use the relevant key and domain parameter
16validation techniques.
18
19 input to the primitive
20 assumptions about the input made in the description of the operation performed by the primitive
21 output from the primitive
22 operation performed by the primitive, expressed as a series of steps
23 conformance region recommendations describing the minimum recommended set of inputs for
24 which an implementation should operate in conformance with the primitive (see Annex B for more
25 on conformance)
26The specifications are functional specifications, not interface specifications. As such, the format of inputs
27and outputs and the procedure by which an implementation primitive is invoked are outside the scope of
28this standard. See Annex E for more information on input and output formats.
294.3 Schemes
30The following types of schemes are defined in this standard:
31
32 Key agreement schemes (KAS), in which two parties use their public/private key pairs, and
33 possibly other information to agree on a shared secret key. The shared secret key may then be used
34 for symmetric cryptography. (See Clause 3 for the definition of symmetric cryptography.)
35
36 Signature schemes with appendix (SSA), in which one party signs a message using its private key,
37 and any other party can verify the signature by examining the message, the signature, and the
38 signer’s corresponding public key.
39
2 19
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 Signature schemes giving (message) recovery (SSR), in which one party signs a message using its
2 private key such that part or all of the message can be recovered from the signature, and any other
3 party can verify the signature, and recover that part of the message by examining the non-
4 recoverable part of the message (if any), the signature and the signer’s corresponding public key.
5
6 Encryption schemes (ES), in which any party can encrypt a message using a recipient’s public key,
7 and only the recipient can decrypt the message by using its corresponding private key. Encryption
8 schemes may be used for establishing secret keys to be used in symmetric cryptography.
9Schemes in this standard are presented in a general form based on certain primitives and additional
10methods, such as message encoding methods. For example, an encryption scheme is based on an encryption
11primitive, a decryption primitive, and an appropriate message encoding method.
12Schemes also include key management operations, such as selecting a private key or obtaining another
13party’s public key. For proper security, a party needs to be assured of the true owners of the keys and
14domain parameters and of their validity. Generation of domain parameters and keys needs to performed
15properly, and in some cases validation also needs to be performed. While outside the scope of this
16standard, proper key management is essential for security. It is addressed in more detail in Annex D.
18
19 scheme options, such as choices for primitives and additional methods
20 one or more operations, depending on the scheme, expressed as a series of steps
21 conformance region recommendations for implementations conforming with the scheme (see
22 Annex B for more on conformance)
23As for primitives, the specifications are functional specifications, not interface specifications. As such, the
24format of inputs and outputs and the procedure by which an implementation of a scheme is invoked are
25outside the scope of this standard. See Annex E for more information on input and output formats.
28
29 Message-encoding methods, which are components of signature or encryption schemes
30
31 1) Encoding methods for signatures with appendix (EMSA)
32 2) Encoding methods for signatures giving message recovery (EMSR)
33 3) Encoding methods for encryption (EME)
34
35 Key derivation functions (KDF), which are components of key agreement schemes
36
37 Auxiliary techniques, which are building blocks for other additional methods
38
39 1) Mask generation functions (MGF), which are used in EME
40 2) Hash functions, which are used in EMSA, EMSR, EME, KDF, and MGF
2 20
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 3) Symmetric encryption schemes, which are used in some encryption schemes, EMSR and
2 EME
3 4) Message authentication codes (MAC), which are a component of some encryption schemes
4The specified additional methods are strongly recommended for use in the schemes. The use of an
5inadequate message-encoding method, key derivation function, auxiliary function, or message
6authentication code may compromise the security of the scheme in which it is used. Therefore, any
7implementation that chooses not to follow the recommended additional methods for a particular scheme
8should perform its own thorough security analysis of the resulting scheme.
OR
OR
OR
2 21
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
OR
OR
OR
ECPSP-NR2/PV, ECSP-NR2
and ECVP-NR2
OR
Encryption Schemes
2 22
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
Schemes—KAS: key agreement scheme, SSA: signature scheme with appendix, SSR:
signature scheme giving message recovery, IES: integrated encryption scheme, ES:
encryption scheme
2 23
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
8
90 Denotes the integer 0, the bit 0, or the additive identity (the element zero) of a finite field.
10 See Clause 5.3 for more on finite fields.
111 Denotes the integer 1, the bit 1, or the multiplicative identity (the element one) of a finite
12 field. See Clause 5.3 for more on finite fields.
13a b The product of a and b, where a and b are either both integers, or both finite field
14 elements. When it does not cause confusion, is omitted and the notation ab is used. See
15 Clause 5.3 for more on finite fields.
16a P Scalar multiplication of an elliptic curve point P by a non-negative integer a. When it
17 does not cause confusion, is omitted and the notation aP is used. See Clause 5.4 for
18 more on elliptic curves.
19x The smallest integer greater than or equal to the real number x. For example, 5 = 5 and
20 5.3 = 6.
21x The largest integer less than or equal to the real number x. For example, 5 = 5 and 5.3
22 = 5.
23[a, b] The interval of integers between and including the integers a and b.
24LCM (a, b) For two positive integers a and b, denotes the least common multiple of a and b, i.e., the
25 least positive integer that is divisible by both a and b. See Annex A.1.1 and A.2.2 for an
26 algorithm to compute the LCM.
27GCD (a, b) For two positive integers a and b, denotes the greatest common divisor of a and b, i.e., the
28 largest positive integer that divides both a and b. See Annex A.1.1 and A.2.2 for an
29 algorithm to compute the GCD.
30X Y Bitwise exclusive-or (XOR) of two bit strings or two octet strings X and Y of the same
31 length.
32X || Y Ordered concatenation of two strings X and Y. X and Y are either both bit strings, or both
33 octet strings.
34log2 x The logarithmic function of a positive number x to the base 2.
35log256 x The logarithmic function of a positive number x to the base 256.
36a mod n The unique remainder r, 0 r < n, when the integer a is divided by the positive integer n.
37 For example, 23 mod 7 = 2. The operator “mod” has the lowest precedence of all
38 arithmetic operators (e.g., 5 + 8 mod 3 is equal to 13 mod 3, not 5 + 2). See Annex A.1.1
39 for more details.
40a b (mod n) The integers a and b have the same remainder when divided by the positive integer n.
41 Pronounced “a is congruent to b modulo n.” This is equivalent to (a mod n) = (b mod n).
42 See Annex A.1.1 for more details.
43a ( b (mod n) The integers a and b have different remainders when divided by the positive integer n.
44 Pronounced “a is not congruent to b modulo n.” This is equivalent to (a mod n) (b mod
45 n).
2 24
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1a –1 mod n A positive integer b < n, if it exists, such that ab mod n = 1. Prounouced “the
2 (multiplicative) inverse of a modulo n.” Also denoted by 1/a mod n. See Annex A.1.1
3 and A.2.2 for a more detailed description and an algorithm for computing it.
4a/b mod n An integer a multiplied by the inverse of the integer b modulo n. Equivalent to ab –1 mod
5 n.
6GF (p) The finite field of p elements, represented as the integers modulo p, where p is an odd
7 prime number. Also known as a prime finite field. See Clause 5.3.1 for more information.
8GF(q) The finite field containing q elements. For this standard, q will be either a power of an odd
9 prime p or a power of 2.
10GF (2m) The finite field containing 2m elements for some integer m > 0. Also known as a
11 characteristic two finite field. See Clause 5.3.2 for more information.
12GF(pm) The finite field containing pm elements for some integer m > 1 where p is an odd prime
13 number. Also known as odd-characteristic extension field. See 5.3.3 for more information.
14NOTE—Although mathematically, the various techniques based on GF(pm) may generally also be employed when m =
151, for the purposes of this standard, it will be assumed that m > 1 when the notation “GF(pm)” or the term “odd-
16characteristic extension field” is given. The cases GF(pm) and GF(p) are thus treated separately.
17ASK IEEE EDITORIAL – THIS LOOKS WEIRD – Where should the note go?
18
x
19 The Jacobi symbol of the integer x with respect to the integer n. See Annex A.1.4 for a
n
20 detailed description and A.2.3 for an algorithm to compute the Jacobi symbol.
21O The elliptic curve point at infinity. See Clause 5.4 for more information.
22exp(a, b) The result of raising a to the power b, where a is an integer or a finite field element, and b
23 is an integer. Also denoted by a b.
24exp(a) The result of raising the number e (where e = 2.718…) to the power a, where a is a real
25 number.
26NOTE—Throughout this main document, integers and field elements are denoted with lower-case letters; while octet
27strings and elliptic curve points are denoted with upper-case letters. The one exception is when a public key that can be
28either a field element or an elliptic curve point is denoted by a lower-case letter in the DL and EC schemes (Clauses
299.2, 9.3, 9.4 and 10.2).
36Note that when a string is represented as a sequence, it may be indexed from right to left or from left to
37right, starting with any index; this does not change the meaning of the terms above. For example, consider
38the octet string of 4 octets: 1c 76 3b e4. One can represent it as a string a0 a1 a2 a3 with a0 = 1c, a1 = 76, a2
39= 3b, and a3 = e4. In this case, a0 represents the first octet, and a3 represents the last octet. Alternatively,
40one can represent it as a string a1 a2 a3 a4 with a1 = 1c, a2 = 76, a3 = 3b, and a4 = e4. In this case, a1
41represents the first octet, and a4 represents the last octet. Yet another possibility would be to represent it as
42a3 a2 a1 a0 with a3 = 1c, a2 = 76, a1 = 3b, and a0 = e4. In this case, a3 represents the first octet and a0
43represents the last octet. No matter how this string is represented, the value of the first octet is always 1c
44and the value of the last octet is always e4.
2 25
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
8A prime finite field is a field containing a prime number of elements. If p is an odd prime number, then
9there is a unique field GF (p) with p elements. For purposes of conversion, the elements of GF (p) shall be
10represented by the integers 0, 1, 2..., p – 1.
11A description of the arithmetic of GF (p) is given in Annex A.1 and A.2.
13A characteristic two finite field is a finite field whose number of elements is a power of 2. If m 1, then
14there is a unique field GF (2m) with 2m elements. For purposes of conversion, the elements of GF (2m)
15should be represented by bit strings of length m.
16There are several ways of performing arithmetic in GF (2m). The specific rules depend on how the bit
17strings are interpreted. For purposes of conversion, this interpretation should be made in terms of one of
18the following basis representations.
19NOTE—As opposed to the representation method for prime finite fields, which is required, the representation methods
20for binary finite fields are recommendations. The choice of a particular representation for binary fields affects the
21primitives and schemes in which conversion from field elements to other objects is used. See Annex D.4.1.3 and
22D.4.2.3 (and related notes in D.4.1.4 and D.4.2.4) for related security considerations.
24This representation is determined by choosing an irreducible binary polynomial p(t) of degree m. (See
25Annex A.3 and A.4 for the definitions of the above terms and for a description of the arithmetic of a field
26using this representation.) If the polynomial basis representation over GF (2) is used, then, for purposes of
27conversion, the bit string
28(am–1 … a2 a1 a0)
32In particular, for purposes of conversion, the additive identity (zero) element of the field is represented by a
33string of all zero bits, and the multiplicative identity (one) element of the field is represented by a string
34where all bits but the last are zero, and the last bit is one. (Note, however, that in mathematical expressions
35in this standard, for typographic convenience, the numeral 0 is used to represent the element zero of a field,
36and the numeral 1 is used to represent the element one of the field.)
2 26
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1NOTE—In keeping with the traditional mathematical notation, the bits in this representation are indexed from right to
2left, as opposed to the bits in the normal basis representation (Clause 5.3.2.2), which are indexed from left to right. See
3also Clause 5.2.
5This representation is determined by choosing a normal polynomial p(t) of degree m. (See Annex A.3 and
6A.4 for the definitions of the above terms and for a description of the arithmetic of a field using this
7representation.) If the normal basis representation over GF (2) is used, then, for purposes of conversion,
8the bit string
9(a0 a1 … am–1)
18NOTE—In keeping with the traditional mathematical notation, the bits in this representation are indexed from left to
19right, as opposed to the bits in the polynomial basis representation (Clause 5.3.2.1), which are indexed from right to
20left. See also Clause 5.2.
22This representation is possible for fields GF(2m) if m is a composite integer. The representation is
23determined by choosing a subfield GF(2d) of GF(2m), where 1 < d < m, and m = ds. Elements of GF(2m) are
24then represented as vectors of s elements from GF(2d) using any basis representation, including those in
255.3.2.3.1 or 5.3.2.3.2. Elements of GF(2d) may in turn be represented in any basis, including those in
265.3.2.1 or 5.3.2.2, or with another composite basis if d is a composite integer. This process of choosing
27representations for subfields of GF(2d) may be repeated for each of the divisors of d.
29This representation is similar to that defined in 5.3.2.1 with the difference that d 1. This representation is
30determined by choosing an irreducible polynomial f(t) over GF(2d) of degree s = m/d. Then GF(2m) is
31isomorphic to GF(2d)[t]/f(t).
32Then if the polynomial basis representation over GF(2d) is used, for purposes of conversion, the string
33(as–1 … a2 a1 a0)
34where each ai is a bit string of length d shall be taken to represent the polynomial
2 27
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1where the coefficients ai are elements of GF(2d). The coefficients ai will in turn be represented with some
2basis over some subfield of GF(2d) (perhaps GF(2)).
3As in 5.3.2.1, the additive identity (zero) element of the field GF(2m) is represented by a string of s
4representations of the zero element in the chosen representation for GF(2d). Thus, if GF(2d) is represented
5with a polynomial or normal basis, the zero element of GF(2m) is represented by a string of all zero bits.
6Similarly, the multiplicative identity (one) element of GF(2m) is represented by a string of (s–1)
7representations of the zero element of GF(2d) followed by the representation of the one element of GF(2d).
8Thus, if GF(2d) is represented with a polynomial basis, the one element of GF(2m) is represented by a string
9of m 1 zero bits followed by a one bit. If GF(2d) is represented by a normal basis, the one element of
10GF(2m) is represented by a string of (s – 1)d zero bits followed by d one bits.
11The arithmetic in this basis is identical to that of 5.3.2.1 with the exception that all coefficient operations
12are performed in the field GF(2d).
14This representation is similar to that defined in 5.3.2.2 with the difference that d 1. This representation is
15determined by choosing a normal polynomial f(t) of degree s = m/d. Then GF(2m) is isomorphic to GF(2d)
16[t]/f(t).
17Then if the normal basis representation over GF(2d) is used, for purposes of conversion, the string
18(a0 a1 … as-1),
19where each ai is a bit string of length d, shall be taken to represent the element
21where is a root of f(t) in GF(2s). The coefficients ai will in turn be represented with some basis over some
22subfield of GF(2d) (perhaps GF(2)).
23As in 5.3.2.2, the additive identity (zero) element of the field GF(2m) is represented by a string of s
24representations of zero in GF(2d). For example, if GF(2d) is represented with a polynomial or normal basis,
25a string of zero bits represents zero in GF(2m). The multiplicative identity (one) element of the field is
26represented by a string of s representations of one in GF(2d). For example, if GF(2d) is represented with a
27polynomial basis, the string consists of the pattern: (d – 1) zero bits followed by a one bit. The pattern
28repeated s times represents one in GF(2m). If GF(2d) is represented with a normal basis, the one element of
29GF(2m) is represented with a string of all one bits.
30The arithmetic in this basis is identical to that of 5.3.2.1 with the exception that all coefficient operations
31are performed in the field GF(2d).
33An odd characteristic extension field is a finite field whose number of elements is a power of an odd prime.
34If m > 1, then there is a unique field (up to isomorphism) GF(pm) with pm elements. For purposes of
35conversion, the elements of GF(pm) shall be represented in a polynomial basis and converted to integers in
36the set {0, 1, …, pm1} as follows. The polynomial basis representation is determined by choosing an
37irreducible polynomial f(t) over GF(p). Then GF(pm) is isomorphic to GF(p)[t]/f(t). The element with
38representation
2 28
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
3(note that each ai is between 0 and p1, so the result is between 0 and pm1). (The coefficients can be
4recovered from this integer by successively dividing by p and keeping the remainder. For instance,
5denoting the integer by a, the coefficient a0 can be obtained as a0 = a mod p, then a can be updated to a =
6a / p, then a1 can be obtained as a1 = a mod p, and so on.)
7Note that for purposes of conversion, the additive identity (zero) element of the field is represented by the
8integer 0, and the multiplicative identity (one) element of the field is represented by the integer 1.
10
12An elliptic curve E defined over GF (q) is a set of points P = (xP, yP) where xP and yP are elements of
13GF (q) that satisfy a certain equation, together with the point at infinity denoted by O. For the purposes of
14this standard, it is specified by two field elements a GF (q) and b GF (q), called the coefficients of E.
15The field elements xP and yP are called the x-coordinate of P and the y-coordinate of P, respectively.
16If q = pm, p > 3, m 1, then a and b shall satisfy 4 a3 + 27 b2 0 in GF(q), and every point P = (xP, yP) on E
17(other than the point O) shall satisfy the following equation in GF(q):
18yP2 = xP3 + a xP + b.
19If q is a power of 2, then b shall be nonzero in GF(q), and every point P = (xP, yP) on E (other than the
20point O) shall satisfy the following equation in GF(q):
22If q is a power of 3, then a and b shall be nonzero in GF(q), and every point P = (xP, yP) on E (other than
23the point O) shall satisfy the following equation in GF(q):
25See Annex A.9 and A.10 for more on elliptic curves and elliptic curve arithmetic.
29This clause describes the primitives that shall be used to convert between different types of objects and
30strings when such conversion is required in primitives, schemes or encoding techniques. Representation of
31mathematical and cryptographic objects as octet strings is not specifically addressed here; rather, it is
32discussed in the informative Annex E. The following diagram describes the primitives presented in this
33clause.
2 29
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
I2BSP
Integer (I) Bit String (BS)
BS2IP
FE2OSP OS2ECP
Field Element (FE) Octet String (OS) Elliptic Curve
OS2FEP EC2OSP Point (EC)
1
35.5.1 Converting Between Integers and Bit Strings (I2BSP and BS2IP)
4In performing cryptographic operations, bit strings sometimes need to be converted to non-negative
5integers and vice versa.
6To convert a non-negative integer x to a bit string of length l (l has to be such that 2 l > x), the integer shall
7be written in its unique l-digit representation base 2:
9where xi is either 0 or 1 (note that one or more leading digits will be zero if x < 2 l–1). Then let the bit bi
10have the value xl–i for 1 i l. The bit string shall be b1 b2 … bl.
11For example, the integer 10945 is represented by a bit string of length 19 as 000 0010 1010 1100 0001.
12The primitive that converts integers to bit strings is called Integer to Bit String Conversion Primitive or
13I2BSP. It takes an integer x and the desired length l as input and outputs the bit string if 2 l > x. It shall
14output “error” otherwise.
15The primitive that converts bit strings to integers is called Bit String to Integer Conversion Primitive or
16BS2IP. It takes a bit string as input and outputs the corresponding integer. Note that the bit string of
17length zero (the empty bit string) is converted to the integer 0.
185.5.2 Converting Between Bit Strings and Octet Strings (BS2OSP and OS2BSP)
19To represent a bit string as an octet string, one simply pads enough zeroes on the left to make the number of
20bits a multiple of 8, and then breaks it up into octets. More precisely, a bit string bl–1 bl–2 … b0 of length l
21shall be converted to an octet string Md–1 Md–2 … M0 of length d = l/8 as follows: for 0 i < d – 1, let the
22octet Mi = b8i+7 b8i+6 ... b8i. The leftmost octet Md–1 shall have its leftmost 8d – l bits set to 0; its rightmost 8
23– (8d – l) bits shall be bl–1 bl–2 … b8d–8.
24The primitive that converts bit strings to octet strings is called Bit String to Octet String Conversion
25Primitive or BS2OSP. It takes the bit string as input and outputs the octet string.
26The primitive that converts octet strings to bit strings is called Octet String to Bit String Conversion
27Primitive or OS2BSP. It takes an octet string of length d and the desired length l of the bit string as input.
28It shall output the bit string if d = l/8 and if the leftmost 8d – l bits of the leftmost octet are zero; it shall
29output “error” otherwise.
2 30
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
15.5.3 Converting between Integers and Octet Strings (I2OSP and OS2IP)
2To represent a non-negative integer x as an octet string of length l (l has to be such that 256 l > x), the
3integer shall be written in its unique l-digit representation base 256:
5where 0 xi < 256 (note that one or more leading digits will be zero if x < 256 l–1). Then let the octet Mi
6have the value xi for0 i l-1. The octet string shall be Ml-1 Ml-2 … M0.
7For example, the integer 10945 is represented by an octet string of length 3 as 00 2A C1.
8The primitive that converts integers to octet strings is called Integer to Octet String Conversion Primitive or
9I2OSP. It takes an integer x and the desired length l as input and outputs the octet string if 256 l > x. It
10shall output “error” otherwise.
11The primitive that converts octet strings to integers is called Octet String to Integer Conversion Primitive or
12OS2IP. It takes an octet string as input and outputs the corresponding integer. Note that the octet string of
13length zero (the empty octet string) is converted to the integer 0.
145.5.4 Converting between Finite Field Elements and Octet Strings (FE2OSP and OS2FEP)
15An element x of a finite field GF(q), for purposes of conversion, is represented by an integer if q is an odd
16prime or an odd prime power (see 5.3.1 and 5.3.3) or by a bit string if q is a power of 2 (see 5.3.2). If q is
17an odd prime or an odd prime power, then to represent x as an octet string, I2OSP shall be used with the
18integer value representing x and the length log256 q as inputs. If q is a power of 2, then to represent x as an
19octet string, BS2OSP shall be applied to the bit string representing x.
20The primitive that converts finite field elements to octet strings is called the Field Element to Octet String
21Conversion Primitive or FE2OSP. It takes a field element x, the field size q, and both the field characteristic
22p and the extension degree m if q is an odd prime-power as inputs and outputs the corresponding octet
23string.
24To convert an octet string back to a field element, if q is an odd prime or an odd prime power, then OS2IP
25shall be used with the octet string as the input. If q is a power of 2, then OS2BSP shall be used with the
26octet string and the length log2 q as inputs. The primitive that converts octet strings to finite field elements
27is called the Octet String to Field Element Conversion Primitive or OS2FEP. It takes the octet string and
28the field size q as inputs and outputs the corresponding field element. It shall output “error” if OS2BSP or
29OS2IP outputs “error.”
31In performing cryptographic operations, finite field elements sometimes need to be converted to non-
32negative integers. The primitive that performs this is called Field Element to Integer Conversion Primitive
33or FE2IP.
34A element j of a finite field GF (q) shall be converted to a non-negative integer i by the following, or an
35equivalent, procedure:
36 a) Convert the element j to an octet string using FE2OSP.Convert the resulting octet string to an
37 integer i using OS2IP.Output i.
2 31
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Note that if q is an odd prime, j is already represented as an integer and FE2IP merely outputs that
2representation. If q is a power of 2, then FE2IP outputs an integer whose binary representation is the same
3as the bit string representing j.
4ADD I2FEP
5ADD FE2OSP
6ADD OS2FEP
9An elliptic curve point P (which is not the point at infinity O) can be represented in either compressed or
10uncompressed form. (For internal calculations, it may be advantageous to use other representations; e.g.,
11the projective coordinates of A.9.6. Also see A.9.6 also for more information on point compression.) The
12uncompressed form of P is simply given by its two coordinates. The compressed form is presented below.
13The octet string format is defined to support both compressed and uncompressed points.
15The compressed form of an elliptic curve point P O defined over GF(p) and GF(2m) is the pair (xP, )
16where xP is the x-coordinate of P, and is a bit which is computed as defined next.
17Two compressed forms are defined: an LSB compressed form defined for elliptic curves over GF(p) and
18GF(2m), and an SORT compressed form is defined for elliptic curves over GF(2m) and GF(pm).
19NOTE—Elliptic curve points over GF(2m) can be compressed with either the LSB or SORT method. The LSB method
20is equivalent to the point compression method in Annex E of IEEE Std 1363-2000.
22Over GF(p), the LSB compressed form has = FE2IP (yP) mod 2. Put another way, is the rightmost bit of
23yP.
24Over GF(2m), the LSB compressed form has = 0 if xP = 0 and = FE2IP (yPxP–1) mod 2 if xP 0. That is, is
25the rightmost bit of the field element yPxP–1 if xP 0. (This rule applies for any of the basis representations
26given in 5.3.2.)
27Procedures for point decompression (i.e., recovering yP given xP and ) are given in A.12.8 (for q an odd
28prime) and A.12.9 (for q a power of 2).
29NOTE—The name “LSB” refers to the fact that the compressed bit is the least significant bit of the integer
30representation of yP or yPxP–1.
32Let (xP, yP) be the inverse of the point (xP, yP). (For GF(pm), yP = yP; for GF(2m), yP = xP + yP.)
2 32
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The SORT compressed form has = 1 if FE2IP (yP) > FE2IP (yP), and = 0 otherwise.
2A procedure for point decompression is given in A.12.11.
3NOTES
41—It may be more efficient to determine by comparing the coefficients of yP and yP directly, rather than first
5computing FE2IP (yP) and FE2IP (yP).
62—Although the SORT compressed form is defined here for any field, in the representations below it is only employed
7for elliptic curves over GF(2m) and GF(pm).
83—The name “SORT” refers to the fact that the compressed bit is based on comparing the integer representations of yP
9and yP.
11For all the conversion primitives in this subclause, the point O shall be represented by an octet string
12containing a single 0 octet. The rest of this subclause discusses octet string representation of a point P O.
13Let the x-coordinate of P be xP and the y-coordinate of P be yP. Let (xP, ) be the compressed representation
14of P in one of the forms above.
15The representations in this subclause are all “lossless,” i.e., the elliptic curve point can be uniquely
16recovered from its octet string representation, because both coordinates are represented.
17An octet string PO representing P shall have one of the following three formats: compressed,
18uncompressed, or hybrid. (The hybrid format contains information of both compressed and uncompressed
19form.) For all primitives in this subclause, PO shall have the following general form
20PO = PC || X || Y
21where
22
23 PC is a single octet of the form 0000SUC defined as follows:
24 — Bit S is 1 if the format uses the SORT compressed form; 0 otherwise.
25 — Bit U is 1 if the format is uncompressed or hybrid; 0 otherwise.
26 — Bit C is 1 if the format is compressed or hybrid; 0 otherwise.
27 — Bit is equal to the bit if the format is compressed or hybrid; 0 otherwise.
28
29 X is the octet string of length log256 q representing xP according to FE2OSP (see 5.5.4).
30
31 Y is the octet string of length log256 q representing yP of P according to FE2OSP (see 5.5.4) if the
32 format is uncompressed or hybrid; Y is an empty string if the format is compressed.
33The primitive that converts elliptic curve points to octet strings for a given representation is called Elliptic
34Curve Point to Octet String Conversion Primitive–R, or EC2OSP–R, where R is the representation. It takes
35an elliptic curve point P and the size q of the underlying field as input and outputs the corresponding octet
36string PO.
2 33
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The primitive that converts octet strings to elliptic curve points is called Octet String to Elliptic Curve Point
2Conversion Primitive–R, or OS2ECP–R. It takes the octet string and the field size q as inputs and outputs
3the corresponding elliptic curve point, or “error.” It shall use OS2FEP to get xP. It shall use OS2FEP to get
4yP if the format is uncompressed, and may output “error” if the recovered point is not on the elliptic curve.
5It shall use point decompression (see 5.5.6.1) to get yP if the format is compressed. It can get yP by either of
6these two means if the format is hybrid, and, if the format is hybrid, may output “error” if different values
7are obtained by the two means. It shall output “error” in the following cases:
8
9 If the first octet is not as expected for the representation
10 If the octet string length is not as expected for the representation
11 If an invocation of OS2FEP outputs “error”
12 If an invocation of the point decompression algorithm outputs “error”
13The pairs of primitives for each of five representations are defined in the following subclauses.
15This representation is defined for elliptic curves over all finite fields in this standard.
16In this representation, the octet PC shall have binary value 0000 0100 and the octet strings X and Y shall
17represent xP and yP respectively. The length of the octet string PO shall be 1+ 2 log256 q. The
18corresponding primitives are called EC2OSP-XY and OS2ECP-XY.
20This representation is defined for elliptic curves over GF(p) and GF(2m) only.
21In this representation, the octet PC shall have binary value 0000 001 where is equal to the bit in the LSB
22compressed form, the octet string X shall represent xP, and the octet string Y shall be the empty string. The
23length of the octet string PO shall be 1+ log256 q. The corresponding primitives are called EC2OSP-XL
24and OS2ECP-XL.
26This representation is defined for elliptic curves over GF(2m) and GF(pm) only.
27In this representation, the octet PC shall have binary value 0000 101 where is equal to the bit in the SORT
28compressed form, the octet string X shall represent xP, and the octet string Y shall be the empty string. The
29length of the octet string PO shall be 1+ log256 q. The corresponding primitives are called EC2OSP-XS
30and OS2ECP-XS.
32This representation is defined for elliptic curves over GF(p) and GF(2m) only.
33In this representation, the octet PC shall have binary value 0000 011 where is equal to the bit in the LSB
34compressed form, and the octet strings X and Y shall represent xP and yP respectively. The length of the
2 34
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1octet string PO shall be 1+ 2 log256 q. The corresponding primitives are called EC2OSP-XYL and
2OS2ECP-XYL.
4This representation is defined for elliptic curves over GF(2m) and GF(pm) only.
5In this representation, the octet PC shall have binary value 0000 111 where is equal to the bit in the SORT
6compressed form, and the octet strings X and Y shall represent xP and yP respectively. The length of the
7octet string PO shall be 1+ 2 log256 q. The corresponding primitives are called EC2OSP-XYS and
8OS2ECP-XYS.
10The x-coordinate only representation in this subclause is “lossy,” i.e., the elliptic curve point cannot be
11uniquely recovered from its octet string representation, because only the x-coordinate is represented.
12This representation is defined for elliptic curves over all fields in this standard.
13In this representation, the octet PC shall have binary value 0000 0001, the octet string X shall represent xP,
14and the octet string Y shall be empty. The length of the octet string PO shall be 1+ log256 q. The
15corresponding primitives are called EC2OSP-X and OSC2ECP-X.
16OS2ECP-X may output any of the (at most two) elliptic curve points with the given x-coordinate. Thus, the
17original y-coordinate is not necessarily recovered.
18This representation should be employed only if the recipient of the octet string PO does not need to resolve
19the ambiguity in the y-coordinate, or can do so by other means.
20NOTE—In some situations, only the x-coordinate is needed. For instance, the shared secret value computed by
21ECSVDP-DH or ECSVDP-DHC depends only on the x-coordinate of other party’s public key, not the y-coordinate. If
22this representation is employed in such a situation, then when the “octet-string-to-point” conversion primitive is called,
23the implementation need not compute a y-coordinate at all (though it may output “error” if no point exists with the
24given x-coordinate).
2 35
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
OS2ECP-XS GF(pm)
NOTES
1—The first four bits of the first octet PC are reserved and may be used in future formats defined in
an amendment to, or in future versions of, this standard. It is essential that they be set to 0 and
checked for 0 in order to distinguish the formats defined here from other formats. Of course,
implementations may support other, non-standard formats that employ the reserved bits, but these
formats would not conform with the ones defined in this clause.
2—The various representations employ distinct values for the first octet PC, so the octet strings
produced by the different representations are non-overlapping, except at the point O. Consequently,
a “generic” OS2ECP primitive may be constructed that handles all of the representations.
76.1.1 Notation
8The list below introduces the notation used in Clauses 6, 9, and 10. It is meant as a reference guide only;
9for complete definitions of the terms listed, refer to the appropriate text. Some other symbols are also used
10occasionally; they are introduced in the text where appropriate.
11
12 q The size of the field used (part of the DL domain parameters)
13 r The prime divisor of q – 1 and the order of g (part of the DL domain parameters)
14 g An element of the field GF (q) generating a multiplicative subgroup of order r (part of the DL
15 domain parameters)
16 k (q – 1) / r, the cofactor
17 s, u, s, u DL private keys, integers, corresponding to public keys w, v, w, v, respectively
18 w, v, w, v DL public keys, elements of GF (q), corresponding to private keys s, u, s, u,
19 respectively
2 36
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 (s, w), (u, v) DL key pairs, where s and u are private keys, and w and v are the corresponding public
2 keys
3 z, z1, z2 Shared secret values, elements of GF (q), derived by secret value derivation primitives
4 K Shared secret key agreed upon by a key agreement scheme
5 f Message representative, an integer, computed by a message encoding operation
6 M The message, an octet string, whose signature is computed by a signature scheme
7 (c, d) Signature, a pair of integers, computed by a signature primitive
8 c Signature part, an integer, computed by a signature primitive
9 d Signature part, an integer, computed by a signature primitive
10 h Randomized hash value, an integer
11 i Pre-signature, an integer
12 u Randomizer, an integer
13 C Encrypted message, an octet string, computed by an encryption scheme
14 M1 Recoverable message part, an octet string, the part of a message that can be recovered from the
15 signature in a signature scheme giving message recovery
16 M2 Non-recoverable message part (if any), an octet string, the part of a message that cannot be
17 recovered from the signature in a signature scheme giving message recovery
18 T Authentication tag, a bit string, computed by an encryption scheme
19
20NOTES
211—When keys from two parties are involved in a primitive or scheme, the symbols s, u, w, v are used to denote the
22party’s own keys, and the symbols s, u, w, v are used to denote the other party’s keys.
232—Multiplication of field elements, as well as multiplication of integers, is denoted by , although this symbol may be
24omitted when such omission does not cause ambiguity. The notation such as exp( w, c), where w is a field element and
25c 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
26integer.
273—Throughout this clause, operations on finite field elements and integers are being used. Care needs to be exercised
28to distinguish integers from field elements, as operations on integers and field elements are denoted by the same
29symbols. See Clause 5.3 for more information on finite fields.
31DL domain parameters are used in every DL primitive and scheme and are an implicit component of every
32DL key. A set of DL domain parameters specifies a field GF(q), where q is a positive odd prime integer p,
332m for some positive integer m, or pm for an odd prime p and some integer m 2; a positive prime integer r
34dividing (q – 1); and a field element g of multiplicative order r (g is called the generator of the subgroup of
35order r). If q = 2m, it also specifies a representation for the elements of GF(q) to be used by the conversion
36primitives (see 5.3 and 5.5). Implicitly it also specifies the cofactor k = (q – 1) / r. If the DLSVDP-DHC or
37DLSVDP-MQVC primitive is to be applied, then it shall also be the case that GCD (k, r) = 1 (i.e., r does
38not divide k; see A.1.1).
39Depending on the scheme and protocol used, a party may need to generate its own set of domain
40parameters or use domain parameters provided by another party. If parameters are provided by another
41party, their authenticity may need to be determined (as further discussed in Annex D.3.1), and they may
42need to be validated (see below). The security issues related to domain parameter generation are discussed
43in D.3.2 and D.4.1. Suggested methods for generating DL domain parameters are contained in Annex
44A.16.1 and A.16.3.
45Parties establish DL domain parameters as part of key management for a scheme. Depending on the key
46management technique, it is possible that the established domain parameters do not satisfy the intended
47definition, even though they have the same general form (i.e., components q, r, g and optionally k). To
48accommodate this possibility, the term “DL domain parameters” shall be understood in this standard as
2 37
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1referring to instances of the general form for DL domain parameters. The term valid DL domain
2parameters shall be reserved for DL domain parameters satisfying the definition.
3Domain parameter validation is the process of determining whether a set of DL domain parameters is
4valid. Further discussion of domain parameter validation is contained in D.3.3. Suggested algorithms for
5DL domain parameter validation are contained in Annex A.16.2 and A.16.4.
6There may be more than one set of domain parameters used in a primitive or scheme; the sets of DL
7domain parameters may be different for different keys, or they may be the same, depending on the
8requirements of a primitive or scheme. Unlike keys, which are not meant to be shared among users, a set of
9domain parameters can and sometimes needs to be shared. DL domain parameters are often public; the
10security of the schemes in this standard does not rely on these domain parameters being secret.
12For a given set of DL domain parameters, a DL key pair consists of a DL private key s which is an integer
13in the range [1, r – 1] and a DL public key w which is an element of GF (q), where w = exp(g, s). For
14security, DL private keys need to be generated so that they are unpredictable and stored so that they are
15inaccessible to an adversary. DL private keys may be stored in any form convenient to the application.
16DL key pairs are closely associated with their domain parameters, and can only be used in the context of
17the domain parameters. A key pair shall not be used with a set of domain parameters different from the one
18for which it was generated. A set of domain parameters may be shared by a number of key pairs (see
19Annex D.4.1.2 and D.4.1.4, Note 1).
20A DL key pair may or may not be generated by the party using it, depending on the trust model. This and
21other security issues related to DL key pair generation are discussed in D.3.2 and D.4.1. A suggested
22method for generating DL key pairs is contained in A.16.5.
23As is also the case for DL domain parameters, parties establish DL keys as part of key management for a
24scheme, and depending on the key management technique, it is possible that an established key does not
25satisfy the intended definition for the key, even though it has the same general form. Accordingly, the terms
26“DL public key” and “DL private key” shall be understood in this standard as referring to instances of the
27general form for the key, and the terms valid DL public key, valid DL private key, and valid DL key pair
28shall be reserved to keys satisfying the definition.
29Key validation is the process of determining whether a key is valid. Further discussion of key validation is
30contained in D.3.3. A suggested algorithm for DL public key validation is contained in Annex A.16.6. In
31some cases (when DLSVDP-DHC or DLSVDP-MQVC primitive is applied), it may only be necessary to
32verify that the public key is a member of GF (q) (rather than a stronger condition that it is a power of g
33other than one). The algorithm to verify this weaker condition is also contained in Annex A.16.6. No
34algorithm is given for DL private key validation, because, generally, a party controls its own private key
35and need not validate it. However, private key validation may be performed if desired.
366.2 Primitives
37This clause describes primitives used in the DL family. Before proceeding with this clause, the reader
38should be familiar with the material of Clause 4.
39As detailed in Clause 4 and Annex B, an implementation of a primitive may make certain assumptions
40about its inputs, as listed with the specification of the primitive. For example, if DL domain parameters q,
41r and g and a public key w are inputs to a primitive, an implementation may generally assume that the
2 38
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1domain and the public key parameters are valid, i.e., that g has order r in GF (q) and w = exp(g, s) for some
2integer s in the interval [1, r – 1]; the behavior of an implementation is not specified if w is not a power of
3g, and in such a case the implementation may or may not output an error condition. It is up to the properly
4implemented scheme to ensure that only appropriate inputs are passed to a primitive, or to accept the risks
5of passing inappropriate inputs. For more on conforming with a primitive, see Annex B.
66.2.1 DLSVDP-DH
7DLSVDP-DH is Discrete Logarithm Secret Value Derivation Primitive, Diffie-Hellman version. It is based
8on the work of [DH76]. This primitive derives a shared secret value from one party’s public key and
9another party’s private key, where the keys have the same set of DL domain parameters. If two parties
10correctly execute this primitive with corresponding keys as inputs, they will produce the same output. This
11primitive can be invoked by a scheme to derive a shared secret key; specifically, it may be used with the
12schemes DLKAS-DH1 and DL/ECKAS-DH2. It assumes that the input keys are valid (see also Clause
136.2.2).
14Input:
15 the DL domain parameters q, r and g associated with the keys s and w (the domain parameters
16 shall be the same for both s and w)
17 the party’s own private key s
18 the other party’s public key w
19Assumptions: private key s, DL domain parameters q, r and g, and public key w are valid; both keys are
20associated with the domain parameters
21Output: the derived shared secret value, which is a nonzero field element z GF (q)
22Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
23steps:
311—This primitive does not address small subgroup attacks (see Annex D.5.1.6), which may occur when the public key
32w is not valid. To prevent them, a key agreement scheme should validate the public key w before executing this
33primitive (see also Clause 6.2.2).
342—When the public key w and the private key s are valid, w has order r and s is in the interval [1, r-1]. Thus the
35output z in this case is neither the element zero nor the element one.
2 39
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
16.2.2 DLSVDP-DHC
2DLSVDP-DHC is Discrete Logarithm Secret Value Derivation Primitive, Diffie-Hellman version with
3cofactor exponentiation. It is based on the work of [DH76], [LMQ98] and [Kal98a]. This primitive
4derives a shared secret value from one party’s public key and another party’s private key, where the keys
5have the same set of DL domain parameters. If two parties correctly execute this primitive with
6corresponding keys as inputs, they will produce the same output. This primitive can be invoked by a
7scheme to derive a shared secret key; specifically, it may be used with the schemes DLKAS-DH1 and
8DL/ECKAS-DH2. It does not assume the validity of the input public key, but does assume that the public
9key is an element of GF(q) (see also Clause 6.2.1).
10Input:
11 the DL domain parameters q, r, g and the cofactor k associated with the keys s and w (the domain
12 parameters shall be the same for both s and w)
13 the party’s own private key s
14 the other party’s public key w
15 an indication as to whether compatibility with DLSVDP-DH is desired
16Assumptions: private key s and DL domain parameters q, r, g and k are valid; the private key is associated
17with the domain parameters; w is in GF (q); GCD (k, r) = 1
18Output: the derived shared secret value, which is a nonzero field element z GF (q); or “invalid public
19key”
20Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
21steps:
22 c) If compatibility with DLSVDP-DH is desired, then compute an integer t = k–1s mod r; otherwise set
23 t = s.Compute a field element z = exp(w, kt).If z = 0 or z = 1, output “invalid public key”; else,
24 output z as the shared secret value.
25Conformance region recommendation. A conformance region should include:
311—This primitive addresses small subgroup attacks, which may occur when the public key w is not valid (see Annex
32D.5.1.6). A key agreement scheme only needs to validate that w is in GF (q) before executing this primitive (see also
33Clause 6.2.1).
342—The cofactor k depends only on the DL domain parameters and is equal to (q – 1) / r. Hence, it can be computed
35once for a given set of domain parameters and stored as part of the domain parameters. Similarly, in the compatibility
36case, the value k–1 can be computed once and stored with the domain parameters, and the integer t can be computed
37once for a given private key s.
2 40
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
13—When the public key w and the private key s are valid, the output z will be an element of a subset of GF (q) that
2consists of all the powers of g (except for the element one). As a consequence, z cannot be the element zero or the
3element one in this case. When the public key is invalid, the output will be either “invalid public key” or an element of
4order r in GF (q); in particular, it will not be in a small subgroup.
54—In the compatibility case, DLSVDP-DHC computes the same output for valid keys as DLSVDP-DH, so an
6implementation that conforms with DLSVDP-DHC in the compatibility case also conforms with DLSVDP-DH.
76.2.3 DLSVDP-MQV
14In this primitive, let h = (log2 r) / 2. Note that h depends only on the DL domain parameters, and hence
15can be computed once for a given set of domain parameters.
16Input:
17 the DL domain parameters q, r and g associated with the keys s, (u, v), w, and v (the domain
18 parameters shall be the same for these keys)
19 the party’s own first private key s
20 the party’s own second key pair (u, v)
21 the other party’s public key w
22 the other party’s second public key v
23Assumptions: private key s, key pair (u, v), public keys w, v, and DL domain parameters q, r and g are
24valid; all the keys are associated with the domain parameters
25Output: the derived shared secret value, which is a nonzero field element z GF (q); or “error”
26Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
27steps:
28 d) Convert v into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.Convert v
29 into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.Compute an
30 integer e = ts + u mod r.Compute a field element z = exp(v exp(w, t), e).If z = 1, output “error”
31 and stop.
32 8. Output z as the shared secret value.
33Conformance region recommendation. A conformance region should include:
2 41
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
11—This primitive does not address small subgroup attacks (see Annex D.5.1.6), which may occur when the public keys
2w and v are not valid. To prevent them, a key agreement scheme should validate the public keys w and v before
3executing this primitive (see also Clause 6.2.4).
42—When the public keys w and v are valid, the output z will be an element of a subset of GF (q) that consists of all
5the powers of g. It is possible (although very unlikely) that even though all the keys and parameters are valid, z will be
6the element one. In this case, the primitive will output “error,” and will need to be re-run with a different input. Except
7for this rare case, z will always be defined and will not be the element zero or the element one as long as the input keys
8and parameters are valid.
96.2.4 DLSVDP-MQVC
17In this primitive, let h = (log2 r) / 2. Note that h depends only on the DL domain parameters, and hence
18can be computed once for a given set of domain parameters.
19Input:
20 the DL domain parameters q, r, g and the cofactor k associated with the keys s, (u, v), w, and v
21 (the domain parameters shall be the same for these keys)
22 the party’s own first private key s
23 the party’s own second key pair (u, v)
24 the other party’s public key w
25 the other party’s second public key v
26 an indication as to whether compatibility with DLSVDP-MQV is desired
27Assumptions: private key s, key pair (u, v), and DL domain parameters q, r, g and k are valid; private key
28s and key pair (u, v) are associated with the domain parameters; w and v are in GF (q); GCD (k, r) = 1
29Output: the derived shared secret value, which is a nonzero field element z GF (q); or “invalid public
30key”
31Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
32steps:
33 e) Convert v into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.Convert v
34 into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.If compatibility
35 with DLSVDP-MQV is desired, then compute an integer e = k–1(ts + u) mod r; otherwise compute
36 an integer e = ts + u mod r.Compute a field element z = exp(v exp(w, t), ke).If z = 0 or z = 1,
37 output “invalid public key”; else, output z as the shared secret value.
38Conformance region recommendation. A conformance region should include:
2 42
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 all valid key pairs (u, v) associated with the same set of domain parameters as s
2 all elements w and v in GF (q), where q is from the domain parameters of s
3 compatibility with DLSVDP-MQV may be preset by the implementation, or given as an input flag
4NOTES
51—This primitive addresses small subgroup attacks, which may occur when the public keys w and v are not valid (see
6Annex D.5.1.6). A key agreement scheme only needs to validate that w and v are in GF (q) before executing this
7primitive (see also Clause 6.2.3).
82—The cofactor k depends only on the DL domain parameters and is equal to (q – 1) / r. Hence, it can be computed
9once for a given set of domain parameters and stored as part of the domain parameters. Similarly, in the compatibility
10case, the value k-1 can be computed once and stored with the domain parameters. An equivalent way to compute the
11integer e in this case is as (tk–1s + k–1u) mod r, where k–1s mod r and k–1u mod r can be computed once for each given
12private key s and u.
133—When the public keys w and v are valid, the output z will be an element of a subset of GF (q) that consists of all
14the powers of g. It is possible (although very unlikely) that even though all the keys and parameters are valid, z will be
15the element one, and the primitive will output “invalid public key.” In this case, the primitive will need to be re-run
16with a different input. Except for this rare case, z will always be defined and will not be the element zero or the
17element one as long as the input keys and parameters are valid. When one of the public keys is invalid, the output will
18be either “invalid public key” or an element of order r in GF (q); in particular, it will not be in a small subgroup.
194—In the compatibility case, DLSVDP-MQVC computes the same output for valid keys as DLSVDP-MQV, so an
20implementation that conforms with DLSVDP-MQVC in the compatibility case also conforms with DLSVDP-MQV.
216.2.5 DLSVDP-HMQV
30In this primitive, let h = (log2 r) / 2. Note that h depends only on the DL domain parameters, and hence
31can be computed once for a given set of domain parameters.
32Input:
33 the DL domain parameters q, r and g associated with the keys s, (u, v), w, and v (the domain
34 parameters shall be the same for these keys)
35 the party’s own first private key s
36 the party’s own second key pair (u, v)
37 the other party’s public key w
38 the other party’s second public key v
39 the party’s identity, denoted id, and the other party’s identity, denoted id’
40 a specified hash function H with output of length ≥ h.
2 43
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Assumptions: private key s, key pair (u, v), and DL domain parameters q, r and g are valid; private key s
2and keypair (u, v) are associated with the domain parameters; public keys w, and v are in GF(q)\{0,1}.
3Output: the derived shared secret value, which is a nonzero field element z GF (q); or “invalid public
4key”
5Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
6steps:
31NOTE 2—A secure key agreement protocol must ensure that, even in the presence of an adversary that controls the
32communication channels and may corrupt individual parties and sessions, keys computed at uncorrupted parties and
33associated with peers that are also uncorrupted remain unguessable by the attacker. In particular, the attacker should not
34be able to force such keys to fall in a small subset of values. DLSVDP-HMQV guarantees this property as follows: any
35shared value z established at an uncorrupted party and associated with a peer’s identity id’, where id’ identifies an
36uncorrupted party, must be of order divisible by r in GF(q), and hence its set of possible values is at least of size r. In
37the case in which a party performs an r-order test, it is guaranteed that z is of exact order r. Yet this property (exact
38order r, rather than order simply divisible by r) is of no advantage in this case since the value z is not used directly but
39instead input into a hash function. Note that keys esatablished by corrupted parties or with corrupted parties may
40belong to arbitrary sets; there is no security guarantee provided on such keys (even if such a key may fall in a large set,
41the key is still insecure as the corrupted peer can choose its private exponents from a small set or simply leak the key,
42etc).
2 44
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1NOTE 3—It is imperative for the security of key agreement protocols based on DLSVDP-HMQV that the shared
2secret z is not used directly as a key but only as the input to a strong KDF. It is shown in [Kra05] that if the value z
3arising from an execution of the protocol is revealed to the attacker then the attacker can use this value to attack the
4keys of other sessions, thus compromising the security of the key agreement protocol. In the case of HMQV, the
5hashing of z via the KDF is sufficient to guarantee the security of the protocol, independently of possible additional
6parameters involved in the hashing of z.
7NOTE 4—Since the protocol requires to test that both public keys contributed by the other party are in GF(q)\{0,1}, z
8cannot be 0 and will be 1 with negligible probability. Thus an output of either 0 or 1 is regarded as a strong indication
9of a failure in the testing of public keys and causes an error message of “invalid public key”. This event may trigger a
10new run of the primitive with new inputs and it should be logged as a potential security breach.
11NOTE 5—The comptation of z includes the identities of the peers. Identities are octet strings that uniquely identify an
12entity (in this case, a participant in the protocol) for the purpose of authentication. Identities may include names as well
13as other attributes that are relevant to the unique identification and authentication of an entity. When digital certificates
14are used to bind entities to public keys, the identities used in the protocol will usually be the same as or related to the
15identity appearing in the certificate (or may be the certificate itself). The specific meaning of identities and the
16decisions made on the basis of such identities vary by scenario and application, and are usually determined by policy
17rules, authorization and access control mechanisms, etc.
186.2.6 DLSVDP-HMQVC
19DLSVDP-MQV is Discrete Log Secret Value Derivation Primitive, Hashed Menezes-Qu-Vanstone version
20with cofactor exponentiation. It is based on the work of [LMQ98], [Kal98a] and [Kra05]. This primitive
21derives a shared secret value from one party’s two key pairs and another party’s two public keys, where all
22the keys and values have the same set of EC domain parameters. The computation of the shared secret also
23involves the identities of the parties and a hash function. If two parties correctly execute this primitive, they
24will produce the same output. This primitive can be invoked by a scheme to derive a shared secret key;
25specifically, it may be used with the scheme DLKAS-MQV (see Clause ***). It does not assume the
26validity of the input public keys, but does assume that the public keys are elements of GF(q)\{0,1}.
27In this primitive, let h = (log2 r) / 2. Note that h depends only on the DL domain parameters, and hence
28can be computed once for a given set of domain parameters.
29Input:
30 the DL domain parameters q, r and g associated with the keys s, (u, v), w, and v (the domain
31 parameters shall be the same for these keys)
32 the party’s own first private key s
33 the party’s own second key pair (u, v)
34 the other party’s public key w
35 the other party’s second public key v
36 the party’s identity, denoted id, and the other party’s identity, denoted id’
37 a specified hash function H with output of length ≥ h.
38Assumptions: private key s, key pair (u, v), and DL domain parameters q, r, k and g are valid; private key
39s and keypair (u, v) are associated with the domain parameters; public keys w, and v are in GF(q)\{0,1};
40GCD(k,r) = 1.
41Output: the derived shared secret value, which is a nonzero field element z GF (q); or “invalid public
42key”
2 45
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
2steps:
26NOTE 2—The cofactor k depends only on the DL domain parameters and is equal to (q − 1)/r. Hence, it can be
27computed once for a given set of domain parameters and stored as part of the domain parameters. Similarly, in the
28compatibility case, the value k−1 can be computed once and stored with the domain parameters. An equivalent way to
29compute the integer e in this case is as (tk−1s + k−1u) mod r , where k−1s mod r and k−1u mod r can be computed once for
30each given private key s and u.
31NOTE 3—Since the protocol requires to test that both public keys contributed by the other party (the peer), namely v’
32and w’, are in GF(q) \ {0, 1} then z cannot be 0 and can be 1 with negligible probability only. Thus an output of either 0
33or 1 is regarded as a strong indication of a failure in the testing of public keys and hence the corresponding abort
34message “invalid public key” output by the protocol in this case. This event may trigger a new run of the primitive with
35new inputs, and it should be logged as a potential security breach. In all other cases, it is guaranteed that z is of order q;
36in particular, it will not be in a small group.
37NOTE 4—In the compatibility case, DLSVDP-HMQVC computes the same output as DLSVDP-HMQV, so an
38implementation that conforms with DLSVDP-HMQVC in the compatibility case also conforms with DLSVDP-
39HMQV.
40NOTE 5—It is imperative for the security of key agreement protocols based on DLSVDP-HMQVC (and the same is
41true for HMQV and the original MQV protocols) that the shared secret z not be used directly as a key but only as the
42input to a KDF (actually a strong KDF modeled as a random oracle in analysis). See more on this in note number 3 in
43Section 6.2.3’.
2 46
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
16.2.7 DLSP-NR
2DLSP-NR is the Discrete Logarithm Signature Primitive, Nyberg-Rueppel version. It is based on the work
3of Nyberg and Rueppel [B120]. It can be invoked in a scheme to compute a signature on a message
4representative with the private key of the signer, in such a way that the message representative can be
5recovered from the signature using the public key of the signer by the DLVP-NR primitive. Note, however,
6that the DLPSP-NR2/PV and DLSP-NR2 primitives are intended for signature schemes giving message
7recovery in this version of the standard. DLSP-NR can be invoked in the scheme DLSSA as part of
8signature generation.
9Input:
15Output: the signature, which is a pair of integers (c, d), where 1 c < r and 0 d < r
16Operation. The signature (c, d) shall be computed by the following or an equivalent sequence of steps:
17 f) Generate a key pair (u, v) with the same set of domain parameters as the private key s. (See the
18 note below.)Convert v into an integer i with primitive FE2IP (recall that v is an element of
19 GF (q)).Compute an integer c = i + f mod r. If c = 0, then go to Step 1.Compute an integer d = u –
20 sc mod r.Output the pair (c, d) as the signature.
21Conformance region recommendation. A conformance region should include:
261—The key pair in step 1 should be a one-time key pair which is generated and stored by the signer following the
27security recommendations of D.3.1, D.4.1.2, D.6 and D.7. The private key should be selected in an unbiased manner
28(see D.5.2.1 for further discussion), and a new key pair should be generated for every signature. The one-time private
29key u should be securely deleted after step 4, as its recovery by an opponent can lead to the recovery of the private key
30s.
312—The one-time key pair in step 1 may be precomputed in advance of the availability of the message representative.
32See D.5.2.1 for further discussion.
336.2.8 DLVP-NR
34DLVP-NR is the Discrete Logarithm Verification Primitive, Nyberg-Rueppel version. It is based on the
35work of Nyberg and Rueppel [B120]. This primitive recovers the message representative that was signed
36with DLSP-NR, given only the signature and public key of the signer. It can be invoked in a scheme as part
37of signature verification and, possibly, message recovery. Note, however, that the DLVP-NR2 primitive is
38intended for signature schemes giving message recovery in this version of the standard. DLVP-NR can be
39invoked in the scheme DLSSA as part of signature verification.
2 47
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Input:
6Output: the message representative, which is an integer f such that 0 f < r; or “invalid”
7Operation. The message representative f shall be computed by the following or an equivalent sequence of
8steps:
9 g)If c is not in [1, r – 1] or d is not in [0, r – 1], output “invalid” and stop.Compute a field element j =
10 exp(g, d) exp(w, c).Convert the field element j to an integer i with primitive FE2IP.Compute an
11 integer f = c – i mod r.Output f as the message representative.
12Conformance region recommendation. A conformance region should include:
176.2.9 DLSP-DSA
18DLSP-DSA is Discrete Logarithm Signature Primitive, DSA version. It is based on the work of [Kra93]. It
19can be invoked in a scheme to compute a signature on a message representative with the private key of the
20signer. The message representative cannot be recovered from the signature, but DLVP-DSA can be used in
21the scheme DLSSA to verify the signature.
22Input:
28Output: the signature, which is a pair of integers (c, d), where 1 c < r and 1 d < r
29Operation. The signature (c, d) shall be computed by the following or an equivalent sequence of steps:
30 h) Generate a key pair (u, v) with the same set of domain parameters as the private key s. (See the note
31 below.)Convert v into an integer i with primitive FE2IP (recall that v is an element of
32 GF (q)).Compute an integer c = i mod r. If c = 0, then go to Step 1.Compute an integer d = u–1(f +
33 sc) mod r. If d = 0, then go to Step 1.Output the pair (c, d) as the signature.
34Conformance region recommendation. A conformance region should include:
2 48
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 at least one valid private key s for each set of domain parameters
2 a range of message representatives f; this should at least include all f 0 with bit length no greater
3 than that of r, where r is from the domain parameters of s
4NOTES
51—The key pair in step 1 should be a one-time key pair which is generated and stored by the signer following the
6security recommendations of D.3.1, D.4.1.2, D.6 and D.7. The private key should be selected in an unbiased manner
7(see D.5.2.1 for further discussion), and a new key pair should be generated for every signature. The one-time private
8key u should be securely deleted after step 4, as its recovery by an opponent can lead to the recovery of the private key
9s.
102—Similar to DLSP-NR, the one-time key pair in step 1 may be precomputed in advance of the availability of the
11message representative. Steps 2 and 3 as well as the values u–1 and sc in step 4 may also be precomputed. See D.5.2.1
12for further discussion.
136.2.10 DLVP-DSA
14DLVP-DSA is Discrete Logarithm Verification Primitive, DSA version. It is based on the work of
15[Kra93]. This primitive verifies whether the message representative and the signature are consistent given
16the key and the domain parameters. It can be invoked in the scheme DLSSA as part of signature
17verification.
18Input:
26Operation. The output shall be computed by the following or an equivalent sequence of steps:
27 i) If c is not in [1, r – 1] or d is not in [1, r – 1], output “invalid” and stop.Compute integers h = d –1
28 mod r; h1 = f h mod r; h2 = c h mod r.Compute a field element j = exp(g, h1) exp(w, h2).Convert
29 the field element j to an integer i with primitive FE2IP.Compute an integer c = i mod r.
30 6. If c = c, then output “valid”; else, output “invalid.”
31Conformance region recommendation. A conformance region should include:
2 49
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
16.2.11 DLPSP-NR2/PV
9Output:
14
15 1. Generate a key pair (u, v) with the set of domain parameters. (See the notes below.)
16 2. Convert v into an integer i with primitive FE2IP (recall that v is an element of GF(q)).
17 3. Output u as the randomizer and i as the pre-signature.
18Conformance region recommendation: A conformance region should include:
211—The key pair in step 1 should be a one-time key pair which is generated by the signer following the security
22recommendations of D.3.1, D.4.1.2, D.6 and D.7. The randomizer should be selected in an unbiased manner (see
23D.5.2.1 for further discussion), and a new randomizer / pre-signature pair should be generated for every signature. (If
24signatures are computed with the same randomizer for two or more different message representatives, or if the
25randomizer becomes known, an opponent may be able to recover the signer’s private key.) The randomizer should be
26stored following the same security recommendations as for an ephemeral private key (it should be securely deleted
27after it is used in DLSP-NR2 or DLSP-PV).
282—Similar to DLSP-NR, the key pair may be precomputed in advance of the availability of the message representative.
296.2.12 DLSP-NR2
30DLSP-NR2 is the Discrete Logarithm Signature Primitive, Nyberg-Rueppel version 2. It is based on the
31work of ISO/IEC 9796-3:2000 [B79] and Nyberg and Rueppel [B120]. The primitive generates a signature
32on a message representative with the private key of the signer, given a randomizer and a pre-signature
33generated by DLPSP-NR2/PV, in such a way that the message representative and the pre-signature can be
34recovered from the signature using the public key of the signer by the DLVP-NR or DLVP-NR2 primitive.
35It can be invoked in the scheme DLSSR as part of signature generation. DLSP-NR2 corresponds to the last
36three steps of DLSP-NR.
37Except for having DL domain parameters as input rather than EC domain parameters, the primitive is
38identical to ECSP-NR2.
39Input:
2 50
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
8Output: The signature, which is a pair of integers (c, d) such that 1 c < r and 0 d < r; or “error”
9Operation: The signature (c, d) shall be computed by the following or an equivalent sequence of steps:
10
11 1. Compute an integer c = i + f mod r. If c = 0, then output “error.” (This is an extremely rare
12 event for recommended values of r — see Note 2.)
13 2. Compute an integer d = u – sc mod r.
14 3. Output the pair (c, d) as the signature.
15Conformance region recommendation: A conformance region should include:
221—Following the discussion above for DLPSP-NR2/PV, for security reasons, the randomizer u should be securely
23deleted after step 2.
242—The probability that the primitive will output “error” is about 1/r (i.e., essentially 0 for recommended values of r),
25assuming the pre-signature i is generated at random by DLPSP-NR2/PV. Thus, the check at the end of step 1 is
26included for completeness only; it is unlikely to occur in practice. The motivation for the check is to ensure that the
27signature depends on the signer’s private key s; otherwise the signature could be verified with anyone’s public key with
28the same domain parameters. (An “error” output in any case does not disclose any information about the private key s,
29since the private key is not involved in the pre-signature primitive or prior to step 2.)
306.2.13 DLVP-NR2
31DLVP-NR2 is the Discrete Logarithm Verification Primitive, Nyberg-Rueppel version 2. It is based on the
32work of ISO/IEC 9796-3:2000 [B79] and Nyberg and Rueppel [B120]. This primitive recovers the message
33representative that was signed with DLSP-NR or DLSP-NR2, given only the signature and public key of
34the signer, and also recovers the pre-signature. It can be invoked in the scheme DLSSR as part of signature
35verification and message recovery. DLVP-NR2 is the same as DLVP-NR, except that the recovered pre-
36signature is output in addition to the message representative.
37Input:
2 51
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
4Output:
9
10 1. If c is not in [1, r – 1] or d is not in [0, r – 1], output “invalid” and stop.
11 2. Compute a field element j = exp(g, d) exp(w, c).
12 3. Convert the field element j to an integer i with primitive FE2IP.
13 4. Compute an integer f = c – i mod r.
14 5. Output f as the message representative and i as the pre-signature.
15Conformance region recommendation: A conformance region should include:
206.2.14 DLSP-PV
21DLSP-PV is the Discrete Logarithm Signature Primitive, Pintsov-Vanstone version. It is based on the work
22of Pintsov and Vanstone [PV99]. The primitive generates a signature part on a randomized hash value with
23the private key of the signer, given a randomizer generated by DLPSP-NR2/PV, in such a way that the pre-
24signature generated by DLPSP-NR2/PV can be recovered from the signature part using the public key of
25the signer by the DLVP-PV primitive. It can be invoked in the scheme DLSSR-PV as part of signature
26generation.
27Except for having DL domain parameters as input rather than EC domain parameters, the primitive is
28identical to ECSP-PV.
29Input:
2 52
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 1. Compute an integer d = u – sh mod r.
3 2. Output d as the signature part.
4Conformance region recommendation: A conformance region should include:
101—Following the discussion above for DLPSP-NR2/PV, for security reasons, the randomizer u should be securely
11deleted after step 1.
122—This primitive does not check whether h = 0 to ensure that the signature depends on the signer’s public key, since it
13is such an unlikely occurrence in the scheme in which DLSP-PV is employed, but an implementation could do so if
14desired.
156.2.15 DLVP-PV
16DLVP-PV is the Discrete Logarithm Verification Primitive, Pintsov-Vanstone version. It is based on the
17work of Pintsov and Vanstone [PV99]. This primitive recovers a pre-signature from a signature part
18generated with DLSP-PV, given only the randomized hash value and the public key of the signer. It can be
19invoked in the scheme DLSSR-PV as part of signature verification and message recovery.
20Input:
26
27 Output: The pre-signature, which is an integer i such that 1 i < q
28Operation: The pre-signature i shall be computed by the following or an equivalent sequence of steps:
29
30 1. If d is not in [0, r – 1], output “invalid” and stop.
31 2. Compute a field element j = exp(g, d) exp(w, h).
32 3. Convert the field element j to an integer i with primitive FE2IP.
33 4. Output i as the pre-signature.
34Conformance region recommendation: A conformance region should include:
1 All signature parts d that can be input to the implementation; this should at least include all d such
2 that d is in the range [0, r – 1]
3
2 54
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
67.1.1 Notation
7The list below introduces the notation used in Clauses 7, 9, and 10. It is meant as a reference guide only;
8for complete definitions of the terms listed, refer to the appropriate text. Some other symbols are also used
9occasionally; they are introduced in the text where appropriate.
11
12 q The size of the underlying field used (part of the EC domain parameters)
13 a, b The coefficients defining the elliptic curve E, elements of GF (q) (part of the EC domain
14 parameters)
15 E The elliptic curve over the field GF (q) defined by a and b
16 #E The number of points on the elliptic curve E
17 r The prime divisor of #E and the order of G (part of the EC domain parameters)
18 G A curve point generating a subgroup of order r (part of the EC domain parameters)
19 k #E / r, the cofactor
20 s, u, s, u EC private keys, integers, corresponding to public keys W, V, W, V, respectively
21 W, V, W, V EC public keys, points on the curve, corresponding to private keys s, u, s, u, respectively
22 (s, W), (u, V) EC key pairs, where s and u are the private keys, and W and V are the corresponding
23 public keys
24 z, z1, z2 Shared secret values, elements of GF (q), derived by secret value derivation primitives
25 K Shared secret key agreed upon by a key agreement scheme
26 f Message representative, an integer, computed by a message encoding operation
27 M The message, an octet string, whose signature is computed by a signature scheme
28 (c, d) Signature, a pair of integers, computed by a signature primitive
29 c Signature part, an integer, computed by a signature primitive
30 d Signature part, an integer, computed by a signature primitive
31 h Randomized hash value, an integer
32 i Pre-signature, an integer
33 u Randomizer, an integer
34 C Encrypted message, an octet string, computed by an encryption scheme
35 M1 Recoverable message part, an octet string, the part of a message that can be recovered from the
36 signature in a signature scheme giving message recovery
37 M2 Non-recoverable message part (if any), an octet string, the part of a message that cannot be
38 recovered from the signature in a signature scheme giving message recovery
39 T Authentication tag, a bit string, computed by an encryption scheme
40
41NOTES
421—When keys from two parties are involved in a primitive or scheme, the symbols s, u, W, V are used to denote the
43party’s own keys, and the symbols s, u, W, V are used to denote the other party’s keys.
2 55
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
12—Multiplication of field elements, multiplication of integers, and scalar multiplication of elliptic curve points by
2integers are denoted by , although this symbol may be omitted when such omission does not cause ambiguity.
3Addition of field elements, addition of integers, and addition of elliptic curve points are denoted by +. Elliptic curve
4points are always denoted by capital letters; for an elliptic curve point P O, its x-coordinate and y-coordinate are
5denoted by xP and yP, respectively: P = (xP, yP).
63—Throughout this clause, operations on finite field elements, integers, and elliptic curve points are used. Care needs
7to be exercised to distinguish these, as operations are denoted by the same symbols regardless of operands. See Clause
85.3 for more information on finite fields; Clause 5.4 for more information on elliptic curves.
10EC domain parameters are used in every EC primitive and scheme and are an implicit component of every
11EC key. A set of EC domain parameters specifies a field GF(q), where q is a positive odd prime integer p,
122m for some positive integer m, or pm for an odd prime p and some integer m 2; two elliptic curve
13coefficients a and b, elements of GF(q), that define an elliptic curve E; a positive prime integer r dividing
14the number of points on E; and a curve point G of order r (G is called the generator of a subgroup of order
15r). If q = 2m, it also specifies a representation for the elements of GF(q) to be used by the conversion
16primitives (see 5.3 and 5.5). Implicitly it also specifies the cofactor k = #E / r (where #E is the number of
17points on E). If key validation is to be performed or if the ECSVDP-DHC or ECSVDP-MQVC primitive is
18to be applied, then it shall also be the case that GCD (k, r) = 1 (i.e., r does not divide k; see A.1.1).
19Depending on the scheme and protocol used, a party may need to generate its own set of domain
20parameters or use domain parameters provided by another party. If parameters are provided by another
21party, their authenticity may need to be determined (as further discussed in Annex D.3.1), and they may
22need to be validated (see below). The security issues related to domain parameter generation are discussed
23in D.3.2 and D.4.2. A suggested method for generating EC domain parameters is contained in Annex
24A.16.7 (see also Annex A.9.5).
25Parties establish EC domain parameters as part of key management for a scheme. Depending on the key
26management technique, it is possible that the established domain parameters do not satisfy the intended
27definition, even though they have the same general form (i.e., components q, r, G and optionally k). To
28accommodate this possibility, the term “EC domain parameters” shall be understood in this standard as
29referring to instances of the general form for EC domain parameters. The term valid EC domain
30parameters shall be reserved for EC domain parameters satisfying the definition.
31Domain parameter validation is the process of determining whether a set of EC domain parameters is valid.
32Further discussion of domain parameter validation is contained in D.3.3. A suggested algorithm for EC
33domain parameter validation is contained in Annex A.16.8.
34There may be more than one set of domain parameters used in a primitive or scheme; the sets of EC
35domain parameters may be different for different keys, or they may be the same, depending on the
36requirements of a primitive or scheme. Unlike keys, which are not meant to be shared among users, a set of
37domain parameters can and sometimes needs to be shared. EC domain parameters are often public; the
38security of the schemes in this standard does not rely on these domain parameters being secret.
40For a given set of EC domain parameters, an EC key pair consists of an EC private key s which is an
41integer in the range [1, r – 1] and an EC public key W which is a point on E, where W = s G (note that W
42O, since G has order r and 0 < s < r). For security, EC private keys need to be generated so that they are
43unpredictable and stored so that they are inaccessible to an adversary. EC private keys may be stored in
44any form convenient to the application.
2 56
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1EC key pairs are closely associated with their domain parameters, and can only be used in the context of
2the domain parameters. A key pair shall not be used with a set of domain parameters different from the one
3for which it was generated. A set of domain parameters may be shared by a number of key pairs (see Annex
4D.4.2.2 and D.4.2.4, Note 1).
5An EC key pair may or may not be generated by the party using it, depending on the trust model. This and
6other security issues related to EC key pair generation are discussed in D.3.2 and D.4.2. A suggested
7method for generating EC key pairs is contained in Annex A.16.9.
8As is also the case for EC domain parameters, parties establish EC keys as part of key management for a
9scheme, and depending on the key management technique, it is possible that an established key does not
10satisfy the intended definition for the key, even though it has the same general form. Accordingly, the terms
11“EC public key” and “EC private key” shall be understood in this standard as referring to instances of the
12general form for the key, and the terms valid EC public key, valid EC private key and valid EC key pair
13shall be reserved to keys satisfying the definition.
14Key validation is the process of determining whether a key is valid. Further discussion of key validation is
15contained in D.3.3. A suggested algorithm for EC public key validation is contained in Annex A.16.10. In
16some cases (when ECSVDP-DHC or ECSVDP-MQVC primitive is applied), it may only be necessary to
17verify that the public key is a point on the curve (rather than a stronger condition that it is a non-zero
18multiple of G). The algorithm to verify that is also contained in Annex A.16.10. No algorithm is given for
19EC private key validation, because, generally, a party controls its own private key and need not validate it.
20However, private key validation may be performed if desired.
217.2 Primitives
22This clause describes primitives used in the EC family. Before proceeding with this clause, the reader
23should be familiar with the material of Clause 4.
24As detailed in Clause 4 and Annex B, an implementation of a primitive may make certain assumptions
25about its inputs, as listed with the specification of each primitive. For example, if EC domain parameters q,
26a, b, r and G and a public key W are inputs to a primitive, the implementation may generally assume that
27the domain parameters are valid, i.e., that G has order r on the elliptic curve defined by a and b, and W = s
28G for some integer s in the interval [1, r – 1]. The behavior of an implementation is unconstrained in the
29case that W is not a multiple of G, and in such a case the implementation may or may not output an error
30condition. It is up to the properly implemented scheme to ensure that only appropriate inputs are passed to a
31primitive, or to accept the risks of passing inappropriate inputs. For more on conforming with a primitive,
32see Annex B.
337.2.1 ECSVDP-DH
34ECSVDP-DH is Elliptic Curve Secret Value Derivation Primitive, Diffie-Hellman version. It is based on
35the work of [DH76], [Mil86], and [Kob87]. This primitive derives a shared secret value from one party’s
36private key and another party’s public key, where both have the same set of EC domain parameters. If two
37parties correctly execute this primitive, they will produce the same output. This primitive can be invoked
38by a scheme to derive a shared secret key; specifically, it may be used with the schemes ECKAS-DH1 and
39DL/ECKAS-DH2. It assumes that the input keys are valid (see also Clause 7.2.2).
40Input:
41 the EC domain parameters q, a, b, r and G associated with the keys s and W (the domain
42 parameters shall be the same for both s and W)
2 57
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
5Output: the derived shared secret value, which is a field element z GF (q); or “error”
6Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
7steps:
8 j) Compute an elliptic curve point P = s W.If P = O output “error” and stop. Let z = xP, the x-
9 coordinate of P.
10 4. Output z as the shared secret value.
11Conformance region recommendation. A conformance region should include:
161—This primitive does not address small subgroup attacks (see Annex D.5.1.6), which may occur when the public key
17W is not valid. To prevent them, a key agreement scheme should validate the public key W before executing this
18primitive (see also Clause 7.2.2).
192—When the public key W and the private key s are valid, W has order r and s is in the interval [1, r-1]. Thus the
20point P in this case is not the element O.
217.2.2 ECSVDP-DHC
22ECSVDP-DHC is Elliptic Curve Secret Value Derivation Primitive, Diffie-Hellman version with cofactor
23multiplication. It is based on the work of [DH76], [Mil86], [Kob87], [LMQ98] and [Kal98a]. This
24primitive derives a shared secret value from one party’s private key and another party’s public key, where
25both have the same set of EC domain parameters. If two parties correctly execute this primitive, they will
26produce the same output. This primitive can be invoked by a scheme to derive a shared secret key;
27specifically, it may be used with the schemes ECKAS-DH1 and DL/ECKAS-DH2. It does not assume the
28validity of the input public key (see also Clause 7.2.1).
29Input:
30 the EC domain parameters q, a, b, r, G and the cofactor associated with the keys s and W (the
31 domain parameters shall be the same for both s and W)
32 the party’s own private key s
33 the other party’s public key W
34 an indication as to whether compatibility with ECSVDP-DH is desired
35Assumptions: private key s, EC domain parameters q, a, b, r, G and k are valid; the private key is
36associated with the domain parameters; W is on the elliptic curve defined by a and b over GF (q); GCD (k,
37r) = 1
2 58
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Output: the derived shared secret value, which is a field element z GF (q); or “invalid public key”
2Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
3steps:
4 k) If compatibility with ECSVDP-DH is desired, then compute an integer t = k–1s mod r; otherwise set
5 t = s.Compute an elliptic curve point P = kt W.If P = O output “invalid public key” and stop. Let z
6 = xP, the x-coordinate of P. Output z as the shared secret value.
7Conformance region recommendation. A conformance region should include:
141—This primitive addresses small subgroup attacks, which may occur when the public key W is not valid (see Annex
15D.5.1.6). A key agreement scheme only needs to validate that W is on the elliptic curve defined by a and b over
16GF (q) before executing this primitive (see also Clause 7.2.1).
172—The cofactor k depends only on the EC domain parameters. Hence, it can be computed once for a given set of
18domain parameters and stored as part of the domain parameters. Similarly, in the compatibility case, the value k–1 can
19be computed once and stored with the domain parameters, and the integer t can be computed once for a given private
20key s. Algorithms for computing or verifying the cofactor are included in Annex A.12.3.
213—When the public key W and the private key s are valid, the point P will be an element of a subset of the elliptic
22curve that consists of all the multiples of G (except for the element O). As a consequence, z will always be defined in
23this case. When the public key is invalid, the output will be either “invalid public key” or an element of order r on the
24elliptic curve; in particular, it will not be in a small subgroup.
254—In the compatibility case, ECSVDP-DHC computes the same output for valid keys as ECSVDP-DH, so an
26implementation that conforms with ECSVDP-DHC in the compatibility case also conforms with ECSVDP-DH.
277.2.3 ECSVDP-MQV
34In this primitive, let h = (log2 r) / 2. Note that h depends only on the EC domain parameters, and hence
35can be computed once for a given set of domain parameters.
36Input:
37 the EC domain parameters q, a, b, r and G associated keys s, (u, V), W, V (the domain parameters
38 shall be the same for these keys)
39 the party’s own first private key s
2 59
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 the party’s own second key pair (u, V), where V = (x, y)
2 the other party’s first public key W
3 the other party’s second public key V = (x, y)
4Assumptions: private key s, key pair (u, V), public keys W, V, and EC domain parameters q, a, b, r and G
5are valid; all the keys are associated with the domain parameters
6Output: the derived shared secret value, which is a nonzero field element z GF (q); or “error”
7Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
8steps:
9 l) Convert x into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.Convert x
10 into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.Compute an
11 integer e = ts + u mod r.Compute an elliptic curve point P = e (V + tW). If P = O output “error”
12 and stop.Let z = xP, the x-coordinate of P. Output z as the shared secret value.
13Conformance region recommendation. A conformance region should include:
191—This primitive does not address small subgroup attacks (see Annex D.5.1.6), which may occur when the public keys
20W and V are not valid. To prevent them, a key agreement scheme should validate the public keys W and V before
21executing this primitive (see also Clause 7.2.4).
222—When the public keys W and V are valid, the point P will be an element of a subset of the elliptic curve that
23consists of all the multiples of G. It is possible (although very unlikely) that even though all the keys and parameters
24are valid, P will be the point O. In this case, the primitive will output “error,” and will need to be re-run with a
25different input. Except for this rare case, z will always be defined as long as the input keys and parameters are valid.
267.2.4 ECSVDP-MQVC
27ECSVDP-MQVC is Elliptic Curve Secret Value Derivation Primitive, Menezes-Qu-Vanstone version with
28cofactor multiplication. It is based on the work of [LMQ98] and [Kal98a]. This primitive derives a shared
29secret value from one party’s two key pairs and another party’s two public keys, where all the keys and
30values have the same set of EC domain parameters. If two parties correctly execute this primitive, they will
31produce the same output. This primitive can be invoked by a scheme to derive a shared secret key;
32specifically, it may be used with the scheme ECKAS-MQV. It does not assume the validity of the input
33public keys (see also Clause 7.2.3).
34In this primitive, let h = (log2 r) / 2. Note that h depends only on the EC domain parameters, and hence
35can be computed once for a given set of domain parameters.
36Input:
37 the EC domain parameters q, a, b, r, G, and the cofactor k associated with keys s, (u, V), W, V
38 (the domain parameters shall be the same for these keys)
2 60
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
9Output: the derived shared secret value, which is a nonzero field element z GF (q); or “invalid public
10key”
11Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
12steps:
13 m) Convert x into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.Convert x
14 into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.If compatibility
15 with ECSVDP-MQV is desired, the compute an integer e = k–1(ts + u) mod r; otherwise compute an
16 integer e = ts + u mod r.Compute an elliptic curve point P = ke (V + tW). If P = O output “invalid
17 public key” and stop.Let z = xP, the x-coordinate of P. Output z as the shared secret value.
18Conformance region recommendation. A conformance region should include:
261—This primitive addresses small subgroup attacks, which may occur when the public keys W and V are not valid
27(see Annex D.5.1.6). A key agreement scheme only needs to validate that W and V are in GF (q) before executing this
28primitive (see also Clause 7.2.3).
292—The cofactor k depends only on the EC domain parameters. Hence, it can be computed once for a given set of
30domain parameters and stored as part of the domain parameters. Similarly, in the compatibility case, the value k–1 can
31be computed once and stored with the domain parameters. An equivalent way to compute the integer e in this case is as
32(tk–1s + k–1u) mod r, where k–1s mod r and k–1u mod r can be computed once for each given private key s and u.
33Algorithms for computing or verifying the cofactor are included in Annex A.12.3.
343—When the public key W is valid, the point P will be an element of a subset of the elliptic curve that consists of all
35the multiples of G. It is possible (although very unlikely) that even though all the keys and parameters are valid, P will
36be the point O, and the primitive will output “invalid public key.” In this case, the primitive will need to be re-run with
37a different input. Except for this rare case, z will always be defined as long as the input keys and parameters are valid.
38When one of the public keys is invalid, the output will be either “invalid public key” or the x coordinate of a point of
39order r on the elliptic curve; in particular, it will not be the x coordinate of a point in a small subgroup.
404—In the compatibility case, ECSVDP-MQVC computes the same output for valid keys as ECSVDP-MQV, so an
41implementation that conforms with ECSVDP-MQVC in the compatibility case also conforms with ECSVDP-MQV.
2 61
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
17.2.5 ECSVDP-HMQV
2TODO: This has not yet been updated with the appropriate HMQV text.
11In this primitive, let h = (log2 r) / 2. Note that h depends only on the EC domain parameters, and hence
12can be computed once for a given set of domain parameters.
13Input:
14 the EC domain parameters q, a, b, r and G associated keys s, (u, V), W, V (the domain parameters
15 shall be the same for these keys)
16 the party’s own first private key s
17 the party’s own second key pair (u, V), where V = (x, y)
18 the other party’s first public key W
19 the other party’s second public key V = (x, y)
20Assumptions: private key s, key pair (u, V), public keys W, V, and EC domain parameters q, a, b, r and G
21are valid; all the keys are associated with the domain parameters
22Output: the derived shared secret value, which is a nonzero field element z GF (q); or “error”
23Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
24steps:
25 n) Convert x into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.Convert x
26 into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.Compute an
27 integer e = ts + u mod r.Compute an elliptic curve point P = e (V + tW). If P = O output “error”
28 and stop.Let z = xP, the x-coordinate of P. Output z as the shared secret value.
29Conformance region recommendation. A conformance region should include:
351—This primitive does not address small subgroup attacks (see Annex D.5.1.6), which may occur when the public keys
36W and V are not valid. To prevent them, a key agreement scheme should validate the public keys W and V before
37executing this primitive (see also Clause 7.2.4).
2 62
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
12—When the public keys W and V are valid, the point P will be an element of a subset of the elliptic curve that
2consists of all the multiples of G. It is possible (although very unlikely) that even though all the keys and parameters
3are valid, P will be the point O. In this case, the primitive will output “error,” and will need to be re-run with a
4different input. Except for this rare case, z will always be defined as long as the input keys and parameters are valid.
57.2.6 ECSVDP-HMQVC
6TODO: This has not yet been updated with the appropriate HMQV text.
7ECSVDP-MQVC is Elliptic Curve Secret Value Derivation Primitive, Menezes-Qu-Vanstone version with
8cofactor multiplication. It is based on the work of [LMQ98] and [Kal98a]. This primitive derives a shared
9secret value from one party’s two key pairs and another party’s two public keys, where all the keys and
10values have the same set of EC domain parameters. If two parties correctly execute this primitive, they will
11produce the same output. This primitive can be invoked by a scheme to derive a shared secret key;
12specifically, it may be used with the scheme ECKAS-MQV. It does not assume the validity of the input
13public keys (see also Clause 7.2.3).
14In this primitive, let h = (log2 r) / 2. Note that h depends only on the EC domain parameters, and hence
15can be computed once for a given set of domain parameters.
16Input:
17 the EC domain parameters q, a, b, r, G, and the cofactor k associated with keys s, (u, V), W, V
18 (the domain parameters shall be the same for these keys)
19 the party’s own first private key s
20 the party’s own second key pair (u, V), where V = (x, y)
21 the other party’s first public key W
22 the other party’s second public key V = (x, y)
23 an indication as to whether compatibility with ECSVDP-MQV is desired
24Assumptions: private key s, key pair (u, V), and EC domain parameters q, a, b, r, G and k are valid; private
25key s and key pair (u, V) are associated with the domain parameters; W and V are on the elliptic curve
26defined by a and b over GF (q); GCD (k, r) = 1
27Output: the derived shared secret value, which is a nonzero field element z GF (q); or “invalid public
28key”
29Operation. The shared secret value z shall be computed by the following or an equivalent sequence of
30steps:
31 o) Convert x into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.Convert x
32 into an integer i using FE2IP. Compute an integer t = i mod 2h. Let t = t + 2h.If compatibility
33 with ECSVDP-MQV is desired, the compute an integer e = k–1(ts + u) mod r; otherwise compute an
34 integer e = ts + u mod r.Compute an elliptic curve point P = ke (V + tW). If P = O output “invalid
35 public key” and stop.Let z = xP, the x-coordinate of P. Output z as the shared secret value.
36Conformance region recommendation. A conformance region should include:
2 63
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 all points W and V on the curve over GF (q) defined by a and b, where q, a and b are from the
2 domain parameters of s
3 compatibility with ECSVDP-MQV may be preset by the implementation, or given as an input flag
4NOTES
51—This primitive addresses small subgroup attacks, which may occur when the public keys W and V are not valid
6(see Annex D.5.1.6). A key agreement scheme only needs to validate that W and V are in GF (q) before executing this
7primitive (see also Clause 7.2.3).
82—The cofactor k depends only on the EC domain parameters. Hence, it can be computed once for a given set of
9domain parameters and stored as part of the domain parameters. Similarly, in the compatibility case, the value k–1 can
10be computed once and stored with the domain parameters. An equivalent way to compute the integer e in this case is as
11(tk–1s + k–1u) mod r, where k–1s mod r and k–1u mod r can be computed once for each given private key s and u.
12Algorithms for computing or verifying the cofactor are included in Annex A.12.3.
133—When the public key W is valid, the point P will be an element of a subset of the elliptic curve that consists of all
14the multiples of G. It is possible (although very unlikely) that even though all the keys and parameters are valid, P will
15be the point O, and the primitive will output “invalid public key.” In this case, the primitive will need to be re-run with
16a different input. Except for this rare case, z will always be defined as long as the input keys and parameters are valid.
17When one of the public keys is invalid, the output will be either “invalid public key” or the x coordinate of a point of
18order r on the elliptic curve; in particular, it will not be the x coordinate of a point in a small subgroup.
194—In the compatibility case, ECSVDP-MQVC computes the same output for valid keys as ECSVDP-MQV, so an
20implementation that conforms with ECSVDP-MQVC in the compatibility case also conforms with ECSVDP-MQV.
217.2.7 ECSP-NR
22ECSP-NR is the Elliptic Curve Signature Primitive, Nyberg-Rueppel version. It is based on the work of
23Koblitz [B94], Miller [B117], and Nyberg and Rueppel [B120]. It can be invoked in a scheme to compute a
24signature on a message representative with the private key of the signer, in such a way that the message
25representative can be recovered from the signature using the public key of the signer by the ECVP-NR
26primitive. Note, however, that the ECPSP-NR2/PV and ECSP-NR2 primitives are intended for signature
27schemes giving message recovery in this version of the standard. ECSP-NR can be invoked in the scheme
28ECSSA as part of signature generation.
29Input:
35Output: the signature, which is a pair of integers (c, d), where 1 c < r and 0 d < r
36Operation. The signature (c, d) shall be computed by the following or an equivalent sequence of steps:
37 p)Generate a key pair (u, V) with the same set of domain parameters as the private key s. (See the
38 note below.) Let V = (xV, yV) (V O because V is a public key).Convert xV into an integer i with
39 primitive FE2IP (recall that xV is an element of GF (q)).Compute an integer c = i + f mod r. If c =
40 0, then go to Step 1.Compute an integer d = u – sc mod r.Output the pair (c, d) as the signature.
41Conformance region recommendation. A conformance region should include:
2 64
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
51—The key pair in step 1 should be a one-time key pair which is generated and stored by the signer following the
6security recommendations of D.3.1, D.4.2.2, D.6 and D.7. The private key should be selected in an unbiased manner
7(see D.5.2.1 for further discussion), and a new key pair should be generated for every signature. The one-time private
8key u should be securely deleted after step 4, as its recovery by an opponent can lead to the recovery of the private key
9s.
102—The one-time key pair in step 1 may be precomputed in advance of the availability of the message representative.
11See D.5.2.1 for further discussion.
127.2.8 ECVP-NR
13ECVP-NR is the Elliptic Curve Verification Primitive, Nyberg-Rueppel version. It is based on the work of
14Koblitz [B94], Miller [B117], and Nyberg and Rueppel [B120]. This primitive recovers the message
15representative that was signed with ECSP-NR, given only the signature and public key of the signer. It can
16be invoked in a scheme as part of signature verification and, possibly, message recovery. Note, however,
17that the ECVP-NR2 primitive is intended for signature schemes giving message recovery in this version of
18the standard. ECVP-NR can be invoked in the scheme ECSSA as part of signature verification.
19Input:
25Output: the message representative, which is an integer f such that 0 f < r; or “invalid”
26Operation. The message representative f shall be computed by the following or an equivalent sequence of
27steps:
28 q) If c is not in [1, r – 1] or d is not in [0, r – 1], output “invalid” and stop.Compute an elliptic curve
29 point P = d G + c W. If P = O, output “invalid” and stop. Otherwise, P = (xP, yP).Convert the field
30 element xP to an integer i with primitive FE2IP.Compute an integer f = c – i mod r.Output f as the
31 message representative.
32Conformance region recommendation. A conformance region should include:
2 65
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
17.2.9 ECSP-DSA
2ECSP-DSA is Elliptic Curve Signature Primitive, DSA version. It is based on the work of [Mil86],
3[Kob87] and [Kra93]. It can be invoked in a scheme to compute a signature on a message representative
4with the private key of the signer. The message representative cannot be recovered from the signature, but
5ECVP-DSA can be used in the scheme ECSSA to verify the signature.
6Input:
12Output: the signature, which is a pair of integers (c, d), where 1 c < r and 1 d < r
13Operation. The signature (c, d) shall be computed by the following or an equivalent sequence of steps:
14 r)Generate a key pair (u, V) with the same set of domain parameters as the private key s. (See the
15 note below.) Let V = (xV, yV) (V O because V is a public key).Convert xV into an integer i with
16 primitive FE2IP (recall that xV is an element of GF (q)).Compute an integer c = i mod r. If c = 0,
17 then go to Step 1.Compute an integer d = u–1(f + sc) mod r. If d = 0, then go to Step 1.Output the
18 pair (c, d) as the signature.
19Conformance region recommendation. A conformance region should include:
251—The key pair in step 1 should be a one-time key pair which is generated and stored by the signer following the
26security recommendations of D.3.1, D.4.2.2, D.6 and D.7. The private key should be selected in an unbiased manner
27(see D.5.2.1 for further discussion), and a new key pair should be generated for every signature. The one-time private
28key u should be securely deleted after step 4, as its recovery by an opponent can lead to the recovery of the private key
29s.
302—Similar to ECSP-NR, the one-time key pair in step 1 may be precomputed in advance of the availability of the
31message representative. Steps 2 and 3 as well as the values u–1 and sc in step 4 may also be precomputed. See D.5.2.1
32for further discussion.
337.2.10 ECVP-DSA
34ECVP-DSA is Elliptic Curve Verification Primitive, DSA version. It is based on the work of [Mil86],
35[Kob87] and [Kra93]. This primitive verifies whether the message representative and the signature are
36consistent given the key and the domain parameters. It can be invoked in the scheme ECSSA as part of
37signature verification.
38Input:
2 66
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
8Operation. The output shall be computed by the following or an equivalent sequence of steps:
9 s) If c is not in [1, r – 1] or d is not in [1, r – 1], output “invalid” and stop.Compute integers h = d –1
10 mod r; h1 = f h mod r; h2 = c h mod r.Compute an elliptic curve point P = h1G + h2W. If P = O,
11 output “invalid” and stop. Otherwise, P = (xP, yP).Convert the field element xP to an integer i with
12 primitive FE2IP.Compute an integer c = i mod r.
13 6. If c = c, then output “valid”; else, output “invalid.”
14Conformance region recommendation. A conformance region should include:
217.2.11 ECPSP-NR2/PV
29Output:
34
35 1. Generate a key pair (u, V) with the set of domain parameters. (See the notes below.) Let V =
36 (xV, yV) (V O because V is a public key).
37 2. Convert xV into an integer i with primitive FE2IP (recall that xV is an element of GF(q)).
2 67
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
51—The key pair in step 1 should be a one-time key pair which is generated by the signer following the security
6recommendations of D.3.1, D.4.1.2, D.6 and D.7. The randomizer should be selected in an unbiased manner (see
7D.5.2.1 for further discussion), and a new randomizer / pre-signature pair should be generated for every signature. (If
8signatures are computed with the same randomizer for two or more different message representatives, or if the
9randomizer becomes known, an opponent may be able to recover the signer’s private key.) The randomizer should be
10stored following the same security recommendations as for an ephemeral private key (it should be securely deleted
11after it is used in ECSP-NR2 or ECSP-PV).
122—Similar to ECSP-NR, the key pair may be precomputed in advance of the availability of the message representative.
137.2.12 ECSP-NR2
14ECSP-NR2 is the Elliptic Curve Signature Primitive, Nyberg-Rueppel version 2. It is based on the work of
15ISO/IEC 9796-3:2000 [B79], Koblitz [B94], Miller [B117], and Nyberg and Rueppel [B120]. The primitive
16generates a signature on a message representative with the private key of the signer, given a randomizer
17and a pre-signature generated by ECPSP-NR2/PV, in such a way that the message representative and the
18pre-signature can be recovered from the signature using the public key of the signer by the ECVP-NR or
19ECVP-NR2 primitive. It can be invoked in the scheme ECSSR as part of signature generation. ECSP-NR2
20corresponds to the last three steps of ECSP-NR.
21Except for having EC domain parameters as input rather than DL domain parameters, the primitive is
22identical to DLSP-NR.
23Input:
31Output: The signature, which is a pair of integers (c, d) such that 1 c < r and 0 d < r; or “error”
32Operation: The signature (c, d) shall be computed by the following or an equivalent sequence of steps:
33
34 1. Compute an integer c = i + f mod r. If c = 0, then output “error.” (This is an extremely rare
35 event for recommended values of r — see Note 2.)
36 2. Compute an integer d = u – sc mod r.
37 3. Output the pair (c, d) as the signature.
38Conformance region recommendation: A conformance region should include:
1 At least one valid private key s for each set of domain parameters
2 All randomizers u in the range [1, r – 1]
3 All pre-signatures i in the range [1, q – 1]
4 All message representatives f in the range [0, r – 1]
5NOTES
61—Following the discussion above for ECPSP-NR2/PV, for security reasons, the randomizer u should be securely
7deleted after step 2.
82—The probability that the primitive will output “error” is about 1/r (i.e., essentially 0 for recommended values of r),
9assuming the pre-signature i is generated at random by ECPSP-NR2/PV. Thus, the check at the end of step 1 is
10included for completeness only; it is unlikely to occur in practice. The motivation for the check is to ensure that the
11signature depends on the signer’s private key s; otherwise the signature could be verified with anyone’s public key with
12the same domain parameters. (An “error” output in any case does not disclose any information about the private key s,
13since the private key is not involved in the pre-signature primitive or prior to step 2.)
147.2.13 ECVP-NR2
15ECVP-NR is the Elliptic Curve Verification Primitive, Nyberg-Rueppel version 2. It is based on the work
16of ISO/IEC 9796-3:2000 [B79], Koblitz [B94], Miller [B117], and Nyberg and Rueppel [B120]. This
17primitive recovers the message representative that was signed with ECSP-NR2, given only the signature
18and public key of the signer, and also recovers the pre-signature. It can be invoked in the scheme ECSSR as
19part of signature verification and message recovery. ECVP-NR2 is the same as ECVP-NR, except that the
20recovered pre-signature is output in addition to the message representative.
21Input:
27Output:
32
33 1. If c is not in [1, r – 1] or d is not in [0, r – 1], output “invalid” and stop.
34 2. Compute an elliptic curve point P = d G + c W. If P = O, output “invalid” and stop.
35 Otherwise, P = (xP, yP).
36 3. Convert the field element xP to an integer i with primitive FE2IP.
37 4. Compute an integer f = c – i mod r.
38 5. Output f as the message representative and i as the pre-signature.
39Conformance region recommendation: A conformance region should include:
2 69
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
57.2.14 ECSP-PV
6ECSP-PV is the Elliptic Curve Signature Primitive, Pintsov-Vanstone version. It is based on the work of
7Koblitz [B94], Miller [B117], and Pintsov and Vanstone [PV99]. The primitive generates a signature part
8on a randomized hash value with the private key of the signer, given a randomizer generated by ECPSP-
9NR2/PV, in such a way that the pre-signature generated by ECPSP-NR2/PV can be recovered from the
10signature using the public key of the signer by the ECVP-PV primitive. It can be invoked in the scheme
11ECSSR-PV as part of signature generation.
12Except for having EC domain parameters as input rather than DL domain parameters, the primitive is
13identical to DLSP-PV.
14Input:
23
24 1. Compute an integer d = u – sh mod r.
25 2. Output the pair d as the signature part.
26Conformance region recommendation: A conformance region should include:
2 70
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1NOTES
21—For security reasons, the randomizer u should be securely deleted after step 2.
32—This primitive does not check whether h = 0 to ensure that the signature depends on the signer’s public key, since it
4is such an unlikely occurrence in the scheme in which ECSP-PV is employed, but an implementation could do if
5desired.
67.2.15 ECVP-PV
7ECVP-PV is the Elliptic Curve Verification Primitive, Pintsov-Vanstone version. It is based on the work of
8Koblitz [B94], Miller [B117], and Pintsov and Vanstone [PV99]. This primitive recovers a pre-signature
9from a signature part generated with ECSP-PV, given only the randomized hash value and the public key of
10the signer. It can be invoked in the scheme ECSSR-PV as part of signature verification and message
11recovery.
12Input:
21
22 1. If d is not in [0, r – 1], output “invalid” and stop.
23 2. Compute an elliptic curve point P = d G + h W. If P = O, output “invalid” and stop.
24 Otherwise, P = (xP, yP).
25 3. Convert the field element xP to an integer i with primitive FE2IP.
26 4. Output i as the pre-signature.
27Conformance region recommendation: A conformance region should include:
2 71
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1There are four types of primitives in this family. While they are all related to the integer factorization
2problem, they are based on different keys and operations. One type is known as RSA, for “Rivest-Shamir-
3Adleman” (see Rivest, Shamir, Adleman [B129]); a second is known as RW, for “Rabin-Williams” (see
4Rabin [B128] and Williams [B149]). The third is known as OU, for “Okamoto-Uchiyama” (see Okamoto
5and Uchiyama [OU98]) and the fourth is known as ESIGN (see Fujisaki and Okamoto [FO98] and
6Okamoto [Oka90]).
88.1.1 Notation
9The list below introduces the notation used in Clauses 8, 10 and 11. It is meant as a reference guide only;
10for complete definitions of the terms listed, refer to the appropriate text. Some other symbols are also used
11occasionally; they are introduced in the text where appropriate.
12
13 n The modulus, part of the keys
14 p, q The prime factors of the modulus n
15 e The public exponent, part of a public key (e is odd for RSA; e is even for RW; e 8 for ESIGN)
16 d The private exponent, part of some of the representations of a private key
17 d1 d mod (p – 1), part of one of the representations of a private key
18 d2 d mod (q – 1), part of one of the representations of a private key
19 c q –1 mod p, part of one of the representations of a private key
20 (n, e) An RSA or RW public key
21 K An RSA or RW private key
22 s Signature, an integer, computed by a signature primitive
23 g Encrypted message, an integer, computed by an encryption primitive
24 f Message representative, an integer, computed by a message encoding operation
25 M The message, an octet string, which is encrypted in an encryption scheme or whose signature is
26 computed by a signature scheme
27 k The length in bits of the primes for OU and ESIGN
28 u Part of the OU public key
29 up The value exp(u, p–1) mod p2, used in OU
30 r Randomized hash value, an integer
31 v Part of the OU public key
32 L(x) The function (x – 1) / p, used in OU
33 (n, u, v, k) An OU public key
34 (p, q, k, w) An OU private key
35 (n, e, k) An ESIGN public key
36 (p, q, k, e) An ESIGN private key
37 C Encrypted message, an octet string, computed by an encryption scheme
38 M1 Recoverable message part, an octet string, the part of a message that can be recovered from the
39 signature in a signature scheme giving message recovery
40 M2 Non-recoverable message part (if any), an octet string, the part of a message that cannot be
41 recovered from the signature in a signature scheme giving message recovery
42
43NOTE—Multiplication of integers is denoted by , although this symbol may be omitted when such omission does not
44cause ambiguity. When typographically convenient, notation such as exp(f, e), where f and e are integers, will be used
45to denote raising f to the power e. The more traditional notation f e may also be used
2 72
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2Unlike the DL or EC families, the IF family has no domain parameters. The keys contain all the necessary
3information within themselves. While DL or EC primitives and schemes sometimes require domain
4parameters to be common to a group of keys, no similar requirement exists for any IF primitive or scheme.
5Of course, as with other families, parties need to be aware of each other’s capabilities in order to work
6together—for example, some parties may have restrictions on the size of the modulus they can use or
7generate, while others may only work with a particular fixed public exponent (see below).
9Since there are two types of IF primitives, there are also two types of IF keys. They are similar, but the
10distinctions between them are significant.
12An RSA public key consists of a modulus n, which is the product of two odd positive prime integers p and
13q, and an odd public exponent e (3 e < n) which is an integer relatively prime to (p – 1) and (q – 1). The
14corresponding RSA private exponent is an integer d (1 d < n) such that
17An RSA private key K may have multiple representations. The use of one of the following three
18representations is recommended in this standard:
19 t) 1. a pair (n, d)a quintuple (p, q, d1, d2, c), where d1 = d mod (p – 1), d2 = d mod (q – 1), and
20 c = q –1 mod p
21 3. a triple (p, q, d)
23An RW public key consists of a modulus n, which is the product of two odd positive prime integers p and q
24such that p ( q (mod 8), and an even public exponent e (2 e < n) which is an integer relatively prime to
25(p – 1)(q – 1)/4. (Note that these conditions imply that p q 3 (mod 4); moreover, one of the primes is
26congruent to 3 (mod 8) and the other is congruent to 7 (mod 8).) The corresponding RW private exponent
27is an integer d (1 d < n) such that
30An RW private key K may have multiple representations. The use of one of the following three
31representations is recommended in this standard:
32 u) 1. a pair (n, d)a quintuple (p, q, d1, d2, c), where d1 = d mod (p – 1), d2 = d mod (q – 1), and
33 c = q –1 mod p
34 3. a triple (p, q, d)
2 73
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2An OU public key consists of a modulus n, which is of the form p2q for two odd positive prime integers p
3and q where the length of each of p and q is k bits for some integer k, a pair of integers (u, v) (1 < u < n, 1 <
4v < n) such that the order of up = exp(u, p 1) mod p2 is p and where v = v0n mod n for some integer v0 (1 <
5v0 < n). Define the function L(x) as
6L(x) = (x – 1) / p
7and let w = L(up). The corresponding OU private key consists of the primes p and q, the length parameter k,
8and the value w.
9NOTE—The value v0 need not be kept secret. A typical selection of the value v0 is u. See D.5.3.2.1 for further
10discussion.
12An ESIGN public key consists of a modulus n, which is of the form p2q for two odd positive prime integers
13p and q where the length of each of p and q is k bits for some integer k and the length of n is 3k bits, a
14public exponent e (8 e < n) such that GCD (e, n) = 1, and the length parameter k. The corresponding
15ESIGN private key consists of the pair of primes (p, q), the length parameter k and the exponent e.
17An IF key pair may or may not be generated by the party using it, depending on the trust model. This and
18other security issues related to IF key pair generation are discussed in D.3.1 and D.4.3. A suggested method
19for generating RSA key pairs is contained in A.16.11. A suggested method for generating RW key pairs is
20contained in A.16.12.
21Parties establish IF keys as part of key management for a scheme. Depending on the key management
22technique, it is possible that an established key does not satisfy the intended definition for the key, even
23though it has the same general form (e.g., components n and e). To accommodate this possibility, the terms
24RSA public key, RW public key, OU public key, ESIGN public key, and similarly for private keys shall be
25understood in this standard as referring to instances of the general form for the key. The terms valid RSA
26public key, valid RW public key, valid OU public key, valid ESIGN public key, valid RSA key pair, valid
27RW key pair, and so on shall be reserved for keys satisfying the definitions.
28Key validation is the process of determining whether a key is valid. Further discussion of key validation is
29contained in D.3.3, although no algorithm for IF public key validation is suggested in Annex A. No
30algorithm is given for IF private key validation, because, generally, a party controls its own private key and
31need not validate it. However, private key validation may be performed if desired.
32For security, the primes p and q need to be generated so that they are unpredictable and inaccessible to an
33adversary. Whatever form a private key is represented in, it needs to be stored so that it is inaccessible to an
34adversary. The compromise of the primes or other private key components (that are not already part of the
35public key) may aid the adversary in recovering the private key. These values should be securely deleted if
36not used.
37Three representations are provided for RSA and RW private keys because of performance tradeoffs
38between the representations. Use of the quintuple representation tends to result in faster performance for
39larger sizes of n.
2 74
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
18.2 Primitives
2This clause describes primitives used in the IF family. Before proceeding with this clause, the reader
3should be familiar with the material of Clause 4.
4As detailed in Clause 4 and Annex B, an implementation of a primitive may make certain assumptions
5about its inputs, as listed with the specification of the primitive. For example, if an RSA public key (n, e) is
6an input to a primitive, an implementation may assume that the public key is valid, i.e., that n is a product
7of two odd primes, 3 e < n, and e is relatively prime to (p – 1)(q – 1). The behavior of an implementation
8is not specified in the case that the input does not satisfy these conditions, and in such a case the
9implementation may or may not output an error condition. It is up to the properly implemented scheme to
10ensure that only appropriate inputs are passed to a primitive, or to accept the risks of passing inappropriate
11inputs. For more on conforming with a primitive, see Annex B.
12The primitives described in this subclause can be combined into six pairs: message representatives
13encrypted with IFEP-RSA can be decrypted with IFDP-RSA; message representatives signed with IFSP-
14RSA1, IFSP-RSA2 or IFSP-RW can be recovered with IFVP-RSA1, IFVP-RSA2 or IFVP-RW,
15respectively; message representatives encrypted with IFEP-OU can be decrypted with IFDP-OU; and
16message representatives signed with IFSP-ESIGN can be verified with IFVP-ESIGN. While IFEP-RSA is
17mathematically identical to IFVP-RSA1, and IFDP-RSA is mathematically identical to IFSP-RSA1, these
18primitives are used for entirely different purposes and should not be confused. The -RSA1, -RSA2 and
19-RW signature primitives are similar, but have some important differences (see C.3.6). To aid in defining
20these three primitives, the operation “IF Private Key Operation” is defined first.
22IF Private Key Operation is not a primitive in itself, but rather is used in some of the primitives below. The
23operation produces the same result independent of the representation of the private key.
24Input:
32Output: an integer j such that 0 j < n, the result of the private key operation on i
33Operation. The integer j shall be computed by the following or an equivalent sequence of steps:
34
35 I. If the first representation (n, d) of K is used:
36 1. Let j = exp(i, d) mod n.
37 2. Output j.
38 II. If the second representation (p, q, d1, d2, c) of K is used:
39 1. Let j1 = exp(i, d1) mod p.
40 2. Let j2 = exp(i, d2) mod q.
41 3. Let h = c (j1 – j2) mod p.
2 75
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 4. Let j = j2 + h q.
2 5. Output j.
3 III. If the third representation (p, q, d) of K is used:
4 1. Let j1 = exp(i, d mod (p – 1)) mod p.
5 2. Let j2 = exp(i, d mod (q – 1)) mod q.
6 3. Let h = q –1 (j1 – j2) mod p.
7 4. Let j = j2 + h q.
8 5. Output j.
98.2.2 IFEP-RSA
10IFEP-RSA is RSA Encryption Primitive. It is based on the work of [RSA78]. It is invoked in the scheme
11IFES as part of encrypting a message, given the message and the public key of the intended recipient. The
12message can be decrypted within a scheme by invoking IFDP-RSA.
13Input:
17Output: the encrypted message representative, which is an integer g such that 0 g < n
18Operation. The encrypted message representative g shall be computed by the following or an equivalent
19sequence of steps:
258.2.3 IFDP-RSA
26IFDP-RSA is RSA Decryption Primitive. It is based on the work of [RSA78]. It is used in the scheme
27IFES as part of decrypting a message encrypted with the use of IFEP-RSA, given the encrypted message
28representative and the private key of the recipient.
29Input:
2 76
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 w) Perform the IF Private Key Operation described in 8.2.1 on K and g to produce an integer f.
2 2. Output f.
3Conformance region recommendation. A conformance region should include:
68.2.4 IFSP-RSA1
7IFSP-RSA1 is the RSA Signature Primitive, version 1. It is based on the work of Rivest, Shamir, and
8Adleman [B129]. It can be invoked in a scheme to compute a signature on a message representative with
9the private key of the signer, in such a way that the message representative can be recovered from the
10signature using the public key of the signer by the IFVP-RSA1 primitive. IFSP-RSA1 can be invoked in the
11schemes IFSSA and IFSSR as part of signature generation.
12Input:
18 x) Perform the IF Private Key Operation described in 8.2.1 on K and f to produce an integer s.
19 2. Output s.
20Conformance region recommendation. A conformance region should include:
238.2.5 IFVP-RSA1
24IFVP-RSA1 is the RSA Verification Primitive, version 1. It is based on the work of Rivest, Shamir, and
25Adleman [B129]. This primitive recovers the message representative that was signed with IFSP-RSA1,
26given only the signature and public key of the signer. It can be invoked in a scheme as part of signature
27verification and, possibly, message recovery. IFVP-RSA1 can be invoked in the schemes IFSSA and
28IFSSR as part of signature verification.
29Input:
33Output: the message representative, which is an integer f such that 0 f < n; or “invalid”
2 77
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Operation. The message representative f shall be computed by the following or an equivalent sequence of
2steps:
3 y)
4 z) 1 If s is not in [0, n – 1], output “invalid” and stop.Let f = exp(s, e) mod n.Output f.
5Conformance region recommendation. A conformance region should include:
98.2.6 IFSP-RSA2
10IFSP-RSA2 is the RSA Signature Primitive, version 2. It is based on the work of ISO/IEC 9796:1991 [B78]
11and Rivest, Shamir, and Adleman [B129]. Its output is at least one bit shorter than the RSA modulus n. It
12can be invoked in a scheme to compute a signature on a message representative of a certain form with the
13private key of the signer, in such a way that the message representative can be recovered from the signature
14using the public key of the signer by the IFVP-RSA2 primitive. IFSP-RSA2 can be invoked in the schemes
15IFSSA and IFSSR as part of signature generation.
16Input:
22 aa) Perform the IF Private Key Operation described in 8.2.1 on K and f to produce an integer t.Let s =
23 min (t, n – t).Output s.
24Conformance region recommendation. A conformance region should include:
288.2.7 IFVP-RSA2
29IFVP-RSA2 is the RSA Verification Primitive, version 2. It is based on the work of ISO/IEC 9796:1991
30[B78] and Rivest, Shamir, and Adleman [B129]. This primitive recovers the message representative that
31was signed with IFSP-RSA2, given only the signature, the public key of the signer, and the last four bits of
32the message representative. It can be invoked in a scheme as part of signature verification and, possibly,
33message recovery. IFVP-RSA2 can be invoked in the schemes IFSSA and IFSSR as part of signature
34verification.
35Input:
3Output: the message representative, which is an integer f such that 0 f < n and f 12 (mod 16); or
4“invalid”
5Operation. The message representative f shall be computed by the following or an equivalent sequence of
6steps:
7 a)
8 b) 1 If s is not in [0, (n – 1) / 2], output “invalid” and stop.Compute t = exp(s, e) mod n.If t
9 12 (mod 16), then let f = t.Else let f = n – t. If f ( 12 (mod 16), output “invalid” and stop.Output f.
10Conformance region recommendation. A conformance region should include:
148.2.8 IFSP-RW
15IFSP-RW is the RW Signature Primitive. It is based on the work of ISO/IEC 9796:1991 [B78], Rabin
16[B128], and Williams [B149]. Its output is at least one bit shorter than the RW modulus n. It can be
17invoked in a scheme to compute a signature on a message representative with the private key of the signer,
18in such a way that the message representative can be recovered from the signature using the public key of
19the signer by the IFVP-RW primitive. IFSP-RW can be invoked in the schemes IFSSA and IFSSR as part
20of signature generation.
21Input:
f
27 c) If the Jacobi symbol = +1, let u = f.Else let u = f / 2 (recall that f is even).Perform the IF
n
28 Private Key Operation described in 8.2.1 on K and u to produce an integer t.Let s = min (t, n –
29 t).Output s.
30Conformance region recommendation. A conformance region should include:
2 79
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
18.2.9 IFVP-RW
2IFVP-RW is the RW Verification Primitive. It is based on the work of ISO/IEC 9796:1991 [B78], Rabin
3[B128], and Williams [B149]. This primitive recovers the message representative that was signed with
4IFSP-RW, given only the signature, public key of the signer, and the last four bits of the message
5representative. It can be invoked in a scheme as part of signature verification and, possibly, message
6recovery. IFVP-RW can be invoked in the schemes IFSSA and IFSSR as part of signature verification.
7Input:
11Output: the message representative, which is an integer f such that 0 f < n and f 12 (mod 16); or
12“invalid”
13Operation. The message representative f shall be computed by the following or an equivalent sequence of
14steps.
15 a)
16 b) 1 If s is not in [0, (n – 1) / 2], output “invalid” and stop.Compute t1 = exp(s, e) mod
17 n.Compute t2 = n – t1.If t1 12 (mod 16), then let f = t1.Else if t1 6 (mod 8), then let f = 2t1.Else if
18 t2 12 (mod 16), then let f = t2.Else if t2 6 (mod 8), then let f = 2t2.Else output “invalid” and
19 stop.Output f.
20Conformance region recommendation. A conformance region should include:
248.2.10 IFEP-OU
25IFEP-OU is the OU Encryption Primitive. It is based on the work of Okamoto and Uchiyama [OU98]. It is
26invoked in the scheme IFES-EPOC as part of encrypting a message, given the message and the public key
27of the intended recipient, and is also used to verify that decryption was successful. The message can be
28decrypted within a scheme by invoking IFDP-OU.
29Input:
34Output: The encrypted message representative, which is an integer g such that 0 g < n
35Operation: The encrypted message representative g shall be computed by the following or an equivalent
36sequence of steps:
2 80
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 1. Let g = exp(u, f) exp(v, r) mod n.
3 2. Output g as the encrypted message representative.
4Conformance region recommendation: A conformance region should include:
2 81
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
18.2.11 IFDP-OU
2IFDP-OU is the OU Decryption Primitive. It is based on the work of Okamoto and Uchiyama [OU98]. It is
3used in the scheme IFES-EPOC as part of decrypting a message encrypted with the use of IFEP-OU, given
4the encrypted message representative and the private key of the recipient.
5Input:
10Output: The message representative, which is an integer f such that 0 f < 2k1; or “invalid”
11Operation: The message representative f shall be computed by the following or an equivalent sequence of
12steps:
13
14 1. Compute gp = exp(g, p – 1) mod p2.
15 2. Compute L(gp) = (gp – 1) / p.
16 3. Compute f =L(gp) / w mod p.
17 4. Check whether 0 f < 2k1.
18 5. If it holds, output f. Otherwise, output “invalid.”
19Conformance region recommendation: A conformance region should include:
228.2.12 IFSP-ESIGN
23IFSP-ESIGN is ESIGN Signature Primitive. It is based on the work of Fujisaki and Okamoto [FO98] and
24Okamoto [Oka90]. It can be invoked in a scheme to compute a signature on a message representative with
25the private key of the signer, in such a way that the message representative can be recovered from the
26signature using the public key of the signer by the IFVP-ESIGN primitive. It is intended for a signature
27scheme with appendix and can be invoked in the scheme IFSSA as part of signature generation.
28Input:
32Output: The signature, which is an integer s such that 0 s < n, where n is from the corresponding public
33key
34Operation: The signature s shall be computed by the following or an equivalent sequence of steps:
35
2 82
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
141—The integer r in step 1 should be a one-time value which is generated by the signer following the security
15recommendations of D.6 and D.7. A new integer r should be generated for every signature, as its reuse can lead to the
16recovery of the private key. The integer r and other intermediate values should be securely deleted after they are used
17as their recovery by an opponent may lead to the recovery of the private key.
182—The integer r in step 1, the value exp(r, e) mod n in step 3, and the value 1 / (e exp(r, e – 1)) mod p in step 7 may
19be precomputed in advance of the availability of the message representative, although such precomputation will only be
20useful for a fraction of the message representatives if the optional test in step 6 is included.
213—Note that the length in bits of the modulus n must be a multiple of 3 (as is defined in 8.1.3.4) in order for the
22signature and verification primitives to operate correctly. Otherwise, it is possible that some signatures generated by
23IFSP-ESIGN may be rejected by IFVP-ESIGN, as noted by Shipsey [Shi01].
248.2.13 IFVP-ESIGN
25IFVP-ESIGN is ESIGN Verification Primitive. It is based on the work of Fujisaki and Okamoto [FO98]
26and Okamoto [Oka90]. This primitive recovers the message representative that was signed with IFSP-
27ESIGN, given only the signature and public key of the signer. It is intended for a signature scheme with
28appendix and can be invoked in the scheme IFSSA as part of signature verification.
29Input:
33Output: the message representative, which is an integer f such that 0 f < 2k1; or “invalid”
34Operation: The message representative f shall be computed by the following or an equivalent sequence of
35steps:
36
37 1. If s is not in [0, n – 1], output “invalid” and stop.
38 2. Let f = (exp(s, e) mod n) / 22k .
39 3. If f is not in [0, 2k1 – 1], output “invalid” and stop.
40 4. Output f.
41Conformance region recommendation: A conformance region should include:
2 83
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 84
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
11A key agreement scheme consists of a key agreement operation, along with supporting key management.
12Domain parameter and key pair generation for the key agreement schemes are specified further in
13connection with the DL and EC families (Clauses 6 and 7, respectively). Security considerations for key
14agreement schemes are given in Annex D.5.1.
15A key agreement operation has the following form for all the schemes:
16 c) 1. Establish one or more sets of valid domain parameters with which the parties’ key pairs
17 shall be associated.Select one or more valid private keys (and, in some cases, their corresponding
18 public keys) for the operation, associated with the domain parameters established in Step 1. (Note
19 2.)Obtain one or more other party’s purported public keys for the operation. (Note 3.)(Optional.)
20 Depending on the cryptographic operations in Step 5, choose an appropriate method to validate the
21 public keys and the domain parameters. If any validation fails, output “invalid” and stop. (Note
22 4.)Apply certain cryptographic operations to the private and public keys to produce a shared secret
23 value.For each shared secret key to be agreed on, establish or agree on key derivation parameters
24 and derive a shared secret key from the shared secret value and the key derivation parameters using
25 a key derivation function. (Note 5.)
26NOTES
271—(Key confirmation.) By the definition of a key agreement scheme, if the correct keys are used and computation is
28performed properly, the shared secret keys computed by the two parties will also be the same. However, to verify the
29identities of the parties and to ensure that they indeed possess the same key, the parties may need to perform a key
30confirmation protocol. See Annex D.5.1.3 for more information.
312—(Repeated use of a key pair.) A given public/private key pair may be used by either party for any number of key
32agreement operations, depending on the implementation.
333—(Authentication of ownership.) The process of obtaining the other party’s public key (Step 3) may involve
34authentication of ownership of the public key, as further described in D.3.1 and D.5.1.5. This may be achieved by
35verifying a certificate or by other means. The means by which the key (or the certificate containing it) is obtained may
36vary, and may include one party sending the key to the other, or a party obtaining the other party’s key from a third
37party or from a local database.
2 85
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
14—(Domain parameter and key validation.) Since a key agreement primitive assumes (with some exceptions,
2depending on the primitive chosen) that the domain parameters and the public key are valid, the result of the primitive
3is undefined otherwise. Consequently, it is recommended that parties validate the set(s) of domain parameters in step 1
4and the public key(s) in step 4, unless the risk of operating on invalid domain parameters or keys is mitigated by other
5means, as discussed further in D.3.2 and D.5.1.6. Examples of “other means” include validation within the supporting
6key management, or use of -DHC and -MQVC primitives together with simpler validation. In the case of key
7agreement it is only necessary that each party is assured of domain parameter and public key validity prior to use of the
8shared secret key. Therefore, while it may be more efficient to validate domain parameters once and then validate each
9key as it is used, there may be instances where domain parameter validation follows public key validation. In other
10words, an implementation may perform domain parameter validation and public key validation in a different order than
11assumed in the specification (step 1 followed by step 4), with equivalent effect, provided that both occur prior to use of
12the shared secret key.
135—(Key derivation parameters.) Depending on the key derivation function, there may be security-related constraints
14on the set of allowed key derivation parameters. The interpretation of these parameters is left to the implementation.
15For instance, it may contain key-specific information, protocol-related public information, and supplementary, private
16information. For security, the interpretation should be unambiguous. See Annex D.5.1.4 for further discussion.
176—(Attributes of the shared secret key.) The attributes of the shared secret key depend on the particular key agreement
18scheme used, the attributes of the public/private key pairs, the nature of the parameters to the key derivation function,
19and whether or not key confirmation is performed. See Annex D.5.1 for further discussion of the attributes of the
20shared secret key.
217—(Error conditions.) The two parties may produce errors under certain conditions, such as the following:
22
28
29Such error conditions should be detected and handled appropriately by an implementation, but the specific methods for
30detecting and handling them are outside of the scope of this standard.
319.2 DL/ECKAS-DH1
32DL/ECKAS-DH1 is Discrete Logarithm and Elliptic Curve Key Agreement Scheme, Diffie-Hellman
33version, where each party contributes one key pair.
2 86
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 Figure 2 — DL/ECKAS-DH1 key agreement operation
4The following options shall be established or otherwise agreed upon between the parties to the scheme:
2 87
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The above information may remain the same for any number of executions of the key agreement scheme,
2or it may be changed at some frequency. The information need not be kept secret.
4A sequence of shared secret keys K1, K2, …, Kt shall be generated by each party by performing the
5following or an equivalent sequence of steps:
6 d)Establish the valid set of DL or EC domain parameters with which the parties’ key pairs shall be
7 associated.Select a valid private key s for the operation, associated with the parameters established
8 in Step 1.Obtain the other party’s purported public key w for the operation, associated with the
9 parameters established in Step 1.(Optional.) If the selected secret value derivation primitive is
10 DLSVDP-DHC or ECSVDP-DHC, then validate that w is an element in the appropriate group
11 (i.e., in GF (q) for DL or on the elliptic curve for EC—see Clauses 6.2.2 and 7.2.2); otherwise
12 validate that w is a valid public key. If any validation fails, output “invalid public key” and
13 stop.Compute a shared secret value z from the private key s and the other party’s public key w with
14 the selected secret value derivation primitive (see Clause 9.2.1).Convert the shared secret value z to
15 an octet string Z using FE2OSP.For each shared secret key to be agreed on:
16 a. Establish or otherwise agree on key derivation parameters Pi for the key.
17 b. Derive a shared secret key Ki from the octet string Z and the key derivation parameters Pi with
18 the selected key derivation function (see Clause 9.2.1).
19Conformance region recommendation. A conformance region should include:
289.3 DL/ECKAS-DH2
29DL/ECKAS-DH2 is the Discrete Logarithm and Elliptic Curve Key Agreement Scheme, Diffie-Hellman
30version, where each party contributes two key pairs. Particular variants may be derived from the work of
31[MTI86], [Gos90], [Gun90], [ANS98b], [Joh] and [BJM98].
2 88
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 Figure 3 — DL/ECKAS-DH2 key agreement operation
4The following options shall be established or otherwise agreed upon between the parties to the scheme:
5
6 a) Two secret value derivation primitives, each of which (independently) shall be: DLSVDP-
7 DH, DLSVDP-DHC, ECSVDP-DH or ECSVDP-DHC
8 b) For each -DHC secret value derivation primitive, an indication as to whether or not
9 compatibility with the corresponding -DH primitive is desired
10 c) If the two secret value derivation primitives are the same (and have the same compatibility
11 option in the -DHC case), an indication whether compatibility with DL/ECKAS-DH1 is desired
12 d) A key derivation function, which should be KDF1 (Subclause 13.1), KDF2 (Subclause 13.2),
13 or a function designated for use with DL/ECKAS-DH2 in an amendment to this standard
14The above information may remain the same for any number of executions of the key agreement function,
15or it may be changed at some frequency. The information need not be kept secret.
2 89
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2A sequence of shared secret keys K1, K2, …, Kt shall be generated by each party by performing the
3following or an equivalent sequence of steps:
4 e) Establish the valid set of DL or EC domain parameters with which the parties’ first key pairs shall
5 be associated.Establish the valid set of DL or EC domain parameters with which the parties’ second
6 key pairs shall be associated.Select valid first and second private keys s and u for the operation,
7 associated with the domain parameters established in steps 1 and 2, respectively.Obtain the other
8 party’s first and second purported public keys w and v for the operation, associated with the
9 domain parameters established in Steps 1 and 2, respectively.(Optional.) If the first selected secret
10 value derivation primitive is DLSVDP-DHC or ECSVDP-DHC, then validate that w is an element
11 in the appropriate group (i.e., in GF(q) for DL or on the elliptic curve for EC—see Clauses 6.2.2
12 and 7.2.2); otherwise validate that w is a valid public key. If the second selected secret value
13 derivation primitive is DLSVDP-DHC or ECSDVP-DHC, then validate that v is an element in the
14 appropriate group; otherwise validate that v is a valid public key. If any validation fails, output
15 “invalid public key” and stop.Compute a first shared secret value z1 from s and w with the first
16 selected secret value derivation primitive (see Clause 9.3.1). Convert z1 to an octet string Z1 using
17 FE2OSP.Compute a second shared secret value z2 from u and v with the second selected secret
18 value derivation primitive (see Clause 9.3.1). Convert z2 to an octet string Z2 using FE2OSP.If
19 compatibility with DL/ECKAS-DH1 is desired, the selected private keys s and u (and associated
20 domain parameters) are the same, and the other party’s public keys w and v (and associated
21 domain parameters) are the same, then let Z = Z1. Otherwise, let Z = Z1 || Z2.For each shared secret
22 key to be agreed on:
23 a. Establish or otherwise agree on key derivation parameters Pi for the key.
24 b. Derive a shared secret key Ki from the octet string Z and the key derivation parameters Pi with
25 the selected key derivation function (see Clause 9.3.1).
26Conformance region recommendation. A conformance region should include:
27 at least one valid set of domain parameters for the first pair of keys
28 at least one valid private key s for each set of domain parameters for the first pair of keys
29 all valid public keys w associated with the same set of domain parameters as s
30 at least one valid set of domain parameters for the second pair of keys
31 at least one valid private key u for each set of domain parameters for the second pair of keys
32 all valid public keys v associated with the same set of domain parameters as u
33 a range of key derivation parameters P
34 if key validation is performed or a -DHC primitive is used, invalid public keys that are
35 appropriately handled by the implementation may also be included in the conformance region
36NOTES
371—If the two secret value derivation primitives are the same, compatibility with DL/ECKAS-DH1 is selected, and each
38party contributes two identical key pairs, then DL/ECKAS-DH2 will compute the same output as DL/ECKAS-DH1
39with the same primitive and key pairs.
402—This scheme, with appropriate restrictions on the scheme options and inputs, may be compatible with techniques in
41ANSI X9.42 [ANS98b] (in the DL case) and ANSI X9.63 [ANS98f] (in the EC case).
2 90
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
19.4 DL/ECKAS-MQV
2DL/ECKAS-MQV is Discrete Logarithm and Elliptic Curve Key Agreement Scheme, Menezes-Qu-
3Vanstone version. Each party contributes two key pairs.
5
6 Figure 4 — DL/ECKAS-MQV key agreement operation
8The following options shall be established or otherwise agreed upon between the parties to the scheme:
9
10 a) A secret value derivation primitive, which shall be: DLSVDP-MQV, DLSVDP-MQVC,
11 ECSVDP-MQV, ECSVDP-MQVC, DLSVDP-HMQV, DLSVDP-HMQVC, ECSVDP-HMQV, or
12 ECSVDP-HMQVC
2 91
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
7TODO: Convert the following text, relevant to HMQV, into notes in the appropriate section.
8The optional steps for validation will be the same as those listed there for the MQVC variants. (A note can
9be added that in the case of the DL/ECSVDP-HMQV scheme full validation – namely, prime order
10validation – may be performed if defense against leaked ephemeral exponents is desired.)
11In addition, Section 9.4 should have an explicit note explaining that the value of the shared secret z should
12never be revealed to a non-secure interface since revealing this value not only compromises the specific
13session using the key derived from z but it can potentially compromise other sessions. This note needs to be
14there regardless of the addition of HMQV since it also applies to MQV.
15Also, a note about key confirmation, especially as a way to ensure full forward secrecy (against active
16attacks) should be added to 9.4 (again, irrespective of HMQV adoption).
17Finally, text about the checking of certificates, or other ways to validate the authenticity of public keys,
18should be added too.
20A sequence of shared secret keys K1, K2, …, Kt shall be generated by each party by performing the
21following or an equivalent sequence of steps:
22 f)Establish the valid set of DL or EC domain parameters with which the parties’ two key pairs shall
23 be associated.Select a valid private key s and a valid key pair (u, v) for the operation, associated
24 with the parameters established in Step 1.Obtain the other party’s two purported public keys w and
25 v for the operation, associated with the parameters established in Step 1.(Optional.) If the selected
26 secret value derivation primitive is DLSVDP-MQVC or ECSVDP-MQVC, then validate that w
27 and v are elements in the appropriate group (i.e., in GF(q) for DL or on the elliptic curve for EC—
28 see Clauses 6.2.4 and 7.2.4); otherwise validate that w and v are valid public keys. If any
29 validation fails, output “invalid public key” and stop.Compute a shared secret value z from the
30 selected private key s, the selected key pair (u, v), and the other party’s two public keys w and v
31 with the selected secret value derivation primitive (see 9.4.1).Convert the shared secret value z to
32 an octet string Z using FE2OSP.For each shared secret key to be agreed on:
33 a. Establish or otherwise agree on key derivation parameters Pi for the key.
34 b. Derive a shared secret key Ki from the octet string Z and the key derivation parameters Pi with
35 the selected key derivation function (see Clause 9.4.1).
36Conformance region recommendation. A conformance region should include:
2 92
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 all valid public keys w and v associated with the same set of domain parameters as s; if key
2 validation is performed or an -MQVC primitive is used, invalid public keys w and v that are
3 appropriately handled by the implementation may also be included in the conformance region
4 a range of key derivation parameters P
5NOTE—These schemes, with appropriate restrictions on the scheme options and inputs, may be compatible with
6techniques in ANSI X9.42 [ANS98b] (in the DL case) and ANSI X9.63 [ANS98f] (in the EC case).
18The security of KEM is defined by inability of an adversary in the chosen-ciphertext attack to distinguish a
19real key/ciphertext pair (K;C) from a fake pair (K’;C). The security of DEM is defined by
20indistinguishability of an adversary in the “chosen-ciphertext” attack for symmetric encryption; One
21example of secure DEM is a one-time-pad-then-MAC. For more details about definitions, security notions
22and composition theorem of these mechanisms, see ***[4].
23A KEM scheme consists of a KEM.Encapsulate stage, carried out by the sender, and a KEM.Recover stage,
24carried out by the receiver.
25In the KEM-encapsulate stage, the sending party submits to the encryption primitive a random buffer (of
26the appropriate type, for example an integer for IF-based schemes). This buffer is not preprocessed in any
27way before submitting it to the encryption primitive. The output ciphertext is sent to the receiving party.
28The sending party then puts the buffer through an appropriately chosen agreed Key Derivation function or
29KDF. The success of the encapsulation is demonstrated by subsequent use of the derived key in a
30symmetric operation; this use is out of scope for this standard.
31In the KEM-recover stage, the receiving party submits the received ciphertext to the decryption primitive.
32The output is a buffer of the appropriate time. The receiving party puts the buffer through the agreed KDF.
33The success of the encapsulation is demonstrated by subsequent use of the derived key in a symmetric
34operation; this use is out of scope for this standard.
36An key encapsulation operation has the following form for all the schemes:
37
38 1. Obtain the recipient’s purported public key (together with its set of domain parameters, if any)
39 for the operation (Note 1 below).
2 93
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 2. (Optional) Validate the public key and its associated set of domain parameters, if any. If
2 validation fails, output “invalid” and stop (Note 2 below).
3 3. Apply certain cryptographic operations to the public key, and the encoding parameters, if any,
4 to produce a ciphertext and a symmetric key.
5 4. Output the ciphertext. Retain the symmetric key.
6A decryption operation has the following form:
7
8 1. Select a valid private key (together with its set of domain parameters, if any) for the
9 operation.
10 2. Apply certain cryptographic operations to the ciphertext, the private key, and the encoding
11 parameters, if any, to recover a symmetric key (Note 2 below).
12 3. Output the symmetric key.
13NOTES
141—(Authentication of ownership) The process of obtaining the recipient’s public key (step 1 of encryption) may
15involve authentication of ownership of the public key, as further described in D.3.2 and D.5.3.4. This may be achieved
16by verifying a certificate or by other means. The means by which the key (or the certificate containing it) is obtained
17may vary, and may include the recipient sending the key to the sender, or the sender obtaining the key from a third
18party or from a local database.
192—(Domain parameter and key validation) Since the underlying primitives generally assume that the domain
20parameters (if any) and public key are valid, the result of a primitive may be undefined otherwise. Consequently, it is
21recommended that the sender validate the public key (and its associated set of domain parameters, if any) in step 1 of
22the encryption operation, unless the risk of operating on invalid domain parameters or keys is mitigated by other means,
23as discussed further in D.3.3 and D.5.3.5. Key validation may also be a consideration in step 2 of the decryption
24operation for some schemes. Examples of “other means” include validation within the supporting key management.
253—(Error conditions) The sender’s and recipient’s steps may produce errors under certain conditions, such as the
26following:
27
30— Message, encoding parameters, or public key not supported in sender’s step 3
32— Ciphertext, encoding parameters, or private key not supported in recipient’s step 2
33Such error conditions should be detected and handled appropriately by an implementation, but the specific methods for
34detecting and handling them are outside of the scope of this standard.
3510.2 IFKEM-RSA
36RSAES-KEM is a Key Encapsulation Mechanism Scheme based on the IFEP-RSA and IFDP-RSA
37primitives (see 8.2.2, 8.2.3) and a key derivation function (see ***).
39
2 94
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
3The following options shall be established or otherwise agreed upon between the parties to the scheme (the
4sender and the recipient):
5
6 the key derivation function, which should be *** (Clause ***), or a technique designated for use
7 with IFKEM-RSA in an addendum to this standard
8 the parameters to be used with the chosen KDF, including the algorithm of the output symmetric
9 key.
10
11The above information may remain the same for any number of executions of the KEM scheme, or it may
12be changed at some frequency. The information need not be kept secret.
14A sender shall generate a ciphertext and key pair (g, S) by the following or an equivalent sequence of steps:
15 a) Obtain the recipient’s purported public key (n, e) for the operation. Denote the length of the
16 modulus n in octets by nLen.
17 b) (Optional.) Validate the public key (n, e). Stop if validation fails.
18 c) Generate a statistically uniform random integer z in the range [0, n-1].
19 d) Compute the ciphertext g from z and the recipient’s public key with the primitive IFEP-RSA.
20 e) Convert the integer z to a string Z of length nLen using I2OSP (Clause 5.5.3)
21 f) Obtain the shared key S by running the agreed KDF with the agreed parameters using Z as input.
22 g) Output (g, S)
23Conformance region recommendation. A conformance region should include:
24 at least one valid RSA public key (n, e); if key validation is performed, invalid public keys (n, e)
25 that are appropriately rejected by the implementation may also be included in the conformance
26 region
27 at least one KDF
29The receiver shall recover the shared key S from the ciphertext g by the following or an equivalent
30sequence of steps:
2 95
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
710.3 ECKEM-PSEC
8ECKEM-PSEC is a Key Encapsulation Mechanism Scheme based on the ECSVP-DH or ECSVP-DHC
9primitives (see ***) and a key derivation function (see ***). It is defined for the EC family only and does
10not have a DL equivalent.
12
15The following options shall be established or otherwise agreed upon between the parties to the scheme (the
16sender and the recipient):
17 the secret value derivation primitive, which shall be DLSVDP-DH, DLSVDP-DHC, ECSVDP-DH
18 or ECSVDP-DHC
19 for the -DHC secret value derivation primitive, an indication as to whether or not compatibility
20 with the -DH primitive is desired.
21 the key derivation function, which should be *** (Clause ***), or a technique designated for use
22 with IFKEM-RSA in an addendum to this standard.
23 the parameters to be used with the chosen KDF, including the algorithm of the output symmetric
24 key.
25 a pair of primitives for converting elliptic curve points to and from octet strings appropriate for the
26 underlying finite field, which should be among those in 5.5.6.2 and 5.5.6.3.
27 the length oLen of the random octet string to be used.
28The above information may remain the same for any number of executions of the encryption scheme, or it
29may be changed at some frequency. The information need not be kept secret. However, it is recommended
30that for any particular recipient’s public key, the same set of options be used each time to avoid unintended
31interactions between different options for that public key. (See *** for further discussion.)
33A sender shall generate a ciphertext and key (C, S) by the following or an equivalent sequence of steps:
2 96
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 a) Establish the valid set of EC domain parameters with which the parties’ key pairs shall be
2 associated.
3 b) Obtain the recipient’s purported public key W for the operation, associated with the parameters
4 established in step 1.
5 c) Optional) If the selected secret value derivation primitive is DLSVDP-DHC or ECSVDP-DHC,
6 then validate that W is an element in the appropriate group (i.e., in GF(q) for DL or on the elliptic
7 curve for EC—see 6.2.2 and 7.2.2); otherwise validate that W is a valid public key. If any
8 validation fails, output “invalid public key” and stop.
9 d) Generate a random octet string o of length oLen.
10 e) Let H := KDF(I2OSP(0,4) || o, rLen + 16 + keyLen), where rLen is length in octets of I2OSP(r), r
11 the order of G in the elliptic curve domain parameters; and keyLen is the length of the symmetric
12 key to be output. WHAT INPUT DOES KDF TAKE?
13 f) Parse H := t||S’, where the octet length of t is rLen + 16, and the octet length of S’ is keyLen.
14 g) Let s := OS2IP(t) mod r. WHAT INPUT DOES OS2IP TAKE?
15 h) Let P := sW. Let z be the x-coordinate of P.
16 i) Let C1 := sG.
17 j) Let c2 := o ⊕ KDF(I2OSP(1,4) || ECP2OSP (C1) || FE2OSP(z), oLen).
18 k) Let C := ECP2OSP(C1) || c2.
19 l) Output (C, S).
20Conformance region recommendation: A conformance region should include:
26The receiver shall recover the key S from the ciphertext C by the following or an equivalent set of steps:
27 a) Establish the valid set of DL or EC domain parameters with which the parties’ key pairs shall be
28 associated.
29 b) Select the private key s for the operation, associated with the parameters established in step 1.
30 c) Parse the ciphertext C into C1, C2, where the length of C1 is the length of the output of ECP2OSP
31 applied to any point on the elliptic curve E and the length of C2 is the agreed scheme parameter
32 oLen. If C is not of the expected length, output “invalid ciphertext” and exit.
33 d) Convert C1 to a public key v using the selected primitive for converting an octet string to an elliptic
34 curve point (in the EC case). If conversion fails, output “invalid” and stop.
35 e) (Optional) If the selected secret value derivation primitive is ECSVDP-DHC, then validate that v is
36 an element in the appropriate group (i.e., on the elliptic curve for EC—see 7.2.2); otherwise
37 validate that v is a valid public key. If any validation fails, output “invalid public key” and stop.
38 f) Compute a shared secret value z from the private key s and the public key v with the selected secret
39 value derivation primitive (see 9.2.1).
40 g) Let o := c2 ⊕ KDF(I2OSP(1,4) || ECP2OSP (C1) || FE2OSP(z), oLen).
2 97
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
24In addition to providing confidentiality of a message, an encryption scheme may provide for a secure
25association between the message and a string known as encoding parameters. The encoding parameters
26themselves are not encrypted by the encryption scheme, but are securely associated with the ciphertext by
27the sender. The recipient, during decryption, may also supply encoding parameters and verify whether or
28not the sender used the same encoding parameters during encryption. The encoding parameters may be an
29empty string. See Annex D.5.3.3 for more on encoding parameters.
30An encryption scheme consists of an encryption operation and a decryption operation, along with
31supporting key management. Domain parameter and key pair generation for the encryption scheme below
32are specified further in connection with the IF family (Clauses 8). Security considerations for encryption
33schemes are given in Annex D.5.3.
34An encryption operation has the following form for all the schemes:
35
36 1. Obtain the recipient’s purported public key (together with its set of domain parameters, if any)
37 for the operation (Note 1 below).
38 2. (Optional) Validate the public key and its associated set of domain parameters, if any. If
39 validation fails, output “invalid” and stop (Note 2 below).
2 98
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 3. Apply certain cryptographic operations to the message, the public key, and the encoding
2 parameters, if any, to produce a ciphertext.
3 4. Output the ciphertext.
4A decryption operation has the following form:
5
6 1. Select a valid private key (together with its set of domain parameters, if any) for the
7 operation.
8 2. Apply certain cryptographic operations to the ciphertext, the private key, and the encoding
9 parameters, if any, to recover a message (Note 2 below).
10 3. Output the message or “invalid” according to the result of step 2.
11NOTES
121—(Authentication of ownership) The process of obtaining the recipient’s public key (step 1 of encryption) may
13involve authentication of ownership of the public key, as further described in D.3.2 and D.5.3.4. This may be achieved
14by verifying a certificate or by other means. The means by which the key (or the certificate containing it) is obtained
15may vary, and may include the recipient sending the key to the sender, or the sender obtaining the key from a third
16party or from a local database.
172—(Domain parameter and key validation) Since the underlying primitives generally assume that the domain
18parameters (if any) and public key are valid, the result of a primitive may be undefined otherwise. Consequently, it is
19recommended that the sender validate the public key (and its associated set of domain parameters, if any) in step 1 of
20the encryption operation, unless the risk of operating on invalid domain parameters or keys is mitigated by other means,
21as discussed further in D.3.3 and D.5.3.5. Key validation may also be a consideration in step 2 of the decryption
22operation for some schemes. Examples of “other means” include validation within the supporting key management.
233—(Error conditions) The sender’s and recipient’s steps may produce errors under certain conditions, such as the
24following:
25
28— Message, encoding parameters, or public key not supported in sender’s step 3
30— Ciphertext, encoding parameters, or private key not supported in recipient’s step 2
31Such error conditions should be detected and handled appropriately by an implementation, but the specific methods for
32detecting and handling them are outside of the scope of this standard.
3311.2 IFES
34IFES is Integer Factorization Encryption Scheme.
2 99
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 Figure 10 — IFES encryption and decryption operations
3
5The following options shall be established or otherwise agreed upon between the parties to the scheme (the
6sender and the recipient):
7
8 the message encoding method for encryption, which should be EME1 (Clause 12.2.1), or a
9 technique designated for use with IFES in an addendum to this standard
10The above information may remain the same for any number of executions of the encryption scheme, or it
11may be changed at some frequency. The information need not be kept secret.
13The ciphertext g shall be generated by a sender from a message M and encoding parameters P by the
14following or an equivalent sequence of steps:
15 m) Obtain the recipient’s purported public key (n, e) for the operation.(Optional.) Validate the public
16 key (n, e). Stop if validation fails.Set the maximum length of the message representative to be l =
17 (length of n in bits) – 1, where n is the modulus in the IF private key.Use the encoding operation of
18 the selected message encoding method (see Clause 11.2.1) to produce a message representative f of
19 maximum length l from the message M and the encoding parameters P (f will be a non-negative
20 integer). If the message is too long, the encoding method may not be able to produce a
2 100
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 representative of the selected length. In that case, output “error” and stop.Compute the ciphertext g
2 from f and the recipient’s public key with the primitive IFEP-RSA.
3Conformance region recommendation. A conformance region should include:
4 at least one valid RSA public key (n, e); if key validation is performed, invalid public keys (n, e)
5 that are appropriately rejected by the implementation may also be included in the conformance
6 region
7 a range of messages M and encoding parameters P (where the range of encoding parameters may
8 include only the empty string)
10The plaintext M shall be recovered from the ciphertext g and encoding parameters P by the following or an
11equivalent sequence of steps:
12 n) 1. Select the private key K for the operation.Compute an integer f from g and the selected
13 private key K with primitive IFDP-RSA.Set the maximum length of the message representative to
14 be l = (length of n in bits) – 1, where n is the modulus in the IF private key.Decode the integer f
15 according to the decoding operation of the selected message encoding method (see Clause 11.2.1),
16 maximum length l and the encoding parameters P to produce the message M. If the decoding
17 operation produces an error, output “invalid.” Else output the message M as the plaintext.
18Conformance region recommendation. A conformance region should include:
241—(Length of the message.) The upper bound on the length in bits of the encoded message representative is so that,
25when converted to an integer, it is less than the modulus n, as required by the encryption primitive. Since the message
26representative has to, at the very least, contain the information contained in the message itself, the length of messages
27that can be encrypted by this scheme is limited by the modulus length and the selected message encoding method.
282—(Compatibility.) This scheme, with appropriate restrictions on the scheme options and inputs, may be compatible
29with techniques in ANSI X9.44 [B9] and PKCS #1 v2.1 [PKCS1v2_1].
3011.3 DL/ECIES
31DL/ECIES is Discrete Logarithm and Elliptic Curve Integrated Encryption Scheme. It is based on the work
32of Abdalla, Bellare and Rogaway [ABR98] and ANSI X9.63 [B12].
2 101
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 Figure 11 — DL/ECIES encryption and decryption operations
4The following options shall be established or otherwise agreed upon between the parties to the scheme (the
5sender and the recipient):
6
7 a) The secret value derivation primitive, which shall be DLSVDP-DH, DLSVDP-DHC,
8 ECSVDP-DH or ECSVDP-DHC
9 b) For the -DHC secret value derivation primitive, an indication as to whether or not
10 compatibility with the corresponding -DH primitive is desired
11 c) The method for encrypting the message, which shall be either:
12 1) A stream cipher based on a key derivation function, where the key derivation function should
13 be KDF2 (see 13.2) or a function designated for use with DL/ECIES in an amendment to this
14 standard (this method is only recommended for relatively short messages such as symmetric
15 keys, and in non-DHAES mode, the messages should have a fixed length for a given public
16 key—see D.5.3 Note 1 and D.5.3.2.2)
17 2) A key derivation function combined with a symmetric encryption scheme, where the key
18 derivation function should be KDF2 (see 13.2) or a technique designated for use with
19 DL/ECIES in an amendment to this standard, and the symmetric encryption scheme should be
2 102
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 one of the schemes in 14.3, or a technique designated for use with DL/ECIES in an
2 amendment to this standard
3 d) The message authentication code, which should be MAC1 (see 14.4.1), or a MAC designated
4 for use with DL/ECIES in an amendment to this standard
5 e) An indication as to whether to operate in “DHAES” mode (see Abdalla, Bellare and Rogaway
6 [ABR98]), i.e., whether to include a representation of the sender’s public key as an input to the key
7 derivation function
8 f) In the EC case, a pair of primitives for converting elliptic curve points to and from octet
9 strings appropriate for the underlying finite field, which should be among those in 5.5.6.2 and
10 5.5.6.3
11The above information may remain the same for any number of executions of the encryption scheme, or it
12may be changed at some frequency. The information need not be kept secret. However, it is recommended
13that for any particular recipient’s public key, the same set of options be used each time to avoid unintended
14interactions between different options for that public key. (See D.5.3 for further discussion.)
15NOTES
161—Although defined in terms of bit strings, the recommended symmetric encryption schemes in 14.3 all require that
17the length of the bit string is divisible by 8. To encrypt a bit string of length not divisible by 8, a different symmetric
18encryption scheme should be chosen, or the stream cipher option should be selected.
192—Parameters to the underlying symmetric encryption scheme, if any (such as a variable initialization vector) should
20either be included in the encrypted message C, or in the encoding parameters, to ensure their integrity.
22A ciphertext (V, C, T) shall be generated by a sender from a message M of bit length l, key derivation
23parameters P1, and encoding parameters P2 by the following or an equivalent sequence of steps:
24
25 1. Establish the valid set of DL or EC domain parameters with which the parties’ key pairs shall
26 be associated.
27 2. Select a key pair (u, v) for the operation, associated with the parameters established in step 1.
28 3. Obtain the recipient’s purported public key w for the operation, associated with the
29 parameters established in step 1.
30 4. (Optional) If the selected secret value derivation primitive is DLSVDP-DHC or ECSVDP-
31 DHC, then validate that w is an element in the appropriate group (i.e., in GF(q) for DL or on
32 the elliptic curve for EC—see 6.2.2 and 7.2.2); otherwise validate that w is a valid public key.
33 If any validation fails, output “invalid public key” and stop.
34 5. Compute a shared secret value z from the private key u and the recipient’s public key w with
35 the selected secret value derivation primitive (see 9.2.1).
36 6. Convert the shared secret value z to an octet string Z using FE2OSP.
37 7. Convert the sender’s public key to an octet string V using FE2OSP (in the DL case) or the
38 selected primitive for converting an elliptic curve point to an octet string (in the EC case).
39 8. In DHAES mode, let VZ = V || Z. Otherwise, let VZ = Z.
40 9. If the method for encrypting the message is a stream cipher based on a key derivation
41 function:
42 a) Derive a shared secret key K from the octet string VZ and the key derivation parameters
43 P1 with the selected key derivation function (see 9.2.1). The length in bits of the shared
44 secret key K shall be l + k2 where k2 is the length in bits of the key for the message
45 authentication code. In non-DHAES mode, let K1 be the leftmost l bits of K and let K2
46 be the remaining k2 bits. In DHAES mode, let K2 be the leftmost k2 bits of K and let K1
2 103
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 be the remaining l bits. (Note that the order of K1 and K2 is different in the two modes
2 see D.5.3 Note 1.)
3 b) Let C = M K1.
4 10. If the method for encrypting the message is a key derivation function combined with a
5 symmetric encryption scheme:
6 a) Derive a shared secret key K from the octet string VZ and the key derivation parameters
7 P1 with the selected key derivation function (see 9.2.1). The length in bits of the shared
8 secret key K shall be k1 + k2 where k1 is the length in bits of the key for the symmetric
9 encryption scheme and k2 is the length in bits of the key for the message authentication
10 code. Let K1 be the leftmost k1 bits of K and let K2 be the remaining k2 bits.
11 b) Encrypt M under the key K1 with the symmetric encryption scheme to produce an
12 encrypted message C.
13 11. In DHAES mode, convert the length of P2 in bits to an octet string L2 of length 8 octets using
14 I2OSP. Otherwise, let L2 be the empty string.
15 12. Apply the selected message authentication code to the encrypted message C, the encoding
16 parameters P2 and the (possibly empty) length L2 under the key K2 to produce an
17 authentication tag T = (C || P2 || L2).
18 13. Output the triple (V, C, T) as the ciphertext.
19Conformance region recommendation: A conformance region should include:
281—The key pair in step 2 should generally be a one-time key pair which is generated and stored by the sender
29following the security recommendations of D.3.1, D.4.1.2, D.6 and D.7. However, for this scheme the same key pair
30may also be used in additional encryption operations with the same domain parameters, either for the same or for
31different recipients, following the ephemeral-static mode of Diffie-Hellman (see Housley [Hou02], Sec. 6.2.2, and
32Rescorla [Res99], Sec. 2.3). In such a case, the private key should be securely deleted after all the encryption
33operations are complete, as its recovery by an opponent can lead to the recovery of messages encrypted using that key
34pair. If the key pair is used for additional encryption operations for the same recipient, the key derivation parameters P1
35should vary among the operations so that the key K varies (see D.5.3.3).
362—Non-DHAES mode is included for compatibility with ANSI X9.63 [B12] and other standards efforts. In non-
37DHAES mode, a representation of the sender’s public key v is not explicitly included as an input to the key derivation
38function. As further discussed in D.5.3, this raises mainly theoretical concerns. DHAES mode is offered for increased
39assurance.
403—In non-DHAES mode, if the method for encrypting the message is a key derivation function combined with a
41symmetric encryption scheme, provision should be made to address the possibility of ambiguity in the encoding C || P2
42in the input to the MAC in step 12. For example, P2 can have a fixed length or end with a fixed-length encoding of its
43length (see D.5.3.3 for further discussion). This ambiguity is avoided in the stream cipher option if the message (and
44hence C) has a fixed length for a given public key as recommended above.
45In DHAES mode, the ambiguity is avoided by including the length of P2 in the input. (Note that this protection is not
46part of DHAES per se as defined by Abdalla, Bellare and Rogaway [ABR98], since their proposal does not use
47encoding parameters, but the protection is included for increased assurance.)
2 104
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2The message M shall be recovered from the ciphertext (V, C, T), key derivation parameters P1, and
3encoding parameters P2 by the following or an equivalent sequence of steps:
4
5 1. Establish the valid set of DL or EC domain parameters with which the parties’ key pairs shall
6 be associated.
7 2. Select the private key s for the operation, associated with the parameters established in step 1.
8 3. Convert the octet string V to a public key v using OS2FEP (in the DL case) or the selected
9 primitive for converting an octet string to an elliptic curve point (in the EC case). If
10 conversion fails, output “invalid” and stop.
11 4. (Optional) If the selected secret value derivation primitive is DLSVDP-DHC or ECSVDP-
12 DHC, then validate that v is an element in the appropriate group (i.e., in GF(q) for DL or on
13 the elliptic curve for EC—see 6.2.2 and 7.2.2); otherwise validate that v is a valid public key.
14 If any validation fails, output “invalid public key” and stop.
15 5. Compute a shared secret value z from the private key s and the public key v with the selected
16 secret value derivation primitive (see 9.2.1).
17 6. Convert the shared secret value z to an octet string Z using FE2OSP.
18 7. In DHAES mode, let VZ = V || Z. Otherwise, let VZ = V.
19 8. If the method for encrypting the message is a stream cipher based on a key derivation
20 function:
21 a) Derive a shared secret key K from the octet string VZ and the key derivation parameters
22 P1 with the selected key derivation function (see 9.2.1). The length in bits of the shared
23 secret key K shall be l + k2 as above. In non-DHAES mode, let K1 be the leftmost l bits
24 of K and let K2 be the remaining k2 bits. In DHAES mode, let K2 be the leftmost k2 bits
25 of K and let K1 be the remaining l bits. (Note that the order of K1 and K2 is different in
26 the two modes see D.5.3 Note 1.)
27 b) Let M = C K1.
28 9. If the method for encrypting the message is a key derivation function combined with a
29 symmetric encryption scheme:
30 a) Derive a shared secret key K from the octet string VZ and the key derivation parameters
31 P1 with the selected key derivation function (see 9.2.1). The length in bits of the shared
32 secret key K shall be k1 + k2 as above. Let K1 be the leftmost k1 bits of K and let K2 be
33 the remaining k2 bits.
34 b) Decrypt C under the key K1 with the symmetric encryption scheme to recover M. (If
35 the decryption operation outputs “error,” output “invalid” and stop.)
36 10. In DHAES mode, convert the length of P2 in bits to an octet string L2 of length 8 octets using
37 I2OSP. Otherwise, let L2 be the empty string.
38 11. Apply the selected message authentication code to the encrypted message C, the encoding
39 parameters P2 and the (possibly empty) length L2 to verify the authentication tag T, i.e., that T
40 = (C || P2 || L2). If the authentication tag is incorrect, output “invalid” and stop.
41 12. Output the message M.
42Conformance region recommendation: A conformance region should include:
2 105
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1NOTES
21—This scheme is amenable to “single-pass” processing in DHAES mode. In non-DHAES mode, single-pass
3processing is possible if the method for encrypting the message is a key derivation function combined with a symmetric
4encryption scheme, but not if the method is a stream cipher based on a key derivation function, since the MAC key in
5that method may not be available until after the message has been encrypted. Since the latter method is only
6recommended for relatively short messages (see D.5.3.2.2), this is not likely to be a disadvantage in practice.
72—This scheme, in the EC case with appropriate restrictions on the scheme options and inputs, may be compatible with
8techniques in ANSI X9.63 [B12].
911.4 IFES-EPOC
10IFES-EPOC is Integer Factorization Encryption Scheme, EPOC version. It is based on the work of Fujisaki
11and Okamoto [FO99b].
13
14 Figure 12 — IFES-EPOC encryption and decryption operations
16The following options shall be established or otherwise agreed upon between the parties to the scheme (the
17sender and the recipient):
18
19 a) The encryption and decryption primitives, which shall be the pair IFEP-OU and IFDP-OU
20 b) The message-encoding method for encryption, which should be EME2 (see 12.2.2), EME3
21 (see 12.2.3), or a technique designated for use with IFES-EPOC in an amendment to this standard
2 106
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 c) The length in bits, rBits, of the randomized hash value (see D.5.3.2.1)
2The above information may remain the same for any number of executions of the encryption scheme, or it
3may be changed at some frequency. The information need not be kept secret.
4NOTES
51—The form of the ciphertext below depends on whether the selected message-encoding method outputs an encrypted
6message C. If it does, the ciphertext shall consist of an encrypted message representative g and the encrypted message
7C. If not, the ciphertext shall consist only of an encrypted message represented. EME3 outputs an encrypted message C,
8but EME2 does not.
92—The length in bits of the randomized hash value may depend on the public key.
11The ciphertext (g, C) (where C is optional) shall be generated by a sender from a message M and encoding
12parameters P by the following or an equivalent sequence of steps:
13
14 1. Obtain the recipient’s purported public key (n, u, v, k) for the operation.
15 2. (Optional) Validate the public key (n, u, v, k). Stop if validation fails.
16 3. Set the maximum length of the message representative to be l = k 1.
17 4. Use the encoding operation of the selected message-encoding method (see 11.4.1) to produce
18 a message representative f of maximum length l, a randomized hash value r of maximum
19 length rBits, and optionally an encrypted message C from the message M and the encoding
20 parameters P (f and r will be non-negative integers). If the message is too long, the encoding
21 method may not be able to produce a representative of the selected length. In that case, output
22 “error” and stop.
23 5. Compute the encrypted message representative g from f, r, and the recipient’s public key with
24 the primitive IFEP-OU.
25 6. Output the pair (g, C) as the ciphertext.
26Conformance region recommendation: A conformance region should include:
27 At least one valid OU public key (n, u, v, k); if key validation is performed, invalid public keys that
28 are appropriately handled by the implementation may also be included in the conformance region.
29 A range of messages M and encoding parameters P (where the range of encoding parameters may
30 include only the empty string)
32The message M shall be recovered from the ciphertext (g, C) (where C is optional) and encoding
33parameters P, by the following or an equivalent sequence of steps:
34
35 1. Select the private key (p, q, k, w) for the operation and obtain the corresponding public key (n,
36 u, v, k).
37 2. Compute an integer f from g and the selected private key (p, q, k, w) with the primitive IFDP-
38 OU.
39 3. Set the maximum length of the message representative to be l = k – 1, where n is the modulus
40 in the IF private key.
41 4. Decode the integer f and optional encrypted message C if present according to the decoding
42 operation of the selected message-encoding method (see 11.4.1), maximum length l,
2 107
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 randomized hash length rBits, and the encoding parameters P to produce the message M and
2 the randomized hash value r. If the decoding operation produces an error, output “invalid”
3 and stop.
4 5. Compute another encrypted message representative g from f, r, and the public key (n, u, v, k)
5 with the primitive IFEP-OU.
6 6. If g = g, output the message M. Otherwise, output “invalid.”
7Conformance region recommendation: A conformance region should include:
22There are two types of signature scheme. In a signature scheme with appendix, the signer conveys both the
23message and the signature to the verifier, who verifies their consistency. In a signature scheme giving
24message recovery, a message is processed in two parts: a recoverable message part that can be recovered
25from the signature, and a non-recoverable message part. The signer conveys the signature and the non-
26recoverable message part to the verifier, who verifies their consistency and recovers the recoverable part.
27Such a scheme is said to provide total message recovery if the non-recoverable part is empty and partial
28message recovery otherwise.
29A signature scheme giving message recovery will potentially be more efficient in terms of the message
30expansion for signing a message than a signature scheme with appendix. A signature scheme giving
31message recovery is typically considered for shorter messages, for which the message expansion is
32relatively a larger overhead. In a signature scheme with appendix, all of the message will be handled the
33same way, which may be more convenient in terms of implementation and integration with other
34operations, such as multiple signatures on the same message.
35A signature scheme consists of a signature generation operation and a signature verification operation,
36along with supporting key management. Domain parameter and key pair generation for the signature
37schemes are specified further in connection with the DL, EC and IF families (Clauses 6, 7 and 8,
38respectively). Security considerations for signature schemes are given in Annex D.5.2.
39A signature generation operation in a signature scheme with appendix has the following form:
40
2 108
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 1. Select a valid private key (together with its set of domain parameters, if any) for the
2 operation.
3 2. Apply certain cryptographic operations to the message and the private key to produce a
4 signature.
5 3. Output the signature.
6A signature verification operation in a signature scheme with appendix has the following form:
7
8 1. Obtain the signer’s purported public key (together with its set of domain parameters, if any)
9 for the operation (Note 1 below).
10 2. (Optional) Validate the public key and its associated set of domain parameters, if any. If
11 validation fails, output “invalid” and stop (Note 2 below).
12 3. Apply certain cryptographic operations to the message, the signature and the public key to
13 verify the signature.
14 4. Output “valid” or “invalid” according to the result of step 3.
15A signature generation operation in a signature scheme giving message recovery has the following form:
16
17 1. Select a valid private key (together with its set of domain parameters, if any) for the
18 operation.
19 2. Apply certain cryptographic operations to the recoverable message part, the non-recoverable
20 part (if any), and the private key to produce a signature.
21 3. Output the signature.
22A signature verification operation in a signature scheme giving message recovery has the following form:
23
24 1. Obtain the signer’s purported public key (together with its set of domain parameters, if any)
25 for the operation (Note 1 below).
26 2. (Optional) Validate the public key and its associated set of domain parameters, if any. If
27 validation fails, output “invalid” and stop (Note 2 below).
28 3. Apply certain cryptographic operations to the non-recoverable message part (if any), the
29 signature and the public key to verify the signature and recover the recoverable part of the
30 message.
31 4. Output the recoverable part of the message or “invalid” according to the result of step 3.
32NOTES
331—(Authentication of ownership.) The process of obtaining the signer’s public key (step 1 of verification) may involve
34authentication of ownership of the public key, as further described in D.3.1 and D.5.2.4. This may be achieved by
35verifying a certificate or by other means. The means by which the key (or the certificate containing it) is obtained may
36vary, and may include the signer sending the key to the verifier, or the verifier obtaining the key from a third party or
37from a local database.
382—(Domain parameter and key validation.) Since a signature verification primitive assumes that the domain
39parameters and the public key are valid, the result of the primitive is undefined otherwise. Consequently, it is
40recommended that the verifier validate the public key (and its associated set of domain parameters, if any) in step 3,
41unless the risk of operating on invalid domain parameters or keys is mitigated by other means, as discussed further in
42D.3.2 and D.5.2.5. Examples of “other means” include validation within the supporting key management, or
43assignment of liability to a purported signer for all signatures that can be verified with the signer’s public key, whether
44or not the public key is valid.
453—(Error conditions) The signer’s and verifier’s steps may produce errors under certain conditions, such as the
46following:
47
2 109
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2— Message, recoverable message part, non-recoverable message part, or private key not supported in
3signer’s step 2
6— Message, non-recoverable message part, signature, or public key not supported in verifier’s step 3
8Such error conditions should be detected and handled appropriately by an implementation, but the specific methods for
9detecting and handling them are outside of the scope of this standard.
10
114—(Repudiation.) A dishonest signer may be interested in the ability to claim that something went wrong and the
12signature was not authentic in order to disclaim the liability for the signature. This is known as repudiation. See
13Annex D.5.2.3 for more on repudiation and ways to address it.
1412.2 DL/ECSSA
15DL/ECSSA is Discrete Logarithm and Elliptic Curve Signature Scheme with Appendix.
17
18 Figure 5 — DL/ECSSA signature generation and verification operations
2 110
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
3The following options shall be established or otherwise agreed upon between the parties to the scheme (the
4signer and the verifier):
5
6 the signature and verification primitives, which shall be one of the following pair of primitives:
7 — the pair DLSP-NR and DLVP-NR, the pair DLSP-DSA and DLVP-DSA, the pair ECSP-NR
8 and ECVP-NR, or the pair ECSP-DSA and ECVP-DSA
9 the message encoding method for signatures with appendix, which should be EMSA1 (Clause
10 12.1.1), or a technique designated for use with DL/ECSSA (and the selected signature primitive) in
11 an addendum to this standard.
12The above information may remain the same for any number of executions of the signature scheme, or it
13may be changed at some frequency. The information need not be kept secret.
15A signature (c, d) shall be generated by a signer from a message M by the following or an equivalent
16sequence of steps:
17 o) Select a valid private key s and its associate set of domain parameters for the operation.If the
18 selected signature primitive is DLSP-NR or ECSP-NR, then set the maximum length of the
19 message representative to be l = (length of r in bits) – 1, where r is the order of the base point in the
20 DL or EC set of domain parameters.If the selected signature primitive is DLSP-DSA or ECSP-
21 DSA, then set the maximum length of the message representative to be l = length of r in bits.Use
22 the encoding operation of the selected message encoding method (see Clause 10.2.1) to produce a
23 message representative f of maximum length l from the message M (f will be a non-negative
24 integer).Apply the selected signature primitive (see Clause 10.2.1) to the integer f and the private
25 key s to generate the signature (c, d).
26 6. Output the signature.
27Conformance region recommendation. A conformance region should include:
32A signature (c, d) on a message M shall be verified by a verifier by the following or an equivalent sequence
33of steps:
34 p) Obtain the other party’s purported public key w and its associated set of domain parameters for the
35 operation.(Optional.) Validate the public key w and its associated set of domain parameters.
36 Output “invalid” and stop if validation fails.If the selected verification primitive is DLVP-NR or
37 ECVP-NR:
2 111
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 a) Apply the selected verification primitive (see Clause 10.2.1) to the signature (c, d) and the
2 signer’s public key to recover an integer f. If the output of the primitive is “invalid,” output
3 “invalid” and stop.
4 b) Set the maximum length of the message representative to be l = (length of r in bits) – 1, where
5 r is the order of the base point in the DL or EC set of domain parameters.
6 c) Use the verification operation of the selected message encoding method (see Clause 10.2.1) to
7 verify that the integer f is a correct encoded representative of the message M according to the
8 encoding method and maximum length l. If that is the case, output “valid.” Else, output
9 “invalid.”
10 4. If the selected verification primitive is DLVP-DSA or ECVP-DSA:
11 a) Set the maximum length of the message representative to be l = length of r in bits, where r is
12 the order of the base point in the DL or EC set of domain parameters.
13 b) Use the encoding operation of the selected message-encoding method (see 10.2.1) to produce
14 a message representative f of maximum length l from the message M (f will be a non-negative
15 integer).
16 c) Apply the selected verification primitive (see Clause 10.2.1) to the integer f, the signature (c,
17 d), and the signer’s public key to determine whether they are consistent. If the output of the
18 primitive is “invalid,” output “invalid”; otherwise, output “valid.”
19Conformance region recommendation. A conformance region should include:
291—Since message encoding methods for signatures with appendix are usually based on hash functions, the length of a
30message that can be signed by this scheme is usually unrestricted or constrained by a very large number.
312—Because of the way verification is performed when the verification primitive is DLVP-DSA or ECVP-DSA, the
32message encoding method has to be deterministic when one of these primitives is used. Unlike verification using
33DLVP-NR or ECVP-NR, where the message representative is an output of the verification primitive, for DLVP-DSA
34and ECVP-DSA the message representative is one of the inputs to the verification primitive.
353—These schemes, with appropriate restrictions on the scheme options and inputs, may be compatible with techniques
36in ANSI X9.30 [ANS97a] (in the DL case), ANSI X9.62 [ANS98e] (in the EC case) and ISO/IEC 14888-3 [ISO98h].
3712.3 IFSSA
38IFSSA is Integer Factorization Signature Scheme with Appendix.
2 112
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 Figure 6 — IFSSA signature generation and verification operations
3
5The following options shall be established or otherwise agreed upon between the parties to the scheme (the
6signer and the verifier):
7
8 a) The type of key pair for the signer (RSA, RW, or ESIGN)
9 b) The signature and verification primitives, which shall be a pair from the following list:
10 1) If the signer’s public key is an RSA public key, then the primitives shall be either the pair
11 IFSP-RSA1 and IFVP-RSA1, or the pair IFSP-RSA2 and IFVP-RSA2
12 2) If the signer’s public key is an RW public key, then the primitives shall be the pair IFSP-RW
13 and IFVP-RW.
14 3) If the signer’s public key is an ESIGN public key, then the primitives shall be the pair IFSP-
15 ESIGN and IFVP-ESIGN.
16 c) The message-encoding method for signatures with appendix, which should be one of the
17 following:
18 1) If the signature primitive is IFSP-RSA1, then the message-encoding method should be
19 EMSA2 (see 12.1.2), EMSA3 (see 12.1.3), EMSA4 (see 12.1.4), or a technique designated for
20 use with IFSSA and this signature primitive in an amendment to this standard.
21 2) If the signature primitive is IFSP-RSA2 or IFSP-RW, then the message-encoding method
22 should be EMSA2, EMSA4 or a technique designated for use with IFSSA and this signature
23 primitive in an amendment to this standard (where the message-encoding method shall always
24 produce a message representative congruent to 12 modulo 16).
25 3) If the signature primitive is IFSP-ESIGN, then the message-encoding method should be
26 EMSA4, EMSA5 or a technique designated for use with IFSSA and this signature primitive in
27 an amendment to this standard.
28NOTE—EMSA2 requires that the message representative length, i.e., (length of n in bits) – 1 for RSA or RW, be
29congruent to 7 mod 8.
30The above information may remain the same for any number of executions of the signature scheme, or it
31may be changed at some frequency. The information need not be kept secret.
2 113
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2A signature s shall be generated by a signer from a message M by the following or an equivalent sequence
3of steps:
4
5 1. Select a valid private key K for the operation.
6 2. If the selected signature primitive is IFSP-RSA1, IFSP-RSA2 or IFSP-RW, then set the
7 maximum length of the message representative to be l = (length of n in bits) – 1, where n is
8 the modulus in the RSA or RW private key. If the selected signature primitive is IFSP-
9 ESIGN, then set the maximum length to be l = k – 1, where k is from the ESIGN private key.
10 3. Use the encoding operation of the selected message-encoding method (see 10.3.1) to produce
11 a message representative f of maximum length l from the message M (f will be a non-negative
12 integer). If the selected encoding method is EMSA2 or EMSA4, f will be congruent to 12
13 modulo 16.
14 4. Apply the selected signature primitive (see 10.3.1) to the integer f and the selected private key
15 K to generate the signature s.
16 5. Output the signature.
17Conformance region recommendation: A conformance region should include:
21A signature s on a message M shall be verified by a verifier by the following or an equivalent sequence of
22steps:
23
24 1. Obtain the signer’s purported public key.
25 2. (Optional) Validate the public key. Output “invalid” and stop if validation fails.
26 3. Apply the selected verification primitive (see 10.3.1) to the signature s and the signer’s public
27 key to recover an integer f. If the output of the primitive is “invalid,” output “invalid” and
28 stop.
29 4. If the selected verification primitive is IFVP-RSA1, IFVP-RSA2 or IFVP-RW, then set the
30 maximum length of the message representative to be l = (length of n in bits) – 1, where n is
31 the modulus in the RSA or RW public key. If the selected verification primitive is IFVP-
32 ESIGN, then set the maximum length to be l = k – 1, where k is from the ESIGN public key.
33 5. Verify that the integer f is a correct encoded representative of the message M using the
34 verification operation of the selected message-encoding method (see 10.3.1) and maximum
35 length l. If that is the case, output “valid.” Else, output “invalid.”
36Conformance region recommendation: A conformance region should include:
37 At least one valid public key; if key validation is performed, invalid public keys that are
38 appropriately rejected by the implementation may also be included in the conformance region.
39 All messages M that can be input to the implementation
40 All purported signatures s that can be input to the implementation; this should at least include all s
41 in the range [0, n – 1] for IFVP-RSA1 and IFVP-ESIGN or [0, (n – 1)/2] for IFVP-RSA2 and
42 IFVP-RW.
43NOTES
2 114
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
11—The upper bound on the length in bits of the message representative is so that the message representative is less than
2the modulus n, as required by the RSA and RW signature primitives, or so that it is less than 2 k1, as required by the
3ESIGN signature primitive. Since message-encoding methods for signatures with appendix are usually based on hash
4functions, the length of a message that can be signed by this scheme is usually unrestricted or constrained by a very
5large number.
62—This scheme, with appropriate restrictions on the scheme options and inputs, may be compatible with techniques in
7ANSI X9.31-1998 [B7], ISO/IEC 14888-3:1998 [B80], and PKCS #1 v2.1 [PKCS1v2_1].
812.4 DL/ECSSR
9DL/ECSSR is Discrete Logarithm and Elliptic Curve Signature Scheme with Recovery.
11
12 Figure 7 — DL/ECSSR signature generation and verification operations
14The following options shall be established or otherwise agreed upon between the parties to the scheme (the
15signer and the verifier):
16
17 a) The pre-signature, signature and verification primitives, which shall be one of the following
18 triples of primitives:
19 1) DLPSP-NR2/PV, DLSP-NR2 and DLVP-NR2
20 2) ECPSP-NR2/PV, ECSP-NR2 and ECVP-NR2
2 115
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 b) The message-encoding method for signatures giving message recovery, which should be
2 EMSR1 (see 12.3.1), or a technique designated for use with DL/ECSSR in an amendment to this
3 standard
4The above information may remain the same for any number of executions of the signature scheme, or it
5may be changed at some frequency. The information need not be kept secret.
7A signature (c, d) shall be generated by a signer from a recoverable message part M1 and a (possibly empty)
8non-recoverable message part M2 by the following or an equivalent sequence of steps:
9
10 1.Select a valid private key s and its associated set of domain parameters for the operation.
11 2.Apply the selected pre-signature primitive (see 10.4.1) to generate a randomizer u and a pre-
12 signature i. Convert the pre-signature i to a bit string I of length log2 q bits using I2BSP.
13 3. Set the maximum length of the message representative to be l = (length of r in bits) – 1, where
14 r is the order of the base point in the DL or EC set of domain parameters.
15 4. Use the encoding operation of the selected message-encoding method (see 10.4.1) to produce
16 a message representative f of maximum length l (f will be a non-negative integer) from the
17 recoverable message part M1, the non-recoverable message part M2, and the bit string I.
18 5. Apply the selected signature primitive (see 10.4.1) to the integer f, the private key s, the
19 randomizer u and the pre-signature i to generate the signature (c, d). If the signature primitive
20 outputs “error,” then go to step 2.
21 6. Output the signature and optionally the length of the recoverable message part M1.
22Conformance region recommendation: A conformance region should include:
36A signature (c, d) shall be verified and the recoverable message part M1 recovered by a verifier, given a
37(possibly empty) non-recoverable message part M2 and optionally the length of the recoverable message
38part, by the following or an equivalent sequence of steps:
39
40 1. Obtain the signer’s purported public key w and its associated set of domain parameters for the
41 operation.
42 2. (Optional) Validate the public key w and its associated set of domain parameters. Output
43 “invalid” and stop if validation fails.
2 116
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 3. Apply the selected verification primitive (see 10.4.1) to the signature (c, d) and the signer’s
2 public key to recover a message representative f and a pre-signature i (both will be non-
3 negative integers). If the output of the primitive is “invalid,” output “invalid” and stop.
4 Convert the pre-signature i to a bit string I of length log2 q bits using I2BSP.
5 4. Set the maximum length of the message representative to be l = (length of r in bits) – 1, where
6 r is the order of the base point in the DL or EC set of domain parameters.
7 5. Use the decoding operation of the selected message-encoding method (see 10.4.1) to verify
8 that the integer f is a correct encoded representative according to the encoding method and
9 maximum length l, and to recover the recoverable message part M1 given the (possibly empty)
10 non-recoverable message part M2, optionally the length of the recoverable message part, and
11 the bit string I. If the output of the decoding operation is “invalid,” output “invalid.”
12 Otherwise, output the recoverable message part M1.
13Conformance region recommendation: A conformance region should include:
261—Since the recommended message-encoding method is based on a hash function, the length of the non-recoverable
27message part that can be signed by this scheme is either unrestricted or constrained by a very large number. However,
28the length of the recoverable message part is limited.
292—These schemes, with appropriate restrictions on the scheme options and inputs, may be compatible with techniques
30in ISO/IEC 9796-3:2000 [B79].
313—The length of the recoverable message part must be known in advance to the verifier in this scheme if the encoding
32method is EMSR1.
3312.5 DL/ECSSR-PV
34DL/ECSSR-PV is Discrete Logarithm and Elliptic Curve Signature Scheme with Recovery, Pintsov-
35Vanstone version.
2 117
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 Figure 8 — DL/ECSSR-PV signature generation and verification operations
4The following options shall be established or otherwise agreed upon between the parties to the scheme (the
5signer and the verifier):
6
7 a) The pre-signature, signature and verification primitives, which shall be one of the following
8 triples of primitives:
9 1) DLPSP-NR2/PV, DLSP-PV and DLVP-PV
10 2) ECPSP-NR2/PV, ECSP-PV and ECVP-PV
11 b) The message-encoding method for signatures giving message recovery, which should be
12 EMSR2 (see 12.3.2) (including the encoding parameter padLen, which is an integer between 1 and
13 255 giving the amount of added redundancy in octets, and including other parameters of EMSR2),
14 or a technique designated for use with DL/ECSSR-PV in an amendment to this standard
15 c) The redundancy criteria necessary for acceptance of the message after it has been recovered
16 and successfully decoded (see D.5.2.2)
17 d) The hash function Hash, which shall be one of the hash functions in 14.1 or a technique
18 designated for use with DL/ECSSR-PV in an amendment to this standard
19The above information may remain the same for any number of executions of the signature scheme, or it
20may be changed at some frequency. The information need not be kept secret.
22A signature (C, d) shall be generated by a signer from a recoverable message part M1 and a (possibly
23empty) non-recoverable message part M2 by the following or an equivalent sequence of steps:
2 118
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 1. Verify that the message (consisting of the recoverable message part M1 and the non-
3 recoverable message part M2) meets the agreed redundancy criteria. If it does not, output
4 “error.”
5 2. Select a valid private key s and its associated set of domain parameters for the operation.
6 3. Apply the selected pre-signature primitive (see 10.5.1) to generate a randomizer u and a pre-
7 signature i. Convert the pre-signature i to an octet string I of length log256 q octets using
8 I2OSP.
9 4. Use the encoding operation of the selected message-encoding method (see 10.5.1) to produce
10 a message representative C from the recoverable message part M1 and the octet string I.
11 5. Apply the selected hash function (see 10.5.1) to the message representative C and the non-
12 recoverable message part M2 to generate a hash value H as H = Hash (C || M2).
13 6. Convert the hash value H to an integer h with the primitive OS2IP.
14 7. Apply the selected signature primitive (see 10.5.1) to the hash value h, the private key s, and
15 the randomizer u to generate a signature part d.
16 8. Output (C, d) as the signature.
17Conformance region recommendation: A conformance region should include:
25A signature (C, d) shall be verified and the recoverable message M1 recovered by a verifier, given a
26(possibly empty) non-recoverable message part M2, by the following or an equivalent sequence of steps:
27
28 1. Obtain the signer’s purported public key w and its associated set of domain parameters for
29 the operation.
30 2. (Optional) Validate the public key w and its associated set of domain parameters. Output
31 “invalid” and stop if validation fails.
32 3. Apply the selected hash function (see 10.5.1) to the message representative C and the non-
33 recoverable message part M2 to generate a hash value H as H = Hash (C || M2).
34 4. Convert the hash value H to an integer h with the primitive OS2IP.
35 5. Apply the selected verification primitive (see 10.5.1) to the signature part d, the integer h and
36 the signer’s public key w to recover a pre-signature i. Convert the pre-signature i to an octet
37 string I of length log256 q octets using I2OSP.
38 6. Use the decoding operation of the selected message-encoding method (see 10.6.1) to verify
39 that the message representative C is a correctly encoded representative according to the
40 encoding method, and to recover the recoverable message part M1, given the octet string I. If
41 the output of the decoding operation is “invalid,” output “invalid.”
42 7. Verify that the message (consisting of the recoverable message part M1 and the non-
43 recoverable message part M2) meets the agreed redundancy criteria. If it does not, output
44 “invalid.” Otherwise, output the recoverable message part M1.
45Conformance region recommendation: A conformance region should include:
2 119
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 At least one valid public key w for each set of domain parameters; if key validation is performed,
2 invalid public keys w that are appropriately rejected by the implementation may also be included
3 in the conformance region
4 All non-recoverable message parts M2 that can be input to the implementation (which may include
5 only the empty string, i.e., conformance may be claimed for total message recovery only)
6 All purported signatures (C, d) that can be input to the implementation and that correspond to some
7 range of recoverable message parts (for instance, where the range of recoverable message parts
8 may exclude the empty string); this should at least include all (C, d) that correspond to the range of
9 recoverable messages such that d is in the range [0, r – 1], where r is from the domain parameters
10 of w
11NOTES
121—The lengths of both the recoverable message part and the non-recoverable message part that can be signed by this
13scheme are unrestricted or constrained by a very large number.
142—If the encoding method is EMSR2, the agreed redundancy criteria should ensure that no recoverable message part
15that meets the agreed redundancy criteria is a prefix of another recoverable message part that meets the agreed
16redundancy criteria, or comparable provisions should be made to address the possibility of ambiguity in the encoding C
17|| M2 in the input to the hash function (see D.5.2.2.2 Note 4).
183—These schemes, with appropriate restrictions on the scheme options and inputs, may be compatible with techniques
19in ISO/IEC 15946-4 [ISO-15946-4].
204—The length of the recoverable message part does not need to be known in advance to the verifier in this scheme if
21the encoding method is EMSR2.
2 120
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
4
5 Figure 9 — IFSSR signature generation and verification operations
7The following options shall be established or otherwise agreed upon between the parties to the scheme (the
8signer and the verifier):
9
10 a) The type of key pair for the signer (RSA or RW)
11 b) The signature and verification primitives, which shall be a pair from the following list:
12 1) If the signer’s public key is an RSA public key, then the primitives shall be either the pair
13 IFSP-RSA1 and IFVP-RSA1, or the pair IFSP-RSA2 and IFVP-RSA2.
14 2) If the signer’s public key is an RW public key, then the primitives shall be the pair IFSP-RW
15 and IFVP-RW.
16 c) The message-encoding method for signatures giving message recovery, which should be
17 EMSR3 (see 12.3.4), or a technique designated for use with IFSSR in an amendment to this
18 standard (if the signature primitive is IFSP-RSA2 or IFSP-RW, the message-encoding method shall
19 always produce message representatives congruent to 12 modulo 16)
20The above information may remain the same for any number of executions of the signature scheme, or it
21may be changed at some frequency. The information can be shared among a number of parties.
22NOTE—EMSR3 produces message representatives congruent to 12 modulo 16 and is therefore appropriate for use
23with IFSP-RSA2 and IFSP-RW as well as IFSP-RSA1. For EMSR3, the recoverable part of the message is treated as a
24bit string.
2 121
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2A signature s shall be generated by a signer from a recoverable message part M1 and a (possibly empty)
3non-recoverable message part M2 by the following or an equivalent sequence of steps:
4
5 1. Select a valid private key K for the operation.
6 2. Set the maximum length of the message representative to be l = (length of n in bits) – 1,
7 where n is the modulus in the IF private key.
8 3. Use the encoding operation of the selected message-encoding method (see 10.6.1) to produce
9 a message representative f of maximum length l (f will be a non-negative integer) from the
10 recoverable message part M1 and the non-recoverable message part M2. If the selected
11 signature primitive is IFSP-RSA2 or IFSP-RW, f will be congruent to 12 modulo 16.
12 4. Apply the selected signature primitive (see 10.6.1) to the integer f and the selected private key
13 K to generate the signature s.
14 5. Output the signature.
15Conformance region recommendation: A conformance region should include:
23A signature s shall be verified and the recoverable message part M1 recovered by a verifier, given a
24(possibly empty) non-recoverable message part M2, by the following or an equivalent sequence of steps:
25
26 1. Obtain the signer’s purported public key (n, e).
27 2. (Optional) Validate the public key (n, e). Output “invalid” and stop if validation fails.
28 3. Apply the selected verification primitive (see 10.6.1) to the signature s and the signer’s public
29 key to recover an integer f. If the output of the primitive is “invalid,” output “invalid” and
30 stop.
31 4. Set the maximum length of the message representative to be l = (length of n in bits) – 1.
32 5. Use the decoding operation of the selected message-encoding method (see 10.6.1) to verify
33 that the integer f is a correct encoded representative according to the encoding method and
34 maximum length l, and to recover the recoverable message part M1 given the (possibly empty)
35 non-recoverable message part M2. If the output of the decoding operation is “invalid,” output
36 “invalid.” Otherwise, output the recoverable message part M1.
37Conformance region recommendation: A conformance region should include:
38 At least one valid public key (n, e); if key validation is performed, invalid public keys (n, e) that are
39 appropriately rejected by the implementation may also be included in the conformance region
40 All non-recoverable message parts M2 that can be input to the implementation (which may include
41 only the empty string, i.e., conformance may be claimed for total message recovery only)
42 All purported signatures s that can be input to the implementation and that correspond to some
43 range of recoverable message parts (for instance, where the range of recoverable message parts
44 may include octet strings only); this should at least include all s in the range [0, n – 1] for IFVP-
2 122
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 RSA1 or [0, (n – 1)/2] for IFVP-RSA2 and IFVP-RW that correspond to the range of recoverable
2 messages
3NOTES
41—Since the recommended message-encoding method is based on a hash function, the length of the non-recoverable
5message part that can be signed by this scheme is either unrestricted or constrained by a very large number. However,
6the length of the recoverable message part is limited.
72—This scheme, with appropriate restrictions on the scheme options and inputs, is compatible with techniques being
8considered in the draft revision to ISO 9796-2 [ISO-9796-2-revision].
93—The length of the recoverable message part does not need to be known in advance to the verifier in this scheme.
10
2 123
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
14Different message-encoding methods are needed for different categories of schemes. The use of an
15inadequate encoding method may compromise the security of the scheme in which it is used. This standard
16strongly recommends the use of the encoding methods contained in this clause, or any encoding methods
17defined in an addendum to this standard.
18Other encoding methods are allowed within the framework of the schemes. As an example, an
19implementation may select an encoding method similar to one of those defined here, but based on a
20different underlying hash function or symmetric encryption scheme. Such an implementation may still
21claim conformance with the scheme (see Annex B), but with respect to the selected encoding method. The
22selection of encoding methods not recommended here requires further security analysis by the
23implementer.
2813.1.1 EMSA1
29EMSA1 is an encoding method for signatures with appendix based on a hash function. It is recommended
30for use with DLSSA and ECSSA (Clause 10.2).
32
33 A hash function Hash with output length hLen octets, which shall be one of the hash functions in
34 14.1 or a technique designated for use with EMSA1 in an amendment to this standard
35NOTES
2 124
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
12—EMSA1 is amenable to “single-pass” processing in the typical case that the signature is transmitted after the
2message, since the message M can be processed by the verification operation before the signature is available.
4Input:
5 A message, which is an octet string M (depending on the hash function chosen, there may be a
6 length limitation)
7 the maximum bit length l of the output
8Output: a message representative, which is an integer f 0 of bit length at most min(l, 8hLen); or “error”
9The message representative f shall be computed by the following or an equivalent sequence of steps:
10 q) If the length of M is greater than the input length limitation for the selected hash function, output
11 “error” and stop.Compute Hash (M) with the selected hash function to produce an octet string H of
12 length hLen octets.If l < 8hLen, convert H to a bit-string HB of length 8hLen bits with the primitive
13 OS2BSP. Remove 8hLen – l rightmost bits of HB, and then convert the remaining l bits to an
14 integer f using the primitive BS2IP.Else convert H to an integer f using OS2IP.Output f as the
15 message representative.
17Input:
18 A message, which is an octet string M (depending on the hash function chosen, there may be a
19 length limitation)
20 the maximum bit length l of the message representative
21 the message representative, which is an integer f 0
22Output: “valid” if f is a correct representative of M; “invalid” otherwise.
23The validity indicator shall be computed by the following or an equivalent sequence of steps:
2813.1.2 EMSA2
29EMSA2 is an encoding method for signatures with appendix based on a hash function with some additional
30formatting, based on ANSI X9.31 [ANS98a]. It is recommended for use with IFSSA (Clause 10.3).
32
33 A hash function Hash with output length hLen octets, which shall be one of the hash functions in
34 14.1 or a technique designated for use with EMSA2 in an amendment to this standard
2 125
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The encoding method uses a hash function identifier, HashID, which is a single octet. The values of
2HashID for the hash functions in 14.1 are given in the table below. (See Note 3 below for an explanation of
3how the identifiers were assigned.)
4
Hash Function HashID
SHA-1 (14.1.1) 33
RIPEMD-160 (14.1.2) 31
SHA-256 (14.1.3) 34
SHA-384 (14.1.4) 36
SHA-512 (14.1.5) 35
5NOTES
72—EMSA2 is amenable to “single-pass” processing in the typical case that the signature is transmitted after the
8message, since the message M can be processed by the verification operation before the signature is available.
93—HashID corresponds to the part of ISO/IEC 10118 in which the hash function is defined and the algorithm number
10within that part. For instance, RIPEMD-160 is defined in ISO/IEC 10118-3:1998 [ISO-10118-3] and is hash function 1
11within that part, so its hash function identifier is hexadecimal 31. The hash function identifiers for SHA-256, SHA-384
12and SHA-512 were taken from a final revised draft of that document.
134—EMSA2 has a similar construction to that for signatures giving message recovery in ISO/IEC 9796-2:1997, in the
14common case that the length of the message representative is congruent to 7 mod 8 and the hash output is an octet
15string. In other cases, a more general construction based on ISO/IEC 9796-2:1997 may be appropriate.
17Input:
18 A message, which is an octet string M (depending on the hash function chosen, there may be a
19 length limitation)
20 The maximum bit length l of the message representative (l shall be at least 8hLen + 31 and shall be
21 congruent to 7 mod 8)
22Output: A message representative, which is an integer f 0 of bit length at most l; or “error”
23The message representative f shall be computed by the following or an equivalent sequence of steps:
24
25 1. If the length of M is greater than the input length limitation for the selected hash function, or l
26 < 8hLen + 31, or l + 1 is not divisible by 8, output “error” and stop.
27 2. Compute Hash (M) with the selected hash function to produce an octet string H of length
28 hLen octets.
29 3. If M is of length 0 (i.e., an empty string), let P1 be a single octet with hexadecimal value 4b.
30 Otherwise let P1 be a single octet with hexadecimal value 6b.
2 126
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 4. Let P2 be an octet string of length (l + 1) / 8 – hLen – 4 octets, each with hexadecimal value
2 bb.
3 5. Let P3 be a single octet with value HashID (see the table above).
4 6. Let T = P1 || P2 || ba || H || P3 || cc, where ba and cc are single octets represented in
5 hexadecimal.
6 7. Convert T to an integer f using OS2IP.
7 8. Output f as the message representative.
9Input:
10 A message, which is an octet string M (depending on the hash function chosen, there may be a
11 length limitation)
12 The maximum bit length l of the message representative (l shall be at least 8hLen + 31 and shall be
13 congruent to 7 mod 8)
14 The message representative, which is an integer f 0
15Output: “Valid” if f is a correct representative of M; “invalid” otherwise
16The validity indicator shall be computed by the following or an equivalent sequence of steps:
17
18 1. If the length of M is greater than the input length limitation for the selected hash function, or l
19 < 8hLen + 31 or l + 1 is not divisible by 8, output “invalid” and stop.
20 2. Convert f to an octet string T of length (l + 1) / 8 octets using the primitive I2OSP.
21 3. If M is of length 0 (i.e., an empty string), let P1 be a single octet with hexadecimal value 4b.
22 Otherwise let P1 be a single octet with hexadecimal value 6b.
23 4. Verify that the leftmost octet of T is equal to P1, the next (l + 1) / 8 – hLen – 4 octets each
24 have hexadecimal value bb, and the next octet after that has hexadecimal value ba. If not,
25 output “invalid” and stop.
26 5. Verify that the second rightmost octet has value HashID (see the table above). If not, output
27 “invalid” and stop.
28 6. Verify that the rightmost octet has hexadecimal value cc. If not, output “invalid” and stop.
29 7. Remove the leftmost (l + 1) / 8 – 22 octets of T and the rightmost 2 octets of T to produce an
30 octet string H of length hLen octets.
31 8. Apply the selected hash function to M to produce an octet string H of length hLen octets.
32 9. If H = H output “valid.” Otherwise, output “invalid.”
33NOTE—Since the encoding operation for EMSA3 is deterministic, the verification operation may equivalently be
34implemented by applying the encoding operation again to the message and comparing its output to the message
35representative.
3613.1.3 EMSA3
37EMSA3 is an encoding method for signatures with appendix based on a hash function with some additional
38formatting, based on PKCS #1 v1.5 [B126] (see also Kaliski and Staddon [KS98] and PKCS #1 v2.1
39[PKCS1v2_1]). It is recommended for use with IFSSA (see 10.3).
41 A hash function Hash without output length hLen octets, which shall be one of the hash functions
42 in 14.1 or a technique designated for use with EMSA3 in an amendment to this standard
2 127
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The encoding method uses a hash function identifier, HashID, which is an octet string. The values of
2HashID for the hash functions in 14.1 are given in the table below. (See Note 3 below for an explanation of
3how the identifiers were assigned.)
SHA-1 (14.1.1) 30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14
RIPEMD-160 (14.1.2) 30 21 30 09 06 05 2b 24 03 02 01 05 00 04 14
SHA-256 (14.1.3) 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
SHA-384 (14.1.4) 30 41 30 0d 06 09 60 86 48 01 65 03 04 02 02 05 00 04 30
SHA-512 (14.1.5) 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
5NOTES
72—EMSA3 is amenable to “single-pass” processing in the typical case that the signature is transmitted after the
8message, since the message M can be processed by the verification operation before the signature is available.
93—HashID corresponds to the portion of the DER encoding an ASN.1 value of type DigestInfo (see PKCS #1 v1.5
10[B126]) that precedes the hash value itself. The type DigestInfo is defined as
14HashID thus consists of the tag and length fields for the SEQUENCE, the encoding of the AlgorithmIdentifier
15component (see ITU-T Recommendation X.509 [B82]), and the tag and length fields of the encoding of the digest
16component. If a hash function has a fixed-length output, the HashID value will be the same for all hash values for that
17hash function and can thus be considered a constant value, as is the case in the table above.
19Input:
20 A message, which is an octet string M (depending on the hash function chosen, there may be a
21 length limitation)
22 The maximum bit length l of the message representative (l shall be at least 8hashIDLen + 8hLen +
23 80)
24Output: A message representative, which is an integer f 0 of bit length at most l; or “error”
25The message representative f shall be computed by the following or an equivalent sequence of steps:
26
27 1. If the length of M is greater than the input length limitation for the selected hash function,
28 output “error” and stop.
2 128
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 2. Let HashID be the identifier for the hash function (see the table above) and let hashIDLen be
2 the length in octets of HashID.
3 3. Let oLen = l/8. If oLen < hashIDLen + hLen + 10, output “error” and stop.
4 4. Compute Hash (M) with the selected hash function to produce an octet string H of length
5 hLen octets.
6 5. Let P be an octet string of length oLen – hashIDLen – hLen – 2 octets, each with hexadecimal
7 value ff. The length of P will be at least 8 octets.
8 6. Let T = 01 || P || 00 || HashID || H, where 01 and 00 are single octets represented in
9 hexadecimal.
10 7. Convert T to an integer f using OS2IP.
11 8. Output f as the message representative.
13Input:
14 A message, which is an octet string M (depending on the hash function chosen, there may be a
15 length limitation)
16 The maximum bit length l of the message representative (l shall be at least 8hashIDLen + 8hLen +
17 80)
18 The message representative, which is an integer f 0
19Output: “Valid” if f is a correct representative of M; “invalid” otherwise
20The validity indicator shall be computed by the following or an equivalent sequence of steps:
21
22 1. If the length of M is greater than the input length limitation for the selected hash function,
23 output “invalid” and stop.
24 2. Let HashID be the identifier for the hash function (see the table above) and let hashIDLen be
25 the length in octets of HashID.
26 3. Let oLen = l/8. If oLen < hashIDLen + hLen + 10, output “invalid” and stop.
27 4. Convert f to an octet string T of length oLen octets using the primitive I2OSP. If the primitive
28 outputs “error,” output “invalid” and stop.
29 5. Verify that the leftmost octet of T is equal to 01, the next oLen – hashIDLen – hLen – 2 octets
30 each have hexadecimal value ff, the next octet after that has hexadecimal value 00, and the
31 next hashIDLen octets match HashID. If not, output “invalid” and stop.
32 6. Let H be the rightmost hLen octets of T.
33 7. Apply the selected hash function to M to produce an octet string H of length hLen octets.
34 8. If H = H output “valid.” Otherwise, output “invalid.”
35NOTE—Since the encoding operation for EMSA3 is deterministic, the verification operation may equivalently be
36implemented by applying the encoding operation again to the message and comparing its output to the message
37representative.
3813.1.4 EMSA4
39EMSA4 is an encoding method for signatures with appendix based on a hash function and a mask
40generation function, based on the Probabilistic Signature Scheme (PSS) (see Bellare and Rogaway [B19]).
41In one mode of operation, it is similar to Full-Domain Hashing (see Bellare and Rogaway [BR93]). It is
42recommended for use with IFSSA (see 10.3).
2 129
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 A hash function Hash with output length hLen octets, which shall be one of the hash functions in
2 14.1 or a technique designated for use with EMSA4 in an amendment to this standard
3 A mask generation function G, which shall be MGF1 (see 14.2.1) with the same underlying hash
4 function Hash, or a technique designated for use with EMSA4 in an amendment to this standard
5 An indication as to whether hash function identification is desired
6 A salt length in bits saltBits, a nonnegative integer; typical values are 8hLen and 0 (in which case
7 the signature scheme is deterministic, similar to Full-Domain Hashing)
8NOTES
102—EMSA4 is amenable to “single-pass” processing in the typical case that the signature is transmitted after the
11message, since the message M can be processed by the verification operation before the signature is available.
123—EMSA4 is a special case of EMSR3 where the recoverable part of the message is the empty string.
14Input:
15 A message, which is an octet string M (depending on the hash function chosen, there may be a
16 length limitation)
17 The maximum bit length l of the message representative (l shall be at least 8hLen + saltBits + 8u +
18 1, where u = 2 if hash function identification is desired and u = 1 if not)
19Output: A message representative, which is an integer f 0 of bit length at most l where f 12 (mod 16);
20or “error”
21The message representative f shall be computed by the following or an equivalent sequence of steps:
22
23 1. Apply the EMSR3 encoding operation with the selected hash function, mask generation
24 function, and salt length, and the indication as to whether hash function identification is
25 desired, where the recoverable message part is the empty string, the non-recoverable message
26 part is M, and the maximum bit length of the message representative is l to compute a
27 message representative f.
28 2. Output f as the message representative.
30Input:
31 A message, which is an octet string M (depending on the hash function chosen, there may be a
32 length limitation)
33 The maximum bit length l of the message representative (l shall be at least 8hLen + saltBits + 8u +
34 1, where u = 2 if hash function identification is desired and u = 1 if not)
35 The message representative, which is an integer f 0
36Output: “Valid” if f is a correct representative of M; “invalid” otherwise
37The validity indicator shall be computed by the following or an equivalent sequence of steps:
2 130
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 1. Apply the EMSR3 decoding operation with the selected hash function, mask generation
3 function, and salt length, and the indication as to whether hash function identification is
4 desired, where the non-recoverable message part is M, the maximum bit length of the message
5 representative is l, and the message representative is f to recover a recoverable message part
6 M1. If the decoding operation outputs “invalid,” output “invalid” and stop.
7 2. If M1 is the empty string, output “valid.” Otherwise, output “invalid.”
813.1.5 EMSA5
9EMSA5 is an encoding method for signatures with appendix based on a hash function and a mask
10generation function, based on the method in TSH-ESIGN (see Fujisaki and Okamoto [FO98]). It is
11recommended for use with IFSSA (see 10.6).
13 A hash function Hash with output length hBits bits, which shall be one of the hash functions in 14.1
14 or a technique designated for use with EMSA5 in an amendment to this standard
15 A mask generation function G, which shall be MGF1 (see 14.2.1) with the same underlying hash
16 function Hash, or a technique designated for use with EMSA5 in an amendment to this standard
17NOTES
192—EMSA5 is amenable to “single-pass” processing in the typical case that the signature is transmitted after the
20message, since the message M can be processed by the verification operation before the signature is available.
22Input:
23 A message, which is an octet string M (depending on the hash function chosen, there may be a
24 length limitation)
25 The maximum bit length l of the message representative
26Output: A message representative, which is an integer f 0; or “error”
27The message representative f shall be computed by the following or an equivalent sequence of steps:
28
29 1. If the length of M is greater than the input length limitation for the selected hash function,
30 output “error” and stop.
31 2. Let oLen = l / 8 and let t = 8oLen – l. (Note that t will be between 0 and 7.)
32 3. Compute H = Hash (M) with the selected hash function to produce an octet string H of length
33 hLen octets.
34 4. Apply the mask generation function G to the string H to produce an octet string T of length
35 oLen octets.
36 5. Set the leftmost t bits of T to zero.
37 6. Convert T to an integer f with the primitive OS2IP.
38 7. Output f as the message representative.
2 131
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2Input:
3 A message, which is an octet string M (depending on the hash function chosen, there may be a
4 length limitation)
5 The maximum bit length l of the message representative
6 The message representative, which is an integer f 0 of bit length at most l
7Output: “Valid” if f is a correct representative of M; “invalid” otherwise
8The validity indicator shall be computed by the following or an equivalent sequence of steps:
9
10 1. Use the Encoding Operation of EMSA5 to compute a message representative g, a non-
11 negative integer. If the encoding operation outputs “error,” output “invalid” and stop.
12 2. If f = g, output “valid.” Else, output “invalid.”
1713.2.1 EME1
18EME1 is an encoding method for encryption based on the “enhanced OAEP (Optimal Asymmetric
19Encryption Padding)” ([BR95], [JM96]), a hash function (Clause 14.1) and a mask generation function
20(Clause 14.2). It is recommended for use with IFES (Clause 11.2). It can produce message representatives
21of arbitrary length l; however, there are restrictions on the length of the message it can encode that depend
22on l.
24 A hash function Hash with output length hLen octets, which shall be one of the hash functions in
25 14.1 or a technique designated for use with EME1 in an amendment to this standard
26 A mask generation function G, which shall be MGF1, or a technique designated for use with EME1
27 in an amendment to this standard
28NOTE—EME1 can handle messages of length up to (l/8) 2hLen 1 octets where l is the maximum length of the
29message representative.
31Input:
32 The maximum bit length l of the message representative (l shall be at least 16hLen + 8)
33 A message, which is an octet string M of length mLen (l/8) 2hLen 1 octets
2 132
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 Encoding parameters, which is an octet string P (P may be an empty string); see D.5.3.3 for
2 possible uses (depending on the hash function chosen, there may be a length limitation)
3Output: a message representative, which is an integer f 0 of bit length at most l, or “error”
4The message representative f shall be computed by the following or an equivalent sequence of steps:
5 s) If the length of P is greater than the input length limitation for the selected hash function, output
6 “error” and stop.Let oLen = l/8 and seedLen = hLen. If mLen > oLen – hLen – seedLen – 1 then
7 output “error” and stop.Let S be the octet string that consists of oLen – mLen – hLen – seedLen – 1
8 zero octets. Let T be the octet string consisting of a single octet with hexadecimal value 01.Let M
9 = S || T || M.Apply the hash function Hash to the parameters P to produce an octet string cHash of
10 length hLen.Let DB = cHash || M. The length of DB is oLen – seedLen octets.Generate a fresh,
11 random octet string seed of length seedLen octets (for more on generation of random strings, see
12 Annex D.6).Apply the mask generation function G to the string seed to produce an octet string
13 dbMask of length oLen – seedLen octets.Let maskedDB = DB dbMask.Apply the mask
14 generation function G to the string maskedDB to produce an octet string seedMask of length
15 seedLen octets.Let maskedSeed = seed seedMask.Let EM = maskedSeed || maskedDB.Convert
16 EM to an integer f with the primitive OS2IP.
17 14. Output f as the message representative.
18NOTE—Step 5 may be precomputed, if P is known in advance.
20Input:
21 The maximum bit length l of the message representative (l shall be at least 16hLen + 8)
22 The message representative, which is an integer f 0
23 Encoding parameters, which is an octet string P (P may be an empty string); see D.5.3.3 for
24 possible uses (depending on the hash function chosen, there may be a length limitation)
25Output: the message, which is an octet string M; or “error”
27
28 1. If the length of P is greater than the input length limitation for the selected hash function,
29 output “error” and stop.
30 2. Let oLen = l/8 and seedLen = hLen. If oLen < seedLen + hLen + 1, output “error” and stop.
31 3. Apply the hash function Hash to the parameters P to produce an octet string cHash of length
32 hLen.
33 4. Convert f to an octet string EM of length oLen + 1 with the primitive I2OSP. If the primitive
34 outputs “error,” output “error” and stop.
35 5. Let X be the leftmost octet of EM, let maskedSeed be the next seedLen octets, and let
36 maskedDB be the remaining octets.
37 6. Apply the mask generation function G to the string maskedDB to produce an octet string
38 seedMask of length seedLen octets.
39 7. Let seed = maskedSeed seedMask.
40 8. Apply the mask generation function G to the string seed to produce an octet string dbMask of
41 length oLen – seedLen octets.
42 9. Let DB = maskedDB dbMask.
43 10. Let M be all but the first hLen octets of DB.
2 133
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
91—It is important that the implementation output the same error message at the same time in step 12 regardless of the
10cause of error. In particular, an implementation should not reveal whether the error is due to the value X being
11incorrect. Otherwise an opponent will be able to determine whether the most significant octet of an RSA decryption is
12nonzero, which may lead to an attack (see Manger [Man01] and D.5.3.2.1 Note 1 for further discussion).
132—The description of the decoding operation has been modified from that in IEEE Std 1363-2000 to make it clearer
14how to avoid the attack described by Manger [Man01]. This does not affect compatibility; the differences only affect
15when errors are detected. In particular, the error checks involving the message representative (except for the one in step
164, which does not affect security—see Note 3) are all done at step 12. In the previous description the checks were
17distributed through the decoding operation, making it less evident that the same error message should be output at the
18same time in each case.
19As stated in B.1, conformance with may be achieved by implementing either “identical” or “equivalent” steps to those
20specified. An implementation of a scheme that follows the steps specified for EME1 in IEEE Std 1363-2000, yet does
21not reveal information distinguishing which error occurred, may thus claim conformance with EME1 as specified here
22on the basis of “equivalence”.
233—The error in step 4 cannot occur when the EME1 decoding operation follows the IFDP-RSA primitive as specified
24in IFES, since the message representative f output by IFDP-RSA is at most l+1 bits long and the octet string EM is at
25least l+1 bits long.
2713.2.2 EME2
28EME2 is an encoding method for encryption based on the conversion in Fujisaki and Okamoto [FO99b], a
29hash function and a mask generation function. It is recommended for use with IFES-EPOC (see 11.4). It
30can produce message representatives of arbitrary length l; however, there are restrictions on the length of
31the message it can encode that depend on l.
33 A hash function Hash with output length hLen octets, which shall be one of the hash functions in
34 14.1 or a technique designated for use with EME2 in an amendment to this standard
35 A mask generation function G, which shall be MGF1 (see 14.2.1) with the same underlying hash
36 function Hash, or a technique designated for use with EME2 in an amendment to this standard
37 A seed length in octets seedLen, a nonnegative integer; a typical value is hLen
38NOTE—EME2 can handle messages of length up to (l+7)/8 – seedLen – 1 octets where l is the maximum length of
39the message representative.
41Input:
2 134
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 The maximum bit length l of the message representative (l shall be at least 8seedLen + 1); the
2 maximum bit length rBits of the randomized hash value
3 A message, which is an octet string M of length mLen (l+7)/8 – seedLen – 1 octets
4 Encoding parameters, which is an octet string P (P may be an empty string); see D.5.3.3 for
5 possible uses (depending on the hash function chosen, there may be a length limitation)
6Output: A message representative, which is an integer f 0 of bit length at most l, and a randomized hash
7value, which is an integer r 0 of bit length at most 8hLen; or “error”
8The message representative f and randomized hash value r shall be computed by the following or an
9equivalent sequence of steps:
10
11 1. If the length of P plus (l+7)/8 is greater than the input length limitation for the selected hash
12 function, output “error” and stop.
13 2. Let oLen = (l+7)/8. If mLen > oLen – seedLen – 1 then output “error” and stop. Let rLen =
14 rBits / 8 and let t = 8rLen – rBits. (Note that t will be between 0 and 7.)
15 3. Let S be the octet string that consists of oLen – mLen – seedLen – 1 zero octets. Let T be the
16 octet string consisting of a single octet with hexadecimal value 01.
17 4. Let M = S || T || M.
18 5. Generate a fresh, random octet string seed of length seedLen octets (for more on generation of
19 random strings, see D.6).
20 6. Let EM = M || seed.
21 7. Let DB = EM || P.
22 8. Apply the hash function Hash to DB to produce an octet string H of length hLen octets.
23 9. Apply the mask generation function G to the string H to produce an octet string T of length
24 rLen octets.
25 10. Set the leftmost t bits of T to zero.
26 11. Convert EM to an integer f with the primitive OS2IP.
27 12. Convert T to an integer r with the primitive OS2IP.
28 13. Output f as the message representative and r as the randomized hash value.
30Input:
31 The maximum bit length l of the message representative (l shall be at least 8seedLen + 1); the
32 maximum bit length rBits of the randomized hash value
33 The message representative, which is an integer f 0
34 Encoding parameters, which is an octet string P (P may be an empty string); see D.5.3.3 for
35 possible uses (depending on the hash function chosen, there may a length limitation)
36Output: The message, which is an octet string M of length at most l/8 – seedLen – 1 octets, and the
37randomized hash value, which is an integer r 0 of bit length at most 8hLen; or “error”
38The message shall be decoded and the randomized hash value obtained by the following or an equivalent
39sequence of steps:
40
41 1. If the length of P plus l/8 is greater than the input length limitation for the selected hash
42 function, output “error” and stop.
2 135
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 2. Let oLen = l/8. If oLen < seedLen + hLen + 1, output “error” and stop. Let rLen = rBits / 8
2 and let t = 8rLen – rBits. (Note that t will be between 0 and 7.)
3 3. Convert f to an octet string EM of length oLen octets with the primitive I2OSP. If the
4 primitive outputs “error,” output “error” and stop.
5 4. Let M be all but the rightmost seedLen octets of EM.
6 5. Let T be the leftmost nonzero octet of M. If T hexadecimal value 01, output “error” and
7 stop.
8 6. Remove T and all octets to the left of it (which are all zero) from M to produce an octet string
9 M.
10 7. Let DB = EM || P.
11 8. Apply the hash function Hash to DB to produce an octet string H of length hLen octets.
12 9. Apply the mask generation function G to the string H to produce an octet string T of length
13 rLen octets.
14 10. Set the leftmost t bits of T to zero.
15 11. Convert T to an integer r with the primitive OS2IP.
16 12. Output the message M and the randomized hash r.
1713.2.3 EME3
18EME3 is another encoding method for encryption based on the conversion in Fujisaki and Okamoto
19[FO99b], a hash function and a mask generation function. It is recommended for use with IFES-EPOC (see
2011.4). It can produce message representatives of arbitrary length l. In contrast to EME2, the length of the
21message that it can encode is either unrestricted or constrained by a very large number.
23 a) A hash function Hash with output length hLen octets, which shall be one of the hash functions
24 in 14.1 or a technique designated for use with EME3 in an amendment to this standard
25 b) A mask generation function G, which shall be MGF1 (see 14.2.1) with the same underlying
26 hash function Hash, or a technique designated for use with EME3 in an amendment to this standard
27c) The method for combining the seed with the message, which shall be either:
28 1) A stream cipher based on a key derivation function, where the key derivation function shall be
29 KDF2 (see 13.2) or a technique designated for use with EME3 in an amendment to this
30 standard (this method is only recommended for relatively short messages such as symmetric
31 keys—see D.5.3.2.1)
32 2) A key derivation function combined with a symmetric encryption scheme, where the key
33 derivation function shall be KDF2 (see 13.2) or a technique designated for use with EME3 in
34 an amendment to this standard, and the symmetric encryption scheme shall be one of the
35 schemes in 14.3, or a technique designated for use with EME3 in an amendment to this
36 standard
37NOTES
392—EME3 is not amenable to “single-pass” processing since the entire message M must be processed by the hash
40function before the encrypted message C is processed.
413—The encoding method is also implicitly parameterized by any key derivation parameters for the key derivation
42function. As a default the key derivation parameters should be the empty string. Parameters to the symmetric
43encryption scheme (if applicable) such as an initialization vector are local to that scheme.
45Input:
2 136
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 The maximum bit length l of the message representative; the maximum bit length rBits of the
2 randomized hash value
3 A message, which is an octet string M of length mLen octets (depending on the hash function and
4 mask generation function or symmetric encryption scheme chosen, there may be a length
5 limitation)
6 Encoding parameters, which is an octet string P of length pLen octets (P may be an empty string);
7 see D.5.3.3 for possible uses (depending on the hash function chosen, there may be a length
8 limitation)
9Output: A message representative, which is an integer f 0 of bit length at most l, a randomized hash
10value, which is an integer r 0 of bit length at most rBits, and an encrypted message C, which is an octet
11string; or “error”
12The message representative f, randomized hash value r, and encrypted message C shall be computed by the
13following or an equivalent sequence of steps:
14
15 1. If mLen is greater than the output length limitation for the selected key derivation function or
16 the plaintext length limitation for the selected symmetric encryption scheme (whichever is
17 applicable), output “error” and stop.
18 2. Let seedLen = l/8. Let rLen = rBits / 8 and let t = 8rLen – rBits. (Note that t will be
19 between 0 and 7.)
20 3. Generate a fresh, random octet string seed of length seedLen octets (for more on generation of
21 random strings, see D.6).
22 4. If the method for combining the seed with the message is a stream cipher based on a key
23 derivation function:
24 a) Apply the selected key derivation function to seed to produce an octet string mask of
25 length mLen octets.
26 b) Let C = M mask.
27 5. If the method for combining the seed with the message is a key derivation function combined
28 with a symmetric encryption scheme:
29 a) Derive a key K for the selected symmetric encryption scheme from the seed with the
30 selected key derivation function (see 12.2.3 Note 3).
31 b) Encrypt M under the key K with the selected symmetric encryption scheme to produce
32 the encrypted message C.
33 6. Let DB = M || seed || C || P. If the length of DB is greater than the input length limitation for
34 the selected hash function, output “error” and stop.
35 7. Apply the hash function Hash to DB to produce an octet string H of length hLen octets.
36 8. Apply the mask generation function G to the string H to produce an octet string T of length
37 rLen octets.
38 9. Set the leftmost t bits of T to zero.
39 10. Convert seed to an integer f with the primitive OS2IP.
40 11. Convert T to an integer r with the primitive OS2IP.
41 12. Output f as the message representative, r as the randomized hash value, and C as the
42 encrypted message.
44Input:
45 The maximum bit length l of the message representative; the maximum bit length rBits of the
46 randomized hash value
47 The message representative, which is an integer f 0
2 137
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 The encrypted message, which is an octet string C of length cLen octets (depending on the hash
2 function and mask generation function or symmetric encryption scheme chosen, there may be a
3 length limitation)
4 Encoding parameters, which is an octet string P of length pLen octets (P may be an empty string);
5 see D.5.3.3 for possible uses (depending on the hash function chosen, there may a length
6 limitation)
7Output: The message, which is an octet string M, and the randomized hash value, which is an integer r 0
8of bit length at most 8hLen; or “error”
9The message shall be decoded and the randomized hash value obtained by the following or an equivalent
10sequence of steps:
11
12 1. If cLen is greater than the output length limitation for the selected key derivation function or
13 the ciphertext length limitation for the selected symmetric encryption scheme (whichever is
14 applicable), output “error” and stop.
15 2. Let seedLen = l/8. Let rLen = rBits / 8 and let t = 8rLen – rBits. (Note that t will be
16 between 0 and 7.)
17 3. Convert f to an octet string seed of length seedLen octets with the primitive I2OSP. If the
18 primitive outputs “error,” output “error” and stop.
19 4. If the method for combining the message with the seed is a stream cipher based on a key
20 derivation function:
21 a) Apply the selected key derivation function to seed to produce an octet string mask of
22 length cLen octets.
23 b) Let M = C mask.
24 5. If the method for combining the message with the seed is a key derivation function combined
25 with a symmetric encryption scheme:
26 a) Derive a key K for the selected symmetric encryption scheme from the seed with the
27 selected key derivation function (see 12.2.3 Note 3).
28 b) Decrypt C under the key K with the selected symmetric encryption scheme to recover
29 M. (If the decryption operation outputs “error,” output “invalid” and stop.)
30 6. Let DB = M || seed || C || P. If the length of DB is greater than the input length limitation for
31 the selected hash function, output “error” and stop.
32 7. Apply the hash function Hash to DB to produce an octet string H of length hLen octets.
33 8. Apply the mask generation function G to the string H to produce an octet string T of length
34 rLen octets.
35 9. Set the leftmost t bits of T to zero.
36 10. Convert T to an integer r with the primitive OS2IP.
37 11. Output the message M and the randomized hash r.
4213.3.1 EMSR1
43EMSR1 is an encoding method for signatures giving message recovery based on a hash function, based on
44ISO/IEC 9796-3:2000 [B79]. It is recommended for use with DL/ECSSR (see 10.4).
2 138
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 A hash function Hash with output length hLen octets, which shall be one of the hash functions in
3 14.1 or a technique designated for use with EMSR1 in an amendment to this standard
4 An indication as to whether hash function identification is desired
5 The short redundancy length in octets r1Len and the long redundancy length in octets r2Len, each
6 of which shall be at most hLen + 1 if hash function identification is desired, and at most hLen
7 otherwise
8The encoding method optionally uses a hash function identifier, HashID, which is a single octet. The values
9of HashID are given in the table in 12.1.2.
10NOTES
111—EMSR1 can handle recoverable message parts of length up to l/8 – r1Len octets if the non-recoverable message
12part is empty, and m1Len l/8 – r2Len octets otherwise, where l is the maximum length of the message
13representative; the non-recoverable message part can have essentially any length.
142—EMSR1 is not amenable to “single-pass” processing, since the non-recoverable message part M2 cannot be
15processed by the decoding operation until the signature has been processed to recover the recoverable message part M1.
163—If hash function identification is desired, then r1Len and r2Len should be set to hashLen + 1 so that the hash
17function identifier is not truncated during the encoding operation. However, see D.5.2.2 for further discussion on hash
18function identification.
194—For compatibility with ISO/IEC 9796-3:2000, the length of the recoverable message part should be l/8 – r2Len
20octets if the non-recoverable message part is non-empty.
22Input:
23 The maximum bit length l of the message representative (l shall be at least 8r1Len if the non-
24 recoverable message part is empty, or 8r2Len bits otherwise)
25 A recoverable message part, which is an octet string M1 of length m1Len octets, where m1Len
26 l/8 – r1Len if the non-recoverable message part is empty, and m1Len l/8 – r2Len if the non-
27 recoverable message part is not empty
28 A non-recoverable message part, which is an octet string M2 of length m2Len octets (depending on
29 the hash function chosen, there may be a length limitation)
30 A pre-signature, which is a bit string I
31Output: A message representative, which is an integer f 0 of bit length at most l; or “error”
32The message representative f shall be computed by the following or an equivalent sequence of steps:
33
34 1. If the 8m1Len + 8m2Len plus the length in bits of I plus 128 is greater than the length
35 limitation for the selected hash function, output “error” and stop.
36 2. If m2Len = 0, then let rLen = r1Len. Otherwise, let rLen = r2Len.
37 3. If m1Len > l/8 – rLen then output “error” and stop.
38 4. Convert m1Len to an octet string C1 of length 8 octets and m2Len to an octet string C2 of
39 length 8 octets using I2OSP.
2 139
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 140
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2Input:
3 The maximum bit length l of the message representative (l shall be at least 8r1Len if the non-
4 recoverable message part is empty, or 8r2Len bits otherwise)
5 The message representative, which is an integer f 0 of bit length at most l
6 The length in octets m1Len of the recoverable message part
7 The non-recoverable message part, which is an octet string M2 of length m2Len octets (depending
8 on the hash function chosen, there may be a length limitation)
9 The pre-signature, which is a bit string I
10Output: The recoverable message part M1 or “invalid”
11The recoverable message part shall be recovered by the following or an equivalent sequence of steps:
12
13 1. If 8m1Len + 8m2Len plus the length in bits of I plus 128 is greater than the length limitation
14 for the selected hash function, output “invalid” and stop.
15 2. If m2Len = 0, then let rLen = r1Len. Otherwise, let rLen = r2Len.
16 3. If m1Len > l/8 – rLen then output “invalid” and stop.
17 4. Convert f to an octet string T of length rLen + m1Len octets with the primitive I2OSP. If the
18 primitive outputs “error,” output “invalid” and stop.
19 5. Let R be the leftmost rLen octets of T and let M1 be the rightmost m1Len octets.
20 6. Convert m1Len to an octet string C1 of length 8 octets and m2Len to an octet string C2 of
21 length 8 octets using I2OSP.
22 7. Let M = OS2BSP (C1 || C2 || M1 || M2) || I.
23 8. Compute Hash (M) with the selected hash function to produce an octet string H of length
24 hLen octets.
25 9. If hash function identification is desired, then let H = H || HashID, where HashID is a single
26 octet identifying the selected hash function (see the table in 12.1.2).
27 10. Let R be the leftmost rLen octets of H.
28 11. If R = R output the message part M1. Otherwise, output “invalid.”
2913.3.2 EMSR2
30EMSR2 is an encoding method for signatures giving message recovery based on simple message padding
31and randomization. It is recommended for use with DL/ECSSR-PV (see 10.5).
2 141
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 schemes in 14.3, or a technique designated for use with EMSR2 in an amendment to this
2 standard
2 142
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1NOTES
21—EMSR2 can handle recoverable message parts of essentially any length in octets. The non-recoverable message
3parts is not processed by EMSR2.
42—EMSR2 is, in principle, amenable to “single-pass” processing since the non-recoverable message part is not
5processed at all by EMSR2 (and in fact DL/ECSSR-PV, which employs EMSR2, supports single-pass processing of the
6non-recoverable message part if the message representative C is transmitted before the non-recoverable message part).
73—The encoding method is also implicitly parameterized by any key derivation parameters for the key derivation
8function. As a default the key derivation parameter should be the empty string. Parameters to the symmetric encryption
9scheme (if applicable) such as an initialization vector are local to that scheme.
11Input:
12 A recoverable message part, which is an octet string M1 of length m1Len octets (depending on the
13 key derivation function or symmetric encryption scheme chosen, there may be a length limitation)
14 A pre-signature, which is an octet string I
15Output: A message representative, which is an octet string C of length m1Len + padLen octets
16The message representative C shall be computed by the following or an equivalent sequence of steps:
17
18 1. If mLen is greater than the output length limitation for the selected mask generation function
19 or the plaintext length limitation for the selected symmetric encryption scheme (whichever is
20 applicable), output “error” and stop.
21 2. Convert padLen to an octet string P1 of length 1 with primitive I2OSP.
22 3. Let P2 be the octet string formed from the octet P1 repeated padLen times. (Thus P2 will have
23 length padLen.)
24 4. Let T = P2 || M1.
25 5. If the method for combining the pre-signature is a stream cipher based on a key derivation
26 function:
27 a) Apply the selected key derivation function to the pre-signature I to produce an octet
28 string mask of length m1Len + padLen octets.
29 b) Let C = T mask.
30 6. If the method for combining the pre-signature is a key derivation function combined with a
31 symmetric encryption scheme:
32 a) Derive a key K for the selected symmetric encryption scheme from the pre-signature I
33 with the key derivation function (see 12.3.2 Note 3).
34 b) Encrypt T under the key K with the selected symmetric encryption scheme to produce
35 the message representative C.
36 7. Output C as the message representative.
37NOTE—The padding octet string P2 is 01 if padLen = 1, 02 02 if padLen = 2, 03 03 03 if padLen = 3, 04 04 04 04 if
38padLen = 4, 05 05 05 05 05 if padLen = 5, and so on.
40Input:
2 143
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 The message representative, which is an octet string C of length cLen octets (cLen shall be at least
2 padLen; depending on the key derivation function or symmetric encryption scheme chosen there
3 may be an additional length limitation)
4 The pre-signature, which is an octet string I
5Output: The recoverable message part M1 or “invalid”
6The recoverable message part shall be recovered by the following or an equivalent sequence of steps:
7
8 1. If cLen is greater than the output length limitation for the selected mask generation function or
9 the ciphertext length limitation for the selected symmetric encryption scheme (whichever is
10 applicable), output “error” and stop.
11 2. If the method for combining the pre-signature is a stream cipher based on a key derivation
12 function:
13 a) Apply the selected key derivation function to the pre-signature I to produce an octet
14 string mask of length cLen octets.
15 b) Let T = C mask.
16 3. If the method for combining the pre-signature is a key derivation function combined with a
17 symmetric encryption scheme:
18 a) Derive a key K for the selected symmetric encryption scheme from the pre-signature I
19 with the selected key derivation function (see 12.3.2 Note 3).
20 b) Decrypt C under the key K with the selected symmetric encryption scheme to recover
21 T. (If the decryption operation outputs “error,” output “invalid” and stop.)
22 4. Let tLen be the length of T in octets. If tLen < padLen, output “invalid” and stop.
23 5. Let P1 be the leftmost octet of T.
24 6. Convert P1 to an integer padLen with OS2IP.
25 7. If padLen padLen, output “invalid” and stop.
26 8. If padLen 2, verify that the next padLen – 1 octets after the first octet of T are equal to the
27 octet P1. If not, output “invalid” and stop.
28 9. Let M1 be the rightmost tLen – padLen octets of T.
29 10. Output the octet string M1.
3013.3.3 EMSR3
31EMSR3 is an encoding method for signatures giving message recovery based on a hash function and a
32mask generation function, based on the Probabilistic Signature Scheme with Recovery (PSS-R) (see Bellare
33and Rogaway [B19]). It is recommended for use with IFSSR (see 10.6).
35 A hash function Hash with output length hBits bits, which shall be one of the hash functions in 14.1
36 or a technique designated for use with EMSR3 in an amendment to this standard
37 A mask generation function G, which shall be MGF1 (see 14.2.1) with the same underlying hash
38 function Hash, or a technique designated for use with EMSR3 in an amendment to this standard
39 An indication as to whether hash function identification is desired
40 A salt length in bits saltBits, a nonnegative integer; typical values are hBits and 0 (in which case the
41 signature scheme is deterministic)
42The encoding method optionally uses a hash function identifier, HashID, which is a single octet. The values
43of HashID are given in the table in 12.1.2.
2 144
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1NOTES
21—EMSR3 can handle recoverable message parts of length up to l – saltBits – hBits – 8u – 1 bits, where l is the
3maximum length of the message representative and where u = 2 if hash function identification is desired and u = 1 if
4not; the non-recoverable message part can have essentially any length. Note that for consistency with the draft revision
5to ISO/IEC 9796-2, the value of l should be at least saltBits + hBits + 8u + 8 so that EMSR3 can handle recoverable
6message parts of length up to at least 7 bits, and thus messages of any total length in bits. (This constraint will be
7satisfied for typical values of l, saltBits and hBits.)
82—EMSR3 is amenable to “single-pass” processing in the case that the signature is transmitted after the non-
9recoverable message part, since the non-recoverable message part M2 can be processed by the decoding operation
10before the signature is available.
113—EMSR3 is defined in terms of bit strings for consistency with the draft revision to ISO/IEC 9796-2. However, if the
12message parts, salt, and hash output are all octet strings, then the encoding and decoding operations can be
13implemented with octet string operations only (except for setting certain bits to 0 or 1). Note that as invoked in this
14standard (i.e., by IFSSR), the recoverable message part for EMSR3 is always an octet string.
154—The dependence of the mask generation function on the underlying hash function helps protect against weak hash
16function attacks, as further discussed in D.5.2.2.
18Input:
19 The maximum bit length l of the message representative (l shall be at least saltBits + hBits + 8u + 1,
20 where u = 2 if hash function identification is desired and u = 1 if not)
21 A recoverable message part, which is an octet string M 1 of length m1Len (l – saltBits – hBits –
22 8u – 1)/8 octets or a bit string MB1 of length m1Bits l – saltBits – hBits – 8u – 1 bits
23 A non-recoverable message part, which is an octet string M2 of length m2Len octets (depending on
24 the hash function chosen, there may be a length limitation)
25Output: A message representative, which is an integer f 0 of bit length at most l where f 12 (mod 16);
26or “error”
27The message representative f shall be computed by the following or an equivalent sequence of steps:
28
29 1. If the recoverable message part is provided as an octet string M1, then convert it to a bit string
30 MB1 of length 8m1Len bits with the primitive OS2BSP. Let m1Bits = 8m1Len. Let u = 2 if
31 hash function identification is desired and u = 1 if not.
32 2. If the length of M2 is greater than the input length limitation for the selected hash function or
33 if m1Bits > l – saltBits – hBits – 8u – 1, output “error” and stop.
34 3. Compute Hash (M2) with the selected hash function to produce a bit string H2 of length hBits
35 bits.
36 4. Let oLen = l / 8 and let t = 8oLen – l. (Note that t will be between 0 and 7.)
37 5. Generate a fresh, random bit string salt of length saltBits bits (for more on generation of
38 random strings, see D.6). (If saltLen is 0, then salt will simply be the empty string.)
39 6. Convert m1Bits to a bit string C1 of length 64 bits using I2BSP.
40 7. Let M = C1 || MB1 || H2 || salt.
41 8. Compute Hash (M) with the selected hash function to produce a bit string H of length hBits
42 bits.
43 9. Let S be the bit string that consists of 8oLen – m1Bits – saltBits – hBits – 8u – 1 zero bits.
2 145
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 10. Let DB = S || 1 || MB1 || salt, where 1 is a single bit. The length of DB is 8oLen – hBits – 8u
2 bits.
3 11. Apply the mask generation function G to the string H to produce a bit string dbMask of length
4 8oLen – hBits – 8u bits.
5 12. Let maskedDB = DB dbMask.
6 13. Set the leftmost t bits of maskedDB to zero.
7 14. If hash function identification is desired, then let T = maskedDB || H || HashID || cc, where
8 HashID is a single octet identifying the selected hash function (see the table in 12.1.2) and
9 where cc is a single octet represented in hexadecimal. If not, then let T = maskedDB || H || bc,
10 where bc is a single octet represented in hexadecimal. The length of T is 8oLen bits, which is
11 a multiple of 8, but only the rightmost 8oLen – t = l bits may be nonzero.
12 15. Convert T to an integer f with the primitive OS2IP.
13 16. Output f as the message representative.
14NOTES
151—If a random number generator is not available in step 4, a fixed value may be selected for salt with a resulting
16security analysis similar to that for Full-Domain Hashing (see Bellare and Rogaway [BR93]). Alternatively, saltBits
17may be specified as 0 to avoid the need for random number generation. See D.5.2.2 for further discussion.
182—The security analysis for EMSR3 addresses both the case that the non-recoverable message part M2 is input to the
19module computing the signature and the case that the hash of the non-recoverable message part, Hash (M2), is input.
20Thus, this hash operation may be performed outside the module without loss in the security analysis (which is not the
21case for the original version of PSS (see Bellare and Rogaway [B19])).
23Input:
24 The maximum bit length l of the message representative (l shall be at least saltBits + hBits + 8u + 1,
25 where u = 2 if hash function identification is desired and u = 1 if not)
26 The message representative, which is an integer f 0 of bit length at most l
27 The non-recoverable message part, which is an octet string M2 of length m2Len octets (depending
28 on the hash function chosen, there may be a length limitation)
29Output: The recoverable message part, which is an octet string M1 of length at most (l – saltBits – hBits –
308u – 1)/8 octets or a bit string MB1 of length at most l – saltBits – hBits – 8u – 1 bits; or “invalid”
31The recoverable message part shall be recovered by the following or an equivalent sequence of steps:
32
33 1. Let u = 2 if hash function identification is desired and u = 1 if not. If the length of M2 is
34 greater than the input length limitation for the selected hash function or if l < saltBits + hBits
35 + 8u + 1, output “invalid” and stop.
36 2. Compute Hash (M2) with the selected hash function to produce a bit string H2 of length hBits
37 bits.
38 3. Let oLen = l / 8 and let t = 8oLen – l. (Note that t will be between 0 and 7.)
39 4. Convert f to an octet string T of length oLen octets with the primitive I2OSP. If the primitive
40 outputs “error,” output “invalid” and stop.
41 5. If hash function identification is desired, then verify that the rightmost octet of T has
42 hexadecimal value cc and that the second rightmost octet of T is HashID, where HashID is a
43 single octet identifying the selected hash function (see the table in 12.1.2). If hash function
44 identification is not desired, then verify that the rightmost octet of T has hexadecimal value
45 bc. In either case, if verification fails, output “invalid” and stop.
46 6. Let maskedDB be the leftmost 8oLen – hBits – 8u bits of T, and let H be the next hBits bits.
2 146
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
25The use of an inadequate key derivation function may compromise the security of the scheme in which it is
26used. This standard strongly recommends the use of the key derivation functions contained in this clause, or
27any key derivation functions defined in subsequent addenda to this standard. Similar to the situation for
28encoding methods, other key derivation functions are allowed within the framework of the schemes (see the
29introduction to Clause 10 for further discussion). However, the selection of key derivation functions not
30recommended here requires further security analysis by the implementer.
3114.1 KDF1
32KDF1 is a more general version of a similar construction key derivation function construction in ANSI
33X9.42 ([ANS98b]). It is recommended for use with DL and EC key agreement schemes (Clause 9).
35 a hash function Hash with output length hLen octets, which shall be SHA-1 (Clause 14.1.1), or
36 RIPEMD-160 (Clause 14.1.2), or a technique designated for use with KDF1 in an addendum to the
37 standard
38Input:
2 147
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The shared secret key K shall be computed by the following or an equivalent sequence of steps:
2 t) If zLen + pLen exceeds the length limitation (2 61 – 1 for SHA-1 or RIPEMD-160), output “error”
3 and stop.Compute hash(Z || P) with the selected hash function to produce an octet string K of hLen
4 octets.Output K as the shared secret key.
5
6NOTE—The interpretation and usage of the hLen-octet output K is beyond the scope of this standard. For example, the
7two parties may agree to use the first 128 bits (with parity adjusted) of K as a session key for two-key triple-DES
8[ANS98d].
914.2 KDF2
10KDF2 is based on the constructions in ANSI X9.42:2001 ([B8], Clause 7.7.2) and ANSI X9.63 ([B12],
11Clause 5.6.3). It is recommended for use with DL and EC key agreement schemes (Clause 9), the DL and
12EC encryption scheme (see 11.3), EMSR2 (see 12.3.2), and EME3 (see 12.2.3).
14 A hash function Hash with output length hBits bits, which shall be one of the hash functions in 14.1
15 or a technique designated for use with KDF2 in an amendment to this standard
16Input:
17 A shared secret string, which is an octet string Z of length zLen octets or a bit string ZB of length
18 zBits bits (depending on the hash function chosen, there may be a length limitation)
19 The desired length in octets of the output, which is a positive integer oLen, or the desired length in
20 bits of the output, which is a positive integer oBits (8oLen or oBits shall be less than or equal to
21 hBits (232 – 1))
22 Key derivation parameters, which is an octet string P of length pLen octets or a bit string PB of
23 length pBits bits (depending on the hash function chosen, there may be a length limitation)
24Output: A shared secret key, which is an octet string K of length oLen octets or a bit string KB of length
25oBits bits; or “error”
26The shared secret key K shall be computed by the following or an equivalent sequence of steps:
27
28 1. If the shared secret string is provided as an octet string Z, then convert it to a bit string ZB of
29 length 8zLen bits with the primitive OS2BSP. Let zBits = 8zLen.
30 2. If the desired length of the output is provided as an octet length oLen, then let oBits = 8oLen.
31 3. If the key derivation parameters are provided as an octet string P, then convert it to a bit string
32 PB of length 8pLen bits with the primitive OS2BSP. Let pBits = 8pLen.
33 4. If zBits + pBits + 32 is greater than the input length limitation for the selected hash function or
34 if oBits > hBits (232 – 1), output “error” and stop.
35 5. Let MB be the empty string. Let cThreshold = oBits / hBits .
36 6. Let counter = 1.
37 6.1 Convert counter to a bit string CB of length 32 bits using I2BSP.
38 6.2 Compute Hash (ZB || CB || PB) with the selected hash function to produce a bit string
39 HB of hBits bits.
40 6.3 Let MB = MB || HB.
41 6.4 Increment counter by one. If counter cThreshold, go to step 6.1.
42 7. Let KB be the leftmost oBits bits of MB.
2 148
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 8. If the output is to be returned as a bit string, output KB as the shared secret key. Otherwise,
2 convert KB to an octet string K with the primitive BS2OSP and output K as the shared secret
3 key.
4NOTES
51—KDF2 can accept and return either octet strings or bit strings to support the varying requirements of techniques in
6IEEE Std 1363-2000 and this amendment. For convenience, octet string operands are converted to bit strings here, and
7only bit strings are passed to the underlying hash function. This conversion assumes that the underlying hash function
8would convert an octet string to a bit string the same way that KDF2 does, i.e., most significant bit first. While this is
9true for the hash functions allowed by IEEE Std 1363-2000 and this amendment (SHA-1, SHA-256, SHA-384, SHA-
10512, and RIPEMD-160), it is not true in general for all hash functions. When the operands are all octet strings, KDF2
11can be implemented with octet string operations only, skipping the conversion to bit strings and passing octet strings
12directly to the underlying hash function.
132—The interpretation and usage of the output K in general is beyond the scope of this standard (although within one of
14the encryption schemes and certain encoding methods, a particular interpretation and usage is specified).
153—Since counter is only 32 bits and starts at 1, the maximum length of the output is at most hBits (232 – 1) bits.
164—This method is the same as MGF1 in the case that P is the empty string except that the counter starts at 1 rather than
170 and the output is a bit string rather than an octet string.
2 149
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
7NOTE—Most of the functions defined here can accept and return either octet strings or bit strings to support the
8varying requirements of techniques in IEEE Std 1363-2000 and this amendment. For convenience of specification,
9octet string operands are converted to bit strings via OS2BSP (i.e., most significant bit first), so that only bit strings are
10passed to the underlying hash function. Likewise, an octet string result is obtained via BS2OSP. These conversions
11assume that the underlying hash function would convert the same way. While this is true for the hash functions allowed
12by IEEE Std 1363-2000 and this amendment (SHA-1, SHA-256, SHA-384, SHA-512, and RIPEMD-160), it is not true
13in general for all hash functions. When the operands are all octet strings, the functions can be implemented with octet
14string operations only.
20The use of an inadequate hash function may compromise the security of the scheme in which it is used.
21This standard strongly recommends the use of the hash functions contained in this subclause, or any hash
22functions defined in subsequent addenda to this standard. However, as noted in the introduction to this
23Clause, other hash functions are allowed within the framework of the schemes in this standard, with
24appropriate security analysis by the implementer.
2515.1.1 SHA-1
26SHA-1 is defined in FIPS PUB 180-2 [B55]. The hash output length for SHA-1 is 160 bits and the block
27size (relevant to MAC1) is B = 512.
28Input: An octet string M of length mLen octets (mLen has to be less than 261) or a bit string MB of length
29mBits bits (mBits has to be less than 264)
30Output: A hash value, which is an octet string H of length 20 octets or a bit string HB of length 160 bits
31The hash value shall be computed by the following or an equivalent sequence of steps:
32
33 1. If the input is provided as an octet string M, then convert it to a bit string MB of length 8mLen
34 bits with the primitive OS2BSP.
35 2. Apply the Secure Hash Algorithm, revision 1, as described in FIPS PUB 180-2 to MB to
36 produce a bit string HB of length 160 bits.
37 3. If the output is to be returned as a bit string, output HB as the hash value. Otherwise, convert
38 HB to an octet string H with the primitive BS2OSP and output H as the hash value.
2 150
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
115.1.2 RIPEMD-160
2RIPEMD-160 is based on the work of Dobbertin, Bosselaers, and Preneel [B49]. The hash output length for
3RIPEMD-160 is 160 bits and the block size (relevant to MAC1) is B = 512.
4Input: An octet string M of length mLen octets (mLen shall be at most 2611) or a bit string MB of length
5mBits bits (mBits shall be at most 2641)
6Output: A hash value, which is an octet string H of length 20 octets or a bit string HB of length 160 bits
7The hash value shall be computed by the following or an equivalent sequence of steps:
8
9 1. If the input is provided as an octet string M, then convert it to a bit string MB of length 8mLen
10 bits with the primitive OS2BSP.
11 2. Apply the RIPEMD-160 hash algorithm as described in ISO/IEC 10118-3:1998 [ISO-10118-
12 3], clause 7 to MB to produce a bit string HB of length 160 bits.
13 3. If the output is to be returned as a bit string, output HB as the hash value. Otherwise, convert
14 HB to an octet string H with the primitive BS2OSP and output H as the hash value.
1515.1.3 SHA-256
16SHA-256 is defined in FIPS PUB 180-2 [B55]. The hash output length for SHA-256 is 256 bits and the
17block size (relevant to MAC1) is B = 512.
18Input: An octet string M of length mLen octets (mLen shall be at most 2611) or a bit string MB of length
19mBits bits (mBits shall be at most 2641)
20Output: A hash value, which is an octet string H of length 32 octets or a bit string HB of length 256 bits
21The hash value shall be computed by the following or an equivalent sequence of steps:
22
23 1. If the input is provided as an octet string M, then convert it to a bit string MB of length 8mLen
24 bits with the primitive OS2BSP.
25 2. Apply the SHA-256 hash algorithm as described in FIPS PUB 180-2 to MB to produce a bit
26 string HB of length 160 bits.
27 3. If the output is to be returned as a bit string, output HB as the hash value. Otherwise, convert
28 HB to an octet string H with the primitive BS2OSP and output H as the hash value.
2915.1.4 SHA-384
30SHA-384 is defined in FIPS PUB 180-2 [B55]. The hash output length for SHA-384 is 384 bits and the
31block size (relevant to MAC1) is B = 1024.
32Input: An octet string M of length mLen octets (mLen shall be at most 21251) or a bit string MB of length
33mBits bits (mBits shall be at most 21281)
34Output: A hash value, which is an octet string H of length 48 octets or a bit string HB of length 384 bits
35The hash value shall be computed by the following or an equivalent sequence of steps:
36
2 151
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 1. If the input is provided as an octet string M, then convert it to a bit string MB of length 8mLen
2 bits with the primitive OS2BSP.
3 2. Apply the SHA-384 hash algorithm, as described in FIPS PUB 180-2 [B55] to MB to produce
4 a bit string HB of length 384 bits.
5 3. If the output is to be returned as a bit string, output HB as the hash value. Otherwise, convert
6 HB to an octet string H with the primitive BS2OSP and output H as the hash value.
715.1.5 SHA-512
8SHA-256 is defined in FIPS PUB 180-2 [B55]. The hash output length for SHA-256 is 512 bits and the
9block size (relevant to MAC1) is B = 1024.
10Input: An octet string M of length mLen octets (mLen shall be at most 21251) or a bit string MB of length
11mBits bits (mBits shall be at most 21281)
12Output: A hash value, which is an octet string H of length 64 octets or a bit string HB of length 512 bits
13The hash value shall be computed by the following or an equivalent sequence of steps:
14
15 1. If the input is provided as an octet string M, then convert it to a bit string MB of length 8mLen
16 bits with the primitive OS2BSP.
17 2. Apply the SHA-512 hash algorithm as described in FIPS PUB 180-2 [B55] to MB to produce
18 a bit string HB of length 512 bits.
19 3. If the output is to be returned as a bit string, output HB as the hash value. Otherwise, convert
20 HB to an octet string H with the primitive BS2OSP and output H as the hash value.
28The use of an inadequate mask generation function may compromise the security of the scheme in which it
29is used. This standard strongly recommends the use of the mask generation functions contained in this
30subclause, or any mask generation functions defined in subsequent addenda to this standard. However, as
31noted in the introduction to this Clause, other mask generation functions are allowed within the framework
32of the schemes in this standard, with appropriate security analysis by the implementer.
3315.2.1 MGF1
34MGF1 is a mask generation function based on a hash function, following the ideas of Bellare and Rogaway
35([B18] and [B19]). It is used with EMSA4 (see 12.1.4), EME1 (see 12.2.1), and EMSR3 (see 12.3.3).
37 A hash function Hash with output length hBits bits, which shall be one of the hash functions in 14.1
38 or a technique designated for use with MGF1 in an amendment to this standard
39Input:
2 152
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 An octet string Z of length zLen octets or a bit string ZB of length zBits bits (depending on the hash
2 function chosen, there may be a length limitation)
3 The desired length of the output, which is a positive integer oLen giving the length in octets if the
4 output is to be returned as an octet string, a positive integer oBits giving the length in bits if the
5 output is to be returned as a bit string (8oLen or oBits shall be at most hBits 232)
6Output: A mask value, which is an octet string mask of length oLen octets or a bit string maskB of length
7oBits bits; or “error”
8The octet string mask shall be computed by the following or an equivalent sequence of steps:
9
10 1. If the input is provided as an octet string Z, then convert it to a bit string ZB of length 8zLen
11 bits with the primitive OS2BSP. Let zBits = 8zLen.
12 2. If the output is to be returned as an octet string (so that the desired length of the output is
13 provided as an octet length oLen), then let oBits = 8oLen.
14 3. If zBits + 32 is greater than the input length limitation for the selected hash function, or if
15 oBits > hBits 232, output “error” and stop.
16 4. Let MB be the empty string. Let cThreshold = oBits / hBits .
17 5. Let counter = 0.
18 5.1 Convert counter to a bit string CB of length 32 bits using I2BSP.
19 5.2 Compute Hash (ZB || CB) with the selected hash function to produce a bit string HB of
20 hBits bits.
21 5.3 Let MB = MB || HB.
22 5.4 Increment counter by one. If counter < cThreshold, go to step 5.1.
23 5. Let maskB be the leftmost oBits bits of MB.
24 6. If the output is to be returned as a bit string, output maskB as the mask value. Otherwise,
25 convert maskB to an octet string mask with the primitive BS2OSP and output mask as the
26 mask value.
27NOTES
281—MGF1 can accept and return either octet strings or bit strings to support the varying requirements of techniques in
29IEEE Std 1363-2000 and this amendment. For convenience, octet string operands are converted to bit strings here, and
30only bit strings are passed to the underlying hash function. This conversion assumes that the underlying hash function
31would convert an octet string to a bit string the same way that MGF1 does, i.e., most significant bit first. While this is
32true for the hash functions allowed by IEEE Std 1363-2000 and this amendment (SHA-1, SHA-256, SHA-384, SHA-
33512, and RIPEMD-160), it is not true in general for all hash functions. When the operands are all octet strings, MGF1
34can be implemented with octet string operations only, skipping the conversion to bit strings and passing octet strings
35directly to the underlying hash function.
362—Since counter is only 32 bits, the maximum length of the output is at most hBits 232 bits.
44The use of an inadequate symmetric encryption scheme may compromise the security of the scheme in
45which it is used. This standard strongly recommends the use of the symmetric encryption schemes
46contained in this subclause, or any symmetric encryption schemes defined in subsequent addenda to this
2 153
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1standard. However, as noted in the introduction to this Clause, other symmetric encryption schemes are
2allowed within the framework of the (public-key) schemes in this standard, with appropriate security
3analysis by the implementer.
4NOTE—The symmetric encryption schemes defined here both require that the length in bits of the message is divisible
5by 8. To encrypt messages whose length is not divisible by 8, a different symmetric encryption scheme should be
6chosen (perhaps one similar to those defined here, with slightly different padding; the specifics of such a choice are left
7to the implementer).
815.3.1 Triple-DES-CBC-IV0
9Triple-DES-CBC-IV0 is two- or three-key triple-DES in Cipher Block Chaining (CBC) mode with a null
10initialization vector, as further specified in ANSI X9.52-1998 [B10], FIPS PUB 46-3 [FIPS-46-3] and FIPS
11PUB 113 [FIPS-113].
12The underlying block cipher for the Enc and Dec functions below is the Data Encryption Algorithm (i.e.,
13the DES algorithm from FIPS PUB 46-3 [FIPS-46-3]), which operates on a 64-bit key (of which every
14eighth bit is a parity bit) and a 64-bit block.
16Input:
17 A key, which is a bit string KB of 128 or 192 bits (where every eighth bit of the key, starting at the
18 left does not affect the operation and may be used for parity checking)
19 A message, which is an octet string M of length mLen octets or a bit string MB of length mBits bits
20 (where mBits shall be divisible by 8)
21Output: A encrypted message, which is an octet string C of length cLen octets where cLen =
228(mLen+1)/8 or a bit string CB of length cBits bits, where cBits = 64(mBits+8)/64
23The encrypted message shall be computed by the following or an equivalent sequence of steps:
24
25 1. Let K1 be the leftmost 64 bits of KB and let K2 be the next 64 bits. If length of the bit string
26 KB is 192 bits, then let K3 be the rightmost 64 bits of KB. Otherwise let K3 = K1.
27 2. If the input is provided as a bit string MB, then convert it to an octet string M of length
28 mBits/8 octets with the primitive BS2OSP. Let mLen = mBits/8.
29 3. Let padLen = 8 (mLen mod 8) and let k = (mLen+1)/8.
30 4. Convert padLen to an octet string P1 of length 1 with primitive I2OSP.
31 5. Let P2 be the octet string formed from the octet P1 repeated padLen times. (Thus P2 will have
32 length padLen.)
33 6. Let T = M || P2.
34 7. Consider the padded message T as a sequence of eight-octet blocks T1, …, Tk and the
35 encrypted message C as a sequence of eight-octet blocks C1, …, Ck.
36 8. Let C0 be an octet string that consists of eight zero octets. (C0 is not part of the encrypted
37 message.)
38 9. Let i = 1.
39 9.1 Let U = Ti Ci1.
40 9.2 Let Ci = Enc (K3 (Dec (K2, Enc (K1, U))) where Enc denotes encryption with the Data
41 Encryption Algorithm and Dec denotes decryption.
42 9.2 Increment i by one. If i k, go to step 8.1.
43 10. Let C = C1 || C2 || … || Ck.
2 154
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 11. If the output is to be returned as an octet string, output C as the encrypted message.
2 Otherwise, convert C to a bit string CB of length 64k bits with the primitive OS2BSP and
3 output CB as the encrypted message.
4NOTE—The padding octet string P2 is 01 if padLen = 1, 02 02 if padLen = 2, 03 03 03 if padLen = 3, 04 04 04 04 if
5padLen = 4, 05 05 05 05 05 if padLen = 5, and so on.
7Input:
8 A key, which is a bit string KB of 128 or 192 bits (where every eighth bit of the key, starting at the
9 left does not affect the operation and may optionally be used for parity checking)
10 An encrypted message, which is an octet string C of length cLen octets (cLen shall be a multiple of
11 8 and cLen shall be greater than or equal to 8) or a bit string CB of length cBits bits (cBits shall be a
12 multiple of 64 and cBits shall be greater than or equal to 64)
13Output: A message, which is an octet string M of length mLen octets where cLen 8 mLen cLen 1 or
14a bit string MB of length mBits bits where cBits 64 mBits cBits 8; or “error”
15The message shall be recovered by the following or an equivalent sequence of steps:
16
17 1. If the input is provided as a bit string CB, then convert it to an octet string C of length cBits/8
18 octets with the primitive BS2OSP. Let cLen = cBits/8.
19 2. If cLen is not a multiple of 8, or cLen < 8, output “error” and stop.
20 3. Let K1 be the leftmost 64 bits of KB and let K2 be the next 64 bits. If length of the bit string
21 KB is 192 bits, then let K3 be the rightmost 64 bits of KB. Otherwise let K3 = K1.
22 4. Let k = cLen/8.
23 5. Consider the encrypted message C as a sequence of eight-octet blocks C1, …, Ck a padded
24 message T as a sequence of eight-octet blocks T1, …, Tk.
25 6. Let C0 be an octet string that consists of eight zero octets. (C0 is not part of the encrypted
26 message.)
27 7. Let i = 1.
28 7.1 Let U = Dec (K1, Enc (K2, Dec (K3, Ci))), where Dec denotes decryption with the Data
29 Encryption Algorithm and Enc denotes encryption.
30 7.2 Let Ti = U Ci1.
31 7.2 Increment i by one. If i k, go to step 4.1.
32 8. Let P1 be the rightmost octet of Tk.
33 9. Convert P1 to an integer padLen with OS2IP.
34 10. If padLen < 1 or padLen > 8, output “error” and stop.
35 11. If padLen 2, verify that the next padLen – 1 octets before the last octet of Tk are equal to the
36 octet P1. If not, output “error” and stop.
37 12. Let mLen = cLen padLen and let M be the leftmost mLen octets of T.
38 13. If the output is to be returned as an octet string, output the octet string M as the message.
39 Otherwise, convert M to a bit string MB of length 8mLen bits with the primitive OS2BSP and
40 output MB as the message.
4115.3.2 AES-CBC-IV0
42AES-CBC is the Advanced Encryption Standard (AES) algorithm in Cipher Block Chaining (CBC) mode
43with a null initialization vector, as further specified in FIPS PUB 197 [FIPS-197] and FIPS PUB 113
44[FIPS-113].
2 155
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The underlying block cipher for the Enc and Dec functions below is the AES algorithm, which operates on
2a 128-bit, 192-bit or 256-bit key and a 128-bit block.
4Input:
11
12 1. If the input is provided as a bit string MB, then convert it to an octet string M of length
13 mBits/8 octets with the primitive BS2OSP. Let mLen = mBits/8.
14 2. Let padLen = 16 (mLen mod 16) and let k = (mLen+1)/16.
15 3. Convert padLen to an octet string P1 of length 1 with primitive I2OSP.
16 4. Let P2 be the octet string formed from the octet P1 repeated padLen times. (Thus P2 will have
17 length padLen.)
18 5. Let T = M || P2.
19 6. Consider the padded message T as a sequence of 16-octet blocks T1, …, Tk and the encrypted
20 message C as a sequence of 16-octet blocks C0, …, Ck.
21 7. Let C0 be an octet string that consists of 16 zero octets. (C0 is not part of the encrypted
22 message.)
23 8. Let i = 1.
24 8.1 Let U = Ti Ci1.
25 8.2 Let Ci = Enc (KB, U) where Enc denotes encryption with the AES algorithm.
26 8.3 Increment i by one. If i k, go to step 8.1.
27 9. Let C = C1 || C2 || … || Ck.
28 10. If the output is to be returned as an octet string, output C as the encrypted message.
29 Otherwise, convert C to a bit string CB of length 128k bits with the primitive OS2BSP and
30 output CB as the encrypted message.
32Input:
40
2 156
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 1. If the input is provided as a bit string CB, then convert it to an octet string C of length cBits/8
2 octets with the primitive BS2OSP. Let cLen = cBits/8.
3 2. If cLen is not a multiple of 16, or cLen < 16, output “error” and stop.
4 3. Let k = cLen/16.
5 4. Consider the encrypted message C as a sequence of 16-octet blocks C0, …, Ck a padded
6 message T as a sequence of 16-octet blocks T1, …, Tk.
7 5. Let C0 be an octet string that consists of 16 zero octets. (C0 is not part of the encrypted
8 message.)
9 6. Let i = 1.
10 6.1 Let U = Dec (KB, Ci) where Dec denotes decryption with the AES algorithm
11 6.2 Let Ti = U Ci1.
12 6.3 Increment i by one. If i k, go to step 4.1.
13 7. Let P1 be the rightmost octet of Tk.
14 8. Convert P1 to an integer padLen with OS2IP.
15 9. If padLen < 1 or padLen > 16, output “error” and stop.
16 10. If padLen 2, verify that the next padLen – 1 octets before the last octet of Tk are equal to the
17 octet P1. If not, output “error” and stop.
18 11. Let mLen = cLen padLen and let M be the leftmost mLen octets of T.
19 12. If the output is to be returned as an octet string, output the octet string M as the message.
20 Otherwise, convert M to a bit string MB of length 8mLen bits with the primitive OS2BSP and
21 output MB as the message.
25The use of an inadequate message authentication code may compromise the security of the scheme in
26which it is used. This standard strongly recommends the use of the message authentication code contained
27in this subclause, or any message authentication codes defined in subsequent addenda to this standard.
28However, as noted in the introduction to this Clause, other message authentication codes are allowed within
29the framework of the (public-key) schemes in this standard, with appropriate security analysis by the
30implementer.
3115.4.1 MAC1
32MAC1 is the HMAC message authentication code, which is based on the work of Bellare, Canetti, and
33Krawcyzk [BCK96], as further specified in ANSI X9.71-2000 [ANSI-X9.71] and the forthcoming HMAC
34FIPS [FIPS-198]. (See also RFC 2104 by Krawcyzk, Bellare, and Canetti [KBC97].) The function is
35parameterized by the following choices:
36 A hash function Hash with output length hLen octets, which shall be one of the hash functions in
37 14.1 or a technique designated for use with MAC1 in an amendment to this standard ( B denotes the
38 block length in octets of the hash function)
39 The length in bits of the tag, which is a positive integer tBits (tBits shall be greater than or equal to
40 32 and less than or equal to hBits)
41Input:
42 A key, which is a bit string KB of length kBits bits (kBits shall be a multiple of 8 and kBits/8 shall
43 be greater than or equal to hLen/2)
2 157
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 A message, which is an octet string M of length mLen octets or a bit string MB of length mBits bits
2 (depending on the hash function chosen, there may be a length limitation)
3Output: A tag, which is a bit string TB of length tBits bits or (in the case that tBits is divisible by 8) an
4octet string T of length tBits/8 octets
6
7 1. If the message is provided as an octet string M, then convert it to a bit string MB of length
8 8mLen bits with the primitive OS2BSP. Let mBits = 8mLen.
9 2. If kBits > 8B, then compute Hash (K) with the selected hash function to produce an octet
10 string KK of length hLen octets. Otherwise, convert K to an octet string KK of length kBits/8
11 octets with the primitive BS2OSP. Let kkLen be the length of KK in octets.
12 3. Let P be an octet string of length B – kkLen octets, each with hexadecimal value 00.
13 4. Let K0 = KK || P.
14 5. Let iPad be an octet string of length B octets, each with hexadecimal value 36, and let oPad
15 be an octet string of length B octets, each with hexadecimal value 5c.
16 6. Compute Hash (OS2BSP (K0 iPad) || MB) with the selected hash function to produce an
17 octet string H of length hLen octets.
18 7. Compute Hash ((K0 oPad) || H) with the selected hash function to produce an octet string
19 HH of length hLen octets.
20 8. If the output is to be returned as a bit string, convert HH to a bit string HHB of length tBits
21 bits with the primitive OS2BSP and output the leftmost tBits bits of HHB as the tag.
22 Otherwise, output the leftmost tBits/8 octets of HH as the tag.
23NOTE—MAC1 can accept and return either octet strings or bit strings to support the varying requirements of
24techniques in this amendment. For convenience, octet string operands are converted to bit strings here, and only bit
25strings are passed to the underlying hash function. This conversion assumes that the underlying hash function would
26convert an octet string to a bit string the same way that MAC1 does, i.e., most significant bit first. While this is true for
27the hash functions allowed by IEEE Std 1363-2000 and this amendment (SHA-1, SHA-256, SHA-384, SHA-512, and
28RIPEMD-160), it is not true in general for all hash functions. When the operands are all octet strings, MAC1 can be
29implemented with octet string operations only, skipping the conversion to bit strings and passing octet strings directly
30to the underlying hash function.
2 158
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
4Modular reduction.
5Modular arithmetic is based on a fixed integer m > 1 called the modulus. The fundamental operation is
6reduction modulo m. To reduce an integer a modulo m, one divides a by m and takes the remainder r. This
7operation is written
8r := a mod m.
1111 mod 8 = 3
127 mod 9 = 7
13–2 mod 11 = 9
1412 mod 12 = 0
15Congruences.
16Two integers a and b are said to be congruent modulo m if they have the same result upon reduction
17modulo m. This relationship is written
20Example:
24a0 + a1 b0 + b1 (mod m)
25a0 – a1 b0 – b1 (mod m)
26a0a1 b0b1 (mod m).
27Integers modulo m.
28The integers modulo m are the possible results of reduction modulo m. Thus the set of integers modulo m
29is
2 159
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1One performs addition, subtraction, and multiplication on the set Zm by performing the corresponding
2integer operation and reducing the result modulo m. For example, in Z7
33 = 6 + 4
45 = 1 – 3
56 = 4 5.
6Modular exponentiation.
7If v is a positive integer and g is an integer modulo m, then modular exponentiation is the operation of
8computing gv mod m (also written exp (g, v) mod m). Clause A.2.1 contains an efficient method for
9modular exponentiation.
11If m and h are integers, the greatest common divisor (or G.C.D.) is the largest positive integer d dividing
12both m and h. If d = 1, then m and h are said to be relatively prime (or coprime). Clause A.2.2 contains an
13efficient method for computing the G.C.D.
14The least common multiple (or L.C.M.) is the smallest positive integer l divisible by both m and h. The
15G.C.D. and L.C.M. are related by
18Modular division.
19The multiplicative inverse of h modulo m is the integer k modulo m such that hk 1 (mod m). The
20multiplicative inverse of h is commonly written h–1 (mod m). It exists if h is relatively prime to m and not
21otherwise.
22If g and h are integers modulo m, and h is relatively prime to m, then the modular quotient g/h modulo m is
23the integer gh–1 mod m. If c is the modular quotient, then c satisfies g hc (mod m).
24The process of finding the modular quotient is called modular division. Clause A.2.2 contains an efficient
25method for modular division.
28In the case in which m equals a prime p, the set Zp forms a prime finite field and is denoted GF (p).
29In the finite field GF (p), modular division is possible for any denominator other than 0. The set of nonzero
30elements of GF (p) is denoted GF (p)*.
31Orders.
32The order of an element c of GF (p)* is the smallest positive integer v such that cv 1 (mod p). The order
33always exists and divides p – 1. If k and l are integers, then ck cl (mod p) if and only if k l (mod v).
34Generators.
2 160
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1If v divides p – 1, then there exists an element of GF (p)* having order v. In particular, there always exists
2an element g of order p – 1 in GF (p)*. Such an element is called a generator for GF (p)* because every
3element of GF (p)* is some power of g. In number-theoretic language, g is also called a primitive root for
4p.
6Suppose that the element g of GF (p)* has order v. Then an element h of GF (p)* satisfies
7h g l (mod p)
8for some l if and only if h v 1 (mod p). The exponent l is called the discrete logarithm of h (with respect
9to the base g). The discrete logarithm is an integer modulo v.
10DL-based cryptography
11Suppose that g is an order-r element of GF (p)* where r is prime. Then a key pair can be defined as
12follows.
13
14 The private key s is an integer modulo r.
15 The corresponding public key w is an element of GF (p)* defined by
16 w := gs (mod p).
17It is necessary to compute a discrete logarithm in order to derive a private key from its corresponding
18public key. For this reason, public-key cryptography based on key pairs of this type relies for its security
19on the difficulty of the discrete logarithm problem. Thus it is an example of DL-based cryptography. The
20difficulty of the discrete logarithm problem is discussed in Annex D.4.1.
22RSA moduli.
23An RSA modulus is the product n of two odd (distinct) primes p and q. It is assumed that p and q are large
24enough that factoring n is computationally infeasible (see below).
25A unit modulo n is a positive integer less than n and relatively prime to n (i.e. divisible by neither p nor q).
26The set of all units modulo n is denoted by U n. The modular product and modular quotient of units are also
27units. If a is a unit and k an integer, then a k mod n is also a unit.
28If a positive integer less than n is selected without knowledge of p or q, it is virtually certain to be a unit.
29(Indeed, generating a nonunit modulo n is as difficult as factoring n.)
30Exponentiation.
34a c a d (mod n)
2 161
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
4a de a (mod n)
5for every integer a.
6IF-based cryptography.
7Given an RSA modulus n, a pair of integers d, e satisfying de 1 (mod (n)) can be taken as the
8components of a key pair. Traditionally, e denotes the public key and d the private key. Given n and e, it is
9known that finding d is as difficult as factoring n. This in turn is believed to be necessary for computing a
10unit a given ae mod n. For this reason, public-key cryptography based on key pairs of this type relies for its
11security on the difficulty of the integer factorization problem. Thus it is an example of IF-based
12cryptography. The difficulty of the integer factorization problem is discussed in Annex D.4.3.
a
15If p > 2 is prime, and a is any integer, then the Legendre symbol is defined as follows. If p divides a,
p
a a
16then = 0. If p does not divide a, then equals 1 if a is a square modulo p and –1 otherwise.
p p
17(Despite the similarity in notation, a Legendre symbol should not be confused with a rational fraction; the
18distinction must be made from the context.)
a
20The Jacobi symbol is a generalization of the Legendre symbol. If n > 1 is odd with prime
n
21factorization
t
22n = p
i 1
ei
i
,
ei
a t
a
24 :=
n ,
i 1 pi
a
25where the symbols are Legendre symbols. (Despite the similarity in notation, a Jacobi symbol
pi
26should not be confused with a rational fraction; the distinction must be made from the context.)
2 162
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The values of the Jacobi symbol are 1 if a and n are relatively prime and 0 otherwise. The values 1 and
2–1 are achieved equally often (unless n is a square, in which case the value –1 does not occur at all).
3Algorithms for computing Legendre and Jacobi symbols are given in A.2.3.
5Let p be an odd prime, and let g be an integer with 0 g < p. A square root modulo p of g is an integer z
6with 0 z < p and
7z 2 g (mod p).
g
8The number of square roots modulo p of g is 1+J, where J is the Jacobi symbol .
p
9If g = 0, then there is one square root modulo p, namely z = 0. If g 0, then g has either 0 or 2 square roots
10modulo p. If z is one square root, then the other is p – z.
11A procedure for computing square roots modulo a prime is given in A.2.5.
12RW Moduli.
13If n = pq is an RSA modulus with p q 3 (mod 4) and p ( q (mod 8), then n is called an RW modulus.
u
14Denote by Jn the set of units u such that the Jacobi symbol equals 1. The set Jn comprises precisely
n
15half of the units. If f is a unit, then either f or f/2 mod n is in Jn.
16Exponentiation.
17Let (n) be the universal exponent of n (see Annex A.1.3). If c and d are congruent modulo (n)/2, then
18a c a d (mod n)
19for every a in Jn. It follows that, if
22a de a (mod n)
23for every a in Jn.
24IF-based cryptography.
25Given an RW modulus n, a pair of integers d, e satisfying de 1 (mod (n)/2) can be taken as the
26components of a key pair. Traditionally, e denotes the public key and d the private key. The public key e
27must be even (see Clause 8.1.3.2).
28Given n and e, it is known that finding d is as difficult as factoring n. This in turn is necessary for
29computing a unit a given a e mod n. For this reason, public-key cryptography based on key pairs of this
2 163
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1type provides another example of IF-based cryptography. The difficulty of the integer factorization
2problem is discussed in Annex D.4.3.
5Modular exponentiation can be performed efficiently by the binary method outlined below.
7Output: gv mod m.
8 u) Let v = vrvr–1...v1v0 be the binary representation of v, where the most significant bit vr of v is 1.Set x
9 g.For i from r – 1 downto 0 do
10 3.1 Set x x2 mod m.
11 3.2 If vi = 1 then set x gx mod m.
12 4. Output x.
13There are several modifications that improve the performance of this algorithm. These methods are
14summarized in [Gor98].
16The following algorithm computes efficiently the G.C.D. d of m and h. If m and h are relatively prime, the
17algorithm also finds the quotient g/h modulo m.
18Input: an integer m > 1 and integers g and h > 0. (If only the G.C.D. of m and h is desired, no input g is
19required.)
20Output: the G.C.D. d of m and h and, if d = 1, the integer c with 0 < c < m and c g/h (mod m).
2 164
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
a
4Output: the Jacobi symbol .
n
5 x) Set x a, y n, J 1
6 2. While y > 1
7 2.1 Set x (x mod y)
8 2.2 If x > y/2 then
9 2.2.1 Set x y – x.
10 2.2.2 If y 3(mod 4) then set J –J
11 2.3 If x = 0 then set x 1, y 0, J 0
12 2.4 While 4 divides x
13 2.4.1 Set x x/4
14 2.5 If 2 divides x then
15 2.5.1 Set x x/2.
16 2.5.2 If y 3 (mod 8) then set J –J
17 2.6 If x 3 (mod 4) and y 3 (mod 4) then set J –J
18 2.7 Switch x and y
19 3. Output J
20If n is equal to a prime p, the Jacobi symbol can also be found efficiently using exponentiation via
a
21 := a (p – 1)/2 mod p.
p
2 165
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 v1 v12 – 2 q1 mod n
2 else set
3 q1 q0
4 v1 v0 v1 – P q0 mod n
5 v0 v02 – 2 q0 mod n
6 4. Output v0 and q0.
10Output: a square root modulo p of g if one exists. (In Case III, the message “no square roots exist” is
11returned if none exists.)
12
13 I. p 3 (mod 4), that is p = 4k + 3 for some positive integer k. (See [Leh69].)
14 1. Compute (via A.2.1) and output z := g k + 1 mod p.
15 II. p 5 (mod 8), that is p = 8k + 5 for some positive integer k. (See [Atk92].)
16 1. Compute := (2g)k mod p via A.2.1
17 2. Compute i := 2g 2 mod p
18 3. Compute and output z := g (i – 1) mod p
19 III p 1 (mod 8). (See [Leh69].)
20 1. Set Q g.
21 2. Generate a value P with 0 < P < p not already chosen.
22 3. Compute via A.2.4 the quantities
301—To perform the modular division of an integer V by 2 (needed in Step 4 of case III), one can simply divide by 2 the
31integer V or V + p (whichever is even). (The integer division by 2 can be accomplished by shifting the binary
32expansion of the dividend by one bit.)
332—As written, the algorithm for Case III works for all p 1 (mod 4), although it is less efficient than the algorithm for
34Case II when p 5 (mod 8).
353—In Case III, a given choice of P will produce a solution if and only if P 2 – 4Q is not a quadratic residue modulo p.
36If P is chosen at random, the probability of this is at least 1/2. Thus only a few values of P will be required. It may
37therefore be possible to speed up the process by restricting to very small values of P and implementing the
38multiplications by P in A.2.4 by repeated addition.
394—In cases I and II, the algorithm produces a solution z provided that one exists. If it is unknown whether a solution
40exists, then the output z should be checked by comparing w := z 2 mod p with g. If w = g, then z is a solution; otherwise
41no solutions exist. In case III, the algorithm performs the determination of whether or not a solution exists.
2 166
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2If r > 2 and a < 2r is a positive integer congruent to 1 modulo 8, then there is a unique positive integer b
3less than 2r–2 such that b2 a (mod 2r). The number b can be computed efficiently using the following
4algorithm. The binary representations of the integers a, b, h are denoted as
5a = ar–1...a1a0,
6b = br–1...b1b0,
7h = hr–1...h1h0.
8Input: an integer r > 2, and a positive integer a 1 (mod 8) less than 2r.
9Output: the positive integer b less than 2r–2 such that b2 a (mod 2r).
18Let p be a prime and let g satisfy 1 < g < p. The following algorithm determines the order of g modulo p.
19The algorithm is efficient only for small p.
22 bb) Set b g and j 1.Set b gb mod p and j j + 1.If b > 1 then go to Step 2.
23 4. Output j.
25Let p be a prime and let T divide p – 1. The following algorithm generates an element of GF (p) of order T.
26The algorithm is efficient only for small p.
29 cc) Generate a random integer g between 1 and p.Compute via A.2.7 the order k of g modulo p.If T
30 does not divide k then go to Step 1.
31 4. Output u := gk/T mod p.
33The following algorithm is an implementation of the IFSP-RSA1, IFSP-RSA2, and IFSP-RW signature
34primitives. Assuming e is small, it is more efficient for RW signatures than the primitive given in 8.2.8,
2 167
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1because it combines the modular exponentiation and Jacobi symbol calculations. The algorithm requires
2that the primes p and q be known to the user; thus the private key can have either the second or third form
3specified in 8.1.3. (Note that this algorithm cannot be applied to IF signature verification since it requires
4knowledge of p and q, which is equivalent to knowledge of the private key.)
5One-Time Computation: if the private key is the triple (p, q, d) (see Clause 8.1.3), then the remaining
6components d1, d2, c can be computed via
–1
7c := q mod p via A.2.2
8d1 := d mod (p – 1)
9d2 := d mod (q – 1).
10NOTE—For the smallest values of e, the values of d1 and d2 can be written down explicitly as follows.
11RSA: if e = 3, then
13RW: if e = 2, then
23Input: the (fixed) integers p, q, e, c, d1, d2, and (for RW) w1 and w2; the (per-message) integer f modulo pq.
24(It is unnecessary to store both p and d1, if one can be conveniently computed from the other, as in the cases
25e = 2 or e = 3. The same remark holds for q and d2.)
27The steps marked with an asterisk below are to be implemented only for RW and not for RSA.
2 168
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 t1 := j1w1 mod p
2 t2 := j2w2 mod q
5 t 1 j 1, t 2 j 2
6 gg) Compute
13Let p be a prime. The following algorithm efficiently computes the product of two elements of (Z/p2Z), as
14required in IFDP-OU. It may also be applied to IFSP-ESIGN.
15Input: Two integers u and v modulo p2, represented as u = a + bp and v = c + dp, where 0 a, b, c, d < p
16Output: w = uv mod p2, represented as w = e + hp
17
18 1. Set e ac mod p and f = ac / p. (These values can be computed simultaneously using a
19 standard division algorithm.)
20 2. Set g (ad + bc) mod p.
21 3. Set h (f + g) mod p.
22 4. Output w = e + hp.
23To apply this algorithm to IFSP-ESIGN, observe that step 3 in IFSP-ESIGN requires the computation of
24exp(r, e) mod n where n = p2q. This can be done by computing exp(r, e) mod p2 using the above algorithm
25for multiplication in (Z/p2Z), computing exp(r, e) modulo q, and then combining the results using the
26Chinese Remainder Theorem similarly to A.2.9. This can be done more efficiently if components such as
27p2 mod q are precomputed.
29In order to verify the structure of a received ciphertext (g, C), the IFES-EPOC decryption operation in
3011.4.3 re-encrypts the recovered message M and verifies that the resulting encrypted message
31representative g matches the received ciphertext g.
32Instead of calling the IFEP-OU encryption primitive to regenerate g and comparing it to g, one can instead
33adopt the following more efficient verification procedure.
34Suppose that randomized hash value is r and the message representative is f. The IFES-EPOC decryption
35operation checks whether the following equation holds:
2 169
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1or equivalently whether the equation holds modulo p2 and modulo q. However, as noted below, it is
2sufficient to check modulo p and q. Thus, steps 5 and 6 of the IFES-EPOC decryption operation may be
3replaced with the following:
4
5 5’. Check whether g exp(u, f) exp(v, r) mod p and g exp(u, f) exp(v, r) mod q. If so,
6 output the message M. Otherwise, output “invalid.”
7However, as observed in [NTT01], it is sufficient from a security perspective to check modulo q only.
8Thus, step 5 and 6 may be replaced with:
9
10 5’’. Check whether g exp(u, f) exp(v, r) mod q. If so, output the message M. Otherwise, output
11 “invalid.”
12This is the same as calling the IFEP-OU primitive with the “public” key (q, u, v, k) rather than (n, u, v, k),
13then checking that the resulting g is the same as g. As a further improvement, one may reduce r modulo
14q1 prior to exponentiation.
15NOTE—The rationale for checking modulo p rather than modulo p2 is based on the group isomorphism
17where (x) = L(xp)/L(up) mod p and (x) = x mod p. (Following 8.1.3.3, xp = exp(x, p–1) mod p2 and L(xp) = (xp – 1)/p
18mod p.) The message representative f in the IFES-EPOC decryption operation is recovered by computing
20where w is from the private key. Thus the equation (g) = (exp(u, f) exp(v, r) mod p2) = (exp(u, f) mod p2) already
21holds, and one only has to check whether (g) = '(exp(u, f) exp(v, r) mod p).
24A finite field (or Galois field) is a set with finitely many elements in which the usual algebraic operations
25(addition, subtraction, multiplication, division by nonzero elements) are possible, and in which the usual
26algebraic laws (commutative, associative, distributive) hold. The order of a finite field is the number of
27elements it contains. If q > 1 is an integer, then a finite field of order q exists if q is a prime power and not
28otherwise.
29The finite field of a given order is unique, in the sense that any two fields of order q display identical
30algebraic structure. Nevertheless, there are often many ways to represent a field. It is traditional to denote
31the finite field of order q by Fq or GF (q); this Standard uses the latter notation for typographical reasons. It
32should be borne in mind that the expressions “the field GF (q)” and “the field of order q” usually imply a
33choice of field representation.
34Finite fields exist for every prime-power order. This standard identifies three classes of finite fields that are
35commonly used in cryptography:
36
37 When q is a prime p, the field GF(p) is called a prime finite field. The field GF(p) is typically
38 represented as the set of integers modulo p. See A.1.2 for a discussion of these fields.
2 170
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 When q = 2m for some m, the field GF(2m) is called a binary finite field. Unlike the prime field case,
2 there are many common representations for binary finite fields. These fields are discussed below
3 (A.3.3 to A.3.9).
4 When q = pm for some m > 1 and some odd prime p, the field GF(pm) is called an odd characteristic
5 extension field. Elements of the field GF(pm) are typically represented by polynomials modulo an
6 irreducible field polynomial. These fields are discussed further in A.17.
7These are the three kinds of finite fields considered in this standard.
9A polynomial over GF (q) is a polynomial with coefficients in GF (q). Addition and multiplication of
10polynomials over GF (q) are defined as usual in polynomial arithmetic, except that the operations on the
11coefficients are performed in GF (q).
12A polynomial over the prime field GF (p) is commonly called a polynomial modulo p. Addition and
13multiplication are the same as for polynomials with integer coefficients, except that the coefficients of the
14results are reduced modulo p.
16(t 2 + 4t + 5) + (t 3
+ t + 3) = t 3
+ t 2
+ 5t + 1
17(t 2 + 3t + 4) (t + 4) = t 3 + 2t + 2.
3 3
20(t + 1) + (t + t) = t + 1
21(t + t + 1) (t +1) = t 3 + 1.
2
22A polynomial over GF (q) is reducible if it is the product of two smaller degree polynomials over GF (q);
23otherwise it is irreducible. For instance, the above examples show that t 3 + 2t + 2 is reducible over GF (7)
24and that the binary polynomial t 3 + 1 is reducible.
25Every nonzero polynomial over GF (q) has a unique representation as the product of powers of irreducible
26polynomials. (This result is analogous to the fact that every positive integer has a unique representation as
27the product of powers of prime numbers.) The degree-1 factors correspond to the roots of the polynomial.
28Polynomial congruences.
29Modular reduction and congruences can be defined among polynomials over GF (q), in analogy to the
30definitions for integers given in A.1.1. To reduce a polynomial a (t) modulo a nonconstant polynomial
31m (t), one divides a (t) by m (t) by long division of polynomials and takes the remainder r (t). This
32operation is written
34The remainder r (t) must either equal 0 or have degree smaller than that of m (t).
35If m (t) = t – c for some element c of GF (q), then a (t) mod m (t) is just the constant a (c).
36Two polynomials a (t) and b (t) are said to be congruent modulo m (t) if they have the same result upon
37reduction modulo m (t). This relationship is written
2 171
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
7If m is a positive integer, the binary finite field GF (2m) consists of the 2m possible bit strings of length m.
8Thus, for example,
11For m = 1, the field GF (2) is just the set {0, 1} of integers modulo 2. The addition and multiplication
12operations are given by
+ 0 1 0 1
0 0 1 0 0 0
1 1 0 1 0 1
13Addition.
14For m > 1, addition of two elements is implemented by bitwise addition modulo 2. Thus, for example,
16Multiplication.
17There is more than one way to implement multiplication in GF (2m). To specify a multiplication rule, one
18chooses a basis representation for the field. The basis representation is a rule for interpreting each bit
19string; the multiplication rule follows from this interpretation.
20There are two common families of basis representations; polynomial basis representations and normal
21basis representations.
23In a polynomial basis representation, each element of GF (2m) is represented by a different binary
24polynomial of degree less than m. More explicitly, the bit string (am-1 … a2 a1 a0) is taken to represent the
25binary polynomial
29The addition of bit strings, as defined in A.3.3, corresponds to addition of binary polynomials.
2 172
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Multiplication is defined in terms of an irreducible binary polynomial p(t) of degree m, called the field
2polynomial for the representation. The product of two elements is simply the product of the corresponding
3polynomials, reduced modulo p(t).
4There is a polynomial basis representation for GF (2m) corresponding to each irreducible binary polynomial
5p(t) of degree m. Irreducible binary polynomials exist of every degree. Roughly speaking, every one out of
6m binary polynomials of degree m is irreducible.
8The reduction of polynomials modulo p(t) is particularly efficient if p(t) has a small number of terms. The
9irreducibles with the least number of terms are the trinomials t m + t k + 1. Thus it is a common practice to
10choose a trinomial for the field polynomial, provided that one exists.
11If an irreducible trinomial of degree m does not exist, then the next best polynomials are the pentanomials
12t m + t a + t b + t c + 1. For every m up to 1000, there exists either an irreducible trinomial or pentanomial of
13degree m. Clause A.8 provides a table with an example for each m up to 1000, along with algorithms for
14constructing other irreducibles.
16Normal bases.
18B = { , 2 , 2 , . . ., 2
2 m1
}
19with the property that no subset of B adds to 0. (In the language of linear algebra, the elements of B are
20said to be linearly independent.) There exist normal bases for GF (2m) for every positive integer m.
21The representation of GF (2m) via the normal basis B is carried out by interpreting the bit string (a0 a1 a2 …
22am-1) as the element
23a0 + a1 2 + a2 2 + . . . + am–1 2
2 m1
.
24All of the elements of a normal basis B satisfy the same irreducible binary polynomial p(t). This
25polynomial is called the field polynomial for the basis. An irreducible binary polynomial is called a normal
26polynomial if it is the field polynomial for a normal basis.
28Normal basis representations have the computational advantage that squaring an element can be done very
29efficiently (see Annex A.4.1). Multiplying distinct elements, on the other hand, can be cumbersome in
30general. For this reason, it is common to specialize to a class of normal bases, called Gaussian normal
31bases, for which multiplication is both simpler and more efficient.
32Gaussian normal bases for GF (2m) exist whenever m is not divisible by 8. They include the optimal
33normal bases, which have the most efficient multiplication possible in a normal basis.
34The type of a Gaussian normal basis is a positive integer measuring the complexity of the multiplication
35operation with respect to that basis. The smaller the type, the more efficient the multiplication. For a given
36m and T, the field GF (2m) can have at most one Gaussian normal basis of type T. Thus it is proper to speak
2 173
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1of the type T Gaussian normal basis over GF (2m). See [ABV89] for more information on Gaussian normal
2bases. A table of Gaussian normal bases is given in Annex A.8.1
3The Gaussian normal bases of types 1 and 2 have the most efficient multiplication rules of all normal bases.
4For this reason, they are called optimal normal bases. The type 1 Gaussian normal bases are called Type I
5optimal normal bases, and the type 2 Gaussian normal bases are called Type II optimal normal bases. See
6[Men93a] for more information on optimal normal bases.
8If m > 1 is not divisible by 8, the following algorithm [ABV89] tests for the existence of a Gaussian normal
9basis for GF (2m) of given type. (See also the table in A.8.1.)
11Output: if a type T Gaussian normal basis for GF (2m) exists, the message “True”; otherwise “False.”
12 ii) Set p Tm + 1.If p is not prime then output “False” and stop.Compute via A.2.7 the order k of 2
13 modulo p.Set h Tm / kCompute d := GCD (h, m) via A.2.2
14 6. If d = 1 then output “True”; else output “False.”
15Example: Let m = 4 and T = 3. Then p = 13, and 2 has order k = 12 modulo 13. Since h = 1 is relatively
16prime to m = 4, there does exist a Gaussian normal basis of type 3 for GF (24).
18The following procedure produces the rule for multiplication with respect to a given Gaussian normal basis.
19(See Annex A.6 for a more general method applicable to all normal bases.)
20Input: integers m > 1 and T for which there exists a type T Gaussian normal basis B for GF (2m).
21Output: an explicit formula for the first coordinate of the product of two elements with respect to B.
22 jj) Set p Tm + 1Generate via A.2.8 an integer u having order T modulo pCompute the sequence F
23 (1), F (2), …, F (p–1) as follows:
24 3.1 Set w 1
25 3.2 For j from 0 to T – 1 do
26 Set n w
27 For i from 0 to m – 1 do
28 Set F (n) i
29 Set n 2n mod p
30 Set w uw mod p
31 4. If T is even, then set J 0, else set
m/ 2
32 kk) J :=
k 1
(ak–1 bm/2+k–1 + am/2+k–1 bk–1)Output the formula
p 2
33 c0 = J +
k 1
aF(k+1) bF(p–k)
34Example: For the type 3 normal basis for GF (24), the values of F are given by
2 174
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1F (1) = 0 F (5) = 1 F ( 9) = 0
2F (2) = 1 F (6) = 1 F (10) = 2
3F (3) = 0 F (7) = 3 F (11) = 3
4F (4) = 2 F (8) = 3 F (12) = 2
9The other coordinates of the product are obtained from the formula for c0 by cycling the subscripts modulo
10m. Thus
15The formulae given in A.3.7 for c0, …, cm–1 can be implemented in terms of a single expression. For
17let
18F(u, v)
22 ll) Set (u0 u1 … um–1) (a0 a1 … am–1)Set (v0 v1 … vm–1) (b0 b1 … bm–1)For k from 0 to m – 1 do
23 3.1 Compute
24 ck := F (u, v)
25 3.2 Set u LeftShift(u) and v LeftShift(v), where LeftShift denotes the circular left shift
26 operation.
27 4. Output c := (c0 c1 … cm–1).
28In the above example,
29F (u, v) := u0 (v1 + v2 + v3) + u1 (v0 + v2) + u2 (v0 + v1) + u3 (v0 + v3).
30If
2 175
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
7Exponentiation.
8If k is a positive integer and is an element of GF (2m), then exponentiation is the operation of computing
9 k. Clause A.4.3 contains an efficient method for exponentiation.
10Division.
11If and 0 are elements of the field GF (2m), then the quotient / is the element such that = .
12In the finite field GF (2m), modular division is possible for any denominator other than 0. The set of
13nonzero elements of GF (2m) is denoted GF (2m)*.
15Orders.
16The order of an element of GF (2m)* is the smallest positive integer v such that v = 1. The order always
17exists and divides 2m – 1. If k and l are integers, then k = l in GF (2m) if and only if k l (mod v).
18Generators.
19If v divides 2 m – 1, then there exists an element of GF (2m)* having order v. In particular, there always
20exists an element of order 2m – 1 in GF (2m)*. Such an element is called a generator for GF (2m)* because
21every element of GF (2m)* is some power of .
22Exponentiation and discrete logarithms.
23Suppose that the element of GF (2m)* has order v. Then an element of GF (2m)* satisfies = l for
24some l if and only if v = 1. The exponent l is called the discrete logarithm of (with respect to the base
25). The discrete logarithm is an integer modulo v.
26DL-based cryptography.
27Suppose that is an order-r element of GF (2m)* where r is prime. Then a key pair can be defined as
28follows.
29
30 The private key s is an integer modulo r.
31 The corresponding public key w is an element of GF (2m)* defined by w := s.
32It is necessary to compute a discrete logarithm in order to derive a private key from its corresponding
33public key. For this reason, public-key cryptography based on key pairs of this type relies for its security
34on the difficulty of the discrete logarithm problem. Thus it is an example of DL-based cryptography. The
35difficulty of the discrete logarithm problem is discussed in Annex D.4.1.
2 176
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Field extensions.
2Suppose that d and m are positive integers with d dividing m, and let K be a field GF (2m). Then there are
3precisely 2d elements of K satisfying
4 2d = .
5The set F all of such elements forms a field GF (2d). The field F is called a subfield of K, and K is called
6an extension field of F.
7Suppose that is an element of GF (2m) of prime order r. The prime r is said to be a primitive factor of
82m – 1 if r does not divide 2d – 1 for any d < m dividing m. It follows from the previous paragraph that r is
9primitive if and only if is not an element of any proper subfield of GF (2m). (A proper subfield of a field F
10is any subfield except F itself).
11Example.
12Let K be the field GF (24) given by the polynomial basis with field polynomial p (t) := t 4 + t + 1. Since
13(t 2 + t) 3 = (t 2 + t + 1) 3 = 1,
16When selecting domain parameters for DL-based cryptography over binary fields, it is necessary to begin
17by choosing the following:
18
19 The degree m of the field (so that the field has 2m elements)
20 The prime number r which is to serve as the order of the base point
21These two numbers are related by the condition that r must be a primitive divisor of 2 m – 1 (see Annex
22A.3.9). Moreover, it is a common practice to choose the two numbers to provide comparable levels of
23security. (See Annex D.4.1.4, Note 1.) Each parameter depends on the size of the symmetric keys which
24the DL system is being used to protect.
25The following table lists several common symmetric key lengths. For each length is given a set of
26parameters of m and r which can be used in conjunction with symmetric keys of that length.
27
Key Size m r
40 189 207617485544258392970753527
56 384 442499826945303593556473164314770689
64 506 2822551529460330847604262086149015242689
2 177
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
80 1024 7455602825647884208337395736200454918783366342657
6Polynomial Basis:
7If
12Normal Basis:
20If it is necessary to perform frequent squarings in a fixed polynomial basis, it can be more efficient to use a
21squaring matrix. This is an m-by-m matrix with coefficients in GF (2).
2 178
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
s1,1 s1,m
7S :=
s
m,1 sm,m
8where
d m 2 i ,m j if i m / 2
9si,j := 1 if i m / 2 and 2i j m
0 otherwise.
10If (a0 a1 … am–1) represents the field element , then the representation for 2 is
11(b0 b1 … bm–1) = (a0 a1 … am–1) S.
12A.4.3 Exponentiation
15Output: k.
16 mm) Let k = kr kr–1 ... k1 k0 be the binary representation of k, where the most significant bit kr of k is 1.Set
17 x .For i from r – 1 downto 0 do
18 3.1 Set x x2.
19 3.2 If ki = 1 then set x x.
20 4. Output x.
21There are several modifications that improve the performance of this algorithm. These methods are
22summarized in [Gor98].
23A.4.4 Division
24The quotient / can be computed directly (i.e. in one step by an algorithm with inputs and ), or
25indirectly (by computing the multiplicative inverse –1 and then multiplying it by ). There are two
26common methods of performing division in a finite field GF (2m), one direct and one indirect.
2 179
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1This algorithm produces the quotient directly (also it can be used for multiplicative inversion of , and so
2for indirect division, by using as input 1 in place of ). By r0(t) / r1(t) is meant the quotient upon
3polynomial division, dropping any remainder.
5Output: := /.
6 nn) Set r0(t) p(t)Set r1(t) Set s0(t) 0Set s1(t) While r1(t) 0
7 5.1 Set q(t) r0(t) / r1(t).
8 5.2 Set r2(t) r0(t) + q(t)r1(t)
9 5.3 Set s2(t) s0(t) + q(t)s1(t)
10 5.4 Set r0(t) r1(t)
11 Set r1(t) r2(t)
12 5.5 Set s0(t) s1(t)
13 Set s1(t) s2(t)
14 6. Output := s0(t)
15NOTES
172—The Extended Euclidean Algorithm uses a polynomial basis representation for GF (2m). If a normal basis
18representation is being used, then one can divide using this algorithm only by converting the inputs and to a
19polynomial basis representation, performing the division, and converting the output back to normal basis form. (See
20Annex A.7.1 for methods of converting between different basis representations.)
21Method II: Exponentiation.
22The multiplicative inverse of can be found efficiently in either basis representation via
23 –1 = k,
24where k is any positive integer satisfying
28If a general-purpose exponentiation algorithm such as A.4.3 is used, then the best choice is k := r – 1.
29However, there is also a specialized algorithm [ITT86] for exponentiating to the power k = 2m – 2, which is
30more efficient than the generic method. The efficiency improvements are especially significant when
31squaring can be done quickly, e.g. in a normal basis representation. The procedure is given below.
34 oo) Let m – 1 = br br–1 ... b1 b0 be the binary representation of m – 1, where the most significant bit br of
35 m – 1 is 1.Set and k 1For i from r – 1 downto 0 do
36 3.1 Set
2 180
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 3.2 For j = 1 to k do
2 3.2.1 Set 2
3 3.3 Set and k 2k
4 3.4 If bi = 1, then set 2 and k k + 1
5 4. Output 2.
6A.4.5 Trace
8Tr() = + 2 + 2 + ... + 2 .
2 m–1
9The value of Tr () is 0 for half the elements of GF (2m), and 1 for the other half.
10The trace can be computed efficiently as follows.
11Normal Basis:
23 = (m–1…10)
24where each coordinate
25j = Tr (t j)
26is computed via the basic algorithm. Subsequent traces can be computed via
27Tr () = ,
28where the “dot product” of the bit strings is given by bitwise AND (or bitwise multiplication).
29A.4.6 Half-Trace
10z2 + z =
11has 2 – 2T solutions over GF (2m), where T = Tr (). Thus, there are either 0 or 2 solutions. If z is one
12solution, then the other solution is z + 1. In the case = 0, the solutions are 0 and 1.
13The following algorithms compute a solution if one exists.
14Input: a field GF (2m) along with a polynomial or normal basis for representing its elements; an element
15 0.
22If m is odd, then compute z := half-trace of via A.4.6. For m even, proceed as follows.
2 182
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
5If k is a positive integer and f(t) and m(t) are polynomials with coefficients in the field GF (q), then f(t)k
6mod m(t) can be computed efficiently by the binary method outlined below.
7Input: a positive integer k, a field GF (q), and polynomials f(t) and m(t) with coefficients in GF (q).
9 uu) Let k = kr kr–1 ... k1 k0 be the binary representation of k, where the most significant bit kr of k is 1.Set
10 u(t) f(t) mod m(t).For i from r – 1 downto 0 do
11 3.1 Set u(t) u(t)2 mod m(t).
12 3.2 If ki = 1 then set u(t) u(t) f(t) mod m(t).
13 4. Output u(t).
14There are several modifications that improve the performance of this algorithm. These methods are
15summarized in [Gor98].
17If f(t) and g(t) 0 are two polynomials with coefficients in the field GF (q), then there is a unique monic
18polynomial d(t) of largest degree which divides both f(t) and g(t). The polynomial d(t) is called the
19greatest common divisor or G.C.D. of f(t) and g(t). The following algorithm computes the G.C.D. of two
20polynomials.
21Input: a finite field GF (q) and two polynomials f(t), g(t) 0 over GF (q).
22Output: d(t) = GCD( f(t), g(t)).
31Let f(t) be a polynomial with coefficients in the field GF (p), and suppose that f(t) factors into distinct
32irreducible polynomials of degree d. (This is the special case needed in A.14.) The following algorithm
33finds a random degree-d factor of f(t) efficiently.
34Input: a prime p > 2, a positive integer d, and a polynomial f(t) which factors modulo p into distinct
35irreducible polynomials of degree d.
2 183
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
12Let f(t) be a polynomial with coefficients in the field GF (2), and suppose that f(t) factors into distinct
13irreducible polynomials of degree d. (This is the special case needed in A.14.) The following algorithm
14finds a random degree-d factor of f(t) efficiently.
15Input: a positive integer d, and a polynomial f(t) which factors modulo 2 into distinct irreducible
16polynomials of degree d.
29If f(t) is a polynomial with coefficients in the field GF (2r), then f(t) can be tested efficiently for
30irreducibility using the following algorithm.
32Output: the message “True” if f(t) is irreducible; the message “False” otherwise.
2 184
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 3. Output “True.”
3If f(t) is an irreducible polynomial modulo 2 of degree d dividing m, then f(t) has d distinct roots in the field
4GF (2m). A random root can be found efficiently using the following algorithm.
5Input: an irreducible polynomial modulo 2 of degree d, and a field GF (2m), where d divides m.
18Given a field F = GF (2d), the following algorithm embeds F into an extension field K = GF (2de).
19Input: integers d and e; a (polynomial or normal) basis B for F = GF (2d) with field polynomial p(t); a
20(polynomial or normal) basis for K = GF (2de).
2 m 1
28 := a0 a12 a22 am12 ,
33A general normal basis is specified by its field polynomial p(t) (see Annex A.3.5). The rule for
34multiplication with respect to a general normal basis is most easily described via a multiplication matrix.
2 185
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The multiplication matrix is an m-by-m matrix with entries in GF (2). A description of how to multiply
2using the multiplication matrix is given in A.6.4.
4The following algorithm checks whether an irreducible polynomial p(t) over GF (2) is normal, and if so,
5outputs two matrices to be used later in deriving the multiplication rule for the corresponding normal basis.
7Output: if p(t) is normal, two m-by-m matrices over GF (2). If not, the message “not normal.”
12 …
19If m is a multiple of 8, then the Gaussian normal basis construction of A.3 does not apply. In this case (or
20in any case where a non-Gaussian normal basis is desired), it is possible to find a normal basis by
21searching for a normal polynomial of degree m over GF (2).
22The procedure is to produce an irreducible polynomial of degree m over GF (2), test it for normality via
23A.6.1, and repeat until a normal polynomial is found. To produce an irreducible, one can use the table in
24Annex A.8.1, the random search routine in A.8.2, or one of the techniques in A.8.3 through A.8.5.
25The probability of a randomly chosen irreducible polynomial of degree m over GF (2) being normal is at
26least 0.2 if m 2000, and is usually much higher. Thus one expects to have to try no more than about five
27irreducibles before finding a normal polynomial.
29The following algorithm computes the multiplication matrix of a basis B that has been deemed “normal” by
30A.6.1.
2 186
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
5 1. Set
0 1 0 0
0 0 1 0
6 C: .
0 0 0 1
c0 c1 c2 c m1
7 f) Compute D := ACB over GF (2). (Let di,j denote the (i, j)th entry of D, for 0 i,j < m.)Set i,j := d j–
8 i,–i for each i and j, where each subscript is regarded as an integer modulo m. Output
0 1 0 0
A 0 0 1 0
11 1 ,
1 1 1
0 0 0 1
12so that
1 1 1 1
1 0 0 0
13 B A
1
.
0 1 0 0
0 0 0 1
14Also
0 1 0 0
0 0 1 0
15 C ,
0 0 0 1
1 1 1 1
16so that
2 187
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
0 1 0 0
0 0 0 1
1 D ACB .
1 1 1 1
0 0 1 0
2Therefore
0 0 1 0
0 0 1 1
3 M .
1 1 0 0
0 1 0 1
4In the case of a Gaussian normal basis, the multiplication matrix M can be written down immediately from
5the explicit multiplication rule. For 0 i < m and 0 j < m, i,j is 1 if aibj appears in the formula for c0, and
60 otherwise.
7Example: If B is the type 3 normal basis over GF (24), then it was found in A.3.7 that, if
0 1 1 1
1 0 1 0
12 M .
1 1 0 0
1 0 0 1
13A.6.4 Multiplication
14The following algorithm implements the multiplication of two elements of a field GF (2m) represented in
15terms of a normal basis.
16Input: the multiplication matrix M for the field GF (2m); field elements a = (a0 a1 … am–1) and
17b = (b0 b1 … bm–1).
21 ck := x M ytr
2 188
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 3.2 Set x LeftShift(x) and y LeftShift(y), where LeftShift denotes the circular left shift
2 operation.
3 4. Output c = (c0 c1 … cm–1).
4Example: Let GF (24) be a root of the normal polynomial p(t) = t4 + t3 + t2 + t + 1. Consider
5multiplying the elements
6a = (1000) =
7and
8b = (1101) = + 2 + 8.
9The multiplication matrix for p(t) was found in A.6.3 to be
0 0 1 0
0 0 1 1
10 M .
1 1 0 0
0 1 0 1
11Thus
1
12c0 = (1000) M
1 = 0,
0
1
1
13c1 = (0001) M
0 = 1,
1
1
0
14c2 = (0010) M
1 = 1,
1
1
1
1
15c3 = (0100) M = 1,
1
0
2 189
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
7Suppose that a user has received a field element that is represented in terms of the basis B0, while the user
8himself uses basis B1 for his own computations. This user must now perform a change of basis from B0 to
9B1 on this element. This can be accomplished using a change-of-basis matrix from B0 to B1. This is an m-
10by-m matrix with entries in GF (2).
11Suppose that is the change-of-basis matrix from B0 to B1, and that u is the bit string representing
12GF (2m) in terms of B0. Then
13v = u
15If is the change-of-basis matrix from B0 to B1, then the inverse –1 of the matrix over GF (2) is the
16change-of-basis matrix from B1 to B0. Thus, given a bit string v representing GF (2m) in terms of B1,
17the bit string
18u = v –1
20If is the change-of-basis matrix from B0 to B1, and is the change-of-basis matrix from B1 to B2, then
21the matrix product = is the change-of-basis matrix from B0 to B2.
22The algorithm for calculating the change-of-basis matrix is given in A.7.3. A special case is treated in
23A.7.4.
24Example: Suppose that B0 is the Type I optimal normal basis for GF (24) and B1 is the polynomial basis
25with field polynomial t 4 + t + 1. Then the change-of-basis matrix from B0 to B1 is
1 1 0 0
1 1 1 1
26
1 0 1 0
1 0 0 0
27(see Annex A.7.3). If is the element of GF (24) represented by (1001) with respect to B0, then its
28representation with respect to B1 is
29(1001) = (0100).
2 190
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
0 0 0 1
1 0 0 1
1
1
.
0 0 1 1
1 1 1 1
2If is the element of GF (24) represented by (1101) with respect to B1, then its representation with respect
3to B0 is
4(1101) –1 = (0111).
6In order to compute the change-of-basis matrix for conversion to or from a normal basis B, it is necessary
7to compute the field polynomial for that basis (see Annex A.3.5).
8If GF (2m) has a type T Gaussian normal basis over GF (2), the following algorithm efficiently produces its
9field polynomial.
10Input: positive integers m and T for which there exists a type T Gaussian normal basis for GF (2m) over
11GF (2).
13
14 I. T = 1. (Type I optimal normal basis)
15 1. Set p(t) t m + t m–1 + … + t + 1.
16 2. Output p(t).
17 II. T = 2. (Type II optimal normal basis)
18 1. Set q(t) 1.
19 2. Set p(t) t + 1.
20 3. For i = 1 to m – 1 do
21 r(t) q(t)
22 q(t) p(t)
23 p(t) := t q(t) + r(t)
24 4. Output p(t).
25 III. T 3. (Sub-optimal Gaussian normal basis)
26 1. Set p T m + 1.
27 2. Generate via A.2.8 an integer u having order T modulo p.
28 3. For k from 1 to m do
29 3.1 Compute
T 1
2 k u j i
30 ek =
j 0
exp
p
.
31 4. Compute the polynomial
m
32 f(t) := (t e ) .
k 1
k
2 191
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
9e1 := e 2 i /13
+ e 6 i /13
– e 5 i /13
11e2 := e 4 i /13
+ e 12 i /13
+ e 10 i /13
13e3 := e 8 i /13
– e 11 i /13
– e 7 i /13
15e4 := – e i /13
– e 3 i /13
– e 9 i /13
21The following algorithm efficiently calculates the change-of-basis matrix from a (polynomial or normal)
22basis B0 to one’s own (polynomial or normal) basis B1.
23Input: a field degree m; a (polynomial or normal) basis B0 with field polynomial p0(u); a (polynomial or
24normal) basis B1 with field polynomial p1(t). (Note: in the case of a Gaussian normal basis, the field
25polynomial can be computed via A.7.2.)
27 h) Let u be a root of p0(u) represented with respect to B1. (u can be computed via A.5.6.)
28 2. Define the elements e0, . . ., em–1 via
2 192
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
m1
1 1=
j0
m1, j ej
m1
2 u=
j0
m 2 , j ej
3
m1
4 u m–2 = j 0
1, j ej
m1
5 u m–1 = j0
0, j ej
6 by repeated multiplication by u.
7 — If B0 is a normal basis, then compute
m1
8 u=
j0
0, j e j
m1
9 2
u = 1, j e j
j 0
m1
10 22
u = 2, j e j
j0
11
m1
12 u 2m–1 =
j 0
m1, j e j
13 by repeated squaring.
14 5. Output
0, 0 0,1 0,m1
1, 0 1,1 1,m1
15
m1, 0 m1,1 m1,m1
16Example: Suppose that B0 is the Type I optimal normal basis for GF (24), and B1 is the polynomial basis
17modulo p1(t) = t 4 + t + 1. Then a root of p0(u) = u 4+ u 3 + u 2 + u + 1 is given by u = t 3 + t 2. By repeated
18squaring modulo p1(t),
19u = t3 + t2
2 3 2
20u = t + t + t + 1
4
21u = t3 + t
22u 8 = t3
23so that
2 193
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 1 0 0
1 1 1 1
1 : .
1 0 1 0
1 0 0 0
2Example: Suppose that B0 is polynomial basis modulo p0(u) = u5 + u4 + u2 + u + 1, and B1 is the polynomial
3basis modulo p1(t) = t5 + t2 + 1. Then a root of p0(u) is given by u = t + 1. Thus
41 = 1
5u = t + 1
2
6u = t2 + 1
3 3 2
7u = t + t + t + 1
8u 4 = t4 + 1,
9so that
1 0 0 0 1
0 1 1 1 1
10 : 0 0 1 0 1 .
0 0 0 1 1
0 0 0 0 1
11Example: Suppose that B0 is polynomial basis modulo p0(u) = u5 + u2 + 1, and B1 is the Type II optimal
12normal basis for GF (25). Then a root of p0(u) is given by u = 2 + 4 + 8 + 16. Thus
131 = + 2
+ 4
+ 8
+ 16
14u = 2
+ 4
+ 8
+ 16
15u 2
= + 4
+ 8
+ 16
16u 3
= + 4
+ 16
17u 4 = + 2 + 8 + 16,
18so that
1 1 0 1 1
1 0 1 0 1
19 : 1 0 1 1 1 .
0 1 1 1 1
1 1 1 1 1
20NOTE—If both B0 and B1 are normal bases, then it is sufficient to perform the first computation
m1
21u =
j 0
0, j e j
2 194
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1and omit the rest. This expression provides the top row of the matrix , and subsequent rows are obtained by right
2cyclic shifts.
3Example: Suppose that B0 is the type 3 Gaussian normal basis for GF (24), and B1 is the Type I optimal
4normal basis for GF (24). Then a root of p0(u) = u 4+ u 3 + 1 is given by u = + 4 + 8. Thus
1 0 1 1
1 1 0 1
5 : .
1 1 1 0
0 1 1 1
7If one is representing elements of GF (2m) with respect to the normal basis B1, and it is desired to perform
8division via the Euclidean algorithm (see Annex A.4.4), then it is necessary to construct a change-of-basis
9matrix from some polynomial basis B0 to the basis B1. If another means of division is not available, it is
10necessary to construct this matrix using an algorithm other than that of A.7.3 (which requires division in its
11first step). This can be done as follows.
12Input: a field degree m; a normal basis B1 with field polynomial p(t). (Note: if B1 is a Gaussian normal
13basis, then p(t) can be computed via A.7.2.)
14Output: the change-of-basis matrix from B0 to B1, where B0 is the polynomial basis with field
15polynomial p(t).
0, 0 0,1 0,m1
1, 0 1,1 1,m1
17 :
m1, 0 m1,1 m1,m1
18where
1 if i m 1
19 i , j 1 if 2 j ( i 2 )(mod m 1)
0 otherwise
20In the general case, the algorithm of A.7.3 can be used, with Step 1 replaced by
21 a)
2 m1
22 b) 1. Set u with respect to B1 = {, 2, 2 , …, 2 }.
2 195
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2The matrix multiplication technique described in A.7.1 requires one to store m2 binary coefficients for the
3matrix or –1 and perform linear algebra for each conversion. The techniques below, which are based on
4work by Kaliski and Yin [KY98], require much smaller storage, after a setup operation that depends only
5on the choice of basis, at the expense of a few extra operations per conversion. They generally utilize field
6multiplication in the internal basis rather than linear algebra; if field multiplication in the internal basis is
7optimized, the performance of these algorithms is comparable with the matrix multiplication method. While
8the setup operation for conversion in one direction is simpler than computing the change-of-basis matrix,
9the typical setup operation in the other direction is more complex, involving the computation of a
10multiplication matrix and a matrix inverse in addition to the change-of-basis matrix.
11
12As in A.7.1, let B1 be the basis in which the user performs field operations, and B0 be the other basis. A.7.6
13considers the task of importing (converting a representation in B0 to a representation B1) and A.7.8 that of
14exporting (converting a representation in B1 to a representation in B0). The two tasks are inherently
15different, because it is assumed that the user can efficiently perform field operations in B1 but not in B0.
16Related methods for finite fields other than binary fields and representations other than polynomial and
17normal basis may be found in Kaliski and Yin [KY98] and Kaliski and Liskov [KL99].
19Input: A field degree m; a (polynomial or normal) basis B0 with field polynomial p0(t); a bit string a of
20length m (Note: in the case of a Gaussian normal basis, the field polynomial can be computed via A.7.2.)
21Output: The element v GF(2m) (represented in the internal basis B1) such that the representation of v in
22B0 is a
2 196
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 1. Let u be a root of p0(t) represented with respect to B1. (u can be computed via A.5.6.)
2
3 Conversion (per each element)
4
5 2. Let a = (a0 a1 a2 … am-1).
6 3. If a0 = 0, then set v 0; else set v u.
7 4. For i from 1 to m – 1 do
8 4.1 Set v v 2.
9 4.2 If ai = 1, set v v + u.
10 5. Output v.
11Example (B0 is a Polynomial Basis): Suppose, as in the second example in A.7.3, that B0 is the polynomial
12basis modulo p0(u) = u5 + u4 + u2 + u + 1, and B1 is the polynomial basis modulo p1(t) = t5 + t2 + 1. Then a
13root of p0(u) is given by u = t + 1, and let this be the root selected in the setup operation.
14Suppose a = (10001) is the bit string to be converted. Then the conversion operation sets v 1 in step 4,
15and in step 5 computes the following sequence of values:
16
i ai v
3 0 t+1
2 0 t2 + 1
1 0 t3 + t2 + t + 1
0 1 t4
17The result, v = t4, matches the bit string that would be computed by matrix multiplication:
18(10001) = (10000).
19Example (B0 is a Normal Basis): Suppose, as in the first example in A.7.6, that B0 is the Type I optimal
20normal basis for GF(24), and B1 is the polynomial basis modulo p1(t) = t4 + t + 1. Then a root of p0(u) = u4 +
21u3 + u2 + u + 1 is given by u = t3 + t2; let this be the root selected in the setup operation.
22Suppose a = (1001) is the bit string to be converted. Then the conversion operation sets v t3 + t2 in step
234, and in step 5 computes the following sequence of values:
24
i ai v
1 0 t3 + t2 + t + 1
2 0 t3 + t
3 1 t2
25The result, v = t2, matches the bit string that would be computed by matrix multiplication:
2 197
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1(1001) = (0100).
2NOTES
31—Step 1 of the above algorithms needs be performed only once for each pair B0 and B1; the value u can then be stored
4and used every time an element needs to be imported. This is analogous to (but more space-efficient than) storing the
5matrix to perform the import operation. The value u need not be kept secret, but it must be protected from
6modification to ensure the correctness of subsequent per-element conversion operations. (This is no different than for
7the matrix multiplication technique, where the matrix must be protected from modification but need not be kept secret.)
82—This algorithm may be invoked to facilitate division using the Extended Euclidean algorithm of A.4.4. Specifically,
9when B1 is a normal basis, one needs to export elements and to a polynomial basis B0 before computing = /
10via the Extended Euclidean algorithm, and then import back to B1. In that case, the best choice for B0 is the
11polynomial basis with polynomial f(t), where f(t) is the normal polynomial for B1. Then, in step 1, u should not be
12computed via A.5.6; instead, u will simply be the element whose representation with respect to B1 is (100…0).
13(Computing u via A.5.6 would require one to use division and could thus cause infinitely deep recursion if division is
14again implemented via basis conversion combined with the Extended Euclidean algorithm.)
16The export method presented in A.7.8 requires a computation of the (leftmost) multiplication matrix M for
17the basis B1. For a polynomial basis, the matrix can be computed by the following algorithm. An algorithm
18for a normal basis is given in A.6.3.
20Output: The matrix M such that mij is the leftmost bit of the product of the i-th and j-th basis vectors of B1
21
22 1. Let t be the root of the polynomial defining B1 (t is represented in B1 by the m-bit string (00…
23 010)).
24 2. Let r := t m–1 (represented in B1 by the m-bit string (100…0)).
25 3. Let b0 := b1 := … := bm–2 := 0 and let bm–1 := 1.
26 4. For i from m to 2m – 2 do
27 4.1 Let r := rt.
28 4.2 Let bi be the leftmost bit of the representation of r in B1.
29 5. Set
30
31
32 6. Output M.
33Example: Continuing the first example in A.7.6, let B1 be the polynomial basis modulo p1(t) = t5 + t2 + 1.
34Then the algorithm in step 4 computes:
35
i r bi
5 t2 + 1 0
6 t3 + t 0
7 t4 + t2 1
8 t3 + t2 + 1 0
2 198
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2M := .
4Input: A field degree m; a (polynomial or normal) basis B0 with field polynomial p0(t); an element v
5GF(2m) (represented in the internal basis B1). (Note: in the case of a Gaussian normal basis, the field
6polynomial can be computed via A.7.2.)
2 199
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 5. For i = m – 1 downto 1
2 5.1 Compute w := vz and let ai be the leftmost bit of the representation of w in B1.
3 5.2 Set v := v 2.
4 6. Compute w := vz and let a0 be the leftmost bit of the representation of w in B1.
5 7. Output a := (a0 a1 a2 … am1).
6Example (B0 is a Polynomial Basis): Continuing the first example in A.7.6, let B0 be the polynomial basis
7modulo p0(u) = u5 + u4 + u2 + u + 1 and let B1 be the polynomial basis modulo p1(t) = t5 + t2 + 1. Let the root
8of p0(u) selected be u = t + 1. The setup operation computes
9 :=
10w := u1 = t4 + t3 + t2
11 := 1 =
12s = (11111)
13M :=
14M1 :=
15z = s M–1 = (11100)
16z = t4 + t3 + t2
18Suppose v = t4 is the field element to be converted. Then the conversion operation sets v t4 + t + 1 in step
195, and in step 6 computes the following sequence of values:
20
i ai v
0 1 t2 + 1
1 0 t+1
2 0 1
3 0 t4 + t3 + t2
22Example (B0 is a Normal Basis): Continuing the second example in A.7.6, let B0 be the Type I optimal
23normal basis for GF(24) and let B1 be the polynomial basis modulo p1(t) = t4 + t + 1. Let the root of p0(u)
24selected be u = t3 + t2. The setup operation computes
25 :=
26 := 1 =
27s = (1111)
2 200
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1M :=
2M1 :=
3z = s M–1 = (1110)
4z = t3 + t2 + t
5Suppose v = t2 is the field element to be converted. Then the conversion operation in step 5 computes the
6following sequence of values:
i w ai v
3 t3 + t2 + 1 1 t+1
2 1 0 t2 + 1
1 t+1 0 t
8In step 6, the conversion operation computes w = t3 + t2 + t + 1 and a0 = 1. The result is a = (1001).
9NOTES
101—Steps 1-4 of the above algorithms need be performed only once for each pair B0 and B1; the value z (and w, in the
11case of polynomial basis) can then be stored and used every time an element needs to be exported. This is analogous to
12(but more space-efficient than) storing the matrix –1 to perform the export operation. (Note that the matrix inversion
13can be avoided if –1 is computed directly as the change-of-basis matrix from B1 to B0 via A.7.3.) Similarly to the
14import operation, the value z (and w, in the polynomial case) need not be kept secret but must be protected from
15modification.
162—The per-element conversion operations in both algorithms (steps 5-7 of the first algorithm and steps 5-6 of the
17second) involve only finite field operations. An alternative approach that is also storage-efficient combines finite field
18operations and dot product operations (a dot product a b of two m-bit vectors a = (a0 a1 a2 … am-1) and b = (b0 b1 b2 …
19bm-1) is a single bit defined as a0 b0 a1 b1 … am-1 bm-1). For a polynomial basis, steps 5-7 would be replaced with
20
21 5. Set e 1 (the element one of GF(2m), represented with respect to B1).
22 6. For i = 0 to m – 2
23 6.1 Let v be the m-element bit string representing v in B1, and compute ai := v s.
24 6.2 If ai = 1, then set v v + e.
25 6.3 Set v := vw.
26 7. Let v be the m-element bit string representing v in B1, and compute am–1 := v s.
27For a normal basis, steps 5-6 would be replaced with
28
29 5. For i = m – 1 downto 1
30 5.1 Let v be the m-element bit string representing v in B1, and compute ai := v s.
31 5.2 Set v := v 2.
32 6. Let v be the m-element bit string representing v in B1, and compute a0 := v s.
33In both alternatives, the element z is not needed, so steps 3 and 4 of the algorithm can be omitted and A.7.7 is not
34needed.
2 201
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
13—If this subroutine is invoked to facilitate division using the Extended Euclidean algorithm of A.4.4 (as described in
2Note 2 of A.7.6), then in step 1, u and should be computed via A.7.4 rather than A.7.3 (u will simply be the element
3whose representation with respect to B1 is (100…0)). w = u–1 should be computed by raising u to the power 2m – 2 via
4A.4.3. (Computing w or the division in A.7.3 via the extended Euclidean algorithm would require one to use basis
5conversion again, and could thus result in infinitely deep recursion.)
8The following table provides irreducible polynomials modulo 2 that are minimal, in the sense that they
9have as few terms as possible and that those terms are of the smallest possible degree. More precisely, if an
10irreducible binary trinomial t m + t k + 1 exists, then the minimal possible value of k is listed; if no such
11trinomial exists, then a pentanomial t m + t a + t b + t c + 1 is listed. In the latter case, the value of a is
12minimal; the value of b is minimal for the given a; and c is minimal for the given a and b. In addition, for
13each m not divisible by 8 is given the minimal type among Gaussian normal bases for GF (2m).
14The optimal normal bases are type 1 and type 2 Gaussian normal bases (see Annex A.3.5). In the cases
15where both type 1 and type 2 bases exist, they are both listed in the table.
16
2 202
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 203
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 204
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 205
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 206
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2The basic method for producing an irreducible polynomial modulo 2 of degree m is as follows: generate a
3random polynomial (perhaps subject to certain conditions, such as number of terms), test for irreducibility
4(via A.5.5 with r = 1), and repeat until an irreducible is found. The polynomial f(t) should satisfy the
5following three conditions, since these are necessary for irreducibility modulo 2.
6
7 i) f(t) must have an odd number of (nonzero) terms.
8 ii) The constant term of f(t) must be 1.
9 iii) There must be at least one odd-degree term.
10If a random f(t) of degree at most m satisfies these conditions, then the probability that f(t) is irreducible is
11roughly 4 / m. Thus one can expect to find an irreducible after m / 4 random tries.
13If f(t) is an irreducible of degree m, then so are the following five polynomials.
m
14g(t) = t f(1 / t)
15h(t) = g(t + 1)
m
16j(t) = t h(1 / t)
17k(t) = j(t + 1)
m
18l(t) = t k(1 / t)
19 = f(t + 1)
20Example:
5 2
21f(t) = t + t + 1
5 3
22g(t) = t + t + 1
5 4 3 2
23h(t) = t + t + t + t + 1
5 3 2
24j(t) = t + t + t + t + 1
5 4 3
25k(t) = t + t + t + t + 1
5 4 2
26l(t) = t + t + t + t + 1
27Another construction is as follows. Suppose that f(t) is an irreducible of odd degree m. Define the
28polynomials h0(t), h1(t), h2(t) by
30Then
2 207
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1More generally, if r is an odd number relatively prime to 2m – 1, then define h0(t), …, hr–1(t) by
r 1
2f(t) =
k 0
t k hk(t r).
6Mi,j = wi–j(t)
7where the subscripts of w are taken modulo r. Then the determinant of M is an irreducible of degree m.
9If m = 2d, then one can produce an irreducible of degree m more efficiently by generating an irreducible of
10degree d and using the following degree-doubling technique.
11If
12p(t) = t d + t d–1 + 1 + t
i
ki
16Examples:
3 2
17p(t) = t + t + 1,
6 4 3 2
18P(t) = t + t + t + t + 1.
5 4 3
19 p(t) = t + t + t + t + 1,
20P(t) = t 10 + t 8 + t 6
+ t 5
+ t 4
+ t 3
+ t 2
+ t + 1.
5 4 2
21p(t) = t + t + t + t + 1,
10 8 5
22P(t) = t + t + t + t + 1.
23If an irreducible f(t) is not of the form required for degree doubling, then it may be used to construct one
24that is suitable via the methods of A.8.3. In particular, if m = 2d with d odd, then either f(t) or f(t + 1) is of
25the suitable form.
28 c) If f(t) has a degree d – 1 term then set p(t) f(t); else set p(t) f(t + 1)
29 2. Apply degree doubling to p(t) and output the result.
2 208
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The degree doubling technique can often be applied more than once. The following algorithm treats a
2family of cases in which this is possible.
3Input: an irreducible f(t) of odd degree d satisfying at least one of the following three conditions:
4
5 i) f(t) contains both degree 1 and degree d – 1 terms.
6 ii) f(t) contains a degree 1 term and contains an even number of odd-degree terms in all.
7 iii) f(t) contains a degree d – 1 term and contains an odd number of odd-degree terms in all.
8Output: an irreducible of degree 4d.
9 d) If f(t) satisfies (iii) then set p(t) f(t); else set p(t) t d f(1 / t)Apply degree doubling to p(t) to
10 produce an irreducible P(t) of degree 2d.Set g(t) P(t + 1).Set h(t) t 2d g(1 / t).Apply degree
11 doubling to h(t) and output the result.
13A search for irreducible trinomials should take into account the following restrictions on which trinomials
14can be irreducible modulo 2.
15Suppose the trinomial to be checked is f(t) = t m + t k + 1, where m > k > 0. (Note that, since f(t) is
16irreducible if and only if t m + t m–k + 1 is, then only half the possible k need to be checked. For instance, it
17is sufficient to check for k m / 2.) Then f(t) is reducible in all of the following cases.
18 e) m and k are both even.m is a multiple of 8.m = hn, and k = 2h or (n – 2)h, for some odd number n, h
19 such that n h (mod 8).k = 2h or m – 2h for some h not dividing m, and m 3 (mod 8).m = 2n
20 where n is odd and n k (mod 4), except for the polynomials t 2k + t k + 1 with k a power of 3. (All
21 of these polynomials are irreducible.)
23A.9.1 Introduction
24A plane curve is defined to be the set of points satisfying an equation F (x, y) = 0. The simplest plane
25curves are lines (whose defining equation has degree 1 in x and y) and conic sections (degree 2 in x and y).
26The next simplest are the cubic curves (degree 3). These include elliptic curves, so called because they
27arose historically from the problem of computing the circumference of an ellipse. (Note: see [Sil86] for a
28mathematically precise definition of “elliptic curve.” This Standard restricts its attention to cubic plane
29curves, although other representations could be defined. The coefficients of such a curve must satisfy a
30side condition to guarantee the mathematical property of nonsingularity. The side condition is given below
31for each family of curves.)
32In cryptography, the elliptic curves of interest are those defined over finite fields. That is, the coefficients
33of the defining equation F (x, y) = 0 are elements of GF (q), and the points on the curve are of the form P =
34(x, y), where x and y are elements of GF (q). Examples are given below.
36There are several kinds of defining equations for elliptic curves, but the most common are the Weierstrass
37equations.
2 209
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 For the prime finite fields GF (p) with p > 3, the Weierstrass equation is
3 y 2 = x 3 + ax + b
4 where a and b are integers modulo p for which 4a 3 + 27b 2 ( 0 (mod p).
5
6 For the binary finite fields GF (2m), the Weierstrass equation is
7 y 2 + xy = x 3 + ax 2 + b
12Given a Weierstrass equation, the elliptic curve E consists of the solutions (x, y) over GF (q) to the defining
13equation, along with an additional element called the point at infinity (denoted O). The points other than O
14are called finite points. The number of points on E (including O) is called the order of E and is denoted by
15#E (GF (q)).
17y 2 = x 3 + 10 x + 5
19{O, (1,4), (1,9), (3,6), (3,7), (8,5), (8,8), (10,0), (11,4), (11,9)}.
22y 2 + xy = x 3 + (t + 1) x 2 + 1
23over the field GF (23) given by the polynomial basis with field polynomial t 3 + t + 1 = 0. Then the points
24on E are
32There is an addition operation on the points of an elliptic curve which possesses the algebraic properties of
33ordinary addition (e.g. commutativity and associativity). This operation can be described geometrically as
34follows.
2 210
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
( x , y ) if q p prime,
2– P =
( x , x y ) if q 2 .
m
3Then the sum P + Q of the points P and Q is the point R with the property that P, Q, and –R lie on a
4common line.
6The point at infinity O plays a role analogous to that of the number 0 in ordinary addition. Thus
7P + O = P,
8P + (– P) = O
10Full addition.
11When implementing the formulae for elliptic curve addition, it is necessary to distinguish between
12doubling (adding a point to itself) and adding two distinct points that are not inverses of each other,
13because the formulae are different in the two cases. Besides this, there are also the special cases involving
14O. By full addition is meant choosing and implementing the appropriate formula for the given pair of
15points. Algorithms for full addition are given in A.10.1, A.10.2 and A.10.8.
16Scalar multiplication.
17Elliptic curve points can be added but not multiplied. It is, however, possible to perform scalar
18multiplication, which is another name for repeated addition of the same point. If n is a positive integer and
19P a point on an elliptic curve, the scalar multiple nP is the result of adding n copies of P. Thus, for
20example, 5P = P + P + P + P + P.
21The notion of scalar multiplication can be extended to zero and the negative integers via
24Orders.
25The order of a point P on an elliptic curve is the smallest positive integer r such that rP = O. The order
26always exists and divides the order of the curve #E(GF (q)). If k and l are integers, then kP = lP if and only
27if k l (mod r).
28Elliptic curve discrete logarithms.
29Suppose that the point G on E has prime order r where r 2 does not divide the order of the curve #E(GF (q)).
30Then a point P satisfies P = lG for some l if and only if rP = O. The coefficient l is called the elliptic curve
31discrete logarithm of P (with respect to the base point G). The elliptic curve discrete logarithm is an
32integer modulo r.
33EC-based cryptography.
2 211
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Suppose that the base point G on E has order r as described in the preceding paragraph. Then a key pair
2can the defined as follows.
3
4 The private key s is an integer modulo r.
5 The corresponding public key W is a point on E defined by W := sG.
6It is necessary to compute an elliptic curve discrete logarithm in order to derive a private key from its
7corresponding public key. For this reason, public-key cryptography based on key pairs of this type relies
8for its security on the difficulty of the elliptic curve discrete logarithm problem. Thus it is an example of
9EC-based cryptography. The difficulty of the elliptic curve discrete logarithm problem is discussed in
10Annex D.4.2.
12The discrete logarithm problem in finite fields GF (q)* and the elliptic curve discrete logarithm are in some
13sense the same abstract problem in two different settings. As a result, the primitives and schemes of DL
14and EC based cryptography are closely analogous to each other. The following table makes these analogies
15explicit.
DL EC
17The most difficult part of generating EC parameters is finding a base point of prime order. Generating such
18a point requires knowledge of the curve order n = #E(GF (q)). Since r must divide n, one has the following
19problem: given a field F = GF (q), find an elliptic curve defined over F whose order is divisible by a
20sufficiently large prime r. (Note that “sufficiently large” is defined in terms of the desired security; see
21Annex A.9.3 and D.4.2.) This clause discusses this problem.
22Basic facts.
23 If n is the order of an elliptic curve over GF (q), then the Hasse bound is
24 q–2 q + 1 n q + 2 q + 1.
2 212
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 If q is a prime p, let n be the order of the curve y 2 = x 3 + ax + b, where a and b are both nonzero.
3 Then if 0, the order of the curve y 2 = x 3 + a 2x + b 3 is n if is a square modulo p and
4 2p + 2 – n otherwise. (This fact allows one to replace a given curve by one with the same order
5 and satisfying some extra condition, such as a = p – 3 which will be used in A.10.4.) In the case b =
6 0, there are four possible orders; in the case a = 0, there are six. (The formulae for these orders can
7 be found in Step 6 of A.14.2.3.)
8 If q = 2m, let n be the order of the curve y 2 + xy = x 3 + ax 2 + b, where a and b are both nonzero.
9 Then if 0, the order of the curve y 2 + xy = x 3 + (a + ) x 2 + b is n if has trace 0 and
10 2m+1 + 2 – n otherwise (see Annex A.4.5). (This fact allows one to replace a given curve by one
11 with the same order and satisfying some extra condition, such as a = 0 which will be used in
12 A.10.7.)
13 If q = 2m, then the curves y 2 + xy = x 3 + ax 2 + b and y 2 + xy = x 3 + a 2 x 2 + b 2 have the same order.
14Near primality.
15Given a trial division bound lmax, the positive integer k is called smooth if every prime divisor of k is at most
16lmax. Given large positive integers rmin and rmax, u is called nearly prime if u = kr for some prime r in the
17interval rmin r r max and some smooth integer k. (The requirement that k be smooth is omitted in most
18definitions of near primality. It is included here to guarantee that there exists an efficient algorithm to
19check for near primality.) In the case in which a prime order curve is desired, the bound lmax is set to 1.
20NOTE—since all elliptic curves over GF (q) have order at most umax = q + 2 q + 1, then rmax should be no greater
21than umax. (If no maximum is desired, e.g., as in draft ANSI X9.62 [ANS98e], then one takes rmax umax.) Moreover, if
22rmin is close to umax, then there will be a small number of possible curves to choose from, so that finding a suitable one
23will be more difficult. If a prime-order curve is desired, a convenient choice is rmin = q + q.
24Finding curves of appropriate order.
25In order to perform EC-based cryptography it is necessary to be able to find an elliptic curve. The task is as
26follows: given a field size q and lower and upper bounds rmin and rmax for base point order, find an elliptic
27curve E over GF (q) and a prime r in the interval rmin r rmax which is the order of a point on E.
28Since factor large numbers are difficult to factor in general, a trial division bound lmax is chosen and the
29search is restricted to nearly prime curve orders (see Annex A.15.5). There are four approaches to selecting
30such a curve:
31 f) Select a curve at random, compute its order directly, and repeat the process until an appropriate
32 order is found.Select curve coefficients with particular desired properties, compute the curve order
33 directly, and repeat the process until an appropriate order is found.If q = 2m where m is divisible by
34 a “small” integer d, then select a curve defined over GF (2d) and compute its order (over GF (2m))
35 via A.11.6. Repeat if possible until an appropriate order is found.
36 4. Search for an appropriate order, and construct a curve of that order.
37The first approach is described in A.12.4 and A.12.6 (except for the point-counting algorithm, which is
38omitted). The second approach is not described since its details depend on the particular desired properties.
39The third approach is given in A.11.4–A.11.6. The fourth approach is implemented using the complex
40multiplication (or CM) method, given in A.14.
2 213
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2This clause discusses the issues involved in choosing representations for points on elliptic curves, for
3purposes of internal computation and for external communication.
4Affine coordinates.
5A finite point on E is specified by two elements x, y in GF (q) satisfying the defining equation for E. These
6are called the affine coordinates for the point. The point at infinity O has no affine coordinates. For
7purposes of internal computation, it is most convenient to represent O by a pair of coordinates (x, y) not on
8E. For q = 2 m, the simplest choice is O = (0,0). For q = p, one chooses O = (0, 0) unless b = 0, in which
9case O = (0, 1).
10Coordinate compression.
11The affine coordinates of a point require 2m bits to store and transmit, where q is either 2m or an m-bit
12prime. This is far more than is needed, however. For purposes of external communication, therefore, it can
13be advantageous to compress one or both of the coordinates.
14The y coordinate can always be compressed. The compressed y coordinate, denoted ~y , is a single bit,
15defined as follows.
16
17 if q is an odd prime, then ~y := y mod 2, where y is interpreted as a positive integer less than q. Put
18 ~
another way, y is the rightmost bit of y.
19 If q is a power of 2 and the LSB compressed form is employed, then is the rightmost bit of the
20 field element y x –1 (except when x = 0, in which case := 0).
21 If the SORT compressed form is employed, let y be the y-coordinate of the inverse point.
22 (That is, y = y if q is odd, and y = x + y if q is even.) Then is 1 if FE2IP (y) > FE2IP (y),
23 and 0 otherwise, where FE2IP is defined in 5.5.5.
24Compression of x coordinates takes place only when q = 2m. Moreover, the x coordinate of a point can be
25compressed if and only if the point is twice another point. In particular, every point of prime order can be
26compressed. Therefore, x coordinate compression can be used in all cryptographic algorithms specified in
27this Standard that are based on an elliptic curve over a binary field.
29The string ~
x is derived from x by dropping a certain bit from the bit string representing x. If F is given by
30a normal basis, or if m is odd, then the rightmost bit is dropped. If F is given by a polynomial basis
31{t m–1, …, t, 1}
32and m is even, then one drops the rightmost bit corresponding to a basis element of trace 1. In other words,
33one drops the bit in the location of the rightmost 1 in the vector defined in A.4.5.
34Examples:
35
36 i) If m = 5 and x = (11001), then ~
x = (1100).
37 ii) If F is given by the field polynomial t 6 + t 5 + 1, then
2 214
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 = (111110),
4NOTES
62—There are many other possible ways to compress coordinates; the methods given here are the ones that have
7appeared in the literature (see [Men95], [Ser98]).
83—It is a common usage (adopted, in particular, within this Standard) to say that the point P is compressed if its y
9coordinate is compressed but its x coordinate is not. (See E.2.3.1.)
10Projective coordinates.
11If division within GF (q) is relatively expensive, then it may pay to keep track of numerators and
12denominators separately. In this way, one can replace division by with multiplication of the denominator
13by . This is accomplished by the projective coordinates X, Y , and Z, given by
X Y
14 x 2
,y 3.
Z Z
21The formulae above provide the method for converting a finite point from projective coordinates to affine.
22To convert from affine to projective, one proceeds as follows.
23X x, Y y, Z 1.
24Projective coordinates are well suited for internal computation, but not for external communication since
25they require so many bits. They are more common over GF (p) since division tends to be more expensive
26there.
29The following algorithm implements a full addition (on a curve modulo p) in terms of affine coordinates.
30Input: a prime p > 3; coefficients a, b for an elliptic curve E: y 2 = x 3 + ax + b modulo p; points P0 = (x0,
31y0) and P1 = (x1, y1) on E.
2 215
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
6 i) 6 Set (3 x12 + a) / (2y1) mod pSet x2 2 – x0 – x1 mod pSet y2 (x1 – x2) – y1 mod
7 pOutput P2 (x2, y2)
8The above algorithm requires 3 or 4 modular multiplications and a modular inversion.
9To subtract the point P = (x, y), one adds the point –P = (x, –y).
11The following algorithm implements a full addition (on a curve over GF (2m)) in terms of affine
12coordinates.
13Input: a field GF (2m); coefficients a, b for an elliptic curve E: y 2 + xy = x 3 + ax 2 + b over GF (2m); points
14P0 = (x0, y0) and P1 = (x1, y1) on E.
26To subtract the point P = (x, y), one adds the point –P = (x, x + y).
27Further Speedup.
29
30 6.1 x1 + y1 / x1
31 6.2 x2 a + 2 +
32require a multiplication and an inversion. If GF (2m) is represented by a normal basis, this can be improved
33by replacing the two lines with the following steps.
34
35 6.1 w x12
36 6.2 x2 w + b / w
2 216
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 6.3 Solve the equation 2 + = x2 + a for via A.4.7 (normal basis case).
2 6.4 z w + y1
3 6.5 If z = x1 then else + 1
4NOTE—The determination of whether z = x1 can be accomplished by computing one bit of the product x1 (any bit
5for which the corresponding bit of x1 is 1) and comparing it to the corresponding bit of z.
6This routine is more efficient than the ordinary method because it replaces the general multiplication by a
7multiplication by the constant b. (See [SOM95].)
9Scalar multiplication can be performed efficiently by the addition-subtraction method outlined below.
12 m) If n = 0 then output O and stop.If n < 0 the set Q (–P) and k (–n), else set Q P and k
13 n.Let hl hl–1 ...h1 h0 be the binary representation of 3k, where the most significant bit hl is 1.Let kl kl–
14 1...k1 k0 be the binary representation of k.Set S Q.
25where
26M = 3 X 12 + a Z14 ,
27Z2 = 2Y1Z1,
28S = 4X1 Y12 ,
2
29X2 = M – 2S,
30T = 8 Y14 ,
31Y2 = M (S – X2) – T.
33Input: a modulus p; the coefficients a and b defining a curve E modulo p; projective coordinates (X1, Y1,
34Z1) for a point P1 on E.
35Output: projective coordinates (X2, Y2, Z2) for the point P2 = 2P1.
2 217
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
33where
34U0 = X0 Z12 ,
35S0 = Y0 Z13 ,
36U1 = X1 Z02 ,
37S1 = Y1 Z 03 ,
38W = U0 – U1,
39R = S0 – S1,
40T = U0 + U 1,
2 218
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1M = S0 + S1,
2Z2 = Z0Z1W,
2 2
3X2 = R – TW ,
2
4V = TW – 2X2,
52Y2 = VR – MW 3.
7Input: a modulus p; the coefficients a and b defining a curve E modulo p; projective coordinates (X0, Y0,
8Z0) and (X1, Y1, Z1) for points P0 and P1 on E, where Z0 and Z1 are nonzero.
9Output: projective coordinates (X2, Y2, Z2) for the point P2 = P0 + P1, unless P0 = P1. In this case, the
10triplet (0, 0, 0) is returned. (The triplet (0, 0, 0) is not a valid projective point on the curve, but rather a
11marker indicating that routine Double should be used.)
12 p) T1 X0 = U0 (if Z1 = 1)T2
13 Y0 = S0 (if Z1 = 1)T3
14 Z0T4 X1T5 Y1
15 6. If Z1 1 then
16 T6 Z1
17 T7 T62
18 T1 T1 T7 = U0 (if Z1 1)
19 T7 T6 T7
20 T2 T2 T7 = S0 (if Z1 1)
21 q) 7. T7 T32 T4 T4 T7
22 = U1T7 T3 T7T5 T5 T7
23 = S1T4 T1 – T4 = WT5 T2 – T5
24 =R
25 13. If T4 = 0 then
26 If T5 = 0 then output (0,0,0) and stop
27 else output (1, 1, 0) and stop
28 r) 14. T1 2 T1 – T4 = TT2 2 T2 –
29 T5 =M
30 16. If Z1 1 then
31 T3 T3 T6
32 s) 17. T3 T3 T4 = Z2T7 T42 T4
33 T4 T7 T7 T1 T7 T1 T52 T1 T1 – T7
34 = X2T7 T7 – 2 T1
35 = VT5 T5 T7T4 T2 T4T2 T5 – T4T2 T2 / 2
36 = Y2X2 T1Y2 T2Z2 T3
37NOTE—the modular division by 2 in Step 27 can be carried out in the same way as in A.2.4.
38This algorithm requires 16 field multiplications and 7 temporary variables. In the case Z1 = 1, only 11 field
39multiplications and 6 temporary variables are required. (This is the case of interest for elliptic scalar
40multiplication.)
2 219
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2The projective form of the doubling formula on the curve y 2 + xy = x 3 + ax 2 + b over GF (2m) uses, not the
3coefficient b, but rather the field element
4c := b 2m2 ,
7where
8Z2 = X1 Z12 ,
9X2 = (X1 + c Z12 )4,
10U = Z2 + X12 + Y1Z1,
11Y2 = X14 Z2 + UX2.
13Input: a field of 2m elements; the field elements a and c specifying a curve E over GF (2m); projective
14coordinates (X1, Y1, Z1) for a point P1 on E.
15Output: projective coordinates (X2, Y2, Z2) for the point P2 = 2P1.
25The projective form of the adding formula on the curve y 2 + xy = x 3 + ax2 + b over GF (2m) is
27where
28U0 = X0 Z12 ,
29S0 = Y0 Z13 ,
30U1 = X1 Z02 ,
31W = U0 + U 1,
2 220
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1S1 = Y1 Z 03 ,
2R = S0 + S1,
3L = Z0 W
4V = RX1 + LY1,
5Z2 = LZ1,
6T = R + Z2,
7 X2 = a Z22 + TR + W 3
,
8Y2 = TX2 + VL 2.
10Input: a field of 2m elements; the field elements a and b defining a curve E over GF (2m); projective
11coordinates (X0, Y0, Z0) and (X1, Y1, Z1) for points P0 and P1 on E, where Z0 and Z1 are nonzero.
12Output: projective coordinates (X2, Y2, Z2) for the point P2 = P0 + P1, unless P0 = P1. In this case, the
13triplet (0, 0, 0) is returned. (The triplet (0, 0, 0) is not a valid projective point on the curve, but rather a
14marker indicating that routine Double should be used.)
15 u) T1 X0 = U0 (if Z1 = 1)T2
16 Y0 = S0 (if Z1 = 1)T3
17 Z0T4 X1T5 Y1
18 6. If a 0 then
19 T9 a
20 7. If Z1 1 then
21 T6 Z1
22 T7 T62
23 T1 T1 T7 = U0 (if Z1 1)
24 T7 T6 T7
25 T2 T2 T7 = S0 (if Z1 1)
26 v) 8. T7 T32 T8 T4 T7
27 = U1T1 T1 + T8 = WT7 T3
28 T7T8 T5 T7 = S1T2 T2 + T8
29 =R
30 14. If T1 = 0 then
31 If T2 = 0 then output (0, 0, 0) and stop
32 else output (1, 1, 0) and stop
33 w) 15. T4 T2 T4T3 T1 T3
34 = L (= Z2 if Z1 = 1)T5 T3 T5T4 T4 + T5
35 = VT5 T32 T7 T4 T5
36 21. If Z1 1 then
37 T3 T3 T6 = Z2 (if Z1 1)
38 x) 22. T4 T2 + T3 = TT2 T2
39 T4T5 T12 T1 T1 T5
40 26. If a 0 then
41 T8 T32
42 T9 T8 T9
2 221
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 T1 T1 + T9
2 y) 27. T1 T1 + T2 = X2T4 T1
3 T4T2 T4 + T7 = Y2X2 T1Y2
4 T2Z2 T3
5This algorithm requires 5 field squarings, 15 general field multiplications and 9 temporary variables. If
6a = 0, then only 4 field squarings, 14 general field multiplications and 8 temporary variables are required.
7(About half of the elliptic curves over GF (2m) can be rescaled so that a = 0. They are precisely the curves
8with order divisible by 4. See Annex A.9.5, Basic Facts.)
9In the case Z1 = 1, only 4 field squarings, 11 general field multiplications, and 8 temporary variables are
10required. If also a = 0, then only 3 field squarings, 10 general field multiplications, and 7 temporary
11variables are required. (These are the cases of interest for elliptic scalar multiplication.)
13The following algorithm FullAdd implements a full addition in terms of projective coordinates.
14Input: a field of q elements; the field elements a and b defining a curve E over GF (q); projective
15coordinates (X0, Y0, Z0) and (X1, Y1, Z1) for points P0 and P1 on E.
16Output: projective coordinates (X2, Y2, Z2) for the point P2 = P0 + P1.
17 z) If Z0 = 0 then output (X2, Y2, Z2) (X1, Y1, Z1) and stop.If Z1 = 0 then output (X2, Y2, Z2) (X0, Y0,
18 Z0) and stop.Set (X2, Y2, Z2) Add[(X0, Y0, Z0), (X1, Y1, Z1)].If (X2, Y2, Z2) = (0, 0, 0) then set (X2, Y2,
19 Z2) Double[(X1, Y1, Z1)]Output (X2, Y2, Z2).
20An elliptic subtraction is implemented as follows:
21Subtract[(X0, Y0, Z0), (X1, Y1, Z1)] = FullAdd[(X0, Y0, Z0), (X1, U, Z1)]
22where
Y1 mod p if q p
23U =
X 1 Z1 Y1 if q 2 m
2 222
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 cc) 5. Go to Step 8Set k (–n)If q = p then set Y* –Y (mod p); else set Y* XZ +YIf Z* = 1
2 then set X1 X*, Y1 Y*; else set X1 X* / (Z*)2, Y1 Y* / (Z*)3Let hl hl–1 ...h1 h0 be the binary
3 representation of 3k, where the most significant bit hl is 1.Let kl kl–1...k1 k0 be the binary
4 representation of k.
5 11. For i from l – 1 downto 1 do
6 11.1 Set (X*, Y*, Z*) Double[(X*, Y*, Z*)].
7 11.2 If hi = 1 and ki = 0 then set (X*, Y*, Z*) FullAdd[(X*, Y*, Z*), (X1, Y1, Z1)].
8 11.3 If hi = 0 and ki = 1 then set (X*, Y*, Z*) Subtract[(X*, Y*, Z*), (X1, Y1, Z1)].
9 12. Output (X*, Y*, Z*).
10There are several modifications that improve the performance of this algorithm. These methods are
11summarized in [Gor98].
14The following algorithm provides an efficient method for finding a random point (other than O) on a given
15elliptic curve over the finite field GF (p).
18 dd) Choose random x with 0 x < p.Set x3 + ax + b mod p.If = 0 then output (x, 0) and
19 stop.Apply the appropriate technique from A.2.5 to find a square root modulo p of or determine
20 that none exist.If the result of Step 4 indicates that no square roots exist, then go to Step 1.
21 Otherwise the output of Step 4 is an integer with 0 < < p such that
22 2 (mod p).
23 ee) Generate a random bit and set y (–1) .
24 7. Output (x, y).
26The following algorithm provides an efficient method for finding a random point (other than O) on a given
27elliptic curve over the finite field GF (2m).
28Input: a field GF (2m) and the parameters a, b of an elliptic curve E over GF (2m).
30 ff) Choose random x in GF (2m).If x = 0 then output (0, b2 ) and stop.Set x3 + ax2 + b.If = 0
m–1
31 then output (x, 0) and stop.Set x – 2 .Apply the appropriate technique from A.4.7 to find an
32 element z for which z2 + z = or determine that none exist.If the result of Step 6 indicates that no
33 solutions exist, then go to Step 1. Otherwise the output of Step 6 is a solution z.Generate a random
34 bit and set y (z + ) x.Output (x, y).
2 223
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2If the order #E(GF (q)) = u of an elliptic curve E is nearly prime, the following algorithm efficiently
3produces a random point on E whose order is the large prime factor r of u = kr. (See Annex A.9.5 for the
4definition of nearly prime.)
5Input: a prime r, a positive integer k not divisible by r, and an elliptic curve E over the field GF (q).
6Output: if #E(GF (q)) = kr, a point G on E of order r. If not, the message “wrong order.”
7 gg) Generate a random point P (not O) on E via A.11.1 or A.11.2.Set G kP.If G = O then go to Step
8 1.Set Q rG.If Q O then output “wrong order” and stop.
9 6. Output G.
11If d is “small” (i.e. it is feasible to perform 2 d arithmetic operations), then the order of the curve y2 + xy = x3
12+ ax2 + b over GF (2d) can be calculated directly as follows. Let
17#E(GF (2d)) = 2d + 1 + ( 1)
(x)
.
x 0
19Given the order of an elliptic curve E over a finite field GF (2d), the following algorithm computes the
20order of E over the extension field GF (2de).
21Input: positive integers d and e, an elliptic curve E defined over GF (2d), and the order w of E over
22GF (2d).
24 hh) Set P 2d + 1 – w and Q 2d.Compute via A.2.4 the Lucas sequence element Ve.Compute u :=
25 2de + 1 – Ve.
26 4. Output u.
28The algorithms of A.11.4 and A.11.5 allow construction of elliptic curves with known orders over GF (2m),
29provided that m is divisible by an integer d that is small enough for A.11.4. The following algorithm finds
30such curves with nearly prime orders when such exist. (See Annex A.9.5 for the definition of nearly
31prime.)
2 224
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Input: a field GF (2m); a subfield GF (2d) for some (small) d dividing m; lower and upper bounds rmin and
2rmax for the base point order.
3Output: elements a, b GF (2m) specifying an elliptic curve E, along with the nearly prime order n =
4#E(GF (2m)), if one exists; otherwise, the message “no such curve.”
5 ii) Select elements a0, b0 GF (2d) such that b0 has not already been selected. (If all of the b0’s have
6 already been tried, then output the message “no such curve” and stop.) Let E be the elliptic curve
7 y2 + xy = x3 + a0 x2 + b0.Compute the order w = #E(GF (2d)) via A.11.4.Compute the order u =
8 #E(GF (2m)) via A.11.5.Test u for near-primality via A.15.5.If u is nearly prime, then set 0 and
9 n u and go to Step 9.Set u = 2m+1 + 2 – u.Test u for near-primality via A.15.5.If u is nearly
10 prime, then set 1 and n u, else go to Step 1.Find the elements a1, b1 GF (2m)
11 corresponding to a0 and b0 via A.5.7.If = 0 then set 0. If = 1 and m is odd, then set 1.
12 Otherwise, find an element GF (2m) of trace 1 by trial and error using A.4.5.Set a a1 +
13 and b b1
2 225
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 12. Output n, a, b.
2NOTE—It follows from the Basic Facts of A.9.5 that any a0 can be chosen at any time in Step 1.
5The MOV condition ensures that an elliptic curve is not vulnerable to the reduction attack of Menezes,
6Okamoto and Vanstone [MOV93], [Hitt07].
7Before performing the algorithm to check the subfield-adjusted MOV condition, it is necessary to select an
8MOV threshold. This is a positive integer B such that taking discrete logarithms over GF (qB) is judged to
9be at least as difficult as taking elliptic discrete logarithms over GF (q). It follows from the complexity
10discussions of D.4.1 and from [Men95] that B should be large enough so that
11T (mB) m
13 T ( n )
8
3
3n log 2 n ln 2
2 1/ 3
17135872
. .
14(As before, ln x denotes the natural logarithm of x.). The constant in this formula follows from [DL95] and
15[Odl95]. The following table gives the smallest value of B satisfying the above condition, for each q whose
16bit length m is between 128 and 512.
m B m B M B
17Once an appropriate B has been selected, the following algorithm checks the subfield-adjusted MOV
18condition for the choice of field size q = pm and base point order r by verifying that q i is not congruent to 1
19modulo r for any i mB.
20Input: an MOV threshold B, a prime-power q, and a prime r.
21Output: the message “True” if the subfield-adjusted MOV condition is satisfied for an elliptic curve over
22GF (q) with a base point of order r; the message “False” otherwise.
2 226
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
8The Weil pairing is a function <P, Q> of pairs P, Q of points on an elliptic curve E. It can be used to
9determine whether P and Q are multiples of each other. It will be used in A.12.3.
10Let l > 2 be prime, and let P and Q be points on E with lP = lQ = O. The following procedure computes the
11Weil pairing.
12
13 Given three finite points (x0, y0), (x1, y1), (u, v) on E, define the function f((x0, y0), (x1, y1), (u, v)) by
14 u x1 if x0 = x1 and y0 = y1
18 u + x1 if x0 = x1 and y0 = x1 + y1
22 Also define f(O, O, (u, v)) = 1; f(O, (x1, y1), (u, v)) = u x1 over GF(p) and u + x1 over GF(2m); and
23 f((x0, y0), O, (u, v)) = u x0 over GF(p) and u + x0 over GF(2m).
24
25 Given points A, B, C on E, let
31
32 1. Set A D, B D, ha 1, hb 1, n l.
33 2. Set n n / 2.
2 227
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
15 V = P + T, W = Q + U.
16
17 Then
21In the case l = 2, the Weil pairing is easily computed as follows: <P, Q> equals 1 if P = Q and –1
22otherwise.
23Define <P, O> =1 for all points P and <O, Q> =1 for all points Q.
25Let E be an elliptic curve over GF (q) of order u = kr, where r is the prime order of the base point G. The
26integer k is called the cofactor. The DL and EC key agreement schemes provide an option for
27exponentiation or scalar multiplication of the shared secret value by the cofactor. In order to implement
28this option, it is necessary to know the cofactor k.
29In the DL case, the cofactor is simply k = (q – 1)/r. In the EC case, a simple formula exists only if r > 4
30 q (which is typically the case). In this case, k can be computed directly from the verified parameters q
31and r (see Annex A.16.8) via the formula
( q 1) 2
32k : = .
r
33If r 4 q , then k cannot be computed from q and r alone. Therefore the value of k must be sent along
34with the EC parameters, and should be verified by the recipient. This verification is accomplished by a
35rather complex algorithm, as described below.
36Torsion points.
2 228
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1If l is a prime, then a l-torsion point is a finite point T such that lT = O. The following algorithm (a
2subroutine of the cofactor verification procedure to be given below) generates an l-torsion point or reports
3that none exist. The algorithm is probabilistic, but the probability of error can be made as small as desired.
4(A parameter is included for this purpose.)
5Input: the EC parameters q, a, and b; the putative order u = #E(GF (q)); a prime l r; the largest positive
6integer v such that v such that l v divides u; and a positive integer .
7Output: an l-torsion point T and a positive integer v such that T = l P for some point P or the message
8“no torsion point found.”
9 e) Set h kr / lv.Set 0Set + 1If > then output “no torsion point found” and
10 stopGenerate a random finite point R via A.11.1 or A.11.2Compute S := hRIf S = O then go to Step
11 3Set 1Set + 1It > v then output “no torsion point found” and stopSet T SSet S
12 lSIf S O then go to Step 9
13 14. Output T and
14Cofactor verification procedure.
15Input: the EC parameters q, a, b, r, and k; an upper bound for the probability of error.
16Output: “cofactor confirmed” or “cofactor rejected.”
17 f) Set u kr.If u < ( q – 1)2 or u > ( q + 1)2 then output “cofactor rejected” and stop.Factor
log( s / )
23 :
v log l
24
25 4.3 Set j 0.
26 4.4 If q 1 (mod l) then set e 0, f 0, U O, V O.
27 4.5. Set j j + 1
28 4.6 If j > v then output “cofactor rejected” and stop.
29 4.7 Generate an l-torsion point T and associated integer via the subroutine.
30 4.8 If the output of the subroutine is “no torsion point found” then output “cofactor rejected” and
31 stop.
32 4.9 If q ( 1 (mod l) then set else
33 4.9.1 If e then go to Step 4.10
34 4.9.2 Compute the Weil pairing w := <T, V> via A.12.2
35 4.9.3 If f then go to Step 4.9.6
36 4.9.4 If w 1 then set e , U T
37 4.9.5 Go to Step 4.9.8
38 4.9.6 If w 1 then set e f, U V
39 4.9.7 Set f , V T
40 4.9.8 Set e + f.
2 229
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
4It is common to use an elliptic curve selected at random from the curves of appropriate order. (See Annex
5A.9.5.) The following algorithm produces a set of elliptic curve parameters for such a curve over a field
6GF (p), along with sufficient information for others to verify that the curve was indeed chosen pseudo-
7randomly. (The algorithm is consistent with the one given in [ANS98e].)
8See Clause 5.5 of this Standard for the conversion routines BS2IP and I2BSP.
10
11 a prime modulus p
12 lower and upper bounds rmin and rmax for the order of the base point
13 a cryptographic hash function H with output length B bits, where
1
14 B log 2 ( rmin )
2
15
16 the bit length L of inputs to H, satisfying L B.
17The following notation is adopted below:
21Input: a prime modulus p; lower and upper bounds rmin and rmax for r; a trial division bound lmax < rmin.
23 g) Choose an arbitrary bit string X of bit length L.Compute h := H (X).Let W0 be the bit string obtained
24 by taking the w rightmost bits of h.Convert the length-L bit string X to an integer z via BS2IP.For i
25 from 1 to s do:
26 5.1 Convert the integer (z + i) mod (2L) to a length-L bit string Xi via I2BSP.
27 5.2 Compute Wi := H (Xi).
28 6. Let W be the bit string obtained by the concatenation of W0, W1, …, Ws as follows:
29 W = W0 || W1 || … || Ws.
30 h) Convert the length-(v – 1) bit string W to an integer c via BS2IP.If c = 0 or 4c + 27 0 (mod p),
31 then go to Step 1.Choose integers a, b GF (p) such that
33 (The simplest choice is a = c and b = c. However, one may want to choose differently for
34 performance reasons; e.g. the condition a = p – 3 used in A.10.4.)
2 230
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 i) Compute the order u of the elliptic curve E over GF (p) given by y2 = x3 + ax + b. (This can be
2 done using the techniques described in [ANS98h].)Test u for near-primality via A.15.5.If u is not
3 nearly prime, then go to Step 1. (Otherwise the output of A.15.5 consists of the integers k,
4 r.)Generate a point G on E of order r via A.11.3.Output X, a, b, r, G.
6The following algorithm verifies the validity of a set of elliptic curve parameters. In addition, it determines
7whether an elliptic curve over GF (p) was generated using the method of A.12.4.
8The quantities B, L, v, s, and w, and the hash function H, are as in A.12.4. See Clause 5.5 of this Standard
9for the conversion routines BS2IP and I2BSP.
12 j) Compute h := H (X).Let W0 be the bit string obtained by taking the w rightmost bits of h.Convert
13 the bit string X to an integer z via BS2IP.
14 4. For i from 1 to s do:
15 4.1 Convert the integer (z + i) mod (2L) to a length-L bit string Xi via I2BSP.
16 4.2 Compute Wi := H (Xi).
17 5. Let W be the bit string obtained by the concatenation of W0, W1, …, Ws as follows:
18 W = W0 || W1 || … || Ws.
19 k) Convert the length-(v – 1) bit string W to an integer c via BS2IP.
20 7. Perform the following checks.
21 7.1 c>0
22 7.2 (4c + 27 mod p) > 0
23 7.3 cb2 a3 (mod p)
24 7.4 GO
25 7.5 y2 x3 + ax + b (mod p)
26 7.6 rG = O
27 8. If all the checks in Step 7 work, then output “True”; otherwise output “False.”
29It is common to use an elliptic curve selected at random from the curves of appropriate order. (See Annex
30A.9.5.) The following algorithm produces a set of elliptic curve parameters for such a curve over a field
31GF (2m), along with sufficient information for others to verify that the curve was indeed chosen pseudo-
32randomly. (The algorithm is consistent with the one given in [ANS98e].)
33See Clause 5.5 of this Standard for the conversion routines BS2IP, I2BSP, BS2OSP, and OS2FEP.
35
36 a field GF (2m)
37 lower and upper bounds rmin and rmax for the order of the base point
2 231
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 B log 2 ( rmin )
2
3
4 the bit length L of inputs to H, satisfying L B.
5The following notation is adopted below:
6s = (m – 1)/B,
7w = m – B s.
8Input: a field GF (2m); lower and upper bounds rmin and rmax for r; a trial division bound lmax < rmin.
10 l) Choose an arbitrary bit string X of bit length L.Compute h := H (X).Let W0 be the bit string obtained
11 by taking the w rightmost bits of h.Convert the length-L bit string X to an integer z via BS2IP.For i
12 from 1 to s do:
13 5.1 Convert the integer (z + i) mod (2L) to a length-L bit string Xi via I2BSP.
14 5.2 Compute Wi := H (Xi).
15 6. Let W be the bit string obtained by the concatenation of W0, W1, …, Ws as follows:
16 W = W0 || W1 || … || Ws.
17 m) Convert the length-m bit string W to a field element b via BS2OSP and OS2FEP.If b = 0 then go to
18 Step 1.Let a be an arbitrary element in GF (2m). (The simplest choice is a = 0, which also allows
19 for the efficient implementation given in A.10.7. However, one may want to choose differently for
20 other reasons, such as other performance issues or the availability of suitable curves.)Compute the
21 order u of the elliptic curve E over GF (2m) given by y2 + xy = x3 + ax2 + b. (This can be done using
22 the techniques described in [ANS98h]. See also [Men93b].)Test u for near-primality via A.15.5.If
23 u is not nearly prime, then go to Step 1. (Otherwise the output of A.15.5 consists of the integers k,
24 r.)Generate a point G on E of order r via A.11.3.
25 14. Output X, a, b, r, G.
27The following algorithm verifies the validity of a set of elliptic curve parameters. In addition, it determines
28whether an elliptic curve over GF (2m) was generated using the method of A.12.6.
29The quantities B, L, s, and w, and the hash function H, are as in A.12.6. See Clause 5.5 of this Standard for
30the conversion routines BS2IP, I2BSP, BS2OSP, and OS2FEP.
33 n) Compute h := H (X).Let W0 be the bit string obtained by taking the w rightmost bits of h.Convert
34 the bit string X to an integer z via BS2IP.
35 4. For i from 1 to s do:
36 4.1 Convert the integer (z + i) mod (2L) to a length-L bit string Xi via I2BSP.
37 4.2 Compute Wi := H (Xi).
2 232
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 5. Let W be the bit string obtained by the concatenation of W0, W1, …, Ws as follows:
2 W = W0 || W1 || … || Ws.
3 o) Convert the length-m bit string W to the field element b via BS2OSP and OS2FEP.
4 7. Perform the following checks.
5 7.1 b0
6 7.2 b = b
7 7.3 GO
8 7.4 y2 + xy = x3 + ax2 + b
9 7.5 rG = O
10 8. If all the checks in Step 7 work, then output “True”; otherwise output “False.”
12The following algorithm recovers the y coordinate of an elliptic curve point from its compressed form.
13Input: a prime number p, an elliptic curve E defined modulo p, the x coordinate of a point (x, y) on E, and
14the compressed representation ~y of the y coordinate.
16 p) Compute g := x3 + ax + b mod pFind a square root z of g modulo p via A.2.5. If the output of
17 A.2.5 is “no square roots exist,” then return an error message and stop.Let ~
z be the rightmost bit
18 ~ ~
of z (in other words, z mod 2).If z = y then y z, else y p – z.Output y.
19NOTE—when implementing the algorithm from A.2.5, the existence of modular square roots should be checked.
20Otherwise, a value may be returned even if no modular square roots exist.
22The following algorithm recovers the y coordinate of an elliptic curve point from its LSB compressed form.
23Input: A field GF(2m); an elliptic curve E defined over GF(2m); the x coordinate of a point (x, y) on E; the
24LSB compressed representation of the y coordinate.
26 q) If x = 0 then compute y := b via A.4.1 and go to Step 7.Compute the field element := x3 + ax2
27 + b in GF (2m)Compute the element := (x2)–1 via A.4.4Find a field element z such that z2 + z =
28 via A.4.7. If the output of A.4.7 is “no solutions exist,” then return an error message and stop.Let
~ ~
29 z be the rightmost bit of zCompute y := (z + ~z + y ) xOutput y.
30NOTES
311—When implementing the algorithm from A.4.7, the existence of solutions to the quadratic equation should be
32checked. Otherwise, a value may be returned even if no solutions exist.
332—If both coordinates are compressed, the x coordinate must be decompressed first and then the y coordinate. (See
34Annex A.12.10.)
2 233
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2The following algorithm recovers the x coordinate of an elliptic curve point from its compressed form. The
3statement of the algorithm assumes that the point has prime order, since that is the case of cryptographic
4interest; but in fact that condition is unnecessarily restrictive. (See Annex A.9.6.)
5In addition to the EC parameters and the compact representation of the point, it is necessary to possess the
6trace Tr (a) of the coefficient a of the curve (see Annex A.4.5). If F is represented by a polynomial basis
7B = {t m–1, …, t, 1}
8and m is even, it is also necessary to possess the smallest positive integer s such that Tr (t s) = 1, since this
9indicates which bit has been dropped during compression. If a given set of EC parameters is to be reused,
10these two quantities can be computed once and stored with the parameters.
11Input: a field F of 2m elements; an elliptic curve E defined over F; the compact form x~ of the x
12coordinate of a point P on E of prime order; the trace of the coefficient a of the curve; if F is represented by
13a polynomial basis {t m–1, …, t, 1} and m is even, the smallest positive integer s such that Tr (t s) = 1.
18 s) ~ = (um–1 … u1)
Write x
19 2. Let x* be the field element
20 x* := (wm–1 … w0)
21 where
22 wj = uj for j > s
23 ws = 0
29The following algorithm recovers the y coordinate of an elliptic curve point from its SORT compressed
30form.
31Input: A field GF(q); an elliptic curve E defined over GF(q); the x coordinate of a point (x, y) on E; the
32SORT compressed representation of the y coordinate.
2 234
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 u) Find field elements z and z such that (x, z) and (x, z) are elliptic curve points (possibly the same).
2 If none exist, then return an error message and stop.Let be 1 if FE2IP (z) > FE2IP (z), and 0
3 otherwise, where FE2IP is defined in 5.5.5.If z = then y z, else y z.
4 4. Output y.
5NOTES
61—This algorithm works for all finite fields defined in this standard. Although it supports odd-
7characteristic extension fields, the algorithm is defined in this clause rather than A.17 for convenience.
82—The SORT form is only employed for binary fields and odd-characteristic extension fields in the elliptic
9curve point representations in Clause 5.
103—Finding z and z requires one to solve the elliptic curve equation at x. Steps 1 and 2 of A.12.8 do this for
11the prime case and steps 1–4 of A.12.9 do so for the binary case (in the notation of A.12.9, the roots are zx
12and zx + x). For odd-characteristic extension fields, a procedure similar to steps 1 and 2 of A.12.8 may be
13applied, with square roots implemented via A.17.1.3 rather than A.2.5. Once one element is found, the
14other can be determined directly; if q is odd, then z = z, and if q is even, then z = x + z.
17A.13.1 Overview
A B
19 S
B C
21
22 i) GCD (A, 2B, C) = 1,
23 ii) |2B| A C,
24 iii) If either A = |2B| or A = C, then B 0.
25The matrix S will be abbreviated as [A, B, C] when typographically convenient.
26The determinant D := AC – B 2 of S will be assumed throughout this clause to be positive and squarefree
27(i.e., containing no square factors).
28Given D, the class group H (D) is the set of all reduced symmetric matrices of determinant D. The class
29number h(D) is the number of matrices in H(D).
30The class group is used to construct the reduced class polynomial. This is a polynomial wD (t) with integer
31coefficients of degree h (D). The reduced class polynomial is used in A.14 to construct elliptic curves with
32known orders.
2 235
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2The following algorithm produces a list of the reduced symmetric matrices of a given determinant D. See
3[Bue89].
16
17 B = 0 gives A = 1, leading to [1,0,71].
18 B = 1 gives A = 2,3,4,6,8, leading to [3, 1,24] and [8, 1,9].
19 B = 2 gives A = 5, leading to [5, 2, 15].
20 B = 3 gives A = 8, but no reduced matrices.
21 B = 4 gives no divisors A in the right range.
22Thus the class group is
26Let
(1) z
( 3 j 2 j )/ 2 2
27F(z) = 1 +
j
z (3 j j )/ 2
j 1
29and
D Bi
30 = exp .
A
2 236
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Let
2ƒ0(A, B, C) = –1/24
F(–) / F( 2
),
3ƒ1(A, B, C) = –1/24
F() / F( 2
),
4ƒ2(A, B, C) = 2 1/12F( 4) / F( 2).
5NOTE—since
6 | | e 3/2
0.0658287 ,
7the series F (z) used in computing the numbers ƒJ(A, B, C) converges as quickly as a power series in e 3/ 2 .
G
9C(A, B, C) = (N BL 2–I/6 (ƒJ (A, B, C))K) ,
10where:
11 G = GCD(D,3),
3 if D 1,2,6,7 (mod 8 ),
0 if D 3 (mod 8) and D 0 (mod 3),
12 I
2 if D 3 (mod 8) and D 0 (mod 3),
6 if D 5 (mod 8),
0 for AC odd,
13 J 1 for C even,
2 for A even ,
2 237
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 if D 5 (mod 8)
or D 3 (mod 8) and AC odd
or D 7 (mod 8) and AC even,
1 N M if D 1,2,6 (mod 8)
or D 7 (mod 8) and AC odd,
M if D 3 (mod 8) and AC even,
2 = e iK/24.
3If [A1, B1, C1], ..., [Ah ,Bh ,Ch] are the reduced symmetric matrices of (positive squarefree) determinant D,
4then the reduced class polynomial for D is
h
5wD(t) = (t C( A , B , C )) .
j 1
j j j
7NOTE—The above computations must be performed with sufficient accuracy to identify each coefficient of the
8polynomial wD (t). Since each such coefficient is an integer, this means that the error incurred in calculating each
9coefficient should be less than 1/2.
10Example.
1
11w71(t)= t f0 1,0,71
2
12
i /8
ei /8 e
t f1 31
, ,24 t f1 3,1,24
2 2
13
e 23i / 24 e23i / 24
t f2 8,1,9 t f2 8,1,9
2 2
14
e5i /12 e5i /12
t f0 5,2,15 t f0 5,2,15
2 2
15= (t – 2.13060682983889533005591468688942503...)
16 (t – (0.95969178530567025250797047645507504...) +
17 (0.34916071001269654799855316293926907...) i)
18 (t – (0.95969178530567025250797047645507504...) –
2 238
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 (0.34916071001269654799855316293926907...) i)
2 (t + (0.7561356880400178905356401098531772...) +
3 (0.0737508631630889005240764944567675...) i)
4 (t + (0.7561356880400178905356401098531772...) –
5 (0.0737508631630889005240764944567675...) i)
6 (t + (0.2688595121851000270002877100466102...) –
7 (0.84108577401329800103648634224905292...) i)
8 (t + (0.2688595121851000270002877100466102...) +
9 (0. 84108577401329800103648634224905292...) i)
10= t 7 – 2t 6 – t 5 + t 4 + t 3 + t 2 – t – 1.
12A.14.1 Overview
14Z = 4q – (q + 1 – u)2
15is positive by the Hasse bound (see Annex A.9.5). Thus there is a unique factorization
16Z = DV 2
17where D is squarefree (i.e. contains no square factors). Thus, for each non-supersingular elliptic curve over
18GF (q) of order u, there exists a unique squarefree positive integer D such that
19(*) 4q = W 2 + DV 2,
20(**) u=q+1W
22It is said that E has complex multiplication by D (or, more properly, by D ). D is called a CM
23discriminant for q.
24If one knows D for a given curve E, one can compute its order via (*) and (**). As will be demonstrated
25below, one can construct the curves with CM by small D. Therefore one can obtain curves whose orders u
26satisfy (*) and (**) for small D. The near-primes are plentiful enough that one can find curves of nearly
27prime order with small enough D to construct.
28Over GF (p), the CM technique is also called the Atkin-Morain method (see [Mor91]); over GF (2m), it is
29also called the Lay-Zimmer method (see [LZ94]). Although it is possible (over GF (p)) to choose the order
2 239
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1first and then the field, it is preferable to choose the field first since there are fields in which the arithmetic
2is especially efficient.
3There are two basic steps involved: finding an appropriate order, and constructing a curve having that
4order. More precisely, one begins by choosing the field size q, the minimum point order rmin, and trial
5division bound lmax. Given those quantities, D is called appropriate if there exists an elliptic curve over
6GF (q) with CM by D and having nearly prime order.
7
8 Step 1 (A.14.2 and A.14.3, Finding a Nearly Prime Order):
9 Find an appropriate D. When one is found, record D, the large prime r, and the positive integer k
10 such that u = kr is the nearly prime curve order.
11
12 Step 2 (A.14.4 and A.14.5, Constructing a Curve and Point):
13 Given D, k and r, construct an elliptic curve over GF (q) and a point of order r.
16A squarefree positive integer D can be a CM discriminant for p only if it satisfies the following congruence
17conditions. Let
p 1
2
18 K .
rmin
19
20 If p 3 (mod 8), then D 2, 3, or 7 (mod 8).
21 If p 5 (mod 8), then D is odd.
22 If p 7 (mod 8), then D 3, 6, or 7 (mod 8).
23 If K = 1, then D 3 (mod 8).
24 If K = 2 or 3, then D ( 7 (mod 8).
25Thus the possible squarefree D's are as follows:
26If K = 1, then
27D = 3, 11, 19, 35, 43, 51, 59, 67, 83, 91, 107, 115, ….
2 240
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
15Input: a prime p and a squarefree positive integer D satisfying the congruence conditions from A.14.2.1.
174p = W 2 + DV 2
18for some V. [In the cases D = 1 or 3, the output also includes V.] If not, the message “not a CM
19discriminant.”
20 w) Apply the appropriate technique from A.2.5 to find a square root modulo p of –D or determine that
21 none exist.If the result of Step 1 indicates that no square roots exist, then output “not a CM
22 discriminant” and stop. Otherwise, the output of Step 1 is an integer B modulo p.Let A p and C
A B 1
23 (B 2 + D) / p.Let S and U .Until |2B| A C, repeat the following steps.
B C 0
B 1
24 5.1 Let .
C 2
0 1
25 5.2 Let T .
1
26 5.3 Replace U by T –1U.
27 5.4 Replace S by T t S T, where T t denotes the transpose of T.
28 x) 6. If D = 11 and A = 3, let 0 and repeat 5.2, 5.3, 5.4.Let X and Y be the entries of U.
29 That is,
2 241
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
X
1 U .
Y
2 y) If D = 1 or 3 then output W 2X and V 2Y and stop.If A = 1 then output W 2X and stop.If A
3 = 4 then output W 4X + BY and stop.
4 11. Output “not a CM discriminant.”
6Input: a prime p, a trial division bound lmax, and lower and upper bounds rmin and rmax for base point order.
7Output: a squarefree positive integer D, a prime r in the interval rmin r rmax, and a smooth integer k
8such that u = kr is the order of an elliptic curve modulo p with complex multiplication by D.
9 z) Choose a squarefree positive integer D, not already chosen, satisfying the congruence conditions of
D
10 A.14.2.1.Compute via A.2.3 the Jacobi symbol J = . If J = –1 then go to Step 1.List the
p
p
11 odd primes l dividing D.For each l, compute via A.2.3 the Jacobi symbol J = . If J = –1 for
l
12 some l, then go to Step 1.Test via A.14.2.2 whether D is a CM discriminant for p. If the result is
13 “not a CM discriminant,” go to Step 1. (Otherwise, the result is the integer W, along with V if D = 1
14 or 3.)
15 6. Compile a list of the possible orders, as follows.
16 — If D = 1, the orders are
17 p + 1 W, p + 1 V.
18
19 — If D = 3, the orders are
20 p + 1 W, p + 1 (W + 3V)/2, p + 1 (W – 3V)/2.
21
22 — Otherwise, the orders are p + 1 W.
23 aa) 7. Test each order for near-primality via A.15.5. If any order is nearly prime, output (D, k,
24 r) and stop.Go to Step 1.
25Example: Let p = 2192 – 264 – 1. Then
1 D 2
26p = 4X 2 – 2XY + Y and p + 1 – (4X – Y) = r
4
27where D = 235,
28X = –31037252937617930835957687234,
29Y = 5905046152393184521033305113,
31r = 6277101735386680763835789423337720473986773608255189015329.
2 242
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
52 d+2 = W 2 + DV 2,
7 bb) Compute via A.2.6 an integer B such that B 2 –D (mod 2d+2).Let A 2d+2 and C (B 2 + D) / 2d+2
A B
8 (Note: the variables A and C will remain positive throughout the algorithm.)Let S
B C
1
9 and U .
0
X
16 U .
Y
17 cc) If A = 1, then output W X and stop.If A = 4 and Y is even, then output W (4X + BY) / 2 and
18 stop.Output “not a CM discriminant.”
20Input: a field degree d, a trial division bound lmax, and lower and upper bounds rmin and rmax for base point
21order.
22Output: a squarefree positive integer D, a prime r in the interval rmin r rmax, and a smooth integer k
23such that u = kr is the order of an elliptic curve over GF (2d) with complex multiplication by D.
24 dd) Choose a squarefree positive integer D 7 (mod 8), not already chosen.Compute H the class
25 group for D via A.13.2.Set h the number of elements in H.If d does not divide h, then go to Step
26 1.Test via A.14.3.1 whether D is a CM discriminant for 2d. If the result is “not a CM discriminant,”
27 go to Step 1. (Otherwise, the result is the integer W.)The possible orders are 2d + 1 W.Test each
28 order for near-primality via A.15.5. If any order is nearly prime, output (D, k, r) and stop.
29 8. Go to Step 1.
2 243
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
24q = X 2 + DY 2 and q + 1 – X = 4r
4r = 11417981541647679048466230373126290329356873447.
8Given a prime p and a CM discriminant D, the following technique produces an elliptic curve y2 x3 + a0 x
9+ b0 (mod p) with CM by D. (Note that there are at least two possible orders among curves with CM by D.
10The curve constructed here will have the proper CM, but not necessarily the desired order. This curve will
11be replaced in A.14.4.2 by one of the desired order.)
D a0 b0
1 1 0
2 –30 56
3 0 1
7 –35 98
11 –264 1694
19 –152 722
43 –3440 77658
67 –29480 1948226
2 244
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 ee) Compute w(t) wD(t) mod p via A.13.3.Let W be the output from A.14.2.2.If W is even, then use
2 A.5.3 with d = 1 to compute a linear factor t – s of wD(t) modulo p. Let
t 24 mod g( t ) if 3 | D,
9 V ( t ):
256t mod g ( t ) if 3 | D,
8
14 Now let be a nonzero coefficient from a3(t), and let be the corresponding coefficient from b2(t).
15 Finally, let
16 a0 := mod p,
17 b0 := 2 mod p.
18 gg) Output (a0, b0).
19Example: If D = 235, then
20wD (t) = t 6 – 10 t 5 + 22 t 4 – 24 t 3 + 16 t 2 – 4 t + 4.
25a0 = –2089023816294079213892272128,
26b0 = –36750495627461354054044457602630966837248.
31 hh) Select an integer with 0 < < p.If D = 1 then set a a0 mod p and b 0.
32 If D = 3 then set a 0 and b b0 mod p.
33 Otherwise, set a a0 2 mod p and b b0 3 mod p.Look for a point G of order r on the curve
2 245
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 y2 x3 + ax + b (mod p)
2 via A.11.3.
3 ii) If the output of A.11.3 is “wrong order” then output the message “wrong order” and stop.
4 5. Output the coefficients a, b and the point G.
5The method of selecting in the first step of this algorithm depends on the kind of coefficients desired.
6Two examples follow.
7
8 If D 1 or 3, and it is desired that a = –3 (see Annex A.10.4), then take to be a solution of the
9 congruence a0 2 –3 (mod p), provided one exists. If one does not exist, or if this choice of
10 leads to the message “wrong order,” then select another curve as follows. If p 3 (mod 4) and the
11 result was “wrong order,” then choose p – in place of ; the result leads to a curve with a = –3
12 and the right order. If no solution exists, or if p 1 (mod 4), then repeat A.14.4.1 with another
13 root of the reduced class polynomial. The proportion of roots leading to a curve with a = –3 and
14 the right order is roughly one-half if p 3 (mod 4), and one-quarter if p 1 (mod 4).
15 If there is no restriction on the coefficients, then choose at random. If the output is the message
16 “wrong order,” then repeat the algorithm until a set of parameters a, b G is obtained. This will
17 happen for half the values of , unless D = 1 (one-quarter of the values) or D = 3 (one-sixth of the
18 values).
21Input: a field GF (2m), a CM discriminant D for 2m, and the desired curve order u.
23y2 + xy = x3 + ax2 + b
25 jj) Compute w (t) wD(t) mod 2 via A.13.3.Use A.14.3.1 to find the smallest divisor d of m greater
26 than (log2 D) – 2 such that D is a CM discriminant for 2d.Compute p (t) := a degree d factor modulo
27 2 of w (t). (If d = h, then p (t) is just w (t) itself. If d < h, p(t) is found via A.5.4.)Compute := a
28 root in GF (2m) of p (t) = 0 via A.5.6.If 3 divides D
29 then set b
30 else set b 3
31 6. If u is divisible by 4, then set a 0
32 else if m is odd, then set a 1
33 else generate (by trial and error using A.4.5) a random element a GF (2m) of trace 1.
34 7. Output (a, b).
35Example: If D = 942679, then
36wD(t) 1 + t 2 + t 6 + t 10 + t 12 + t 13 + t 16 + t 17 + t 20 + t 22 + t 24 + t 27 + t 30 + t 33 + t 35 + t 36 + t 37 + t 41 + t 42 + t 43 +
37t 45 + t 49 + t 51 + t 54 + t 56 + t 57 + t 59 + t 61 + t 65 + t 67 + t 68 + t 69 + t 70 + t 71 + t 72 + t 74 + t 75 + t 76 + t 82 + t 83 + t 87
38+ t 91 + t 93 + t 96 + t 99 + t 100 + t 101 + t 102 + t 103 + t 106 + t 108 + t 109 + t 110 + t 114 + t 117 + t 119 + t 121 + t 123 + t 125 +
39t 126 + t 128 + t 129 + t 130 + t 133 + t 134 + t 140 + t 141 + t 145 + t 146 + t 147 + t 148 + t 150 + t 152 + t 154 + t 155 + t 157 + t 158 +
2 246
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1t 160 + t 161 + t 166 + t 167 + t 171 + t 172 + t 175 + t 176 + t 179 + t 180 + t 185 + t 186 + t 189 + t 190 + t 191 + t 192 + t 195 + t 200 +
2t 201 + t 207 + t 208 + t 209 + t 210 + t 211 + t 219 + t 221 + t 223 + t 225 + t 228 + t 233 + t 234 + t 235 + t 237 + t 238 + t 239 + t 241 +
3t 242 + t 244 + t 245 + t 248 + t 249 + t 250 + t 252 + t 253 + t 255 + t 257 + t 260 + t 262 + t 263 + t 264 + t 272 + t 273 + t 274 + t 276 +
4t 281 + t 284 + t 287 + t 288 + t 289 + t 290 + t 292 + t 297 + t 299 + t 300 + t 301 + t 302 + t 304 + t 305 + t 306 + t 309 + t 311 + t 312 +
5t 313 + t 314 + t 317 + t 318 + t 320 + t 322 + t 323 + t 325 + t 327 + t 328 + t 329 + t 333 + t 335 + t 340 + t 341 + t 344 + t 345 + t 346 +
6t 351 + t 353 + t 354 + t 355 + t 357 + t 358 + t 359 + t 360 + t 365 + t 366 + t 368 + t 371 + t 372 + t 373 + t 376 + t 377 + t 379 + t 382 +
7t 383 + t 387 + t 388 + t 389 + t 392 + t 395 + t 398 + t 401 + t 403 + t 406 + t 407 + t 408 + t 409 + t 410 + t 411 + t 416 + t 417 + t 421 +
8t 422 + t 423 + t 424 + t 425 + t 426 + t 429 + t 430 + t 438 + t 439 + t 440 + t 441 + t 442 + t 443 + t 447 + t 448 + t 450 + t 451 + t 452 +
9t 453 + t 454 + t 456 + t 458 + t 459 + t 460 + t 462 + t 464 + t 465 + t 466 + t 467 + t 471 + t 473 + t 475 + t 476 + t 481 + t 482 + t 483 +
10t 484 + t 486 + t 487 + t 488 + t 491 + t 492 + t 495 + t 496 + t 498 + t 501 + t 503 + t 505 + t 507 + t 510 + t 512 + t 518 + t 519 + t 529 +
11t 531 + t 533 + t 536 + t 539 + t 540 + t 541 + t 543 + t 545 + t 546 + t 547 + t 548 + t 550 + t 552 + t 555 + t 556 + t 557 + t 558 + t 559 +
12t 560 + t 563 + t 565 + t 566 + t 568 + t 580 + t 585 + t 588 + t 589 + t 591 + t 592 + t 593 + t 596 + t 597 + t 602 + t 604 + t 606 + t 610 +
13t 616 + t 620 (mod 2).
14This polynomial factors into 4 irreducibles over GF (2), each of degree 155. One of these is
15p(t) = 1 + t + t 2 + t 6 + t 9 + t 10 + t 11 + t 13 + t 14 + t 15 + t 16 + t 18 + t 19 + t 22 + t 23 + t 26 + t 27 + t 29 + t 31 + t 49 + t 50
16+ t 51 + t 54 + t 55 + t 60 + t 61 + t 62 + t 64 + t 66 + t 70 + t 72 + t 74 + t 75 + t 80 + t 82 + t 85 + t 86 + t 88 + t 89 + t 91 + t 93 +
17t 97 + t 101 + t 103 + t 104 + t 111 + t 115 + t 116 + t 117 + t 118 + t 120 + t 121 + t 123 + t 124 + t 126 + t 127 + t 128 + t 129 + t 130 +
18t 131 + t 132 + t 134 + t 136 + t 137 + t 138 + t 139 + t 140 + t 143 + t 145 + t 154 + t 155.
20y 2+xy = x 3 + t 3
22r = 11417981541647679048466230373126290329356873447.
24Input: a field size GF (2m), an appropriate D, the corresponding k and r from A.14.3.2.
26 kk) Compute a and b via A.14.5.1 with u = kr.Find a point G of order r via A.11.3.Output the
27 coefficients a, b and the point G.
31If n is a large positive integer, the following probabilistic algorithm (the strong probable prime test or the
32Miller-Rabin test) will determine whether n is prime or composite, with arbitrarily small probability of
33error (see [Knu81]).
34Input: an odd integer n > 2 to be tested, a positive integer t for the number of trials.
2 247
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
17If a random k-bit integer n has tested “prime” after t trials of the Miller-Rabin test, then the probability that
18n is composite is at most
k
19 pk ,t 2 t 4 k ( 2 tk
)
t
k t k t k t
1The values of t in this table can be lowered in many cases; see [DLP93] and [Bur96].
3In generating parameters, one can take random numbers and test them for primality according to A.15.2.
4When verifying parameters, however, one cannot treat the putative prime number as random. In this case,
5the Miller-Rabin test should be run t = 50 times in order to achieve a probability of error less than 2–100.
7Another application of the complex multiplication algorithm of A.14 is proving the primality of an integer
8deemed “prime” by a probabilistic test such as A.15.1. The Goldwasser-Kilian-Atkin algorithm produces a
9primality certificate: a collection
10C = {C1,...Cs}
13where:
14
15 For all i, (xi, yi) is a point of order ri on the elliptic curve
19 p1 = n,
20 pi+1 = ri for 1 i < s,
21 rs < lmax
2
,
24Let p and r be positive integers greater than 3 with r 4 p 1 . Let a, b, x, and y be integers modulo p
25such that (x, y) is a point of order r on the elliptic curve
29Input: a large odd positive integer n that has tested “prime” in A.15.1, and a trial division bound lmax.
2 249
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
18 E : y2 x3 + ax + b (mod p)
24Given lower and upper bounds rmin and rmax, and a trial division bound lmax, the following procedures test an
25integer u for near primality in the sense of A.9.5. Let
26K := u/rmin.
27
28 If K = 1, then u is nearly prime if and only if it is prime.
29 If K 2, then the following algorithm tests u for near primality. Note that one can always take
30 lmax K.
31Input: positive integers u, lmax, rmin, and rmax.
32Output: if u is nearly prime, a prime r in the interval rmin r r max and a smooth integer k such that u =
33kr. If u is not nearly prime, the message “not nearly prime.”
34 oo) Set r u, k 1.
35 2. For l from 2 to l max do
36 2.1 If l is composite then go to Step 2.3.
37 2.2 While (l divides r)
38 2.2.1 Set r r / l and k k l.
39 2.2.2 If r < r min then output “not nearly prime” and stop.
2 250
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 2.3 Next l.
2 pp) 3. If r > rmax then output “not nearly prime” and stop.Test r for primality via A.15.3 (and
3 A.15.4 if desired).If r is prime then output k and r and stop. Output “not nearly prime.”
6The primes p found by this algorithm also satisfy the condition that p – 1 is relatively prime to a specified
7odd positive integer f. Such a condition is required for generating IF parameters. In the case of RSA, f is
8set equal to the public exponent. In the case of RW, f is set equal to one-half the public exponent. For
9applications where such a condition is not needed, one takes f = 1, since this choice leads to a vacuous
10condition.
11Input: a lower bound pmin for p; an upper bound pmax for p; an odd positive integer f.
12Output: a random prime p from the range pmin p pmax for which p – 1 is relatively prime to f.
13 qq) Let kmin := (pmin – 1) / 2 and kmax := (pmax – 1) / 2.Generate a random integer k from the range kmin
14 k kmax..Set p 2k + 1.Compute d := GCD (p – 1, f) via A.2.2If d = 1, then
15 5.1 Test p for primality via A.15.2 (and A.15.4 if desired).
16 5.2 If p is prime, then output p and stop.
17 6. Go to Step 2.
19The following algorithm differs from the preceding one only in that it imposes the additional condition on
20the prime p that p a (mod r) for some specified a and odd prime r. The remarks made at the beginning of
21A.15.6 apply here as well.
22Input: a prime r > 2; a positive integer a not divisible by r; a lower bound pmin for p; an upper bound pmax
23for p; an odd positive integer f.
24Output: a random prime p from the range pmin p pmax satisfying p a (mod r) and for which p – 1 is
25relatively prime to f.
26 rr) Set b a if a is odd else set b a + r.Let kmin := (pmin – b) / (2r) and kmax := (pmax – b) /
27 (2r)Generate a random integer k from the range kmin k kmax.Set p 2rk + b.Compute d := GCD
28 (p – 1, f) via A.2.2.
29 6. If d = 1, then
30 6.1 Test p for primality via A.15.2 (and A.15.4 if desired).
31 6.2 If p is prime, then output p and stop.
32 7. Go to Step 3.
33NOTE—If r and p are to have roughly the same bit length, it is possible that a prime will not be found. More precisely,
34the expected number of primes for a given r is at most (pmax – pmin) / (r log pmax). If this quantity is very small, one
35should give up after a few iterations and restart the algorithm with a new value of r.
2 251
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 p 1 (mod r) for some large prime r.
3 p –1 (mod s) for some large prime s.
4 r 1 (mod t) for some large prime t.
5The following algorithm efficiently produces a strong prime p such that p – 1 is relatively prime to the
6specified odd positive integer z. (If the latter condition is not wanted, the choice z = 1 leads to a vacuous
7condition.)
8Input: a lower bound pmin for p; an upper bound pmax for p; the desired bit lengths L(r), L(s), and L(t); an
9odd positive integer z.
10Output: a random strong prime p from the interval pmin p pmax, where the primes r, s, and t have lengths
11L(r), L(s), and L(t) respectively, where p – 1 is relatively prime to z.
12 ss) Generate a random prime t from the interval 2 L(t)–1 t 2 L(t) – 1 using A.15.6 with f = 1.Generate a
13 random prime r from the interval 2 L(r)–1 r 2 L(r) – 1 satisfying r 1 (mod t) using A.15.7 with f =
14 1.Generate a random prime s from the interval 2 L(s)–1 s 2 L(s) – 1 using A.15.6 with f =
15 1.Compute u := 1/s mod r via A.2.2.Compute v := 1/r mod s via A.2.2.Compute a su – rv mod
16 rs.Generate a random prime p from the interval pmin p pmax satisfying p a (mod rs), using
17 A.15.7 with f = z.
18 8. Output p.
19If the strong prime p is also to satisfy an additional congruence condition p h (mod m), then the last two
20steps of the algorithm should be replaced by the following steps.
21 tt) Compute b := 1 / (rs) mod m via A.2.2.Compute k := 1 / m mod rs via A.2.2.Compute c akm +
22 bhrs mod mrs.Generate a random prime p from the interval pmin p pmax satisfying p c (mod
23 mrs), using A.15.7 with f = z.Output p.
26Input: lower and upper bounds pmin and pmax for the modulus p; lower and upper bounds rmin and rmax for
27the generator order r; whether or not the parameters will be used for DLSVDP-DHC or DLSVDP-MQVC.
28Output: DL parameters q = p, r, and g, satisfying pmin p pmax and rmin r rmax; the cofactor k, if
29desired
30 uu) Generate a random prime r from the interval rmin r rmax using A.15.6 with f = 1.Generate a
31 random prime p from the interval pmin p pmax satisfying the condition p 1 (mod r), using
32 A.15.7 with f = 1.Let k = (p – 1) / r.If the parameters will be used for DLSVDP-DHC or DLSVDP-
33 MQVC, check if r divides k. If so, go to Step 1.Choose an integer h, not already chosen, satisfying
34 1 < h < p – 1.
35 6. Compute
36 g := h k mod p
37 via A.2.1
38 vv) If g =1 then go to Step 5.
2 252
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
3Input: DL parameters q = p, r, and g; the cofactor k (optional); whether or not the parameters will be used
4for DLSVDP-DHC or DLSVDP-MQVC.
6 ww) Check that p is an odd integer and p > 2. Check primality of p via A.15.3.Check that r is an odd
7 integer and r > 2. Check primality of r via A.15.3.Check that g is an integer such that 1 < g <
8 pCheck that gr 1 (mod p)If k is supplied, check that k is an integer such that kr = p – 1If the
9 parameters will be used for DLSVDP-DHC or DLSVDP-MQVC, check that r does not divide k (if
10 k is not supplied, first set k (p – 1)/r)Output “True” if all checks work, and “False” otherwise.
11NOTE—A method for verifiably pseudo-random generation of DL parameters is provided in FIPS 186 [FIP94b], ANSI
12X9.30:1 [ANS97a], and ANSI X9.42 [ANS98b]. See D.4.1.4 for more information.
14Input: lower and upper bounds rmin and rmax for the generator order r; a list of possible field degrees
15m1, …, ml; whether polynomial or normal basis is desired; whether or not the parameters will be used for
16DLSVDP-DHC or DLSVDP-MQVC.
17Output: DL parameters q = 2m, r, and g (and the cofactor k, if desired), satisfying rmin r rmax and m = mi
18for some i, if such exist; otherwise, the message “no such parameters.”
39The Cunningham tables are published collections of factors of 2 m – 1 for m up to 1200, even m up to 2400, and m 4
40(mod 8) up to 4800. They are available in print (see [BLS88]); an up to date version is available via FTP from Oxford
41University at ftp://sable.ox.ac.uk/pub/math/cunningham/.
2 253
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1If m 1200 is odd, then the primitive prime factors of 2m – 1 are listed in Cunningham table 2–, in the entry n = m. If
2m 2400 is even but not divisible by 4, then the primitive prime factors of 2 m – 1 are listed in Cunningham table 2+
3(Odd), in the entry n = m / 2. If m 4800 is divisible by 4 but not by 8, then the primitive prime factors of 2 m – 1 are
4listed in Cunningham table 2LM, in the two entries for n = m / 2. If m 2400 is divisible by 8, then the primitive prime
5factors of 2m – 1 are listed in Cunningham table 2+ (4k), in the entry n = m / 2.
6In the FTP version, the last three tables are combined into one, called 2+, but the entries are listed in the same notation.
72—A polynomial basis can be obtained from the basis table given in Annex A.8.1 if m 1000. Alternatively,
8irreducible polynomials over GF (2) can be obtained using the methods given in Annex A.8.2 through A.8.5.
9If a normal basis is desired and if m 1000 is not divisible by 8, then a Gaussian normal basis can be obtained from the
10basis table given in Annex A.8.1. Alternatively, normal polynomials over GF (2) can be obtained via Annex A.6.2.
12Input: DL parameters q = 2m, r, and g; the cofactor k (optional); the representation for the elements of
13GF (2m) ; whether or not the parameters will be used for DLSVDP-DHC or DLSVDP-MQVC.
15 zz) If the representation for the field elements is given by a polynomial basis, check that m is a positive
16 integer and that the polynomial is of degree m. Check that it is irreducible via A.5.5.If the
17 representation for the field elements is given by a Gaussian normal basis of type T, check that m is
18 a positive integer not divisible by 8 and that T is a positive integer; check that such a basis exists
19 via A.3.6.If the representation for the field elements is given by a general normal basis, check that
20 m is a positive integer and that the polynomial is of degree m. Check that it is irreducible via A.5.5
21 and that it is normal via A.6.1Check that r is an odd integer and r > 2. Check primality of r via
22 A.15.3.Check via A.2.7 that the order of 2 modulo r is m (otherwise, it will be less than m, which
23 means that r is not a primitive factor of 2 m – 1—see Annex A.16.2).Check that g is an element of
24 GF (2m) and that g 0 and g 1 in GF (2m).Check that gr = 1 in GF (2m).If k is supplied, check that
25 k is an integer such that kr = 2m – 1If the parameters will be used for DLSVDP-DHC or DLSVDP-
26 MQVC, check that r does not divide k (if k is not supplied, first set k (2m – 1)/r)
27 10. Output “True” if the checks work, and “False” otherwise.
31 aaa) Generate an integer s in the range 0 < s < r designed to be hard for an adversary to guess (e.g., a
32 random integer).Compute w by exponentiation: w := g s in GF (q).Output w and s.
2 254
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 bbb) If q = p is an odd prime, check that w is an integer such that 1 < w < p.If q = 2m is a power of two,
2 check that w is an element of GF (2m) and that w 0 and w 1 in GF (2m).Check that that w r = 1 in
3 GF (q).
4 4. Output “True” if the checks work, and “False” otherwise.
5The following algorithm does not verify the validity of a DL public key, but merely checks if it is in the
6multiplicative group of GF (q). It may be used in conjunction with DLSVDP-DHC and DLSVDP-MQVC
7primitives.
10 ccc) If q = p is an odd prime, check that w is an integer such that 0 < w < p.If q = 2m is a power of two,
11 check that w is an element of GF (2m) and that w 0 in GF (2m).Output “True” if the checks work,
12 and “False” otherwise.
14Input: a field size q (where q is an odd prime p or 2m); lower and upper bounds rmin and rmax for the base
15point order r; a trial division bound lmax; the representation for the elements of GF (2m) if q = 2m (see Note 2
16in A.16.3 for information on methods for choosing a basis for GF (2m)); whether or not the parameters will
17be used for key validation, ECSVDP-DHC or ECSVDP-MQVC .
19 ddd) Use the techniques of A.14 to find a positive integer k, a prime r in the interval rmin r rmax, a
20 curve E over GF (q) of order kr, and a point G of order r.If q is prime and q = r then the curve is
21 anomalous and subject to the reduction attack described in [Sma98] and [SA98]. Go to Step 1.If
22 the parameters will be used for key validation, ECSVDP-DHC or ECSVDP-MQVC, check if r
23 divides k. If so, go to Step 1.Check the MOV condition via A.12.1. If the output is “False” then go
24 to Step 1.Output q, a, b, r, and G (and k if desired).
26Input: EC parameters q (where q is an odd prime p or 2m), a, b, r, and G; the cofactor k (optional); the
27representation for the elements of GF (2m) if q = 2m; whether or not the parameters will be used for key
28validation, ECSVDP-DHC or ECSVDP-MQVC; whether or not the curve is verifiably pseudo-random, and
29if so, the parameters given in A.12.5 (if q odd) or A.12.7 (if q even).
1 5.2 Check that a and b are integers such that 0 a < p and 0 b < p.
2 5.3 If the curve is verifiably pseudo-random then check this via A.12.5.
3 5.4 Check that 4a3 + 27b2 mod p is not 0.
4 5.5 Check that G O. Let G = (x, y).
5 5.6 Check that x and y are integers such that 0 x < p and 0 y < p.
6 5.7 Check that y2 x3 + ax+ b (mod p).
7 5.8 Check that rG = O.
8 5.9 Check that the curve is not an instance of one of the following excluded cases:
95.9.1 If the output of the algorithm given in A.12.1 is “False,” then the curve is excluded
10because it is subject to the MOV reduction attack described in [MOV93], [Hitt07].
11 5.9.2 If r = p, then the curve is excluded because it is subject to the reduction attack
12 described in [Sma99] and [SA97] (see Annex D.4.2 for more information).
13 6. If q = 2m then
14 6.1 Check the representation for the field elements, as follows:
15 6.1.1 If the representation for the field elements is given by a polynomial basis, check that m
16 is a positive integer and that the polynomial is of degree m. If the polynomial is not
17 listed in Table A.8.1, then check that it is irreducible via A.5.5.
18 6.1.2 If the representation for the field elements is given by a Gaussian normal basis of type
19 T, check that m is a positive integer not divisible by 8 and that T is a positive integer.
20 If the value for T does not appear in the entry for m in Table A.8.1, then check that
21 such a basis exists via A.3.6.
22 6.1.3 If the representation for the field elements is given by a general normal basis, check
23 that m is a positive integer and that the polynomial is of degree m. Check that it is
24 irreducible via A.5.5 and that it is normal via A.6.1.
25 6.2 Check that a and b are elements of GF (2m).
26 6.3 If the curve is verifiably pseudo-random then check this via A.12.7.
27 6.4 Check that b 0 in GF (2m).
28 6.5 Check that G O. Let G = (x, y).
29 6.6 Check that x and y are elements of GF (2m).
30 6.7 Check that y2 + xy = x3 + ax2 + b in GF (2m).
31 6.8 Check that rG = O.
32 6.9 Check that the curve is not an instance of the following excluded case:
336.9.1 If the output of the algorithm given in A.12.1 is “False,” then the curve is excluded
34because it is subject to the MOV reduction attack described in [MOV93], [Hitt07].
35 7. Output “True” if the checks given in Steps 4 through 6 work, and “False” otherwise.
36NOTE—The condition r > 4 q is the usual practice and is required by the ISO and ANSI standards dealing with EC
37parameter validation. Thus, in the typical environment, it will always be the case that r > 4 q. For an environment
38in which this is known to be the case, steps 1.1 and 2 may be omitted.
42 ggg) Generate an integer s in the range 0 < s < r designed to be hard for an adversary to guess (e.g., a
43 random integer).Compute the point W by scalar multiplication: W = sG.Output W and s.
2 256
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
3Input: valid EC parameters q, a, b, r, G and k such that r does not divide k; a public key W.
5 hhh) Check that W O. Let W = (x, y)If q = p, check that x and y are integers such that 0 x < p and 0
6 y < p and y2 x3 + ax+ b (mod p).If q = 2m, check that x and y are elements of GF (2m) and that y2 +
7 xy = x3 + ax2+ b in GF (2m).Check that rW = O.Output “True” if the checks work, and “False”
8 otherwise.
9The following algorithm does not verify the validity of an EC public key, but merely checks if it is a non-
10identity point on the elliptic curve specified by the parameters. It may be used in conjunction with
11ECSVDP-DHC and ECSVDP-MQVC primitives.
14 iii) Check that W O. Let W = (x, y)If q = p, check that x and y are integers such that 0 x < p and 0
15 y < p and y2 x3 + ax+ b (mod p).If q = 2m, check that x and y are elements of GF (2m) and that y2 +
16 xy = x3 + ax2+ b in GF (2m).
17 4. Output “True” if the checks work, and “False” otherwise.
19An RSA modulus is a product n of two (large) primes p and q. Given a public verification (or encryption)
20exponent e, the following algorithm efficiently produces such an RSA modulus along with the secret
21signing (or decryption) exponent d.
22Common choices for e include the Fermat primes 3, 5, 17, 257, and 65537, since these choices lead to
23particularly efficient exponentiations using the binary method of A.2.1. If a pseudo-random value of e is
24desired, it should be generated independently of p and q.
25The primes produced may be randomly generated, or they may be strong primes (see Annex A.15.8). A
26large randomly generated prime is virtually certain to be strong enough in practice.
27Input: the desired bit length L for the modulus; an odd public exponent e > 1.
30 2M–1 p 2M – 1
31 where M = (L + 1)/2, using A.15.6 with f = e (for random primes) or A.15.8 with z = e (for strong
32 primes).
33 kkk) Generate a prime q from the interval
2 257
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 L1 2L
1 1 q
p p
2 using A.15.6 with f = e (for random primes) or A.15.8 with z = e (for strong primes).
3 lll) Set n := pq.Compute l := LCM (p – 1, q – 1) via A.1.1 and A.2.2.Compute d := e –1 mod l via
4 A.2.2.
5 6. Output n and d.
7A Rabin-Williams (RW) modulus is a product n of two (large) primes p 3 (mod 8) and q 7 (mod 8).
8Given a public verification exponent e, the following algorithm efficiently produces such an RW modulus
9along with the secret signing exponent d.
10The usual choice for the verification exponent is e = 2, since this choice means that signature verification
11can be implemented via a modular squaring rather than a modular exponentiation. If a pseudo-random
12value of e is desired, it should be generated independently of p and q.
13The primes produced may be randomly generated, or they may be strong primes (see Annex A.15.8). A
14large randomly generated prime is virtually certain to be strong enough in practice.
15Input: the desired bit length L for the modulus; an even public exponent e.
18 2M–1 p 2M – 1
19 where M = (L + 1)/2, using A.15.7 with f = e/2 (for random primes) or A.15.8 with z = e/2 (for
20 strong primes).
21 nnn) Generate a prime q 7 (mod 8) from the interval
2 L1 2L
22 1 q
p p
23 using A.15.7 with f = e/2 (for random primes) or A.15.8 with z = e/2 (for strong primes).
24 ooo) Set n := pq.Compute l := LCM (p – 1, q – 1) / 2 via A.1.1 and A.2.2.Compute d := e –1 mod l via
25 A.2.2.
26 6. Output n and d.
27
2 258
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1GF(p). As in 5.3.2.3, if m is composite, the field elements may be represented with a composite basis. In
2this case, a subfield GF(pd) of GF(pm) is chosen where 1 < d < m and d | m. Elements of GF(pm) are then
3represented as vectors of elements from GF(pd), as described by Aoki, Hoshino, and Kobayashi [AHK99].
4Arithmetic is performed exactly as described below, except that arithmetic in GF(pm) is implemented using
5operations from GF(pd). This process of choosing representations for subfields of GF(pd) may be repeated
6for each of the divisors of d.
8This subclause describes the basic method for arithmetic in fields GF(pm), for an odd prime p, m > 1, of
9which an Optimal Extension Field (OEF) is a special case. The material in this subclause is described in
10Bailey and Paar [BP98] (see also [Mih97]).
11An extension field GF(pm) is isomorphic to GF(p)[t]/(f(t)), where f(t) is a monic irreducible polynomial of
12degree m over GF(p). In the following, a residue class will be identified with the polynomial of least degree
13in this class. The polynomial basis representation of a field element A(t) GF(pm) has the form:
18Addition and subtraction of two field elements is implemented in a straightforward manner by adding or
19subtracting the coefficients of their polynomial representation and if necessary, performing a reduction
20modulo p by subtracting or adding p once from the intermediate result.
22Field multiplication can be performed in two stages: multiplication and modular reduction. First, perform
23an ordinary polynomial multiplication of two field elements A(t) and B(t), resulting in an intermediate
24product C(t) of degree less than or equal to 2m2:
25C (t) = A(t) B(t) = c2m2 t2m-2 + … + c1 t + c0, ci GF(p).
26The schoolbook method to calculate the coefficients ci, i = 0, 1, …, 2m2, requires m2 multiplications and
27(m1)2 additions in the subfield GF(p), although implementers may achieve better performance using
28convolution methods.
29Second, calculate the residue C(t) C(t) (mod f(t)), C(t) GF(pm). A.17.3.2 presents an efficient method.
30Squaring can be considered a special case of multiplication. The only difference is that the number of
31coefficient multiplications in the schoolbook method can be reduced to m(m + 1)/2.
32Coefficient multiplications require multiplication in the subfield. A method for fast prime subfield
33multiplication is found in A.17.3.1. Certain choices for p can result in additional computational savings in
34the prime subfield multiplication.
2 259
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
5 ppp) Compute b := .
6 2. If b is 0 or 1 output “square”; else output “not a square”.
7NOTE—b should be 0 only if a is 0, and should otherwise be +1 or -1.
8The following algorithm implements a square root in GF(pm).
10Output: An element z such that z2 = g, or the message “no square roots exist”.
11 qqq) If g = 0 then output 0 and stop.Let k := (pm + 1)/4.If k is not an integer, then go to step 6.Let z :=
12 gk.If z2 = g then output z and stop. Otherwise output “no square roots exist” and stop.Choose y
13 GF(pm) at random.If y is a square, then go to step 6.Write pm 1 = k 2e with k odd, and let y :=
14 yk.Let A := gk, z := g(k+1)/2.If 1, then output “no square roots exist” and stop.If A = 1, then go to step
15 14.Let i be the smallest positive integer such that = 1.Let A := , z := . Go to step 11.
16 14. Output z and stop.
17NOTES
181—Steps 3 and 4 are convenient if p 3 mod 4 and m is odd, and can be skipped in any case.
192—The i of step 12 will always be less than e, assuming that the computations are performed in a valid field (i.e., p is
20prime, the field polynomial is primitive, etc.). For assurance, implementations may wish to check that i e, and output
21an error message otherwise.
223—Steps 11–13 will take at most e iterations, again assuming a valid field. To avoid an infinite loop if the parameters
23are invalid, implementations may wish to stop explicitly after e iterations.
244—A more efficient square root algorithm is described by Barreto et al. [BKL+02].
26Performance improvement can result from the selection of particular finite fields in which the algorithms
27for extension field arithmetic have an especially efficient implementation.
28An Optimal Extension Field (OEF) is a finite field GF(pm) such that:
7A Type II OEF allows for a reduction in the complexity of extension field modular reduction since the
8multiplications by in Algorithm A.17.3.2 can be implemented using shifts instead of explicit
9multiplications. An OEF may be of both Type I and Type II.
15
16 1. Set x ab.
17 2. Set q0 x >> n.
18 3. Set r0 x – (q0 << n).
19 4. Set r r0.
20 5. Set i 0.
21 6. While qi > 0
22 6.1 Set qi+1 qic >> n.
23 6.2 Set ri+1 qic – (qi+1 << n).
24 6.3 Set i i + 1.
25 6.4 Set r r + ri.
26 7. While (r p)
27 7.1 Set r r – p.
28The above algorithm requires a maximum of two iterations of the first while loop, so at most two
29multiplications by c are required.
30If c = 1 as in a Type I OEF, this algorithm executes the first while loop only once and multiplication by c is
31an identity map.
33The following algorithm performs extension field modular reduction in the field GF(pm) modulo an
34irreducible binomial.
2 261
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Input: A polynomial C(t), of degree up to (2m – 2), an integer such that f(t) = tm – is an irreducible
2binomial over GF(p)
3Output: A polynomial C(t) C(t) (mod f(t)), where C(t) is of degree less than m
4
5 1. Let C(t) = cm-1 tm-1 + … + c0 and C(t) = c2m-2 t2m–2 + … + c0.
6 2. Set cm-1 cm-1.
7 3. For i from m – 2 downto 0, j from 2m – 2 downto m
8 3.1 Set ci cj + ci.
9The above algorithm requires a maximum of (m – 1) subfield multiplications by . If = 2i as in a Type II
10OEF, these multiplications may be implemented as bitwise shifts.
2 262
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2This algorithm (see Itoh, Teechai, and Tsujii [B81] and Bailey and Paar [BP00]) computes the
3multiplicative inverse -1 of an element such that 1 1 GF(pm). An analogous algorithm for fields
4GF(2m) is in A.4.4.
7
8 1. Set r (pm – 1) / (p – 1).
9 2. Set b r1.
10 3. Set c b.
11 4. Set c1.
12 5. Set 1 b.
13The above algorithm requires an exponentiation to the r-th power and an inversion in GF(p), since c = r =
14Norm() GF(p), where the function Norm is defined as Norm() = p … = r, where r = (pm –
151)/(p – 1), GF(pm).
16To quickly perform the exponentiation, observe the following power series representation for r:
22(log2(m – 1) + Hw(m – 1) – 1) general multiplications + (log2(m – 1) +Hw(m – 1)) exponentiations
23where Hw denotes the Hamming weight, that is, the number of 1s in the binary representation of an integer.
24Each exponentiation is to a pi-th power and is thus an iterate of the Frobenius map (i.e., the map p).
25Since an OEF has an irreducible binomial as the field polynomial, one has the following algorithm for each
26exponentiation.
27The following algorithm computes the pi-th power of , i.e., exp(, pi) in an OEF, when GCD (p, m) = 1.
30
2 263
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2To compute the subfield inverse required in the algorithm in A.17.3.3, one may use the algorithm in A.2.2.
3A.17.3.5 Construction
4This algorithm finds an irreducible binomial to construct an Optimal Extension Field, given an approximate
5subfield order and extension degree.
6Input: An integer n, where 2n c will be the characteristic of the field; a positive integer m, the extension
7degree
9
10 1. Set c 1.
11 2. While log2 c n/2
12 2.1 Set p 2n c.
13 2.2 If p is prime and the divisors of m divide (p – 1).
14 2.2.1 Set 2.
15 2.2.2 While < p
16 2.2.3.1 If tm – is irreducible (see A.17.2), output .
17 2.2.3.2 Set + 1.
18 2.3 Set c c + 2.
19NOTES
201—The performance of this algorithm may be greatly improved by replacing step 2.3 with a sieve step.
212—Under the Extended Riemann Hypothesis, step 2.2.2 will terminate after O(log p) iterations.
n c m mn
7 -1 27 189 3
8 1 32 256 2
13 -1 13 169 2
13 -1 14 182 17
13 -1 15 195 17
13 -1 18 234 17
2 264
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
16 1 16 256 2
17 -1 10 170 3
17 -1 15 255 3
19 -1 9 171 3
31 -1 6 186 7
31 -1 7 217 7
61 -1 3 183 5
3In contrast to their use in the EC setting, an OEF to be used in the DL setting is subject to an additional
4constraint: the OEF must have a sufficiently large subgroup. An analogous situation exists in the use of
5prime fields (see D.4.1.4 Note 5).
6The problem is more difficult in the OEF case. As noted by Lenstra [Len97], a subgroup is required that is
7large enough to thwart collision search methods (see D.4.1.4 Note 1), and that is not contained in any
8GF(pn) for n | m, n < m. For this purpose, it suffices to verify that the m-th cyclotomic polynomial m
9evaluated at p has a sufficiently large prime factor r, which indicates the field has a subgroup of order r
10subject to the above constraints. (The reason that this is sufficient is that, as pointed out in Lenstra [Len97],
11if r > m divides m(p), then r does not divide n(p) for any n | m, n < m. Since pn – 1 is the product of d(p)
12for d | n, d < n, it follows that r does not divide pn – 1 and hence that the subgroup is not contained in
13GF(pn) for any such n.)
17(n) = 1 if n = 1
24From the above formula, the 18-th cyclotomic polynomial is 18(p) = p6 – p3 + 1. This expression is an
25integer of approximately 384 bits, which may be factored by any method, such as the Elliptic Curve
26Method (see D.4.3.4 Note 3). The largest factor found may be used as the subgroup order r.
2 265
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1In general, m(p) will be an integer of ( (m) log2(p)) bits in length, where is the Euler function giving the
2number of integers coprime to m and less than m. It is thus more efficient to construct an OEF in the DL
3setting for those extension degrees m with small values of (m). Even with this restriction, however, there
4are many fields to choose from. The optimal choice of field parameters will be security level and machine
5dependent.
8NOTE—The values log2p, log2r and log2pm have been rounded to the nearest integer.
10In general, algorithms for elliptic curves over odd characteristic extension fields are the same as those given
11in A.9-14 for GF(p) and GF(2m), and for the most part the differences are left as an “exercise to the reader.”
12However, some notable points are as follows:
13
14 If p > 3, one can follow the Weierstrass equation (cf. A.9) and elliptic curve addition formulae (cf.
15 A.10) for elliptic curves over GF(p), replacing GF(p) directly with GF(pm). However, if p = 3, the
16 Weierstrass equation (see Koblitz [Kob98]) is
17 y 2 = x 3 + ax 2 + b
18 where a and b are elements of GF(3m) with a 0 and b 0, and the addition formulae for prime
19 fields in A.10 do not apply. A.17.4.1 gives an algorithm for implementing full addition and
20 subtraction on a curve over GF(3m) in terms of affine coordinates; algorithms for doubling and for
21 projective coordinates are left to the reader.
22
23 The point compression methods in A.9.6 are not directly applicable.
24
2 266
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 The algorithm for computing curve orders in extension fields (A.11.5) can be extended to GF(pm)
2 essentially by replacing 2 with p.
3
4 If p > 3, the algorithm for computing the Weil pairing (A.12.2) is the same as for GF(p). If p = 3,
5 the algorithm is the same except that the function f((x0, y0), (x1, y1), (u, v)) is defined as 2a(ux1)
6 2y1(vy1) when x0 = x1 and y0 = y1.
8The following algorithm implements a full addition (on a curve over GF(3m)) in terms of affine coordinates.
9All arithmetic operations are performed in the field.
10Input: A field GF(3m); coefficients a, b for an elliptic curve E: y 2 = x 3 + ax 2 + b over GF(3m); points P0 =
11(x0, y0) and P1 = (x1, y1) on E
13
14 1. If P0 = O then output P2 P1 and stop.
15 2. If P1 = O then output P2 P0 and stop.
16 3. If x0 x1 then
17 3.1 Set (y0 – y1) / (x0 – x1), GF(3m)*.
18 3.2 Go to step 7.
19 4. If y0 y1 then output P2 O and stop.
20 5. If y1 = 0 then output P2 O and stop.
21 6. Set ax0 / y0.
22 7. Set x2 2 – x0 – x1 – a.
23 8. Set y2 (x1 – x2) – y0.
24 9. Output P2 (x2, y2).
25The above algorithm requires three or four field multiplications and a field inversion.
26To subtract the point P = (x, y), one adds the point –P = (x, –y).
28Algorithms for generating and validating DL and EC domain parameters and keys over odd characteristic
29extension fields are mostly the same as those given in A.16 for GF(p) and GF(2m). The differences are as
30follows:
31Generating DL parameters: Same general approach as A.16.3; an outline of the algorithm for OEFs
32(which is easily generalized to other odd characteristic extension fields) is given in A.17.3.7.
2 267
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
4Validating DL public keys: Same as A.16.6, except that step 2 of each algorithm checks if q = pm, p > 3,
5m > 1, and checks w with respect to GF(pm) rather than GF(p).
7Validating EC parameters: Same general approach as A.16.8, with some differences in details (e.g., the
8curve equation for p = 3).
10Validating EC public keys: Same as A.16.10, except that steps 2 and 3 of each algorithm are replaced
11with the following:
12 2. If q = pm, p > 3, check that x and y are elements of GF(pm) and y2 = x3 + ax + b GF(pm).
13 3. If q = 3m, check that x and y are elements of GF(3m) and that y2 = x3 + ax2+ b GF(3m).
14
2 268
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2The purpose of this Annex is to provide implementers with a consistent language for claiming conformance
3with parts of this standard. Note, however, that this Annex does not provide the means for verifying that a
4particular implementation indeed operates as claimed (this is sometimes called “implementation
5validation”). Therefore, conformance claims made by an implementation are mere claims, unless their
6accuracy can be assured by other means. Such other means may include, for example, implementation
7validation or assignment of legal liability to the implementer claiming conformance. They are outside the
8scope of this standard.
9Note also that conformance for the purposes of this standard is a matter of functional correctness, not
10secure implementation; for the latter, implementers should refer to the security considerations in Annex D.
11An implementation may claim conformance with one or more primitives, schemes or scheme operations
12specified in this standard, as further described in this Annex.
13An implementation shall not claim conformance with this standard as a whole.
14For background on primitives and schemes, please refer to Clause 4. Specific primitives and schemes are
15defined in Clauses 6–10.
19
20 the specification with which conformance is claimed
21 a set of inputs, or conformance region, for which the specification is defined, and over which
22 conformance is claimed
23For the purposes of this standard, the specification may be that of a primitive, a scheme operation, or a
24scheme. (An implementation may claim conformance with a scheme by claiming conformance with each
25operation in the scheme.) For a primitive, the inputs are those stated in the specification; for a scheme
26operation, the term “input” refers both to initial inputs such as messages, and inputs obtained during a step
27of the operation such as domain parameters, keys, and key derivation parameters. Recommended
28conformance regions are given in the specifications.
29The set of inputs for which a specification is defined depends on the particular primitive or scheme. For a
30primitive, the set consists of all inputs that satisfy the assumptions stated for the primitive. For a scheme
31operation, the set includes at least those inputs that satisfy the assumptions for any primitives invoked by
32the operation. If the operation includes key validation or domain parameter validation, then the
33specification may also be defined for certain inputs that do not satisfy the assumptions for a primitive
34invoked by the scheme. Thus, for example, the specification of a scheme operation may be defined for
35invalid as well as valid keys when key validation is included in the scheme, even though the specification
36of a primitive invoked by the scheme is not defined for invalid keys. This is because the behavior of the
37scheme with key validation is defined as follows on invalid keys: the keys are rejected.
38The minimum behavioral requirements for claiming conformance over a conformance region are as
39follows:
2 269
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 sss) On all inputs in the conformance region, the implementation shall perform steps identical to or
2 equivalent to those specified.
3 ttt) On all other inputs it accepts, the behavior of the implementation shall not interfere with correct
4 operation on inputs in the conformance region. The behavior is otherwise unconstrained.
5Acceptable behaviors in item 2 include operating in accordance with the specification (if the specification
6is defined for the input); rejecting the input; performing steps similar to those specified; or performing
7some other non-interfering operation.
8Since primitives are intended for low-level software or hardware implementation, it may be inconvenient
9for an implementation of a primitive to check whether an input is supported. Consequently, while an
10implementation of a primitive may reject some unsupported inputs, it is not expected that an
11implementation of a primitive will reject every unsupported input. Primitives are not intended to provide
12security apart from schemes, so such checking is appropriately deferred to the schemes. It is expected that
13an implementation of a scheme will reject many or even all unsupported inputs, depending on whether key
14and domain parameter validation is included. For more discussion on the risks of not rejecting unsupported
15inputs, see Annex D.3.3.
16An implementation may claim conformance over with more than one conformance region, or more than
17one specification.
18NOTES
191—In the interest of interoperability, a conformance region should be sufficiently broad to support a range of possible
20applications. It is expected that implementation profiles for various applications will give minimum interoperability
21criteria, in terms of specifications and associated conformance region constraints. For a similar reason, a conformance
22region should be documented explicitly. (In some cases, however, the documentation may be implicit to some extent;
23for instance, the domain parameters may be unambiguously specified, but secret.)
242—Although an implementation’s behavior is unconstrained on inputs outside the conformance region (except for not
25interfering with the behavior on inputs in the conformance region), it is recommended in the interest of robustness that
26an implementation include checks that prevent failure when specified assumptions are not satisfied. For instance, an
27implementation should include checks that prevent division by zero, or infinite loops, even if those checks are not
28necessary when the specified assumptions are satisfied.
293—The concept of “equivalence” (as in “perform steps ... equivalent to”) should be understood in the sense of
30indistinguishability. A conformant implementation of a scheme or primitive may perform steps identical to those
31specified for the scheme or primitive, in the sense of performing those steps exactly as specified, or it may perform
32similar steps that produce the same observable behavior.
33For instance, if a step calls for generating a random number, the implementation may generate a pseudorandom
34number. Under the usual cryptographic assumption that the pseudorandom generator is indistinguishable from a truly
35random generator, the implementation is equivalent to the specification at that step.
36Similarly, an implementation may choose to apply restrictions that exclude certain rare events. For instance, an
37implementation may exclude DL or EC private keys that are equal to 1, and instead generate private keys in the range
38[2, r - 1]. An implementation with such a restriction will be indistinguishable from the specification, and may still claim
39conformance. On the other hand, an implementation that generates private keys in the range [1,1000] could not claim
40conformance, since its behavior would be observably different from the specification.
41As another example, an implementation of IFES-RSA might output an error message when the output of
42the encryption primitive equals its input, which is a rare event.
2 270
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1in B.1. Requirements are to be understood in the context of Clauses 2 (References), 3 (Definitions and
2Acronyms), 4 (Types of Cryptographic Techniques) and 5 (Mathematical Conventions).
3An implementation may claim conformance with a primitive, a scheme, or a scheme operation. For a
4scheme or scheme operation, conformance requirements for the selected primitive or primitives and for
5additional techniques such as encoding methods or key derivation functions are also assumed. When
6documenting conformance with a scheme, these scheme options shall be noted explicitly. In addition, the
7documentation shall indicate whether the implementation includes key validation or domain parameter
8validation, and, if so, what is validated—i.e., what properties of keys and parameters are assured by the
9validation. An implementation claiming conformance with a scheme shall satisfy the requirements for each
10operation in the scheme.
12
13 Conforms with IEEE Std 1363-2000 (technique/options) (as amended in IEEE P1363a) over the
14 region where (constraints on inputs).
15The “technique/options” component identifies the primitive, scheme, or scheme operation; any underlying
16techniques such as the encoding method or hash function; and any additional choices such as whether and
17how domain parameter or key validation is performed. The “constraints on inputs” component identifies the
18conformance region. The method of expressing these components is left to the implementation. Some
19examples are given in B.3.
Primitive Subclauses
2 271
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 272
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
3B.3 Examples
4This clause gives some examples of claims of conformance with the primitives and scheme operations in
5the standard.
2 273
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1B.3.1 DLSP-DSA
2A hardware cryptographic module claims conformance with DLSP-DSA. The two parts of its conformance
3claim are as follows:
4
5 Specification: DLSP-DSA, as given in Clause 6.2.7
6 Conformance region: Inputs of the form
7
8 — the DL domain parameters q, r and g associated with the key s
9 — the signer’s private key s
10 — the message representative, which is an integer f 0
11 where the DL domain parameters and the private key are valid and associated, subject to additional
12 conditions that constrain the conformance region
13An example of additional conditions is the following (this follows the recommendations in Clause 6.2.7):
14
15 the DL field order q is a 512-bit to 1024-bit prime
16 the DL subgroup order r is a 160-bit prime
17 the message representative f is at most 160 bits long
18A module claiming conformance under these conditions may document its conformance as follows:
19
20 Conforms with IEEE 1363-2000 DLSP-DSA over the region where the DL field order q is a 512-bit
21 to 1024-bit prime, the DL subgroup order r is a 160-bit prime, the domain parameters and the
22 private key are valid and associated, and the message representative f is at most 160 bits long.
23Such a module may also claim conformance over a subset of the region just stated. For instance, it may
24claim conformance with the region specified in the Digital Signature Standard ([ANS97a] or [FIP94b]),
25where the DL field order q is a 512-bit, 576-bit, …, or 1024-bit prime and the subgroup order r and
26message representative f are as already stated.
28A software application claims conformance with the DLSSA signature verification operation. The two parts
29of its conformance claim are:
30
31 Specification: DLSSA signature verification, as given in Clause 10.2.3, with a particular signature
32 verification primitive and encoding method, and optionally with particular domain parameter and
33 key validation methods
34 Conformance region: Inputs of the form
35
36 — the DL domain parameters q, r and g associated with the key w
37 — the signer’s purported public key w
38 — the message M
39 — the purported signature (c, d)
2 274
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 subject to additional conditions that constrain the conformance region, some of which may depend
2 on the specification.
3An example of the particulars for DLSSA signature verification is the following:
4
5 signature verification primitive: DLSP-DSA
6 encoding method: EMSA1, with SHA-1 hash function
7 no domain parameter or key validation
8With this specification, the behavior is undefined for invalid domain parameters and keys. An
9implementation may thus claim conformance only over a conformance region consisting of valid domain
10parameters and keys. An example of the conditions that constrain the conformance region in this case is the
11following:
12
13 domain parameters and public key are valid and associated
14 the DL field order q is a 512-bit to 1024-bit prime
15 the DL subgroup order r is a 160-bit prime
16 message M is any that can be input to the implementation, at most 100 Mbytes long
17 the purported signature (c, d) is any that can be input to the implementation, including at least all
18 those such that c and d are in the range [1, r – 1]
19A module claiming conformance under these conditions may document its conformance as follows (with
20shorthand for the specification):
21
22 Conforms with IEEE 1363-2000 DLSSA / DLVP-DSA / EMSA1 / SHA-1 signature verification
23 operation with no explicit domain parameter or key validation over the region where the DL field
24 order q is a 512-bit to 1024-bit prime, the DL subgroup order r is a 160-bit prime, the domain
25 parameters and public key are valid and associated, the message M is at most 100 Mbytes long,
26 and the purported signature (c, d) is any that can be input to the implementation, including at least
27 all those such that c and d are in the range [1, r - 1].
28Another example of the particulars is:
29
30 signature verification primitive: DLSP-DSA
31 encoding method: EMSA1, with SHA-1 hash function
32 “canonical seeded hash” domain parameter validation ([ANS97a]), and key validation (A.16.6)
33With this specification, the behavior is defined for invalid domain parameters and public keys: they are
34rejected. (Indeed, domain parameters that are otherwise valid according to the definitions in this standard,
35but for which the seed is incorrect, are also rejected.) An implementation may thus claim conformance over
36a conformance region consisting of valid and invalid domain parameters and keys. The same example
37conditions as given above may be followed here, except for the condition that the domain parameters and
38public key are valid and associated.
40
2 275
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 Conforms with IEEE 1363-2000 DLSSA / DLVP-DSA / EMSA1 / SHA-1 signature verification
2 operation with “canonical seeded hash” domain parameter validation and key validation over the
3 region where the DL field order q is a 512-bit to 1024-bit prime, the DL subgroup order r is a 160-
4 bit prime, the message M is at most 100 Mbytes long, and the purported signature (c, d) is any that
5 can be input to the implementation, including at least all those such that c and d are in the range
6 [1, r – 1].
7B.3.3 IFSP-RSA2
8A hardware cryptographic module claims conformance with IFSP-RSA2. The two parts of its conformance
9claim are:
10
11 Specification: IFSP-RSA2, as given in Clause 8.2.6
12 Conformance region: Inputs of the form
13
14 — the signer’s RSA private key K
15 — the message representative, which is an integer f such that 0 f < n,
16 where the private key K is valid and such that f 12 (mod 16), subject to additional conditions that
17 constrain the conformance region.
18An example of additional conditions is the following (this follows the recommendations in Clause 8.2.6):
19
20 size of the modulus n in the private key is 512 to 2048 bits
21 message representative f is in the range [0, n – 1]
22A module claiming conformance under these conditions may document its conformance as follows:
23
24 Conforms with IEEE 1363-2000 IFSP-RSA2 over the region where the private key K is valid and
25 the size of the modulus n is 512 to 2048 bits, and the message representative f 12 (mod 16) is in
26 the range [0, n – 1].
27The module may also claim conformance over a subset of the region just stated. For instance, it may claim
28conformance with the region where the modulus size is 1024 to 2048 bits.
30A software application claims conformance with the IFSSA signature verification operation. The two parts
31of its conformance claim are:
32
33 Specification: IFSSA signature verification, as given in Clause 10.3.3, with a particular signature
34 verification primitive and encoding method, and optionally with a particular key validation method
35 Conformance region: Inputs of the form
36
37 — the signer’s purported public key (n, e)
38 — the message M
39 — the purported signature s
2 276
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 subject to additional conditions that constrain the conformance region, some of which may depend
2 on the specification.
3An example of the particulars for IFSSA signature verification is the following:
4
5 signature verification primitive: IFVP-RSA2
6 encoding method: EMSA2, with SHA-1 hash function
7 no domain parameter or key validation
8With this specification, the behavior is undefined for invalid keys. An implementation may thus claim
9conformance only over a conformance region consisting of valid keys. An example of the conditions that
10constrain the conformance region in this case is the following:
11
12 public key (n, e) is valid
13 size of the modulus n in the public key is 512 to 2048 bits
14 message M is any that can be input to the implementation, at most 100 Mbytes long
15 the purported signature s is any that can be input to the implementation, including at least all s in
16 the range [0, (n – 1)/2]
17The application may document its conformance as follows (with shorthand for the specification):
18
19 Conforms with IEEE 1363-2000 IFSSA / IFVP-RSA2 / EMSA2 / SHA-1 signature verification
20 operation with no explicit key validation over the region where the public key (n, e) is valid, the
21 size of the modulus n is 512 to 2048 bits, the message M is at most 100 Mbytes long, and the
22 purported signature s is any that can be input to the implementation, including at least include all s
23 in the range [0, (n – 1)/2].
24
2 277
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
3C.1 General
5All three of the families (DL, EC, and IF) are established in the marketplace. They have different
6advantages and disadvantages, such as performance, key size, code size, availability of cryptanalytic
7research, patent coverage and use in other standards. The goal of this standard is not to restrict users to a
8single choice, but rather to provide a framework that would allow selection of methods appropriate for
9particular applications. Since implementers of this standard need not implement it in its entirety, they have
10the option to choose the techniques that best suit their needs.
12In this standard, primitives are presented as mathematical operations, while schemes are presented in a
13general form based on certain primitives and additional techniques such as encoding methods. Historically,
14primitives were discovered based on number-theoretic one-way functions. Encoding methods and other
15components of the scheme were added later to achieve particular security attributes, and tend to focus more
16on bit-string manipulation. The general form of the scheme lays down a good framework to allow
17alternative techniques to be included in a given scheme in future versions of the standard. An
18implementation can conform to either a primitive or a scheme (see Annex B). Hardware components, in
19particular, may find it advantageous to conform to a primitive, because primitives tend to be less flexible
20and change less than encoding methods and other components of a scheme. Note, however, that primitives
21alone are not intended to provide security (see Clause 4).
22C.1.3 How were the decisions made regarding the inclusion of individual schemes?
23Three types of schemes are defined in this standard: key agreement, digital signatures, and public-key
24encryption. In practice, these are the most basic yet important functions in public-key cryptography. Other
25types of schemes (e.g., identification schemes) may be included in future versions of the standard.
26The main purpose for the initial version of the standard (IEEE Std 1363-2000) was to specify basic public-
27key techniques in a common way. It was recognized that additional techniques remained to be specified,
28which could later be added to the standard. However, many of those additional techniques required further
29development before being standardized, whereas the basic techniques in the initial version were relatively
30more established. It was intended that the P1363a amendment would be merged into IEEE Std 1363-2000
31during future revisions.
32The selection of schemes in the P1363a amendment was based on several considerations: an evaluation of
33the “missing parts” of IEEE Std 1363-2000, which techniques were ready for standardization, and
34comparison of features and tradeoffs among the proposed techniques. Some reasons for the selection of
35each individual scheme in IEEE Std 1363-2000 and the P1363a amendment can be found in C.3.
2 278
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2Key sizes are chosen in accordance with security requirements, and these are application-dependent. As the
3focus of the standard is specifications of public-key techniques, not security certification, no constraints are
4given on the key size for any of the schemes. However, recommendations on key sizes for each family of
5techniques are included in Annex D.
6C.1.5 Why are message encoding methods for encryption and signature needed?
7The mathematical structure of certain "raw" cryptographic algorithms can lead to a number of delicate
8attacks, such as chosen ciphertext attacks (where one obtains the decryption of a ciphertext by asking for
9the decryption of an apparently unrelated ciphertext) or chosen message attacks (where one obtains a
10signature of a message after requesting signatures for apparently unrelated messages). An appropriate
11message encoding method provides a systematic way of thwarting all such attacks. Quite a few encoding
12methods for encryption and signature have appeared in academic literature and other standards. The
13methods included in this standard are well established techniques. It is highly recommended to use these
14methods when implementing the schemes specified in the standard. More discussions on security
15properties of message encoding methods are given in Annex D.
17A key derivation function is needed in the DL/EC key agreement schemes. One reason is that the output
18from a DL/EC secret value derivation primitive may not be appropriate to use directly as a session key due
19to a bias in some of the bits of the derived secret value. A good key derivation function helps to remove
20such bias and to use all the entropy in the output of the secret value derivation primitive. Another reason is
21that in many cases it is useful to be able to derive more than one key from a secret value. In addition, key
22derivation functions as defined in the standard also take as input key derivation parameters, which allow
23one to specify additional information related to the derived key as well as the parties in the key agreement
24scheme.
25C.1.7 Why are data formats for input/output, keys, and domain parameters not normative?
26Some data formats for input/output, keys and domain parameters are specified in the informative Annex E.
27A choice of a particular data format does not affect security, as long as the choice is unambiguous and
28known to all parties involved and provides for adequate and unambiguous representation of the relevant
29data. Two implementations with different choices of data formats may not be interoperable. They will
30need to convert between each other's formats to achieve interoperability. The data formats are not
31normative because some applications may not require interoperable formats.
33C.2.1 Why allow all finite fields for the DL and EC families?
34Whereas other standards have limited implementers to prime fields and finite fields of characteristic two
35[B4][B11], recent results show that a broader array of options is warranted. Results in Bailey and Paar
36[BP00] and Lenstra [Len97], for instance, demonstrate the performance advantages which may be gained
37by allowing implementers to choose finite fields which are well-suited to the underlying hardware and/or
38admit the use of more efficient algorithms for finite field arithmetic. Such flexibility does not appear to
39impact security as long as certain guidelines are followed. In fact, Schirokauer, Weber and Denny
40[SWD96] show that in the DL setting, prime fields and finite fields of characteristic two are more
2 279
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1susceptible to attack than other choices. Finally, new proposals such as one by Schroeppel and Eastlake
2[SE02] are emerging which support arbitrary finite fields.
4While there is a single most commonly used representation for GF(p), there are multiple natural commonly
5used representations for GF(2m). There are performance tradeoffs in the use of each representation. When
6choosing a representation, one needs to consider whether hardware or software performance is more
7important as well as time complexity, memory complexity, and relevant patents.
8While it would have been possible to standardize one representation and require that applications that want
9to do computations in a different representation convert from one to the other, the expense of basis
10conversion may be unacceptable in certain applications. The aim instead was to provide a flexible
11framework within which applications will decide how to interoperate. Therefore, recommendations on a
12few popular representations are provided.
13C.3 Schemes
14C.3.1 For the DL and EC families, why have three key agreement schemes (-DH1, -DH2, and
15-MQV)?
16The schemes DL/ECKAS-DH1 are based on the traditional Diffie-Hellman key agreement schemes in
17which each party contributes one key pair. The scheme DL/ECKAS-DH2 is based on the so-called
18"unified model" for key agreement in which each party contributes two key pairs. The schemes
19DL/ECKAS-MQV also utilize two key pairs from each party, but are more computationally efficient than
20DL/ECKAS-DH2. Certain security attributes can be achieved in different ways by the schemes, as further
21discussed in Annex D.
22The reason all three schemes are in the standard is that there are tradeoffs in efficiency, depending on how
23the security attributes are achieved with each of the schemes. There may also be differences in patent
24coverage. When choosing a scheme, one needs to consider the desired security attributes, communication,
25time and memory complexity, and relevant patents.
26C.3.2 For the DL and EC families, why have the “compatibility” option for the DHC and
27MQVC primitives?
28The “compatibility” option provides flexibility to implementers. The “compatible” versions of DHC and
29MQVC are likely to achieve greater interoperability with existing DH and MQV implementations, but the
30“incompatible” versions may have some implementation advantages as they may be easier to layer on top
31of existing DH and MQV implementations. (In particular, it may be convenient in some architectures to
32view the cofactor multiplication as an additional step applied after ordinary DH and MQV.) Concerns about
33interoperability can be addressed in profiles and other standards based on this standard.
34C.3.3 For the EC and DL families, why have both DSA and NR signature schemes with
35appendix?
36The scheme DLSSA-DSA is a generalization of the U.S. Government Digital Signature Standard (DSS)
37specified in FIPS-186 [FIP94b] and ANSI X9.30 [ANS97a], and it has withstood extensive cryptanalysis.
38The scheme ECSSA-DSA is the elliptic curve analog of DLSSA-DSA, and a similar scheme called
39ECDSA is specified in the ANSI X9.62 draft standard [ANS98e].
2 280
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Note that FIPS-186/ANSI X9.30 (and ANSI X9.62) mandate the use of the hash function SHA-1 with DSS
2(and ECDSA), and they have restrictions on the sizes of the DL and EC parameters. However, this standard
3attempts to provide a more flexible specification by allowing other suitable hash functions and a larger
4range of key sizes. A particular application may find that its key sizes need to be shorter or longer than DSS
5allows, and that a different hash function better suits its needs. Implementations of DLSSA-DSA and
6ECSSA-DSA can be compliant with FIPS-186/ANSI X9.30 and ANSI X9.62, respectively.
7The schemes DL/ECSSA-NR have the advantages of better performance and smaller code size (in
8particular because they do not require computation of a multiplicative inverse in a finite field). Also,
9DL/ECSP-NR and DL/ECVP-NR, the basic primitives for the schemes, allow for message recovery,
10whereas DL/ECSP-DSA and DL/ECVP-DSA do not. Should a signature scheme giving message recovery
11be necessary for the DL or EC system, it can potentially be constructed based on DL/ECSP-NR and
12DL/ECVP-NR, although new primitives have been introduced for this purpose in the amendment. See next
13question C.3.4.
14C.3.4 For the DL and EC families, why have two signature schemes giving message
15recovery (DL/ECSSR and DL/ECSSR-PV)?
16It was anticipated that IEEE P1363a might include a signature scheme giving message recovery, and
17ISO/IEC 9796-3:2000 [B79], in draft stage while IEEE Std 1363-2000 was being developed, was
18mentioned as one possibility. This scheme, called DL/ECSSR here, has been included as it is now an
19international standard, and is sufficiently secure and efficient. The second scheme, DL/ECSSR-PV, is more
20bandwidth-efficient than DL/ECSSR, taking advantage of redundancy within the message to minimize the
21overhead due to the signature. DL/ECSSR-PV is being considered for standardization as part of ISO/IEC
2215946-4 [ISO-15946-4].
23C.3.5 For the DL and EC families, why was the DL/ECIES encryption scheme selected?
24Several proposals on DL and EC encryption schemes were presented to the P1363 working group during
25the development of IEEE Std 1363-2000. None of the proposals was considered mature enough to include
26in IEEE Std 1363-2000 and it was expected that a suitable encryption scheme would be established during
27the P1363a effort. The DL/ECIES scheme has emerged as a common reference in several other standards
28efforts, including ANSI X9.63 [B12] and SEC-1 [SEC-1], with accompanying security analysis, and is thus
29considered appropriate for the amendment. DL/ECIES has two modes: non-DHAES mode, which is
30compatible with ANSI X9.63 and SEC-1 but does not have the full set of security properties of the DHAES
31scheme on which it is based (see Abdalla, Bellare, and Rogaway [ABR98]); and DHAES mode, which has
32the full set. For further discussion, see D.5.3.
33C.3.6 For the IF family, why have RSA, RW and ESIGN signature schemes with the various
34encoding methods?
35Both RSA and Rabin-Williams (RW) are established signature schemes based on the integer factorization
36problem. The RSA signature schemes are well understood and widely used. The Rabin-Williams signature
37verification is generally faster than the RSA signature verification if the public exponent of 2 is used;
38however, the RSA signature generation has a code-size and speed advantage since there is no need to
39compute the Jacobi symbol. Both RSA and Rabin-Williams signatures are described in the appendix to
40ISO/IEC 9796:1991 [B78], in ISO/IEC 9796-2:1997 [ISO-9796-2], and in ISO/IEC 14888-3:1998 [B80].
41The ESIGN signature scheme is much faster for signature generation than the RSA and RW schemes, and
42is comparable in speed for signature verification. The ESIGN scheme is also described in ISO/IEC 14888-
433:1998.
2 281
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Note that there are two signature and verification primitives (IFSP/IFVP) for RSA, namely, RSA1 and
2RSA2. RSA1, which specifies just the “raw” RSA operation, has been widely used in various
3implementations and protocols, such as PKCS #1 ([B126], [PKCS1v2_1]), SET ([B104]) and S/MIME
4(Dusse et al. [B51] and Dusse et al. [B52]). RSA2 has an extra simple step to adjust the most significant bit
5of the signature to zero, and hence can save one bit (and potentially one byte for some key sizes) compared
6with RSA1. RSA2 is a component in ANSI X9.31-1998 [B7] and the various ISO/IEC standards (although
7RSA1 is also included in the latest draft revision of ISO/IEC 9796-2 [ISO-9796-2-revision]).
8Two new encoding methods for RSA/RW signatures with appendix have been added in the amendment.
9EMSA3 has been included to align with the various implementations and protocols mentioned above. Also,
10a version of RSA/RW signatures for which a security reduction to integer factorization has been given is
11now offered through the use of the EMSA4 encoding method. (EMSA2, which is also allowed for
12RSA/RW signatures, is for compatibility with ANSI X9.31.)
13C.3.7 For the IF family, why was the IFSSR signature scheme giving message recovery
14selected?
15A signature scheme giving message recovery based on specified in ISO/IEC 9796:1991 [B78] was included
16in drafts of IEEE Std 1363-2000 until the last ballot. However, work by Coron, Naccache, and Stern
17[CNS99] and Coppersmith, Halevi, and Jutla [CHJ99] demonstrated practical chosen-message attacks
18against this scheme. The working group decided that the attacks warranted exclusion of the scheme from
19the standard. The working group was not aware of another scheme that would have been ready for the IF
20family at the time that IEEE Std 1363-2000 was being completed, but anticipated that IEEE P1363a might
21include such a scheme. The PSS scheme (Bellare and Rogaway [B19]) was selected as a basis because a
22security analysis in the random oracle model was available and because PSS can be defined in terms of the
23same set of primitives as the IF signature scheme already in IEEE Std 1363-2000 (some modifications were
24made to address implementation considerations). ISO/IEC JTC1 SC27 (the subcommittee responsible for
25the ISO/IEC 9796 series of standards) decided to pursue this scheme for a revision of ISO/IEC 9796-
262:1997 [ISO-9796-2], with the intent of alignment with IEEE P1363a.
27C.3.8 For the IF family, why are there no key agreement schemes?
28In general, key agreement can be achieved using techniques based on integer factorization. For example,
29each party can transport a secret value using an IF encryption scheme to the other party and a shared secret
30key can then be derived using the two secret values. However, such methods are better described as
31protocols rather than as schemes in the model given in Clause 4. This may be a semantic distinction
32between ‘protocol’ and ‘scheme’. Under the model in Clause 4, a key agreement scheme is a collection of
33related operations by which parties can agree on one or more secret keys in some protocol. While one can
34use IF encryption and decryption operations to agree upon secret keys, those operations are more naturally
35described in an encryption scheme. It is possible that key agreement techniques based on the IF family will
36be specified during the P1363a effort.
37C.3.9 For the IF family, why have two encryption schemes (IFIES and IFIES-EPOC)?
38The two schemes, like many others in the standard, offer tradeoffs in terms of security analysis, underlying
39hard problems and primitives, flexibility, performance, and standardization.
40IFIES has a security analysis in the random oracle model based on the RSA primitives and factoring
41integers of the form n = pq. The length of messages it can encrypt is limited by the modulus length (minus
42any associated padding). IFIES is included in the ANSI X9.44 draft standard [B9] and is being considered
43as an upgrade for existing use of RSA encryption in practice.
2 282
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1IFIES-EPOC also has a security analysis in the random oracle model but is based on the OU primitives and
2factoring integers of the form n = p2q. It is more flexible in that the length of messages it can encrypt is not
3limited. Encryption is typically less efficient with OU compared to RSA, but decryption can be more
4efficient with appropriate optimizations.
6C.4.1 Why were the KDF1 and KDF2 key derivation functions selected?
7KDF1 is based on a simple, ad hoc construction that met the requirements of IEEE Std 1363-2000; KDF2
8extends KDF1 to provide an arbitrary length output, and is specified in ANSI X9.63 [B12]. (The design of
9KDF1 is similar to that of MGF1.) Both are based on an underlying hash function, which is attractive in
10terms of reducing the number of separate components in an implementation. Note that, as is generally the
11case for the additional methods in this standard, other key derivation functions are allowed within the
12framework of the schemes.
13It is recognized that KDF1 and KDF2 were not designed to produce keys to encrypt messages of arbitrary
14length. For direct encryption of a message, symmetric encryption schemes have been introduced (see
15C.4.4).
17MGF1, like KDF1 and KDF2, is a simple, ad hoc construction based on a hash function; it is based on
18suggestions in the literature for instantiating a mask generation function in a signature scheme. While other
19constructions may also appropriate (e.g., a stream cipher, or a block cipher in a certain mode of operation),
20the hash-function-based design is again attractive in terms of reducing the number of separate components.
21MGF1, like the key derivation functions, was not designed as a stream cipher; symmetric encryption
22schemes have been introduced for this purpose (see C.4.4).
24SHA-1 and RIPEMD-160 are the result of several years of hash function design and are generally
25considered state-of-the-art for hash functions with 160-bit outputs. SHA-1 has been adopted in a number of
26standards including ANSI X9.30:2-1997 [B5], FIPS PUB 186-2 [B56], ISO/IEC 10118-3:1998 [ISO-
2710118-3], and IEEE Std 1363-2000; RIPEMD-160 is in ISO/IEC 10118-3:1998 and IEEE Std 1363-2000.
28SHA-1 is perhaps more often recommended but RIPEMD-160 is also attractive because of its more public
29design process.
30To provide a longer hash output than 160 bits (consistent with higher security levels associated with larger
31asymmetric key sizes), NIST has introduced three new hash functions, SHA-256, SHA-384, and SHA-512,
32with the indicated hash output lengths. In anticipation of their adoption in practice, this amendment allows
33for these hash functions in addition to the previous two that were in IEEE Std 1363-2000. Other hash
34functions than these are allowed, of course, with the framework of the schemes in this standard.
36Several of the schemes and methods use an underlying symmetric encryption scheme as part of their
37operation. There are many choices in this area. This amendment has selected two of the most prominent
38with a sufficiently large key size: triple-DES, the near-term replacement to the Data Encryption Standard
39(see ANSI X9.52-1998 [B10] and FIPS PUB 46-3 [FIPS-46-3]), and the Advanced Encryption Standard
2 283
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[FIPS-197], the long-term replacement. In each case, Cipher Block Chaining mode with a common padding
2rule has been selected because of its wide adoption, but with a null initialization vector to minimize
3message expansion (see D.5.2.2.6 and D.5.3.2.6 for security rationale). Other modes of operation and
4algorithms are allowed within the framework of the schemes. In particular, since the recommended
5methods require that the length of the message in bits is divisible by 8, a different method is needed for
6implementations that operate on bit strings of arbitrary length.
8MAC1 is based on the HMAC function, which has been widely adopted in standards development (see
9ANSI X9.71-2000 [ANSI-X9.71], FIPS PUB 198 [FIPS-198], and Krawczyk, Bellare, and Canetti
10[KBC97]). HMAC is attractive because it can be directly built from an existing hash function and offers a
11security analysis under reasonable assumptions about the underlying hash function. Other message
12authentication codes that are more efficient, are based on a different class of underlying function (e.g., a
13symmetric encryption scheme), or offer a better security analysis might also be adopted, but the working
14group did not consider any to be sufficiently established for this amendment.
2 284
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2D.1 Introduction
3This annex addresses security considerations for the cryptographic techniques that are defined in this
4standard. It is not the intent of this annex to teach everything about security or cover all aspects of security
5for public-key cryptography. Rather, the goal of this annex is to provide guidelines for implementing the
6techniques specified in the standard. Moreover, since cryptography is a rapidly changing field, the
7information provided here is necessarily limited to the published state of the art as of the time the standard
8was drafted, August 1998, and amended, October 2001. Implementers should therefore review the
9information against more recent results at the time of implementation; the working group Web page may
10contain additional relevant information (see http://grouper.ieee.org/groups/1363/index.html).
11Some of the techniques given here have security arguments (aka “security proofs”) which claim that certain
12types of attacks are impossible or impractical. These arguments generally rely on assumptions which
13themselves are not proved (e.g., that integer factorization is difficult), as well as on restrictions in the type
14of attack (e.g., the random oracle model). Furthermore, while for some schemes the difficulty of breaking
15the scheme is argued to be close to the difficulty of the underlying hard problem, for other schemes the
16relationship is not so “tight”. (For example, the published security bounds given for EME1 are not very
17tight compared to other schemes; for the most part these distinctions are overlooked in the discussion here.)
18Finally, as with any research, the security arguments may be subject to improvement or correction. In other
19words, a claimed “security proof” is not an absolute guarantee of security. Security arguments nevertheless
20offer some assurance to the implementer, as they imply a more careful analysis by the designer, and faults
21in a security argument do not necessarily lead to an actual attack. In view of these considerations, the terms
22“proof,” “security proof,” and “provable security” are avoided in this document, and the more
23encompassing term “security analysis” is chosen instead.
24Security recommendations (in the form of “should”) are given throughout this annex. It should be
25understood, however, that there may be choices other than the ones recommended here that achieve a given
26level of security. Furthermore, as discussed in D.2, the definition of security depends on the types of attack
27that are relevant to an implementation. If an attack is not relevant, then some recommendations may not
28apply. Thus, while the recommendations given here enable security, they should not necessarily be taken as
29requirements. Nevertheless, it is expected that other standards based on this standard may upgrade some of
30the recommendations to requirements.
31The considerations are presented in six parts. General security principles applying to all the families and
32schemes are presented in D.2. Key management considerations that also apply to all the families and
33schemes are summarized in D.3. Family-specific considerations are given in D.4, and scheme-specific
34considerations are given in D.5. As generation of random numbers is a common tool needed to implement
35this standard, random number generation considerations are summarized in D.6. Implementation
36considerations, relevant to all the families and schemes, are given in D.7.
37For readers who are interested in extensive and in-depth discussions on security and cryptography, some
38reference books include [MOV96], [Sch95], [Sta98] and [Sti95].
2 285
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
7Policy measures such as requiring a password for access to a system, physical measures such as concealing
8wires, and legal measures such as prohibiting eavesdropping by statute, all provide a degree of defense
9against the threats just mentioned. But such approaches are all indirect, as they address only the
10implementation or use of a system—not the data itself. Direct protection, involving operations on the data,
11is the purpose of cryptography.
12As noted in Clause 4 of this standard, three common means of data protection provided by public-key
13cryptography are key agreement schemes, encryption schemes, and digital signature schemes. Implemented
14and combined appropriately, they can address the threats just mentioned. With either a key agreement
15scheme or an encryption scheme, for instance, parties can establish a shared secret key. The parties can
16then prevent unauthorized disclosure by applying a symmetric encryption algorithm to the data using the
17shared secret key, so that parties not possessing the key cannot recover the data. A party can also encrypt
18data directly with an encryption scheme. Similarly, with a signature scheme, parties can detect
19unauthorized modification as well as impersonation.
20The need for the protection of data and identities against the threats mentioned above leads to consideration
21of the following question: “What is a secure system?” There is no easy answer to this question. As the
22Handbook of Applied Cryptography states, “… security manifests itself in many ways according to the
23situation and requirement” [MOV96, Clause 1.2]. The following paragraphs explore some of the general
24principles that help answer this question.
25In a typical security analysis, an opponent (also called an adversary)—the source of the threats mentioned
26above—is assumed to have certain abilities. Under the usual model, called Kerckhoffs’ assumption
27[Ker83], an opponent will have full knowledge of system design, including the specification of all
28cryptographic operations (as, for instance, this standard would provide). Usually, the opponent will be able
29to use more tools than just “passive wiretapping” in order to read messages exchanged between parties.
30For example, the opponent may also be able to modify the message between parties. The opponent should
31also be considered to have some computational resources. The opponent may also be trusted by other
32parties to some extent. For instance, legitimate parties may be willing to perform selected cryptographic
33operations requested by the opponent, or the opponent’s keys may be accepted as legitimate by other
34parties. In other words, the opponent may appear to other parties as a legitimate party. However, the
35opponent generally will not know all of the secrets in the system, such as long-term private keys, and it is
36this knowledge that distinguishes the opponent from the legitimate parties. Any attempt by the opponent to
37violate the security of a system in some manner is called an attack.
38Under the assumption that such an opponent is present, the legitimate parties need to ensure that certain
39security properties (such as, for example, data confidentiality or data integrity) are satisfied. Just as there
40are different classes of opponent, there are different desirable security properties. A higher level of security
41is likely to be desirable for more valuable data, for instance, or for data with a long lifetime. Thus, as a
42general principle, security properties should be selected consistent with the value of the data being
43protected and the set of opponents envisioned. Since the cost of providing security generally varies
44according to the security properties, decisions related to security are appropriately framed as cost-benefit
45analyses.
46In light of the above discussion, security may be defined as the assurance of trust in the face of opponents
47with certain knowledge and resources. Thus, the opponent, and the types of attack it can mount, is a
48required component of the definition of security.
2 286
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1A designer’s objective, then, is to choose security techniques that provide certain desired security
2properties when faced with an opponent considered reasonable for a particular system. The cost-benefit
3analysis that can be applied to make decisions related to security can also be applied when evaluating the
4capabilities of a potential opponent. For example, an opponent is unlikely to spend more on breaking the
5system than it will obtain by doing so. However, it is important not to overestimate the opponent’s costs,
6because an opponent may be using stolen, borrowed or free resources (such as spare cycles of multiple
7computers). Indeed, in the case of free resources, the attack is always worth doing in a cost-benefit analysis,
8assuming the cost is really zero. Also, a large one-time investment for an opponent may pay off over time if
9the opponent breaks multiple systems. For example, if many DL-based systems use one particular finite
10field, a large investment in accelerated hardware modules for solving the DL problem in that specific field
11may pay off for the opponent, especially because the computation time per logarithm goes down if multiple
12discrete logarithms need to be computed. It is also important not to underestimate the opponent’s benefit—
13it may be unclear how much publicity, personal satisfaction, or furthering of political goals may be worth to
14a potential opponent. Finally, one must also consider risk in terms of an opponent's probability of success.
15Even a chance of one in one million may be unacceptably large in some situations, so it is not only the cost
16of guaranteed success that is relevant.
17In support of this process of choosing appropriate techniques when faced with a potential opponent, this
18annex summarizes the choices related to cryptographic techniques in the standard. Note, however, that this
19standard (and this Annex in particular) focuses on individual implementation of individual cryptographic
20techniques, and not on entire systems. In particular, this standard defines cryptographic techniques from
21the point of view of a single party, rather than protocols in which multiple parties participate and multiple
22cryptographic operations are performed. It is expected that techniques in this standard will be combined
23into protocols by other standards or by implementers. However, such combinations, especially ones where
24multiple cryptographic operations (e.g., both encryption and signature) on the same data are performed
25require additional security analyses.
31A set of domain parameters may be generated by one of the parties that intend to use it, by a third party, or
32jointly by any subset of these. A capability to audit the domain parameter generation may be provided to
33other parties by generating random components of the domain parameters using one-way function(s) of
34random seed(s), and publishing the seed(s). Any party can then verify that the domain parameters indeed
35correspond to the seed(s). This provides some degree of assurance that the party generating the parameters
36did not pick them specifically to possess some particular special property. The property in question should
37be rare enough so that it is infeasible to obtain it by simply trying different seeds. The one-way function
38should be such that it is hard to find a seed that produces parameters with that property (for example, the
39property should not be closely related to the one-way function). See Annex A.12.4-A.12.7 for an example
40of parameter generation that provides for auditing. Additional information for auditing domain parameter
41generation is provided by family in D.4.
2 287
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 jointly by the owner of the keys and by another party, such as a certifying authority. Depending on
2 the technique used, the other party may not need to be entrusted with any secrets by the owner of
3 the key pair. This method may be used to ensure that the key pair is not picked by the owner to
4 have some particular special property, and may eliminate the need for a separate verification that
5 the party possesses its private key (see Annex D.3.1). Chen and Williams [CW98] provide an
6 example of this method.
7 by a third party that can be trusted with the private key (in particular, it should be trusted to keep
8 the private key secret and not use its knowledge of the private key to its advantage). If the third
9 party is trusted to perform the key generation properly, this method may be used to ensure that the
10 key pair is not picked by the owner to have some particular special property, and may eliminate the
11 need for a separate verification that the party possesses its private key (see Annex D.3.1).
12A capability to audit the key generation may be provided using methods similar to those for the parameter
13generation, as described above. However, because, as opposed to parameters, the private key is meant to
14be a secret, the random seed should be kept secret, as securely as the private key, because revealing it
15would reveal the private key. Therefore, the actual auditing must be done only by trusted parties or in
16situations when it is appropriate to reveal the private key.
17Private keys should never be shared among parties. Every private key should be generated independently
18of other private keys. If random numbers for use in producing the private keys are generated properly,
19accidental sharing of private keys is extremely unlikely to occur (see Annex D.6 for more on random
20number generation). Two or more dishonest parties, however, may collude in order to make their private
21keys be the same (or stand in some relation known to the colluding parties). Dishonest parties may do so,
22for example, for the purposes of claiming the failure of a key generation procedure and for repudiating
23signatures produced with those keys (see Annex D.5.2.3 for more on repudiation). Such concerns may be
24addressed by establishing trust in the implementation of key generation, or by involving a trusted party in
25the key generation process as described above. It may be possible for an authority to check that no two
26public keys (and, hence, private keys) are equal in a limited system. However, this check will not reveal a
27pair of keys that stand in some special relation to each other and may be impractical to implement in some
28systems.
29More considerations for key and parameter generation are given by family in D.4.
31Authentication of ownership of a public key is the assurance that a given, identified party intends to be
32associated with the public key (and the corresponding set of domain parameters, if any). It may also include
33assurance that the party possesses the corresponding private key (this is commonly known as Proof of
34Possession or POP). The latter assurance is stronger in the sense that it prevents an opponent from
35misleading other parties into believing that the results of operations performed with the private key are
36associated with the opponent, rather than with the actual owner of the private key.
38Authentication of ownership may be conveyed as part of the supporting key management, for instance in a
39certificate, which is a message signed by a certifying authority indicating that a particular party, typically
40identified by a name, owns a given public key (see [MOV96, Clause 13.4.2]). Anyone who knows the
41certifying authority’s public key and trusts the certifying authority can verify the signature on the certificate
42and thereby authenticate the party’s ownership of the public key. Certifying authorities may issue
43certificates to other certifying authorities, so that trust in a single “root” certifying authority’s public key
44can extend through a chain of certificates to the public keys of a large community. Other attributes, such as
45key cryptoperiod or usage restrictions, may also be bound to a public key in this manner (see Annex D.3.6,
46[ITU97]). To gain assurance that a party possesses a private key, and thereby to convey this assurance, a
47certifying authority should perform an appropriate protocol verifying the possession before issuing the
2 288
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1certificate. Such methods may be found in Adams and Farrell [AF99], Clauses 10.3.3, 10.4, and 13.4.2 of
2Menezes, van Oorschot, and Vanstone [B112], and Myers et al. [B141][MLSW00].
3Another way of conveying authentication of ownership is for a party to issue its own certificate, i.e., to sign
4the message containing the public key with a separate private key. This approach is helpful when the public
5key has a short cryptoperiod and it is impractical to obtain a certificate from a certifying authority.
6However, this approach does not necessarily provide assurance that the party possesses the corresponding
7private key.
8A public key should be securely associated with its set of domain parameters (if any). This may be
9accomplished by including the set of domain parameters into the certificate. The set of domain parameters
10may also be embedded into the system if, for example, the system implementation only performs operations
11with a single set of domain parameters. Domain parameters should be authenticated and protected from
12unauthorized modification in the same manner a public key is.
13In general, a party’s possession of a private key should be authenticated as part of authenticating the party’s
14association with a public key. Situations in which it may be acceptable not to do so are given by type of
15scheme in D.5.
17Most primitives specified in this standard are not defined when an input set of domain parameters or key is
18invalid (see Clause 4.2 and Annex B). Implementations should therefore appropriately address this
19possibility. The risks of operating on invalid domain parameters or keys vary depending on the scheme
20used and the particular implementation, and are addressed by type of scheme in D.5.
21DL and EC domain parameters and keys may be validated explicitly before being input to a primitive
22using, for example, the techniques given in A.16. Note that no techniques for private key validation are
23provided, because, generally, a party controls its own private key and need not validate it. However,
24private key validation may be performed if desired. Also note that no techniques for IF public key
25validation are provided in this standard; however, see [LS98] and [GMR98] for some proposed techniques.
26Alternatively, domain parameters may be validated within the infrastructure by an authority. For example,
27a certifying authority may validate domain parameters and keys as part of issuing a certificate; certificate
28verification will then imply validity of the domain parameters or keys it contains. Generation of keys or
29parameters by a trusted authority or jointly with it (see Annex D.3.2) may provide assurance of their
30validity. As another means of domain parameter validation, a standards body may publish a set of domain
31parameters, in effect serving as a trusted third party assuring their validity. Such domain parameters have
32been published, for example, in FIPS 186-1 [FIP94b], ANSI X9.30 [ANS97a] and ANSI X9.42 [ANS98b]
33for the DL family and ANSI X9.62 [ANS98e], ANSI X9.63 [ANS98f], GEC1 [SEC99] and [NIS99] for the
34EC family.
35The above methods ensure that keys satisfy their definitions (i.e., are valid). They do not, however, provide
36an assurance that the keys were generated in a secure manner. Such assurance, in addition to the assurance
37of validity, may be provided by ensuring that only appropriately validated modules can be used for
38generating keys (see Annex D.7). (In contrast, domain parameters may potentially be generated in
39unvalidated modules, provided that the parameters are validated, since no secrets are involved.)
40Public key validation (PKV) and POP (see D.3.2) can be considered as duals. PKV shows that the party's
41public key is valid, but not necessarily that the party possesses the corresponding private key. POP
42demonstrates that the party possesses the private key, but not necessarily that the public key is valid
43(though certain methods for POP may demonstrate both). Both PKV and POP should be considered in high
44assurance applications, unless the risk of operating with invalid keys or without assurance that a party
45possesses a private key is mitigated by other means.
2 289
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Some additional ways to address the risks of operating on invalid domain parameters and keys are given by
2type of scheme in D.5.
4The cryptoperiod of a set of domain parameters or a key is the period during which operations may be
5performed with the set of domain parameters or the key. A set of domain parameters or a key should have
6an appropriate cryptoperiod to limit the amount of data whose protection is at risk (in the event of
7cryptanalytic attack or physical compromise of a private key) and the amount of data available for
8cryptanalysis. The cryptoperiod of a set of domain parameters should be at least as long as the
9cryptoperiod of keys associated with the set of domain parameters. The cryptoperiod of a public key used
10for signature verification should be at least as long as the cryptoperiod of the corresponding private key for
11signature generation; the cryptoperiod of a private key used for decryption should be at least as long as the
12cryptoperiod of the corresponding public key for encryption.
13Keys with long cryptoperiods are known as long-term or static; keys with short cryptoperiods are known as
14short-term or ephemeral. These terms are most commonly used in the context of key agreement schemes
15(see Annex D.5.1). Note that whether a key is static or ephemeral is independent of whether or not it is
16authenticated.
17The protection lifetime of a key is the amount of time that the key is needed to protect data, and is generally
18longer than the cryptoperiod of a key. For example, even after the cryptoperiod of an encrypting key
19expires, the data protected with it may still be sensitive; similarly, the data signed by a signing key may
20need to be protected from unauthorized modification long after the cryptoperiod of the signing key has
21expired. Hence, the security measures for a key (including the appropriate key sizes) should be picked
22primarily according to its protection lifetime, rather than its cryptoperiod.
23In general, there is a distinction between the risk of an opponent learning a private key through physical
24compromise, versus an opponent learning a private key through cryptanalysis. Cryptanalysis may be
25defended against by appropriate key sizes and by limiting the number of operations performed with a given
26key and thus the availability of data to the cryptanalyst. The risk of physical compromise of a given key
27and the value of the key to the opponent may be reduced by giving a private key a short cryptoperiod and
28erasing the key thereafter.
29Implications of domain parameter and key cryptoperiods are described further by type of scheme in D.5.
30The cryptoperiod of domain parameters and public keys may be conveyed as part of the supporting key
31management, for instance as certificate attributes. The cryptoperiod should be securely associated with the
32parameters and keys and protected from unauthorized modification (see Annex D.3.6). To limit the impact
33of a successful cryptanalytic attack or a physical compromise, provision should also be made in supporting
34key management for early termination of a set of domain parameters or a key, for instance through
35certificate revocation (see, e.g., [MOV96, Section 13.6.3], [ITU97], [SHW98]).
37A set of domain parameters or a key should have appropriate restrictions on its use to prevent
38misapplication of the set of domain parameters or the key as input to an operation, as well as
39misinterpretation of the results of an operation.
41
2 290
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 restrictions on the type of scheme—for instance, only a signature scheme, or only an encryption
2 scheme
3 restrictions on scheme options—e.g., only a particular encoding method or hash function for a
4 signature scheme
5 restrictions on messages processed—for instance, only payment orders of a certain format, up to a
6 certain value
7As a prudent security practice, the use of a particular key should be restricted to a single scheme with a
8single specific set of scheme options. Otherwise, the variability of data associated with the key may aid an
9opponent. If a single key is to be used for a variety of schemes or scheme options, additional security
10analysis is required. A set of domain parameters may be identified as intended to be used with a single
11specified scheme, a set of specified schemes, or with all schemes to which it applies in a given family. (The
12granularity of what constitutes a "scheme", e.g., in terms of scheme options, depends on the implementation
13and on what is considered to constitute an attack.)
14Usage restrictions should be securely associated with the parameters and keys and protected from
15unauthorized modification (see Annex D.3.6). To accomplish this, they may be conveyed as part of the
16supporting key management, for instance as certificate attributes (see, e.g., [ITU97]). They may also be
17embedded (explicitly or implicitly) into a system: for example, in a closed system that is only capable of
18producing and verifying one specific type of signatures, there may be no need to convey restrictions on the
19type of scheme or scheme options as part of key management.
21The storage and distribution methods for domain parameters and keys should provide appropriate
22protection.
23It is presumed that domain parameters and keys will be identified somehow (perhaps by the owner’s
24identity) and possibly associated with certain attributes, such as ownership, cryptoperiod, and usage
25restrictions. It is important to protect the integrity of this identification and association when keys or
26domain parameters are stored and distributed. Specifically, it should be difficult for an opponent to modify
27the key or set of domain parameters, its identification, or any attributes that are associated with the key or
28set of domain parameters. The specific protections depend on the component:
29
30 a set of domain parameters should be protected from unauthorized modification, and generally need
31 not be protected from disclosure
32 a public key should be protected from unauthorized modification, and generally need not be
33 protected from disclosure
34 a private key should be protected from unauthorized modification and, with the possible exception
35 of its associated set of domain parameters, if any, protected from unauthorized disclosure
36 identification information and attributes associated with a key or set of domain parameters should
37 be protected from unauthorized modification
38The security properties for a storage or distribution method should be commensurate with the security
39properties intended to be provided by a set of domain parameters or key. A typical protection method for
40domain parameters and public keys is to bind them with identification information and attributes in a
41certificate, which may be stored or distributed; the signature on the certificate protects against unauthorized
42modification. Another method, commonly used for “root” public keys and domain parameters (such as
43public keys of root certifying authorities—see Annex D.3.1) is to embed them in software or hardware in
44such a way that they become an inherent part of the system and are protected from unauthorized
45modification by the same mechanisms as the system itself (see Annex D.7).
2 291
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1When a key is associated with set of domain parameters, the set of domain parameters may either be stored
2and distributed explicitly with the key, or referenced implicitly. When the set of domain parameters is
3referenced implicitly, the reference and the set itself must be protected from unauthorized modification. For
4instance, suppose a key references a shared set of domain parameters. The reference to the shared set must
5be unambiguous, and the set itself must be protected from unauthorized modification. Otherwise, the key
6may be vulnerable to attack by misuse with incorrect domain parameters. Similar considerations apply if a
7public component of a private key (e.g., the modulus n in an RSA or RW private key) is referenced
8implicitly. In such a case, the reference and the components must be protected from unauthorized
9modification or else the private key may be vulnerable to attack by misuse with incorrect public
10components.
14D.4.1 DL Family
16The primary security parameters for the DL family are the length in bits of the field order q and the length
17in bits of the subgroup order r. A common minimum field order length is 1024 bits and a common
18minimum subgroup order length is 160 bits (see ANSI X9.42-2001 [B8]). (Note 1.)
19The field type (prime vs. binary vs. odd characteristic extension field) may affect the security of the
20schemes. (Notes 2 and 3.)
22Considerations for generating domain parameters in the DL family include the following:
23
24 (Prime case.) The field order q (i.e., the prime p) should be generated randomly or pseudorandomly
25 among those field orders with a sufficiently large subgroup, with a prime generation method that
26 has a sufficiently low probability of producing a non-prime. For a canonical method of domain
27 parameter generation that can be audited, the field order should be generated as a one-way function
28 of a random seed. (Note 3.)
29 (Binary case.) The field order q may be predetermined. In a canonical method of domain parameter
30 generation that can be audited, the field order should be selected from a set of allowed values. (See
31 Annex A.16.3–A.16.4 for one such method.) (Note 4.)
32 (Odd characteristic extension field case): The prime subfield order p may be predetermined or
33 generated randomly. The extension degree m must be chosen so that the order of the resulting
34 extension field is sufficiently large, and a subgroup of adequate size exists.
35 The subgroup order r may have any value consistent with the other parameters, provided that it is
36 sufficiently large and prime (and primitive in the case of binary fields—see Note 5); it may be
37 predetermined, generated randomly or pseudorandomly, or derived from the field order. Prime
38 generation or primality testing for the subgroup order may admit the possibility of error, provided
39 the probability of error is sufficiently low. (Note 5.)
2 292
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 The base g may have any value consistent with the other domain parameters. (Note 6.)
2Considerations for generating key pairs in the DL family include the following:
3
4 The private key s should be generated at random from the range [1, r – 1] (or a sufficiently large
5 subset of it). (Note 7.)
6The domain parameters q, r, and g (and the field representation in the binary and odd-characteristic
7extension field cases) may be shared among key pairs. The private key s should not be shared. (Note 8.)
9The field representation (in the binary and odd-characteristic extension field cases) is not known to affect
10security, although since the field representation is a domain parameter, it should be protected from
11unauthorized modification, along with the other domain parameters. (Note 9.)
12D.4.1.4 Notes
13 uuu) Security parameters: The security of schemes in the DL family against attacks whose goal is to
14 solve the discrete logarithm problem depends on the difficulties of general-purpose discrete
15 logarithm methods and of collision-search methods. In turn, the difficulty of general-purpose
16 discrete logarithm methods depends on the length in bits of the field order q and the difficulty of
17 collision-search methods depends on the length in bits of the subgroup order r.
18 The fastest general-purpose finite field discrete logarithm methods today belong to the index
19 calculus family of algorithms. Some members of this family provide better performance than others
20 depending on the relative sizes of p and m in the field GF(pm). For example, the Generalized Number
21 Field Sieve (GNFS) (see Gordon [B64], Section 3.6.5 of Menezes, van Oorschot, and Vanstone
22 [B112], and Schirokauer, Weber, and Denny [SWD96]), which has conjectured asymptotic running
23 time exp(((64/9)1/3 + o(1)) (ln q)1/3 (ln ln q)2/3), when m < (log p)1/2-, where q = pm, o(1) denotes a
24 number that goes to zero as q grows, and > 0. In particular, large prime fields fall into this
25 category.
26 For more on estimating the complexity of GNFS for large prime fields, see Note 1 in D.4.3.4; the
27 table given there also applies except that the memory requirements for the linear algebra are log 2 q
28 times greater for the discrete logarithm problem than they are for the integer factorization problem.
29 (See also the web site http://www.rsasecurity.com/rsalabs/challenges/ on the status of solving the
30 integer factorization problem. The result can be used as an estimate for an appropriate field order in
31 the discrete logarithm system.)
32 For large fields with relatively small characteristic, such as large binary fields, the function field
33 sieve (see Gordon and McCurley [B66], Section 3.6.5 of Menezes, van Oorschot, and Vanstone
34 [B112], Schirokauer [B131], and Semaev [B134]) offers the same conjectured asymptotic running
35 time as the GNFS when m (log p)2. Further improvements for the case of large binary fields bring
36 the asymptotic running time within a constant factor of exp(1.587 (ln q)1/3 (ln ln q)2/3). In particular,
37 the method is faster for binary fields than for prime fields.
38 For odd characteristic extension fields, one may choose m1/2 < (log p) < m2, as is typical when using
39 an OEF in the DL setting. The best known index calculus algorithms in this case have conjectured
40 asymptotic running time of exp((c + o(1)) (ln q)1/2 (ln ln q)1/2) for some constant c. In particular, the
41 method is faster for binary fields than odd characteristic extension fields obeying the restriction m1/2
42 < (log p) < m2.
2 293
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 For all types of field, the Pollard rho method (see Section 3.6.3 of Menezes, van Oorschot, and
2 Vanstone [B112] and Pollard [B123]), and the related Pollard lambda and other collision-search
3 methods (see, e.g., van Oorschot and Wiener [B122]) can compute discrete logarithms after, on
4 average, ( r/4)1/2 field multiplications. The memory requirements of such methods are relatively
5 small. (See also http://www.certicom.com/research.html on the status of solving the elliptic curve
6 discrete logarithm problem. The result can be used as an estimate for an appropriate subgroup order
7 in the discrete logarithm system.)
8 The length of the field order and the length of the subgroup order should be selected so that both the
9 general-purpose methods and the collision-search methods have sufficient running time. Often, the
10 parameters are selected so that the difficulty of both types of method is about the same. It does not
11 have be the same, however. For a variety of reasons, such as availability of hardware, for example,
12 an implementation may choose a larger field or subgroup. As noted, a common minimum field order
13 length is 1024 bits, and a common minimum subgroup order length is 160 bits.
14 When a set of domain parameters is shared among parties, the size should also take into account the
15 number of key pairs associated with the set, since the total running time for computing k discrete
16 logarithms with the same set of domain parameters is only about k1/2 times the running time of
17 computing a single discrete logarithm, provided that more memory is available (van Oorschot and
18 Wiener [B112]). A prudent practice is to pick security parameters such that computing even a single
19 discrete logarithm is considered infeasible.
20 vvv) Field type: prime vs. binary vs. odd characteristic extension field: The field type may affect the
21 security of the schemes, since the running time of general-purpose discrete logarithm methods
22 varies based on the relative size of p and m. Further, since the cost of finite field operations may
23 differ among the types of field, the actual running time of collision-search methods may vary by a
24 small factor. Also, since there is only one binary field for each field order length, there are fewer
25 alternatives to choose from, should some binary field be cryptanalyzed, than should a single prime
26 field be cryptanalyzed. Similarly, although there are many OCEFs for a given field order length,
27 there are still more prime fields for a given length than OCEFs.
28 www) Prime generation: In the prime field case, the field order q (i.e., the prime p) should be
29 generated randomly or pseudorandomly, since this provides resistance to special-purpose discrete
30 logarithm methods such as the Special Number Field Sieve, or those given in Gordon [B63].
31 The prime generation method should have a sufficiently low probability that a non-prime is
32 generated, so that the probability of generating an invalid set of domain parameters is small. A small
33 but nonzero probability of error (say, < 2–100) is acceptable since it makes no difference in practice;
34 methods with a small probability of error are generally simpler than those with zero error. See D.6
35 for more on generating random numbers and A.15 for more on generating primes.
36 The methods of intentionally constructing a field susceptible to the SNFS found in Gordon [B63] are
37 infeasible for odd characteristic extension fields since no constructive methods of finding an
38 extension field with a particular subgroup order are known. In addition, the SNFS is unlikely to
39 succeed in the odd characteristic extension field case due to the difficulty in finding a smoothness
40 bound for large extension fields.
41 A desired security level can also be provided when the field order has a special form; such a choice
42 requires further security analysis by the implementer.
43 Computing the field order as a one-way function of a random seed provides a degree of auditing
44 since it makes it difficult to select a prime with some predetermined rare property. It may not
45 entirely prevent the party generating the prime from producing primes with special properties, since
46 the party can try many different seeds, looking for one that yields the desired property, if the
47 property is likely enough to occur. However, it will make it difficult for a party to produce primes
48 that are vulnerable to a special-purpose discrete logarithm method such as the Special Number Field
49 Sieve, provided that the prime is large enough. (A party might seek to introduce such a vulnerability
2 294
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 in the interest of determining users’ private keys.) It will also make it difficult to mount an attack on
2 DSA in which the opponent picks a particular subgroup order r in order for two messages to have the
3 same signature (see Vaudenay [B146]). (This attack is of concern if the message representative may
4 be larger than the subgroup order r.) ANSI X9.30:1-1997 [B4], ANSI X9.42-2001 [B8], and FIPS
5 PUB 186-2 [B56] give an auditable method of generating primes by incremental search. (As noted
6 above, since there are no known practical methods for an attacker to find an OCEF with a given
7 subgroup order r, an opponent has no known practical avenue to mount this type of attack in the
8 OCEF case.)
9 xxx) (Field order generation, binary case.) The field order q may be predetermined, since there is only
10 one binary field for each field order length, and random generation is not meaningful. For the same
11 reason, in canonical domain parameter generation, the field order is selected from a list of allowed
12 values, not generated at random.
13 yyy) Subgroup order: The subgroup order r may have any value consistent with the other domain
14 parameters (provided it is a primitive divisor of q – 1 in the case of binary fields), since the
15 difficulty of the collision-search methods for the discrete logarithm problem depends only on the
16 size of the subgroup order, not on its particular value, as long as it is prime. Selecting a field order
17 that is larger than the size of the hash value employed in a signature scheme, as is done in ANSI
18 X9.62-1998 [B11] has the benefit of thwarting Vaudenay’s attack (Vaudenay [B146]). A small but
19 nonzero probability of error in prime generation or primality testing (say, < 2 –100) is acceptable
20 since it makes no difference in practice. The subgroup order r should be a primitive divisor of q – 1
21 in the case of binary fields (see A.3.9), because otherwise the subgroup is contained entirely in a
22 proper subfield GF(2d) of GF(2m), in which case the opponent need only solve the DL problem in
23 the smaller field GF(2d).
24 Likewise in the odd characteristic extension field case, r should divide pm – 1, but no pn – 1 for n | m,
25 n < m. To ensure this is the case, it suffices to choose r to be a prime factor of the m-th cyclotomic
26 polynomial evaluated at p (see Lenstra [Len97]) (see A.17.3.7 for more details).
27 zzz) (Base.) The base g may have any value consistent with the other domain parameters since the
28 difficulty of the discrete logarithm problem does not depend on which base is employed for a given
29 subgroup. All bases are equivalent in the sense that if an opponent can compute discrete logarithms
30 with respect to one base, say h, the opponent can compute discrete logarithms with respect to any
31 other base for the same subgroup, say g, by taking a ratio:
33 Computing the base g as a one-way function of a random seed provides a degree of auditing since it
34 makes it difficult to select a predetermined base, such as one that depends on another user’s public
35 key, as in [Vau96]. In particular, it thwarts attacks in which the opponent ensures that two parties
36 have different (but related) bases while thinking that they have the same set of parameters ([Vau96]).
37 Such attacks may also be prevented by ensuring that both parties have the same set of parameters,
38 for example, by verifying the authenticity of the parameters, as described in D.3.1.
39 aaaa)(Private keys.) The private key should be generated in an unbiased manner (i.e., randomly or
40 pseudorandomly in the full interval [1, r–1]) since this maximizes the difficulty of recovering the
41 private key by collision-search methods and prevents attacks based on partial information about the
42 private key. A desired level of security can sometimes be provided when the private key is
43 restricted to a large enough subset of the interval (e.g., is shorter than the subgroup order, has low
44 weight, or has some other structure). Such choices require careful security analysis by the
45 implementer. In particular, attacks are known on the various DL/EC signature primitives (see
46 D.5.2.1 Note 3) such that if too much information is available to an opponent about the one-time
47 private key, the signer’s private key may be revealed after some number of runs of the primitive.
48 See D.5.2.1, Note 3, for further discussion of these attacks, and for discussion of how to generate
49 integers uniformly at random from some interval. D.5.1.1, Note 1, discusses a similar attack,
50 though one that is less directly linked to choice of the second private key on the DLSVDP-MQV,
2 295
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
15D.4.2 EC Family
17The primary security parameter for the EC family is the length in bits of the subgroup order r. A common
18minimum subgroup order length is 161 bits (see ANSI X9.62-1998 [B11]). (Note 1.)
19The field type (prime vs. binary vs. odd characteristic extension field) may slightly affect the security of the
20schemes. (Note 2.)
22Considerations for generating domain parameters in the EC family include the following:
23
24 (Prime case.) The field order q (i.e., the prime p) may have any value that provides a sufficiently
25 large subgroup; it may be predetermined, or generated randomly or pseudorandomly. Prime
26 generation for the field order may admit the possibility of error, provided the probability of error is
27 sufficiently low. (Note 3.)
28 (Binary case.) The field order q may be predetermined. (Note 4.)
29 (Odd characteristic extension field case): The field order q may have any value that provides a
30 sufficiently large subgroup.
31 The elliptic curve may be any curve satisfying the definition in Clause 5.4 as well as the MOV and
32 anomalous criteria (see Note 1) that provides a sufficiently large prime-order subgroup. It may be
33 predetermined, or generated randomly or pseudorandomly, perhaps subject to certain conditions
34 that simplify the computation of the number of points on the elliptic curve. For example, a 169-bit
35 Koblitz curve may be estimated to be about 13 times faster to solve than a canonical random 169-
36 bit curve, though in practice the additional calculations may result in a smaller speedup. This
37 corresponds to a decrease of about 3.5 bits of symmetric key exhaustion security, or 7 bits of
38 elliptic curve security. For a canonical random method of domain parameter generation that can be
39 audited, the elliptic curve coefficients should be generated as a one-way function of a random seed
40 (see Annex A.12.4-A.12.7 for one such method). (Note 5.)
2 296
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 The subgroup order r may have any value consistent with the other domain parameters, provided
2 that it is sufficiently large and prime. Prime generation or primality testing for the subgroup order
3 may admit the possibility of error, provided the probability of error is sufficiently low. (Note 6.)
4 The base point G may have any value consistent with the other domain parameters. (Note 7.)
5Considerations for generating key pairs in the EC family include the following:
6
7 The private key s should be generated at random from the range [1, r – 1] (or a sufficiently large
8 subset of it). (Note 8.)
9The domain parameters may be shared among key pairs. The private key s should not be shared. (Note 9.)
11The field representation (in the binary and odd characteristic extension field cases) is not known to affect
12security, although since the field representation is a domain parameter, it should be protected from
13unauthorized modification, along with the other domain parameters. (Note 10.)
14D.4.2.4 Notes
15 dddd) Security parameters: The security of schemes in the EC family against many attacks
16 whose goal is to solve the elliptic curve discrete logarithm problem depends on the difficulty of
17 collision-search methods, which are the fastest methods known today for computing discrete
18 logarithms on an arbitrary elliptic curve. The difficulty of collision search methods depends, in
19 turn, on the length in bits of the subgroup order r. The Pollard rho (Pollard [B125]), and the related
20 Pollard lambda and other collision-search methods (see, e.g., van Oorschot and Wiener [B122]) can
21 compute elliptic curve discrete logarithms after, on average, ( r/4)1/2 elliptic curve additions. The
22 memory requirements of such methods are relatively small. For prime field anomalous curves, and
23 for curves not satisfying the MOV condition (see A.12.1), there are algorithms known for finding
24 elliptic curve logarithms that are significantly more efficient than the collision methods. For prime
25 field anomalous curves, i.e., elliptic curves over GF(p) having exactly p points, there is an efficient
26 polynomial-time method due to Araki, Satoh, Semaev and Smart (see Satoh and Araki [B130],
27 Semaev [B134] and Smart [B140]) for solving the elliptic curve discrete logarithm problem. For
28 elliptic curves not satisfying the MOV condition, the elliptic curve discrete logarithm can be solved
29 in subexponential time. Such curves are considered insecure and are, thus, avoided in this standard.
30 Collision-search methods may also be sped-up by a factor of about (m/e)1/2 for curves over a binary
31 field GF(2m) whose coefficients lie in a smaller subfield GF(2e) (see Gallant, Lambert, and
32 Vanstone [B57] and Wiener and Zuccherato [B148]); this improvement is not considered
33 significant enough to warrant avoidance of such curves, but it may suggest higher key sizes than
34 for general curves. (See also http://www.certicom.com/research.html for more information on the
35 status of solving the elliptic curve discrete logarithm problem.)
36 The following table provides an estimate for the running time of collisions search methods for
37 different sizes of r. The estimate is given in MIPS-Years, where a MIPS-Year is an approximate
38 amount of computation that a machine capable of performing one million arithmetic instructions per
39 second would perform in one year (about 3 1013 arithmetic instructions).
Size of the generator order r Processing Time
(Bits) (MIPS-Years)
2 297
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
172 3 x 1012
234 3 x 1021
314 2 x 1033
2 There is some variation among published estimates of running time due to the particular definition of
3 a MIPS-Year and to the difficulty of estimating actual processor utilization. (How many arithmetic
4 instructions a modern processor performs in a second when running an actual piece of code depends
5 heavily not only on the clock rate, but also on the processor architecture, the amount and speeds of
6 caches and RAM, and the particular piece of code.) Thus, the estimates given here may differ from
7 others in the literature, although the relative order of growth remains the same. The length of the
8 field order and the length of the subgroup order should be selected so that the collision-search
9 methods have sufficient difficulty. A common minimum subgroup order length is 161 bits.
10 A result in Gaudry, Hess and Smart [GHS02] shows that many elliptic curves defined over a binary
11 field with a composite extension degree are vulnerable to attack via a method entirely different from
12 the collision-search approaches. For the field GF(2m), where m = ds, where d, s > 1, a large number
13 of curves E(GF(2m)) admit a method of attack with asymptotic time complexity O(2s(2+)), where >
14 0. When compared with the collision-search methods, this avenue of attack is asymptotically better
15 when m 4s. However, in contrast to the collision-search methods, this approach requires significant
16 overhead which may make it slower in practice for some parameter choices. More study is needed to
17 fully characterize the break-even point of using the two algorithms. However, as a conservative
18 measure the draft ANSI X9.63 [B12] and FIPS PUB 186-2 [B56] explicitly exclude the use of these
19 fields. Thus, the use of fields GF(2m) where m = ds in the EC setting requires further security
20 analysis by the implementer.
21 The fundamental methods used in Gaudry, Hess and Smart [GHS02] do not apply to prime fields
22 GF(p) because of the lack of a subfield. The methods also do not apply to binary fields GF(2m)
23 where m is prime because the unique subfield GF(2) is not suitable. Also, the particular techniques
24 used to obtain the result in Gaudry, Hess and Smart [GHS02] do not work for odd characteristic
25 fields GF(pm).
26 When a set of domain parameters is shared among parties, the size should also take into account the
27 number of key pairs associated with the set, since the total running time for computing k elliptic
28 curve discrete logarithms with the same set of domain parameters is only about k1/2 times the running
29 time of computing a single elliptic curve discrete logarithm, provided that more memory is available
30 (van Oorschot and Wiener [B112]). A prudent practice is to pick security parameters such that
31 computing even a single elliptic curve discrete logarithm is considered infeasible.
32 eeee)Field type: prime vs. binary vs. odd characteristic extension field: The field type may slightly
33 affect the security of the schemes, since the cost of finite field operations may differ among the
34 types of field, and the actual running time of collision-search methods may vary by a small factor.
35 Furthermore, as indicated in D.4.1.4 Note 3, there are fewer alternatives to choose from should
36 some binary field or OCEF be cryptanalyzed, than should a single prime field be cryptanalyzed;
37 however, in any case there are many elliptic curves to choose from, and no method is known that
38 cryptanalyzes all elliptic curves over a given field at the same time. See also the considerations on
39 choice of extension degree in Note 1.
40 ffff) (Prime generation.) No special primes are known where computing elliptic curve discrete
41 logarithms might be substantially easier. A small but nonzero probability of error in prime
42 generation or primality testing (say, < 2 –100) is acceptable since it makes no difference in practice;
43 methods with a small probability of error are generally simpler than those with zero error. See
44 Annex A.15 for more on generating primes.
2 298
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 gggg) (Field order generation, binary case.) The field order q may be predetermined, since
2 there is only one binary field for each field order length.
3 hhhh) (Elliptic curve.) The elliptic curve may be any curve satisfying the definition of Clause
4 5.4 as well as MOV and anomalous criteria (see Note 1) that provides a sufficiently large prime-
5 order subgroup, as no other special classes of elliptic curves are known where computing elliptic
6 curve discrete logarithms might be substantially easier. The elliptic curve may be predetermined, or
7 generated randomly or pseudorandomly, perhaps subject to certain conditions that simplify the
8 computation of the number of points on the elliptic curve. Of the methods for curve generation
9 described in A.9.5, method 1 (selecting a random curve and computing its order) imposes no
10 additional conditions on the curve, and the other three methods impose additional conditions. In
11 particular, method 3 (selecting a curve over a subfield) imposes additional conditions that make the
12 discrete logarithm computation on the curve subject to the speed-up due to [GLV98] and [WZ98],
13 as further described in Note 1 above.
14 Computing the elliptic curve coefficients (or other inputs to elliptic curve generation) as a one-way
15 function of a random seed provides a degree of auditing since it makes it difficult to select an elliptic
16 curve with some predetermined rare property. It may not entirely prevent the party generating the
17 elliptic curve from producing curves with special properties, since the party can try many different
18 seeds, looking for one that yields the desired property, if the property is likely enough to occur.
19 However, it will make it difficult to mount an attack in which the opponent picks a particular
20 subgroup order r in order for two messages to have the same signature (see [Vau96] for such an
21 attack on DSA). (See also Note 6.) See Annex A.12.4-A.12.7 for an example of such a method.
22
23 NIST has published a set of recommended elliptic curves for government use in FIPS 186-2 [B56].
24 The security parameters for each curve are chosen to correspond to one of five symmetric key sizes
25 (80, 112, 128, 192 and 256 bits), with three curves per key size.
26 iiii) (Subgroup order.) The subgroup order r may have any value consistent with the other domain
27 parameters, since the difficulty of the collision-search methods for the elliptic curve discrete
28 logarithm problem depends only on the size of the subgroup order, not on its particular value,
29 provided that the subgroup order is prime. Selecting a field order that is larger than the size of the
30 hash value employed in a signature scheme, as is done in ANSI X9.62 [ANS98e] has the benefit of
31 thwarting Vaudenay's attack [Vau96]. A small but nonzero probability of error in prime generation
32 or primality testing (say, < 2–100) is acceptable since it makes no difference in practice.
33 jjjj) (Base.) See Note 6 of D.4.1.4, replacing “base g” with “base point G”.
34 kkkk) (Private keys.) See Note 7 of D.4.1.4.
35 llll) (Domain parameters, public key and private key sharing.) See Note 8 of D.4.1.4.
36 mmmm) (Field representation.) See Note 9 of D.4.1.4.
37D.4.3 IF Family
39The primary security parameter for the IF family is the length in bits of the modulus n. A common
40minimum length is 1024 bits (see ANSI X9.31-1998 [B7]). (Note 1.)
41The key type (RSA vs. RW vs. OU vs. ESIGN) may affect the security of the schemes. (Note 2.)
2 299
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
3
4 The modulus n should be sufficiently large. (Note 1.)
5 The lengths of the primes p and q should be approximately half the length of the modulus n for
6 RSA and RW keys, and approximately one third the length for OU and ESIGN keys, although
7 other lengths may also provide sufficient security. (Note 3.)
8 The primes p and q should be generated randomly or pseudorandomly with a prime generation
9 method that has a sufficiently low probability of producing a non-prime. If auditing of key
10 generation is required, then the primes should be generated as a one-way function of a random
11 secret seed. (Note 4.)
12 For RSA and RW keys, the public exponent e may have any value consistent with the modulus and
13 key type; it may be predetermined, or generated randomly or pseudorandomly. For ESIGN keys,
14 the public exponent should be at least e = 8. (Note 5.)
15 The private exponent d for RSA and RW keys should be derived from the public exponent e or
16 generated at random. (Note 6.)
17 For OU keys, the values u and v may have any value consistent with the definition of the key type.
18 The value u may be predetermined, or generated randomly or pseudorandomly; the value v0 from
19 which the value v is derived may also be predetermined, or generated randomly or
20 pseudorandomly. (Note 9)
21The public exponent e (for RSA, RW and ESIGN) may be shared among keys. The modulus n, the primes
22p and q, and the private exponent d (for RSA and RW) should not be shared. The values u and v0 for OU
23keys may be shared among keys. (Note 7.)
25The private-key representation does not affect security in general, although the effectiveness of certain
26physical attacks may vary according to the representation. The private key should be stored securely
27regardless of the representation, as discussed in D.7. (Note 8.)
28D.4.3.4 Notes
29 nnnn) Modulus size: The security of schemes in the IF family against attacks whose goal is to
30 recover the private key depends on the difficulty of integer factorization by general-purpose
31 methods, which, in turn, depends on the length in bits of the modulus n. For large moduli, the
32 fastest general-purpose factoring method today is the generalized number field sieve (GNFS) (see
33 Buchmann, Loho, and Zayer [B32] and Buhler, Lenstra and Pomerance [B34]), which has
34 asymptotic running time exp(((64/9) 1/3 + o(1)) (ln n)1/3 (ln ln n)2/3), where o(1) denotes a number
35 that goes to zero as n grows. Previously, the fastest general-purpose method was the multiple
36 polynomial quadratic sieve (MPQS) (see Silverman [B138]), which has running time of about
37 O(exp (ln n ln ln n)1/2). See Section 3.2 of Menezes, van Oorschot, and Vanstone [B112] and
38 Odlyzko [B121] for more discussion on integer factorization. (See also
39 http://www.rsasecurity.com/rsalabs/challenges/ for more information on the status of solving the
40 integer factorization problem.)
41 In order to compute the complexity of the GNFS accurately for a particular n, one needs to know the
42 precise value of the o(1) term for that n. In particular, the complexity of the GNFS is difficult to
2 300
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 measure accurately for numbers of cryptographic interest, because they are larger than GNFS can
2 currently factor. The standard practice is to estimate the complexity by extrapolating from running
3 times observed for factoring smaller numbers. Following this, ANSI X9.31-1998 [B7] gives the
4 following estimates for GNFS factorization at various modulus sizes. Processing time is the total
5 computational effort, given in MIPS-Years (a MIPS-Year is an approximate amount of computation
6 that a machine capable of performing one million arithmetic instructions per second would perform
7 in one year [about 3 1013 arithmetic instructions]); memory requirements consider the amount of
8 processor memory for a sieving process, which may be distributed among many processors, and for
9 linear algebra operations, which would typically be on a single processor; and storage requirements
10 is the amount of disk space.
11
12 Table D.2 — Estimated cryptographic strength for IF modulus sizes
14 There is some variation among published estimates of running time due to the particular definition of
15 a MIPS-Year and to the difficulty of estimating actual processor utilization. (How many arithmetic
16 instructions a modern processor performs in a second when running an actual piece of code depends
17 heavily not only on the clock rate, but also on the processor architecture, the amount and speeds of
18 caches and RAM, and the particular piece of code.) Thus, the estimates given here may differ from
19 others in the literature, although the relative order of growth remains the same. The length of the
20 modulus should be selected so that integer factorization methods have sufficient difficulty; as
21 mentioned, a common minimum length is 1024 bits. Very recently, there has been significant
22 discussion on the actual cost of hardware for integer factorization, particularly at the 1024-bit level;
23 Bernstein [Ber01], Lenstra et al. [LST+02], and Shamir and Tromer [ST03] give treatments of this
24 issue. The Shamir-Tromer paper proposes a new hardware implementation that very efficiently
25 parallelizes the processing without the usual cost inflation due to memory requirements, affirming
26 that processing time is the primary metric to consider.
27 oooo) Key type: The key type may affect the security of the schemes in two respects: first, the
28 set of supported primitives (and possibly schemes as well) depends on the key type; and second,
29 the form of modulus depends on the key type.
30
31 The choice between RSA and RW (which is only an issue for the signature schemes) affects
32 security for some encoding methods (EMSA4 and EMSR3) to the extent that a security reduction
33 to integer factorization for a signature scheme with those encoding methods has been given in the
34 RW case but not in the RSA case. For the other encoding methods, the choice is not known to
35 affect the security of the schemes. The relationship with integer factorization is known to vary in
36 general between RSA and RW. For instance, certain attack strategies on signature schemes not
37 specified here (see, e.g., Joye and Quisquater [JQ01]) have been shown to yield the factorization of
38 the modulus in the RW case but not in the RSA case. Also, Boneh and Venkatesan [B30] have
2 301
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 recently shown strong evidence that root extraction for a small odd exponent is not equivalent to
2 integer factorization, whereas root extraction for an even exponent of any size is known to be
3 equivalent to integer factorization. Integer factorization is the nevertheless the only known
4 approach for forging signatures or recovering messages for the schemes in this standard with the
5 recommended encoding methods, regardless of key type.
6
7 Regarding the form of modulus, although it is not known whether moduli of the form n = p2q (key
8 types OU and ESIGN) are easier to factor than moduli of the form n = pq (key types RSA and
9 RW), some special algorithms to factor moduli of the form p2q have been studied by several
10 researchers (Peralta [Per97], Peralta and Okamoto [PO96], Pollard [Pol97], Adleman and
11 McCurley [AM95], open problems: C7, O7a and O7b). Such techniques are variants of the elliptic
12 curve method (ECM) and are several times faster. Recently Boneh et al. [BDH99] presented an
13 algorithm for factoring moduli of the form n = prq with large r using the LLL algorithm (lattice
14 reduction). Their algorithm, however, is only effective for the case where r is large (at least (log
15 p)1/2). If r is constant (or small), the running time of their algorithm is exponential in log n. For
16 large moduli of the form n = p2q (e.g., at least 1024 bits), their algorithm is less efficient than ECM
17 and GNFS. Therefore, the modulus size for OU and ESIGN keys can be roughly the same as for
18 RSA and RW keys, given current algorithms. (Note that for ESIGN keys, the modulus size must be
19 a multiple of 3 bits in order for the signature and verification primitives to operate correctly.) If a
20 new algorithm were to be found that is more effective for moduli of the form n = p2q but not for
21 moduli of the form n = pq, the modulus size for OU and ESIGN keys might be recommended to be
22 longer than for RSA and RW keys.
23 pppp) Prime size: For RSA and RW keys, the lengths in bits of the primes p and q should be
24 approximately half the length of the modulus n, since this maximizes the difficulty of certain
25 special-purpose integer factorization methods. Such methods include the Pollard rho method
26 (Pollard [B124]), with asymptotic expected running time O(p1/2); the Pollard p – 1 method (Pollard
27 [B123]), with running time O(p), where p is the largest prime factor of p – 1; and the p + 1
28 method (Williams [B150]), with running time O(p), where p is the largest prime factor of p + 1.
29 The elliptic curve method (ECM) (Lenstra [B101]) is superior to these; its asymptotic running time
30 is O(exp (2ln p ln ln p)1/2). All these methods are slower than GNFS (see Note 1 above) for
31 factoring a large IF modulus with prime factors that are approximately half the length of the
32 modulus. These methods may be effective, however, when one of the prime factors is small.
33
34 For OU and ESIGN keys, the lengths in bits of the primes are the same, i.e., approximately one
35 third the length of the modulus, again to maximize the difficulty of special-purpose methods such
36 as those mentioned in Note 1 above, as well as to meet technical requirements of the schemes based
37 on these keys.
38 A desired security level can also be provided when the lengths of the primes are not approximately
39 half the length of the modulus, so long as the primes are large enough to resist the special-purpose
40 methods just mentioned. Such a choice requires further security analysis by the implementer. (For
41 some further discussion, see Shamir [B136]; see also Gilbert et al. [B59] for a security analysis.)
42 qqqq) (Prime generation.) The primes should be generated randomly or pseudorandomly since
43 this provides resistance to exhaustive search and other special-purpose attacks (see Annex D.6 for
44 more on random number generation). The prime generation method should have a sufficiently low
45 probability that a non-prime is generated, so that the probability of generating an invalid key is
46 small. A small but nonzero probability of error (say, < 2 –100) is acceptable since it makes no
47 difference in practice; methods with a small probability of error are generally simpler than those
48 with zero error. Other criteria may be added to prime generation to ensure that primes meet certain
49 properties. Acceptable prime-generation methods include incremental search from a random
50 starting point (see Annex A.15.6 and A.15.8) with either probabilistic primality testing (probability
51 of nonprime output of less than 2 –100; see Annex A.15.1-A.15.3) or primality proving (see Annex
2 302
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 A.15.4); and recursive construction of primes with an implicit proof of primality (such as [Sha86],
2 [Mau95], [Mih94]). See also [MOV96, Sections 4.1-4.4], ANSI X9.31[ANS98a] and ANSI X9.80
3 [ANS98g].
4 Computing primes as a one-way function of a random seed provides a degree of auditing since it
5 makes it difficult to select a prime with some predetermined rare property. It may not entirely
6 prevent a user from producing primes with special properties, since a user can try many different
7 seeds, looking for one that yields the desired property, if the property is likely enough to occur.
8 However, it will make it difficult for a user to produce primes that are vulnerable to a special-
9 purpose factoring method such as the p – 1 method, provided that the prime is large enough. (A user
10 may wish to do this in the interest of later disavowing a signature.) The seed should be kept secret,
11 because revealing it would reveal p and q and thus the private key. Therefore, the actual auditing
12 must be done only by trusted parties or in situations when it is appropriate to reveal the private key.
13 ANSI X9.31 [ANS98a] gives an auditable method of generating primes by incremental search.
14 rrrr) Public exponent selection (RSA, RW and ESIGN only): For RSA and RW keys, the public exponent
15 may have any value consistent with the modulus and key type, since the value of the public
16 exponent is not known to affect the security of the schemes with recommended and correctly
17 implemented encoding methods. IF schemes for these key types with nonrecommended (or
18 incorrectly implemented) encoding methods, or implementations that leak a fraction of the bits of
19 the private exponent or the primes, may be vulnerable to certain attacks when the public exponent
20 is small (see Boneh, Durfee, and Frankel [B26], Coppersmith et al. [B39], and Hastad [B70]).
21 However, the recommended encoding methods and appropriate protection of the private key (see
22 D.7) prevent these attacks. Typical public exponent values are e = 2 for RW keys and e = 3 or 216+1
23 for RSA keys. A larger public exponent may nevertheless offer an additional line of defense, as it
24 can mitigate concerns about implementation failures in the encoding methods or in the underlying
25 random number generation for an IF encryption scheme. Moreover, it has been shown that for very
26 small public exponents such as e = 3, the RSA problem may not be equivalent to the integer
27 factorization problem (see Boneh and Venkatesan [B30]) (see also Note 2).
28
29 For ESIGN keys, the public exponent should be at least e = 8. The square degree (e = 2) version of
30 ESIGN was proposed in 1985 [OS85] and was broken by Brickell and DeLaurentis in the same
31 year [BD86] (see also Brickell and Odlyzko [BO91]. In other words, they gave an efficient
32 algorithm to solve the approximate square root problem, i.e., the approximate eth root (AER)
33 problem for e = 2. They also presented an efficient algorithm to solve the cubic version (AER
34 problem for e = 3). In the late 1980s, Girault, Toffin and Vallee studied various types of AER
35 problems using lattice reduction [GTV88], [VGT88a], [VGT88b]. (Brickell and DeLaurentis’
36 attack is a special case of their lattice base reduction attack). However, they did not find an efficient
37 solution for e > 3. Lattice basis reduction is currently the only effective tool known to solve such
38 AER problems, and no algorithm is known to efficiently solve the AER problem with e > 3. (Note
39 that lattice basis reduction is a very powerful tool to solve various problems: for example, almost
40 all knapsack public-key cryptosystems were broken by lattice basis reduction.) To keep a sufficient
41 security margin, it is recommended to choose e to be to be at least 8, and more preferably at least
42 32; typical public exponent values for ESIGN keys are e = 2c for 5 c 8. Note that even if e =
43 1024 = 210, the computational complexity for exponentiation is fairly comparable (just around three
44 times slower) to that for e = 8 = 23.
45 Restricting the allowed set of public exponents system-wide, and ensuring that system components
46 refuse to perform operations with public exponents that do not satisfy the restriction, may provide a
47 measure of protection against protocol attacks that exploit the ability of an opponent to pick an
48 arbitrary public exponent (see, e.g., Chen and Hughes [B37]). However, such attacks are generally
49 better defended against by picking appropriate protocols.
50 A more common use of a system-wide restriction is picking a specific public exponent system-wide
51 in order to avoid having to store and transmit it with the public key. For example, a system using
2 303
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 RW keys may have a system-wide policy that e = 2 for all keys, in which case just n, not (n, e),
2 needs to be transmitted and stored for public keys. The system-wide e should be protected from
3 unauthorized modification the same way any public key would be.
4 ssss) (Private exponent selection.) The private exponent should be derived from the public exponent or
5 generated at random (see Annex D.6) so that with high probability it will have approximately the
6 same size as the modulus. In particular, the private exponent should be substantially longer than
7 one quarter of the modulus length. This makes it difficult to recover the private exponent by certain
8 methods, such as [Wie90] and [BD99]. (Note that ANSI X9.31 requires that for a 1024-bit modulus
9 the private exponent is at least 2 512+128s where s is an integer 0.) A desired difficulty can also be
10 provided when the private exponent is significantly shorter than the modulus or has some other
11 structure, such as low weight; such choices require further security analysis by the implementer.
12 tttt) Key component sharing: A modulus should not be shared since it is possible, given two public keys
13 with the same modulus and one of the corresponding private keys, to determine the other private
14 key. A prime should not be shared since moduli with one prime factor in common can be factored
15 by taking their GCD. For RSA and RW, a private exponent should not be shared since it is
16 effectively the only private component of the private key. Sharing of any of these quantities is
17 unlikely to occur if primes are generated at random and, for RSA and RW, the private exponent is
18 derived from the public exponent or generated at random. A public exponent for RSA, RW and
19 ESIGN may be shared since it is public and may have any value consistent with the modulus and
20 key type. Similarly, the values u and v0 for OU may be shared.
21 uuuu) Other component selection (OU only): For OU keys, the values u and v may have any
22 value consistent with the definition of the key type. A typical value for u is u = 2, which may yield
23 implementation advantages. (Note that u = 2 should be appropriate for almost any prime, as the
24 congruence 2p1 1 (mod p2) is conjectured to hold only for a very small fraction of primes.) A
25 typical value for v0 (from which v is generated) is v0 = u.
26 vvvv) Private-key representation: The choice of private-key representation does not affect
27 security against cryptanalytic attack, although security against certain implementation attacks may
28 vary according to the representation. For instance, the Bellcore fault-analysis attack on RSA (or
29 RW) keys (Boneh, DeMillo, and Lipton [B26]) is more feasible if the private key contains the
30 prime factors of the modulus, because a single undetected bit error in an exponentiation modulo
31 one of the primes will compromise the private key. (See D.7 for more on implementation attacks.)
32
38Key agreement schemes are generally used to provide assurance that nobody but the two legitimate parties
39involved in the protocol can compute the shared secret key. Note that a basic key agreement scheme does
40not provide assurances that the parties are correct about each other’s identities, or that both parties can
41actually compute their shared secret keys. Key confirmation (see Annex D.5.1.3) is often used to provide
42such additional assurances.
43In addition, key agreement schemes are sometimes used to provide forward secrecy. See Annex D.5.1.7 for
44more on forward secrecy and how the key agreement schemes in this standard can provide it.
2 304
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The application of key agreement schemes in a key establishment protocol is a particularly challenging
2task, as illustrated by the various attacks on key agreement protocols that have been observed over the
3years. Apparently slight changes, such as the ordering of messages, may well introduce unintended security
4weaknesses. Conversely, slight differences may yield security benefits. For instance, requiring each party to
5commit to its short-term key by sending a hash of the short-term key, prior to exchanging the short-term
6keys, can remove some potential for an opponent to manipulate a protocol. Although the recommendations
7in this clause cover many of the general principles of key agreement, the implementer is encouraged to
8consult recent literature on key agreement protocols for further information.
9D.5.1.1 Primitives
10Secret value derivation primitive choices include the following (the particular choices vary among the three
11key agreement schemes):
12
13 DLSVDP-DH, DLSVDP-DHC, DLSVDP-MQV, DLSVDP-MQVC
14 ECSVDP-DH, ECSVDP-DHC, ECSVDP-MQV, ECSVDP-MQVC
15The choice between DL and EC affects security to the extent that the difficulties of the underlying problem
16differ (see Annex D.4). Attacking the underlying problem is the best currently known method for attacking
17the primitives. (For ECSVDP-DH and ECSVDP-DHC, attacking the primitive is equivalent to attacking the
18underlying problem in the sense that if one takes exponential time, then the other takes exponential time as
19well [BL96].) The choice of -DH vs. –DHC or -MQV vs. -MQVC affects security with respect to key
20validation (see Annex D.5.1.6 below). Security considerations related to the generation of the second key
21pair in the -MQV and -MQVC primitives are addressed in the Note below.
22NOTE—For the MQV Secret Value Derivation Primitives (DLSVDP-MQV, DLSVDP-MQVC, ECSVDP-MQV, and
23ECSVDP-MQVC), Leadbitter and Smart [LS03] have shown in the case of 160-bit r that if an opponent, participating
24in runs of the primitive, can determine the six most significant bits of the other party’s quantity e = ts + u, calculated in
25step 5, and can do this for 20 runs of the primitive, then the opponent can recover the other party's first private key s by
26solving a discrete logarithm problem that requires about 2 40 effort. Similar results apply to the least significant bits, and
27to smaller amounts of bits with greater numbers of primitive invocations and a lower probability of success. It appears
28that even if one party is known to select the second private key u other than randomly or pseudorandomly in the full
29interval [1, r1] (for example, by restricting it to subset of the interval), this knowledge alone is not enough to allow the
30other party to the primitive to mount the attack. The type of information that would be required to mount this attack is
31currently only known to be leaked by side-channel analysis, which is out of scope of this standard.
34The recommended key derivation functions for the key agreement schemes in this standard are KDF1 and
35KDF2.
36A key derivation function for the key agreement schemes in this standard should produce keys that are
37computationally indistinguishable from randomly generated keys. (See D.6 for more on computational
38indistinguishability.) KDF1 and KDF2 are considered to have this property, provided that the shared secret
39input string is sufficiently long and the length of the key derivation parameters is the same for all keys
40computed from a given shared secret value.
41KDF1 and KDF2 have essentially the same design except that KDF2 can produce a key of arbitrary length,
42whereas the length of the key that KDF1 can produce is limited by the hash function output length.
2 305
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1However, although KDF2 can produce an arbitrary length key, it is not recommended for use as a stream
2cipher for encrypting messages of arbitrary length, as this was not a specific design goal for KDF2. See
3D.5.3.2.2 for related discussion.
4The security of KDF1 and KDF2 depends on the underlying hash function (see D.5.1.2.2). The length of
5the hash function’s intermediate chaining value (for iterative constructions such as in the recommended
6hash function) governs the security of KDF1 and KDF2 against certain forms of attack. Typical theoretical
7attacks for distinguishing KDF1 or KDF2 from a random source involve on the order of 2 l operations
8assuming an l-bit hash function, and these attacks do not necessarily yield any particular key.
10The recommended hash functions for the key agreement schemes in this standard are SHA-1, RIPEMD-
11160, SHA-256, SHA-384, and SHA-512, the first two of which are options in KDF1 and all of which are
12options in KDF2.
13While a hash function for a signature scheme in this standard should be collision-resistant (see D.5.2.2.4),
14this property is not strictly necessary for KDF1 and KDF2 since the shared secret string is unknown. In
15addition, although the original design goal of a hash function was to support signature schemes, the
16recommended hash functions are generally considered to be appropriate for a number of applications as
17well, including key derivation.
19Key confirmation is the assurance provided to each party participating in the key agreement protocol that
20the other party is actually capable of computing the agreed-upon key, and that it is the same for both
21parties. Note that key agreement does not necessarily, by itself, provide key confirmation. For example, an
22opponent may present a public key that is identical or related to some other party’s public key, to make it
23appear as though a derived key is shared with the opponent, when in fact it is shared with the other party.
24This is known as the unknown key-share attack (see [BM98], [DOW92], [MQV95], [Kal98b], [LMQ98]).
25An unknown key share attack may be a concern in situations where a party assumes that another party has
26certain privileges as a result of a successful key agreement protocol, and the other party is not further
27identified in the protocol. If an opponent can make it appear as though a derived key is shared with the
28opponent, when in fact it is shared with the other party, then the opponent may be able to impersonate the
29other party in subsequent messages encrypted with the derived key (even though the opponent does not
30know the derived key). In typical protocols, this is a theoretical concern, since exchanged messages (e.g.,
31funds transfers) should generally identify the parties.
32In general, if an opponent can obtain a certificate for another party's public key, the opponent can trivially
33mount an unknown key share attack by substituting its certificate for the other party's certificate. The CA
34can prevent this kind of attack by checking for duplicate public keys, or by requiring a proof of possession
35of the corresponding private key.
36For variants of DH2 where one party's ephemeral key is combined with another party's static key, an
37opponent can also mount an unknown key share attack by substituting powers or multiples of the combined
38static and ephemeral public keys, obtaining a certificate for the new static key, and substituting the new
39certificate. (See [MQV95].) A CA can prevent this attack by requiring a proof of possession of the private
40key, but cannot prevent it by checking for duplicates.
41For MQV, an opponent can mount an unknown key share attack with certain substitutions, as further
42described in [Kal98]. A CA cannot prevent the attack either by checking for duplicates or by requiring a
2 306
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1proof of possession of the private key. As a result, if the unknown key share attack is a concern, protocol
2steps such as key confirmation are essential.
3In general, to avoid unknown key share attacks and other possible attacks, the parties should perform a key
4confirmation protocol which securely associates the names of the parties with the knowledge of the shared
5secret key. Such protocols usually involve computations of cryptographic functions based on the identities
6of the parties and the derived keys (see, e.g., [MQV95], [BJM97], [ANS98b], [ANS98e]).
8The purpose of key derivation parameters is to distinguish one derived key from another. As such, the
9parameters should have an unambiguous interpretation. If no other key confirmation is performed, they
10should identify the parties exchanging the key and specify the purpose of the derived key (e.g., its type and
11position within a sequence of derived keys of the given type).
12For KDF1, the set of all possible key derivation parameters for a given shared secret value should be
13prefix-free. (A string P is called a prefix of a string S if S begins with P, i.e., S = P || R for some string R; a
14set of strings is prefix-free if it does not contain a pair of strings P, S such that P is a prefix of S.)
15Otherwise, due to the nature of hash functions used in KDF1, an opponent may be able to derive new
16shared secret keys based on the same shared secret value and new key derivation parameters, without
17knowing the shared secret value. If all key derivation parameters are the same length, or if they are BER or
18DER encodings of ASN.1 structures, they will satisfy the prefix-free requirement.
20If it is desired to verify that a particular party has the ability to compute a given derived key, the party’s
21ownership of a public key from which the derived key is computed should be authenticated. The following
22table summarizes the typical means of associating the derived key with a particular party, in terms of which
23public key should be authenticated:
24
27In general, as noted in D.3.1 and D.5.1.2, the party’s possession of the corresponding private key should
28also be authenticated, by means of a key confirmation protocol or otherwise. The risk of not doing so is the
29same as the lack of key confirmation, as further discussed in D.5.1.3.
30A situation in which it may be acceptable not to authenticate a party’s possession of a private key (directly
31or through key confirmation) is one in which the key derivation parameters include information identifying
32the party. The identifying information avoids any ambiguity in the sharing of the derived key.
2 307
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2As discussed in D.3.3, using invalid keys or domain parameters as inputs to a primitive carries with it
3certain risks. Specifically, for the key agreement schemes, the risks are outlined below. Note that the risks
4will vary with the particular implementation:
5
6 Failure of the implementation, resulting in an error state
7 Reduction in size of the key space for derived keys (see, e.g., Jablon [B83])
8 Compromise of information about a private key that is combined with the invalid public key in a
9 secret value derivation primitive (Lim and Lee [B102])
10An attack in which an opponent deliberately provides an invalid public key is sometimes referred to as a
11small-subgroup attack. If one does not check whether another party’s public key is valid, an opponent may
12be able to provide an element of small order as the “public key” to confine the shared secret value or to
13obtain information about the legitimate party’s private key. (If both public keys are valid, then the shared
14secret value ranges over the subgroup of size r generated by the generator g; otherwise, it may be outside
15the subgroup of size r, possibly in a small set.)
16These risks can be mitigated by ensuring the validity of domain parameters and public keys. However,
17validation does not address certain other risks. A key may be valid and still be insecure (for example, if the
18random number generation for the key generation was performed improperly, or if the private key is stored
19insecurely or deliberately disclosed). Therefore, an implementer should consider other ways in which the
20key may be insecure, and then decide how to appropriately mitigate the risk. FIPS PUB 140-2 [B54]
21implementation validation and random number generation are typical ways to address some of these
22concerns (see D.6.1 and D.7).
23Cofactor multiplication (i.e., -DHC or -MQVC) is another technique used in defending against invalid
24public keys, which may require less computation than validating the public key directly. Provided that the
25associated set of domain parameters is valid and the public key is validated as an element of the appropriate
26group (i.e., element of the finite field or point on the elliptic curve), a -DHC or -MQVC primitive will
27operate appropriately on public keys which are in the appropriate group but not in the subgroup of size r; no
28further validation is necessary.
29A situation in which it may be acceptable not to validate a public key is one in which the public key is
30authenticated (typically by the other party in a key agreement operation) and the private key with which the
31public key is combined in a secret value derivation primitive has a short cryptoperiod. The authentication
32prevents an outside opponent from substituting an invalid public key in an attempt to reduce the key space.
33The short cryptoperiod of the private key mitigates the potential for an adversary to benefit from
34compromising information about the private key.
35The amount of information about the private key that the opponent can possibly compromise by using an
36invalid public key may be limited if the group has few elements of order less than r (e.g., if q = 2r + 1 in
37the DL case or if the cofactor k is small in the EC case), as described in Lim and Lee [B102]. However, an
38opponent may still be able to reduce the variability of the shared secret key value by confining it to a small
39set, such as described in [B83]. Furthermore, especially in the EC case, the public key should be validated
40as an element of the appropriate group (i.e., a point on the correct elliptic curve, or an element of the
41correct field GF(q)) as specifically defined by the domain parameters. Biehl, Meyer and Müller [BMM00]
42and Antipa, Brown, Menezes, Struik and Vanstone [B1] describe further potential attacks in the EC case
43whereby an opponent can compromise the private key of a party who does not validate that the opponent’s
44public key is a point on the correct elliptic curve.
2 308
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2In a key agreement scheme, if an opponent learns a party’s private key or keys, then the opponent may be
3able to recover derived keys produced from the private key or keys. The longer the cryptoperiod, the more
4derived keys are potentially vulnerable to recovery. The private keys used for key agreement schemes
5should be erased after their cryptoperiods expire, in order to limit a private key’s potential vulnerability to
6physical compromise.
7By giving certain private keys a short cryptoperiod and erasing them after they expire, it is possible to
8overcome the risk of recovery of derived keys due to compromise of parties’ cryptographic state. This
9prevents a passive opponent who merely recorded past communications encrypted with the shared secret
10keys from decrypting them some time in the future by compromising the parties’ cryptographic state. This
11property is called forward secrecy. One-party forward secrecy means that an opponent’s knowledge of that
12party’s cryptographic state after a key agreement operation does not enable the opponent to recover derived
13keys. Two-party forward secrecy ([Gun90]; see also [DOW92]), means that an opponent’s knowledge of
14both parties’ cryptographic state does not enable recovery of previously derived keys.
15The following table summarizes the typical means for achieving forward secrecy with respect to one party
16or both parties with the key agreement schemes, in terms of which private keys should have short
17cryptoperiod (i.e., be short-term):
18
DH2 Either of party’s private keys Both parties’ second private keys (see
the note below)
MQV Party’s second private key Both parties’ second private keys
21Here, “short-term” means that a private key is generated immediately prior to a secret value derivation
22operation, and destroyed as soon as possible thereafter.
23Key cryptoperiod and authentication are independent considerations; a public key may be authenticated
24even if the corresponding private key is short-term. The STS protocol ([MOV96, Section 12.6], [Dif88, p.
25568], [DOW92]) is an example of this approach.
26NOTE—In the DH2 scheme, it is also possible to achieve two-party forward secrecy if both parties’ first private keys
27are short-term; however, conventionally, it is the second private keys that are short-term for two-party forward secrecy.
28Two-party forward secrecy is not achieved if one party’s first key and the other party’s second key are short-term while
29the other keys are long-term.
31There are two types of signature schemes: signature schemes with appendix, and signature schemes giving
32message recovery. Signature schemes with appendix require the message to be transmitted in addition to
33the signature; without knowing the message signed, one cannot verify the signature. Signature schemes
34giving message recovery produce signatures that contain all or part of the message within them. The
2 309
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1verifier does not need to know all of the message in order to verify the signature: if the signature is valid,
2all or part of the message signed is recovered during the signature verification process. While signature
3schemes with appendix may be used to sign messages of practically any length (subject only to the
4limitations of the encoding method), signature schemes giving message recovery are generally used for
5messages that are short (although the schemes themselves may well allow larger messages).
6A further discussion of desired theoretical properties for signature schemes may be found in Bellare and
7Rogaway [B19].
8NOTE—In general, the use of randomization in signature schemes introduces the possibility that a user (or perhaps the
9user’s device, working against the user) can transmit additional and potentially undetected information separate from
10the message that is signed, typically by filtering or controlling the randomization in the scheme. All of the schemes
11except IFSSA with the -RSA or -RW primitives and the EMSA1 or EMSA3 encoding methods (which are
12deterministic) have this property, which is called a “subliminal channel”. The salt value in EMSA4 and EMSR3 is
13particularly amenable to such purposes since it can be directly specified during signature generation. The one-time
14public key in DL and EC signature primitives can be used as a subliminal channel (see Simmons [Sim94]). Also, in
15some situations the recoverable part of the message may also be considered as providing a subliminal channel since it
16cannot be recovered without the signer’s public key.
17To reduce the potential for a subliminal channel, the amount of randomization available for signing a given message
18should be limited and the verifier (perhaps the user, if concerned that the device is working against the user) should
19have some way to check this. Deterministic versions of the DL/EC primitives as contemplated in D.5.2.1 Note 2 help
20somewhat: the same signature is produced each time the same message is signed, thereby removing the channel, but the
21verifier cannot be sure that the channel has been removed without actually testing the signing implementation (or
22examining the source code). The situation is the same if the salt value in EMSA4/EMSR3 is derived as a function of the
23signer’s private key and the message representative. In contrast, if the salt value is fixed in EMSR4/EMSR3, the
24verifier can gain assurance that the channel has been removed simply by observing signatures, without testing the
25signing implementation directly. However, fixing the salt value reduces the tightness of the security analysis (see
26D.5.2.2.1 Note 2).
27D.5.2.1 Primitives
28Pre-signature, signature and verification primitive choices include the following pairs or triples:
29
30 DLSP-NR and DLVP-NR (for DL/ECSSA)
31 DLSP-DSA and DLVP-DSA (for DL/ECSSA)
32 DLPSP-NR2/PV, DLSP-NR2 and DLVP-NR2 (for DL/ECSSR)
33 DLPSP-NR2/PV, DLSP-PV and DLVP-PV (for DL/ECSSR-PV)
34 ECSP-NR and ECVP-NR (for DL/ECSSA)
35 ECSP-DSA and ECVP-DSA (for DL/ECSSA)
36 ECPSP-NR2/PV, ECSP-NR2 and ECVP-NR2 (for DL/ECSSR)
37 ECPSP-NR2/PV, ECSP-PV and ECVP-PV (for DL/ECSSR-PV)
38 IFSP-RSA1 and IFVP-RSA1 (for IFSSA and IFSSR)
39 IFSP-RSA2 and IFVP-RSA2 (for IFSSA and IFSSR)
40 IFSP-RW and IFVP-RW (for IFSSA and IFSSR)
41 IFSP-ESIGN and IFVP-ESIGN (for IFSSA)
42The choice among DL, EC and IF primitives affects security to the extent that the difficulties of the
43underlying problems differ (see D.4). From a practical perspective, the choice of primitive within a family
2 310
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1does not significantly affect security against general attacks, since solving the underlying problem is the
2best currently known general method for attacking the schemes provided that recommended additional
3methods are employed (although as discussed in D.4.3, the underlying problem for ESIGN is different than
4for RSA and RW). The security analysis may vary among the choices; also, certain specific attacks may be
5relevant for some choices but not for others.
6Security considerations related to the generation of one-time key pairs and other values in certain primitives
7are addressed in Notes 1–3 below.
8NOTES
91—Precomputation: The first step in each of DLSP-NR, DLSP-DSA, DLPSP-NR2/PV and their counterparts in the EC
10family is to generate a one-time key pair. Since this step does not depend on the message being signed, the key pair
11may be generated in advance of the availability of the message. FIPS PUB 186-2 [B56], Appendix 3.2, gives one
12precomputation method; additional discussion can be found in Naccache, M’Raïhi, and Vaudenay [NMV+95]. (But see
13Note 3 below for caveats about these methods — while the general principles are correct there is a bias in private key
14generation that should be avoided in the methods are used.) The values r, exp(r, e) mod n, and 1 / (e exp(r, e – 1))
15mod p in IFSP-ESIGN may be precomputed by similar means.
162—Signatures without a random or pseudorandom generator: If a random or pseudorandom generator is not available
17for generating the one-time key pair in an implementation of a DL or EC (pre-)signature primitive, an alternative is to
18apply a key derivation function to the signer’s private key and certain key derivation parameters to produce the one-
19time private key. For instance, the key derivation parameters could equal the message representative, in which case the
20same value and hence the same signature would be produced each time for the same message. In this case, the signature
21scheme would be deterministic, and as the one-time key pair would depend explicitly on the message, it could no
22longer be precomputed in advance of the availability of the message as suggested in Note 1 above. (It can also help in
23avoiding subliminal channels as discussed in D.5.2.) This method is analyzed in M’Raïhi et al. [MNP+98] (but see
24Note 3 below for a caveat; see also PKCS #5 v1.5 [PKCS-5-v1_5], Section 5, Note 5 for a similar method in the
25context of password-based cryptography).
26A counter could also be included in the key derivation parameters to avoid the determinism (see 10.4.2 for a situation
27where this is important). As another alternative, the key derivation parameters could depend on previous messages or
28message representatives, thereby facilitating precomputation of the one-time key pair before a message is available.
29As a clarification to the notes in 6.2.7 and elsewhere, which state that “a new key pair should be generated for every
30signature,” the actual security concern is that different key pairs should be generated for signatures on different
31message representatives. The same “one-time” key pair may be used for multiple signatures on the same message
32representative since in this case the signature operation is merely being repeated. The suggestion above that the one-
33time key pair be obtained deterministically from the message representative is consistent with this point, as the one-
34time key will be the same for the same message representative, and (with overwhelming probability) different for
35different message representatives. (Note that the same message may produce different message representatives if the
36encoding method is randomized, hence the suggested dependence of the one-time key pair on the message
37representative rather than the message itself.)
38(Similar remarks to the foregoing apply to the value r in IFSP-ESIGN and the salt value in EMSA4/EMSR3.)
393—One-time private key generation: The one-time private key u in the DL and EC primitives should be selected in an
40unbiased manner (i.e., randomly or pseudorandomly in the full interval [1, r-1]), as otherwise information about the
41signer’s private key s may be leaked by signature primitive. Following earlier work by Howgrave-Graham and Smart
42[HS01] and Nguyen [Ngu01], Shparlinski and Nguyen have shown [NS02a] that if an opponent can determine the three
43least significant bits of the one-time private key in each of about 100 DLSP-DSA signatures, the opponent can solve for
44the signer’s private key. They also give attacks for the case that other bits of the one-time private key are known. A
45similar attack applies to ECSP-DSA (since the signature equation is essentially the same after the one-time key pair is
46generated) and a related (though more complex) attack applies to the -NR (and hence -PV) primitives (see Nguyen and
47Shparlinski [NS02b] and El Mahassni, Nguyen and Shparlinski [ENS01]).
2 311
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Very recently, Bleichenbacher [Ble01] has given an even more effective attack that can recover the signer’s private key
2given only a slight bias in the distribution of one-time private keys, without actually knowing any bits of the one-time
3private keys. This attack is particularly significant in that methods suggested for generating one-time private keys in
4ANSI X9.30:1-1997 [B4] and FIPS PUB 186-2 [B56] as well as in the Naccache et al. and M’Raïhi et al. proposals
5above have exactly the kind of bias that Bleichenbacher’s attack exploits, as they directly use a hash function to
6generate a value in an interval slightly larger than the subgroup order r. Specifically, for a 160-bit value r, a one-time
7private key is produced by pseudorandomly generating a 160-bit string, converting it to an integer in the interval [0,
821601], and then reducing the integer modulo r. As a result the private key is biased toward the lower end of the
9interval [1, r1], which is sufficient to enable the attack.
10Bleichenbacher’s attack is currently infeasible as long as only on the order of 1,000,000 signatures are generated with a
11given private key. Hence, limiting the number of signatures is an interim solution to prevent the attack. To avoid the
12potential for further attacks, it is preferable to produce the one-time private keys in a different way. Two examples are
13the following:
14— Select from a larger interval before reducing. Generate a 2l-bit string where l = log2 r, convert it to an integer in
15the interval [0, 22l1], and then reduce it modulo r. Assuming the string is uniformly distributed, the private key will be
16nearly uniformly distributed. This method is attractive because it has a fixed running time.
17— Reselect rather than reducing. Generate an l-bit string where l = log2 r, convert it to an integer in the interval [0,
182l1], and if the integer isn’t between 1 and r1, select another one. Assuming the string is uniformly distributed, the
19private key will also be uniformly distributed. This method has a variable running time.
20Variations of these methods may also provide acceptable security, but methods with greater bias than the above ones
21should be carefully analyzed to ensure that the security is indeed acceptable. For instance, in the first method, the
22length of the string doesn’t have to be exactly 2l bits, just sufficiently longer than l bits to ensure a nearly uniform
23distribution after reduction. Specific countermeasures are given in FIPS PUB 186-2, Change Notice 1, and expected to
24be added to ANSI X9.30:1.
27The recommended encoding methods for signatures with appendix are EMSA1 (for DL/ECSSA) and
28EMSA2, EMSA3, EMSA4, and EMSA5 (for IFSSA; the recommendation varies depending on the
29underlying primitives).
30An encoding method for a signature scheme with appendix in this standard should have the following
31properties, stated informally:
32
33 It should be difficult to find a message with a given message representative (the one-way property).
34 It should be difficult to find two messages with the same representative (collision resistance).
35 The encoding method should have minimal mathematical structure that could interact with the
36 selected signature primitive (e.g., if the signature primitive is multiplicative, the encoding method
37 should not be).
38EMSA1 is considered to have these properties for DL/ECSSA, and EMSA2, EMSA3, EMSA4, and
39EMSA5 are considered to have these properties for IFSSA (with respect to the appropriate primitives).
40The security of all four encoding methods depends on the underlying hash function (see D.5.2.2.3). The
41security of EMSA4 depends on the underlying mask generation function (see D.5.2.2.4). Other
42considerations include:
2 312
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1
2 For EMSA1, the relationship between the maximum length of the message representative and the
3 output length of the underlying hash function (Note 1)
4 For EMSA4, the length and randomness of the salt value (Note 2)
5 Whether the message representative identifies the underlying hash function (Note 3)
6NOTES
71—Message representative length for EMSA1: For EMSA1, if the maximum length l of the message representative is
8less than the output length of the hash function, then EMSA1 will simply truncate the hash function output. Thus, for
9DL/ECSSA, if the length of the subgroup order r (and, hence, the maximum length of the message representative) is
10less than the length of the hash function output (e.g., 160 bits for SHA-1), the security of the encoding method will be
11limited by 2l and 2l/2, rather than 2160 and 280, respectively. In addition, for DLSP-DSA and ECSP-DSA, if the length of
12r is not greater than the length of the hash function output, then an opponent may pick r in such a way as to cause two
13different messages to have the same signature (see Vaudenay [B146]). This can be prevented by increasing the length
14of r beyond the length of the hash function output, or by auditing domain parameter generation (see Note 3 in D.4.1.4
15and Note 5 in D.4.2.4). It is customary for the length of r and the length of the hash function output to be approximately
16equal, so the message representative input to the signature primitive spans most or all of the range between 0 and r1.
17If the length of r is greater than the length of the hash value, then this condition will no longer hold, but this is not
18known to result in any security risk.
192—Salt length and randomness for EMSA4 and EMSR3: In the security analysis for the schemes, the ratio of
20complexity between forging signatures and inverting the underlying signature primitive depends on the length and
21randomness of the salt value. Roughly speaking, with a random salt that is as long as the hash output, the ratio
22approaches 1; with a fixed salt or with no salt, the ratio approaches 1/Q, where Q is the number of “queries” (chosen
23messages) involved in the attack. (See Coron [Cor00][Cor02] for a precise analysis in the context of the original PSS
24and Full-Domain-Hash (FDH) schemes.) Thus, even with no salt, the analysis suggests that signature forgery is about
251/Q times as difficult as inverting the verification primitive (this is a lower bound, so it may actually be more difficult).
26See D.6 for recommendations on random number generation.
273—Hash function identification: An encoding method may identify the hash function (and other options) within the
28message representative in order to prevent an opponent from tricking a verifier into operating with a different hash
29function than the signer intended — perhaps a weak hash function — in an attempt to forge a signature. The encoding
30methods vary with respect to this property (see Kaliski [Kal02] for further analysis):
31— EMSA1 does not identify the hash function, but in practice is typically combined with a single hash function, SHA-
321, which amounts to a key usage restriction and removes any risk of ambiguity.
33— EMSA2 and EMSA3 both identify the hash function and offer protection against hash function substitution.
34— EMSA4 includes the option of identifying the hash function, which protects against reuse of existing signatures with
35a different hash function. Even if the hash function is not identified, however, EMSA4 protects against hash function
36substitution (both for existing and new signatures) under reasonable assumptions. In particular, since the mask
37generation function is based on the hash function, EMSA4 protects against hash function substitution by making it
38difficult to obtain new message representatives with appropriate structure for any “natural” hash function. This is
39subject to the condition that a minimum amount of padding (e.g., 80 bits) is included in the message representative, so
40that even if the hash function underlying the mask generation function turns out to be weak, the opponent still will not
41be able to find a signature that yields the correct padding. In EMSA4, the minimum will typically be met as the hash
42output length is significantly shorter than the message representative length.
43The foregoing is based on the assumption that the hash function is a “natural” one, selected independently of the
44signer’s public key; it is certainly possible to “cook” a hash function so that the associated mask generation function
45correctly matches any amount of padding. But now the opponent would need to coerce the verifier into using this
46“cooked” hash function, a much less plausible scenario than tricking the verifier into using a “natural” hash function
47that happens to be weak.
2 313
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1One motivation for not identifying the hash function in EMSA4 is that the security analysis is affected by the number
2of bits of the message representative having fixed values. The fewer, the better, hence the attempt in EMSA4 to
3minimize the number of fixed values (compared to, say, the original ISO/IEC 9796-2:1997 format [ISO-9796-2]).
4Protection against hash function substitution may also be accomplished by other means. For instance, only a small
5number of well trusted hash functions might be accepted in a domain. Alternatively, key usage restrictions associated
6with the signer’s key (see D.3.5) could indicate the acceptable hash functions for that key. Hash function identification
7in signature schemes is an area of current study in ISO/IEC JTC1 SC27.
9The recommended encoding methods for signatures giving message recovery are EMSR1 (for DL/ECSSR),
10EMSR2 (for DL/ECSSR-PV), and EMSR3 (for IFSSR).
11An encoding method for a signature scheme giving message recovery in this standard should have the
12following properties:
13
14 It should produce message representatives from which a message (or recoverable message part) can
15 be easily and uniquely recovered (invertibility).
16 It should produce message representatives that have some verifiable structure, so that it is difficult,
17 without knowing the private key, to forge a signature from which a valid representative can be
18 recovered (redundancy).
19 The encoding method should have minimal mathematical structure that could interact with the
20 selected signature primitive.
21 EMSR1 is considered to have these properties for DL/ECSSR and EMSR3 is considered to have them for IFSSR. EMSR2
22 is considered to have these properties for DL/ECSSR-PV provided the agreed redundancy criteria and the parameter
23 padLen give a sufficient total amount of redundancy. (In general, the role of the encoding method in DL/ECSSR-PV is
24 different than the role of the encoding methods in the other signature schemes, and the required properties are
25 accordingly different. For instance, the third property is less important for EMSR2, since in DL/ECSSR-PV, the output of
26 the encoding method is processed with a hash function before it is input to the signature primitive.)
27The security of EMSR1 and EMSR3 depends on the underlying hash function (see D.5.2.2.3). The security
28of EMSR3 also depends on the underlying mask generation function (see D.5.2.2.4). Other considerations
29include:
30
31 For EMSR1, the redundancy lengths (Note 1)
32 For EMSR2, the method of combining the pre-signature with the padded message part (Note 2), the
33 amount of redundancy in the message representative (Note 3), and the encoding of the message
34 parts (Note 4)
35 For EMSR3, the length and randomness of the salt value (see D.5.2.2.1 Note 2)
36 Whether the message representative identifies the underlying hash function (Note 5)
37NOTES
381—Redundancy lengths for EMSR1: To maintain the security level of the underlying hash function in general, the long
39redundancy length for EMSR1 should equal the output length of the hash function plus the length of any hash function
40identifier. Since hash function collisions are not a concern in the case of total message recovery, the short redundancy
41length is recommended to be at least half the output length of the hash function if hash function identification is not
42desired. However, if hash function identification is desired, it should also equal the output length of the hash function
43plus the length of any hash function identifier.
2 314
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
12—Method of combining the pre-signature with the padded message part for EMSR2: If a symmetric encryption
2scheme is used to combine the pre-signature with the padded message part in EMSR2, then the security depends on the
3key size of the symmetric encryption scheme. For example if a symmetric encryption scheme with a 56-bit key size is
4used and (C, d) is a valid signature on a message with non-recoverable message part M2, then the probability that (C, d)
5will verify for a random d and any given M2 will be roughly 256. This probability of forgery may be too high.
6Similarly, if the key derivation function has a high probability of producing collisions when evaluated with a given
7padded message part and random pre-signatures, then security may be compromised. These concerns highlight the
8importance of selecting a sufficient key size and a good key derivation function such as the recommended key
9derivation function KDF2.
10The primary security attribute of the “combining method” for EMSR2 seems to be combining both inputs (pre-
11signature and padded message part) in a “reversible” way that is highly dependent on both inputs. The additional
12attributes of confidentiality protection required by symmetric encryption schemes and key derivation functions when
13used for encryption are not strictly necessary for EMSR2. Accordingly, a stream cipher based on a key derivation
14function may offer adequate security for EMSR2, even if the key derivation is not sufficiently strong for encryption in
15general. Nevertheless, the heuristic of “ideal randomness” in a strong symmetric encryption scheme with sufficient key
16size might offer better security than a stream cipher based on a key derivation function. Further details may be found in
17Brown and Johnson [BJ00].
183—Amount of redundancy in the message representative for EMSR2: The total amount of redundancy in the message
19representative for EMSR2 is at least 8 padLen + agreed bits, where agreed is the amount of redundancy in bits within
20the recoverable message part M1 ensured by the agreed redundancy criteria for the acceptance of a message by both
21parties. (Redundancy in the non-recoverable message part M2 does not affect the value of agreed.) Implementations
22should ensure that the total redundancy is at least at an acceptable level, which is generally half the length of the
23subgroup order r, or half the length of the hash function output. Implementations may reduce the amount of padding
24padLen to shorten the signature, provided the agreed value is high enough to make the total redundancy acceptable.
25The amount of padding in a symmetric encryption scheme underlying EMSR2 may also be considered in determining
26the total amount of redundancy.
274—Prefixes and redundancy for EMSR2: Suppose the redundancy criteria are such that a message representative C and
28one of its prefixes C’ both yield acceptable recoverable message parts for a given pre-signature I. Then it may be
29possible in DL/ECSSR-PV2 to forge a new signature involving C’ and a new M2’ from a genuine signature involving C
30and M2 by writing C = C’ || T and M2’ = T || M2. (Both cases will yield the same hash value H and hence the same pre-
31signature I for a given public key.)
32There are number of straightforward ways to address this concern. For instance, the redundancy criteria might specify
33that the recoverable message part has a fixed length, or that it begins with a fixed-length representation of its length.
34Another example of redundancy criteria that typically disallows such prefixes is the use of a DER encoding of an
35ASN.1 type. For the recommended options in EMSR2, these criteria ensure that the set of message representatives that
36yield acceptable recoverable message parts for a given pre-signature I is prefix-free (non-recommended options require
37further security analysis by the implementer).
38As alternative approaches, rather than adding to the necessary redundancy criteria for the message representative, one
39might address the concern by specifying that the non-recoverable message part has a fixed length (perhaps empty), or
40that it ends with a fixed-length representation of its length.
415—Hash function identification: Continuing the discussion in D.5.2.2.1 Note 3, the encoding methods vary with
42respect to hash function identification as follows:
43— EMSR1 includes the option of identifying the hash function, but the hash function identifier does not offer the full
44claimed protection against hash function substitution. The option is thus included for compatibility with ISO/IEC 9796-
453:2000 only.
46— EMSR2 does not identify the hash function and does not offer protection against hash function substitution.
2 315
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1— EMSR3 includes the option of identifying the hash function, which protects against reuse of existing signatures with
2a different hash function. Even if the hash function is not identified, however, protection against hash function
3substitution (both for existing and new signatures) may be obtained under similar conditions as with EMSA4. If there is
4a risk of ambiguity in the hash function, the recoverable part of the message should be somewhat shorter than the
5maximum length allowed so that there is sufficient padding (e.g., 80 bits). (This recommendation applies whether the
6hash function is identified or not.)
8The only recommended key derivation function for the signature schemes in this standard is KDF2, which
9is an option in EMSR2.
10As noted in D.5.1.2, a key derivation function for a key agreement scheme in this standard should produce
11keys that are computationally indistinguishable from randomly generated keys, and KDF2 is considered to
12have this property provided that the shared secret input string is sufficiently long. However, as stated in
13D.5.2.2.2 Note 2, this property is not strictly necessary for EMSR2.
15The recommended hash functions for the signature schemes in this standard are SHA-1, RIPEMD-160,
16SHA-256, SHA-384 and SHA-512, which are options in DL/ECSSR-PV and all of the encoding methods
17for signatures except EMSR2 (which does not invoke a hash function), as well as in KDF2 and MGF1.
18A hash function for a signature scheme in this standard should generally be collision-resistant; the
19recommended hash functions are considered to have this property (with respect to a level of difficulty that
20depends on the hash output length).
21Typical attacks for finding a message with a given representative based on hash function inversion involve
22on the order of 2l operations assuming an l-bit hash function; attacks for finding two messages with the
23same representative based on hash function collision involve 2 l/2 operations. However, the actual
24complexity and applicability of an attack is sometimes different. For instance, in the case of total message
25recovery for EMSR1 and EMSR3, collision resistance seems not to be required since even if two
26recoverable message parts have the same hash value, they will have different message representatives, so
27the signature on one recoverable message part cannot be used to recover the other. A collision-resistant
28hash function is nevertheless recommended as it is a prudent security choice; a different choice requires
29further security analysis by the implementer.
30Note that collision resistance does also not seem to be strictly necessary in the original PSS and PSS-R
31proposals (Bellare and Rogaway [B19]), since the message was hashed together with a random salt value.
32Since the message is hashed directly in EMSA4 and EMSR3, however, the collision resistance is again
33required.
34In addition to processing the message directly in EMSA4 and EMSR3, the hash function also instantiates a
35random oracle. As further discussed with respect to mask generation functions in D.5.2.2.5, no formal
36assumptions are known for hash functions that facilitate security analysis outside the random oracle model
37for these schemes. However, a collision-resistant hash function is a reasonable design approach for
38ensuring that specific attacks are implausible. For similar reasons, a collision-resistant (and robustly
39designed) hash function is recommended for constructing a mask generation function.
40Hash function properties use with a key derivation function are discussed in D.5.1.2.2.
2 316
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2The only recommended mask generation function for the signature schemes in this standard is MGF1,
3which is an option in EMSA4 and EMSR3.
4Reflecting the “random oracle” that it instantiates, the mask generation function should be pseudorandom:
5Given one part of the output but not the input, it should be infeasible to predict another part of the output.
6MGF1 is considered to have this property provided the octet string input is sufficiently long. However, it
7should be noted that no formal assumptions are known for mask generation functions that facilitate security
8analysis in the “standard model” (i.e., without random oracle assumptions) for the schemes based on
9EMSA4 and EMSR3. Moreover, security analysis in the random oracle model only addresses “generic” or
10“black-box” attacks, and does not assess whether attacks may exist for specific instantiations with an actual
11mask generation (or hash) function (see also Canetti, Goldreich, and Halevi [CGH98] for discussion).
12Nevertheless, pseudorandomess is a reasonable design approach to ensure that specific attacks are
13implausible.
14The security of MGF1 depends on the underlying hash function (see D.5.2.2.4). To defend against hash
15function substitution (D.5.2.2.2 Note 5), the underlying hash function for MGF1 should be the same as the
16selected hash function for the encoding method that invokes it.
18The recommended symmetric encryption scheme for the signature schemes in this standard are Triple-
19DES-CBC-IV0 and AES-CBC-IV0, which are options in EMSR2.
20As indicated in D.5.2.2.2 Note 2, not all of the attributes of a symmetric encryption scheme are strictly
21necessary for EMSR2; the goal is that the key and the message should be combined reversibly in a way that
22is highly dependent on both inputs. A sufficiently large key size — say, 80 bits or more — is recommended
23to minimize the probability that a random signature will verify. Triple-DES-CBC-IV0, with an effective
24key size (against brute-force search) of at least 112 bits, and AES-CBC-IV0, with at least 128 bits, are
25considered to provide the necessary properties for EMSR2 (though these are clearly not the only symmetric
26encryption schemes that may provide adequate security in this context).
27D.5.2.3 Repudiation
28Signature schemes have a special security concern, similar to that for handwritten signatures. Namely, a
29dishonest signer may be interested in using deliberately weak methods in order to produce a signature that
30is accepted, but later be able to claim that the signature was forged by someone else who “broke” the
31cryptosystem. This may allow the signer to later repudiate the signature. Since signers are often in some
32way liable for the statements they sign, this will allow a dishonest signer to avoid the liability. In fact, a
33dishonest signer may not be using weak methods, but merely be able to claim that the methods were weak,
34by claiming, for example, that the key was leaked or that the random number generator was weak.
35Systems in which this is a concern should consider what conditions may be accepted as a basis for
36repudiation, and then ensure that none of the conditions is present before accepting a signature. For
37example, if repudiation is possible on the basis that the key size was too small, systems should set policies
38by which signatures with keys under a certain size are not accepted. If repudiation is possible on the basis
39that a key was not authentic or invalid, systems should ensure authenticity and validity of keys and
40parameters (see Annex D.3.1, D.3.3, D.5.2.4 and D.5.2.5). If repudiation is possible on the basis that the
41implementation was insecure, implementation validation may be appropriate (see Annex D.7).
42Implementations may also ensure that users are not able to copy or view their own private keys, and thus
43cannot deliberately leak them to other parties (see also D.3.2 for more on key-sharing).
2 317
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1System-wide policies may also help address this concern. For example, if signers generate their own keys,
2a system may choose to prohibit repudiation on the basis that a key was invalid, reasoning that honest
3signers should not generate invalid keys in the first place. They may also choose to prohibit any
4repudiation as long as public keys are securely associated with the signers, by asserting that it is the
5signers’ responsibility to ensure that their keys are secure. In the latter case, a signer has a motivation to
6perform key validation after key generation, if there is any risk that the keys were not generated correctly
7(e.g., an error occurred).
8When performing security analysis of a system that uses signatures, one needs to take into consideration
9not only adversaries whose goal it is to forge signatures, but also adversaries whose goal it is to repudiate
10them.
12If it is desired to verify that a particular party has the ability to generate a given signature (for example, to
13prevent future repudiation of the signature by the party—see Annex D.5.2.3), then the party’s ownership of
14the public key with which the signature is verified should be authenticated. In general, as noted in D.3.1,
15the party’s possession of the corresponding private key should also be authenticated. The risk of not doing
16so is that an opponent may present a public key that is identical or related to some other party’s public key,
17to make it appear as though a message was signed by the opponent, when in fact it was signed by the other
18party. Note, of course, that the opponent can always sign any message it knows with its own key. Thus,
19this risk is of concern in the following two cases:
20
21 the signature is stored in such a way that it cannot be modified by the opponent, and the opponent is
22 trying to show that it generated the signature
23 a portion of the message is secret, and the verifier is relying on the signature as assurance that the
24 purported signer knows the secret. (Note that the use of signature schemes for verification of
25 knowledge of secrets is not discussed in this standard, because such verification is usually
26 accomplished by a protocol, rather than by a scheme [protocols and schemes are discussed in
27 Section 4]. Such use requires additional security analysis by the implementer.)
28If the message on which the signature is computed includes the signer's name, an opponent cannot make it
29appear as though the opponent is the actual signer, because the opponent's name is different. (This is
30essentially how a signature-based proof of possession protocol works.)
32As discussed in D.3.3, using invalid keys or domain parameters as inputs to a primitive carries with it
33certain risks. Specifically, for the signature schemes, the risks are outlined below. Note that the risks will
34vary with the particular implementation:
35
36 failure of the implementation, resulting in an error state
37 potential signature forgery
38 repudiation of signatures based on the argument that the key is invalid and, hence, insecure
39The risk of implementation failure can be addressed by appropriate implementation handling of error cases,
40or by ensuring the validity of the domain parameters and public keys as described in D.3.3.
2 318
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The risk of signature forgery can be mitigated by ensuring the validity of the parameters and keys.
2However, validation does not address certain other risks. A key may be valid and still be insecure (for
3example, if the random number generation for the key generation was performed improperly, or if the
4private key is stored insecurely or deliberately disclosed). Therefore, an implementer should consider other
5ways in which the key may be insecure, and then decide how to appropriately mitigate the risk. FIPS 140-1
6implementation validation and random number generation are typical ways to address some of these
7concerns (see D.6.1 and D.7). Public key and parameter validation will ensure that no invalid public keys
8and parameters are used to verify a signature.
9The risk of repudiation and ways to address it are described in more detail in D.5.2.3.
11In a signature scheme, if an opponent learns a signer’s private key, the opponent can generate new
12signatures that can be verified with the corresponding public key. The longer the cryptoperiod of a private
13key in a signature scheme, the more data is available to a cryptanalyst. The longer the private key is not
14erased, the longer it is potentially vulnerable to physical compromise. However, if the private key is erased
15and its owner needs to repudiate a signature that was forged by an opponent, the private key is not available
16as evidence (the owner may need to use the private key to show, for example, that the private key was
17somehow weak and therefore forgery was possible).
18If a verifier requires a secure timestamp [MOV96, Section 13.8.1] on signed messages and only accepts
19signatures that have timestamps prior to a certain date, then the opponent is limited to generating new
20signatures before that date. Hence, if secure time-stamps are used, the protection lifetime of the private key
21can be limited by a specific date, provided that the date is securely associated with the corresponding public
22key (see Annex D.3.6). Note, however, that secure timestamping is more than just a date field added by the
23signer. The existence of the signature on the message at the claimed date must be independently confirmed
24by the verifier or by a third party.
26Encryption schemes are generally used to provide confidentiality of data. A theoretical definition of
27“semantic security” (or, equivalently, “indistinguishability” or “polynomial security”) is commonly used as
28the basis for the meaning of “confidentiality” (see Goldwasser and Micali [B61], Section 8.7 of Menezes,
29van Oorschot, and Vanstone [B112], Micali, Rackoff, and Sloan [B114], and Yao [B151]). Semantic
30security provides that it should be computationally infeasible to recover any information about the plaintext
31(except its length) from the ciphertext without knowing the private key. This implies, in particular, that it
32should also be infeasible to find out whether two ciphertexts correspond to the same, or in some way
33related, plaintexts, or whether a given ciphertext is an encryption of a given plaintext. The encryption
34schemes in this standard are believed to provide semantic security against an adaptive chosen ciphertext
35attack (an attack in which the opponent requests decryptions of specially chosen ciphertexts in order to be
36able to decrypt other ciphertexts) when the appropriate scheme options are selected.
37The encryption schemes in this standard are constructed in two different ways. DL/ECIES is built from a
38secret value derivation primitive, a key derivation function, and a message authentication code; IFES and
39IFES-EPOC are built from a pair of encryption and decryption primitives, and an encoding method for
40encryption. All the encryption schemes support encoding parameters. DL/ECIES also supports key
41derivation parameters. Accordingly, some of the discussion below applies only to DL/ECIES, and some
42only to IFES and IFES-EPOC.
43For more on relations among notions of security and modes of attack for encryption schemes, see
44[BDPR98].
2 319
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1NOTES
21—DL/ECIES differs from the original Abdalla-Bellare-Rogaway DHAES submission [ABR98] in that it offers the
3choice of whether or not to include a representation of the sender’s public key v as an input to the key derivation
4function (DHAES mode vs. non-DHAES mode). If a representation of the public key is not included, the scheme is
5malleable in the formal sense that an opponent can replace a ciphertext (V, C, T) with a different ciphertext (V', C, T)
6that yields the same message M, for any V' such that SVDP (s, v) = SVDP (s, v') where SVDP is the selected secret
7value derivation primitive and v and v' are the public keys corresponding to the representations V and V'. (If a scheme is
8malleable, then formally it is not secure against an adaptively chosen ciphertext attack.) For instance, when SVDP
9includes cofactor multiplication, a component outside the subgroup can be added to v without affecting the output of
10SVDP (except for elliptic curve groups with a prime number of points, which have no components outside the
11subgroup). In addition, for elliptic curve groups, v can be inverted without affecting the output of SVDP, regardless of
12whether SVDP includes cofactor multiplication. Shoup has also observed in his write-up assessing encryption schemes
13for the ISO 18033 project (see Shoup [Sho01b], Section 15.6.1) that leaving out the sender’s public key also appears to
14weaken the security analysis of the scheme.
15More generally, in non-DHAES mode, the representation of the sender’s public key in the ciphertext can be changed
16(e.g., compressed vs. uncompressed points) without affecting the output of SVDP. This raises primarily theoretical
17concerns since the resulting message is the same. Indeed, every encryption scheme might be malleable in this
18theoretical sense because of non-unique representations of the ciphertext commonly used in transmission (as is the case
19with BER encoding). If assurance of the exact representation of a ciphertext is essential, other authentication methods,
20especially those using a private key of the sender, should be considered.
21Non-DHAES mode is included for compatibility with related standards efforts. The original motivation for leaving out
22the sender’s public key in those standards efforts was to reduce the size of the input to KDF and thereby reduce
23processing time, although one can argue that the processing time for KDF is likely to be small in general compared to
24the time to generate a key pair and to apply the secret value derivation primitive. However, where it is practical to do
25so, the sender should include a representation of the public key as an input to the key derivation function for increased
26assurance. DHAES mode does this automatically. In non-DHAES mode, this can be done by “defining” the key
27derivation parameters so that they include the public key. In either case, if the sender’s public key is included, the
28sender and recipient both have to be able to process whatever representation is selected for the public key when it is
29input to the KDF (e.g., compressed vs. uncompressed points, as above).
30As Shoup has also shown ([Sho01b], Section 15.6.4), the message length in non-DHAES mode with the stream cipher
31option should be fixed for a given public key, because otherwise the encryption scheme is malleable due to the
32incorrect ordering of the encryption and MAC keys (K1 and K2 in the scheme). In DHAES mode the ordering is
33corrected so this is not an issue.
342—In general, a recipient’s public key should be used for only one set of scheme options to prevent undesirable
35interactions between different options. As an example of such interactions, if a recipient’s public key in DL/ECIES
36may be used either in combination with a stream cipher based on a key derivation function and in combination with a
37symmetric encryption scheme, it may be possible for an opponent to transform a ciphertext generated with the
38symmetric encryption scheme into that appears to have been generated with the stream cipher and that corresponds to a
39different message. One way to avoid this interaction if both options are supported is to include an indication of which
40option is selected in the key derivation parameters.
413—The specific choice of primitives for converting elliptic curve points to and from octet strings is not known to affect
42security. However, to avoid any potential for attacks based on “collisions” between different primitives (i.e., where the
43same octet string corresponds to different points in different representations), it is beneficial if the sets of octet strings
44for different representations are non-overlapping (except perhaps at the point at infinity). This is the case for the
45various primitives specified in 5.5.6.
46D.5.3.1 Primitives
47Secret value derivation primitive choices for DL/ECIES include the following:
48
49 DLSVDP-DH
2 320
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 DLSVDP-DHC
2 ECSVDP-DH
3 ECSVDP-DHC
4Encryption and decryption primitive choices for IFES and IFES-EPOC include the following pairs:
5
6 IFEP-RSA and IFDP-RSA (for IFES)
7 IFEP-OU and IFDP-OU (for IFES-EPOC)
8The choice among DL, EC and IF primitives affects security to the extent that the difficulties of the
9underlying problems differ (see D.4). From a practical perspective, the choice of primitive within a family
10does not significantly affect security against general attacks, since solving the underlying problem is the
11best currently known general method for attacking the schemes provided that recommended additional
12methods are employed (although as discussed in D.4.3, the underlying problem for OU is different than for
13RSA). The choice of -DH vs. -DHC affects security with respect to key validation (see D.5.1.6). The
14security analysis may vary among the choices; also, certain specific attacks may be relevant for some
15choices but not for others.
18The recommended encoding methods for encryption are EME1 (for IFES) and EME2 and EME3 (for IFES-
19EPOC). DL/ECIES does not use an encoding method.
20An encoding method for IFES should have the following properties, stated informally:
21
22 Representatives of different messages should be unrelated.
23 The encoding method, through incorporation of randomness or otherwise, should ensure that
24 representatives of the same message produced at different times are unrelated, and that it is difficult
25 to determine (without the private key), given a ciphertext and a plaintext, whether the ciphertext is
26 an encryption of the plaintext.
27 Message representatives should have some verifiable structure, so that it is difficult to produce a
28 ciphertext that decrypts to a valid message representative.
29 The encoding method should have minimal mathematical structure that could interact with the
30 encryption primitive (e.g., the encoding method should not be multiplicative, because IFEP-RSA
31 is).
32EME1 is considered to have these properties for IFES (one motivation for using EME1 as opposed to other
33encoding methods is a result by Bleichenbacher [B23]). (See Note 1 for recent results on the security of
34EME1.)
35An encoding method for IFES-EPOC (which produces a randomizer as well as a message representative)
36should have the same properties except for the third (“verifiable structure”), which is provided directly by
37the encryption and decryption primitives in IFES-EPOC. It should also ensure that the randomizer is
38unpredictable.
2 321
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1The three encoding methods also have the additional property of securely associating optional encoding
2parameters with a message, where the encoding parameters are not encrypted but are protected from
3modification; see D.5.3.3.
4The security of the three encoding methods depends on the underlying hash function (see D.5.2.3.3) and on
5the length and randomness of the seed (Note 2). The security of EME3 also depends on the method for
6combining the seed with the message (Note 3).
7NOTES
81—EME1 security: Bellare and Rogaway’s original paper on Optimal Asymmetric Encryption Padding (OAEP) [B18]
9introduced and gave a security analysis for an encryption scheme based on a predecessor to the EME1 encoding
10method and an arbitrary trapdoor one-way function f. The security analysis in the paper is easily seen to address so-
11called “indifferent” or “lunch-time” chosen-ciphertext attacks in the random oracle model. However, their paper did not
12contain a rigorous security analysis for the stronger class of adaptive chosen-ciphertext attacks. Two recent results have
13filled this gap. First, Shoup [Sho01a] has given evidence that a generic security reduction cannot be obtained in this
14sense for an arbitrary f (although it is possible to obtain one if the encoding method is modified slightly). Second,
15Fujisaki et al. [FOP01] have given a security analysis for adaptive chosen ciphertext attacks when f is the RSA
16function. This analysis applies to the EME1 encoding method as well.
17An attacker cannot gain any information from an implementation of IFES decryption by observing whether a ciphertext
18results in an error message, because of the “plaintext awareness” of OAEP. (Informally, the attacker needs to “know”
19the plaintext in order to construct a valid ciphertext, so the attacker will already know whether a ciphertext will result in
20an error message.) However, it is important that the implementation output the same error message at the same time
21regardless of the cause of error. In particular, an implementation should not reveal whether the error is due to the
22message representative being too long (that is, longer than l/8 octets) in the EME1 decoding operation. Otherwise an
23opponent will be able to determine whether the most significant octet of an RSA decryption is nonzero, which may lead
24to an attack (see Manger [Man01]).
252—EME2 security: A security analysis for the IFES-EPOC encryption scheme based on the EME2 encoding method
26against adaptive chosen-ciphertext attacks has been presented in the random oracle model under the p-subgroup
27assumption. This assumption is, stated roughly, that is difficult to distinguish exp(v, r0) mod n and u exp(v, r1) mod n,
28where r0 and r1 are uniformly and independently selected, and n, u and v are as in 8.1.3.3.
29The security analysis for IFES-EPOC combines two other analyses: the semantic security of the IFEP-OU primitive
30(under the p-subgroup assumption) given in [OU98], and the security of the EME2 encoding method against adaptive
31chosen-ciphertext attacks (in the random oracle model) given in [FO99a].
32Let (u/n) be the Jacobi symbol of u over n. If (u/n) = 1 and (v/n) = 1, the p-subgroup assumption is not true. To avoid
33such a vulnerability, it is recommended that (u/n) = (v/n). This is achieved if the value v = un mod n, i.e., v0 = u and v =
34v0n mod n as noted in 8.1.3.3.
35For high assurance of the p-subgroup assumption, the length in bits, rBits, of the randomized hash value should be 2k+c
36for a positive constant c (e.g., c = 32) where k is the length of the prime factors of the OU modulus n.
373—EME3 security: A security analysis for the IFES-EPOC encryption scheme based on the EME3 encoding method
38has been presented in the random oracle model, under the assumption that factoring is difficult for moduli of the form
39p2q. For the case that rBits = log2 n1 where rBits is the length in bits of the randomized hash value (this is the
40maximum length since the randomized hash value must be less than the OU modulus n), the security analysis combines
41two other analyses: the one-wayness of the IFEP-OU primitive (under the factoring assumption) given in [OU98], and
42the security of the EME3 encoding method against adaptive chosen-ciphertext attacks (in the random oracle model)
43given in [FO99b].
44The case that rBits = 2k+c for a positive constant c (e.g., c = 32), is analyzed in [NTT01]. In the analysis, a typical case
45of v such as v = exp(u, n) mod n is adopted for simplicity.
464—Seed length and randomness: The security of the three encoding methods depends on the unpredictability of the
47seed.
2 322
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1— For EME1, the seed length equals the length of the hash function output, and the seed value is generated at random.
2This makes it unlikely both that the seed value can be predicted and that the same seed value will be selected more than
3once. (If a seed value is selected twice for the same message, for instance, then an opponent will be able to determine
4that the resulting ciphertexts are for the same message.)
5— For EME2, the seed length is recommended to be equal to the hash function output length and the seed value is
6generated at random for similar reasons.
7— For EME3, the seed length is based on the message representative length, which is in turn related to the length of
8prime factor p in the OU private key. For the recommended sizes, the seed length will be at least as long as the hash
9function output length. The seed value is again generated at random. Random generation of a sufficiently long seed is
10particularly important in EME3 because the message is encrypted with a symmetric key derived from the seed value.
11An adequate security level may also be obtained for these encoding methods if the seed length is shorter (for EME2,
12where the length is an option), or is not generated entirely at random, but such choices require further security analysis
13by the implementer.
145—Method for combining the seed with the message in EME3: Except for relatively short messages (such as symmetric
15keys), the method for combining the seed with the message in EME3 should be a key derivation function combined
16with a symmetric encryption scheme. A stream cipher based on a key derivation function is not recommended other
17than for such relatively short messages because the design goal of a key derivation function is to produce
18correspondingly short keys, not to generate an arbitrarily long keystream; further security analysis is needed if a key
19derivation is employed as a stream cipher to encrypt messages of arbitrary length. See D.5.3.2.2 and D.5.2.3.5 for
20security considerations related to key derivation functions and symmetric encryption schemes respectively.
2 323
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2The only recommended key derivation function the encryption schemes in this standard is KDF2, which is
3an option in EME3 and DL/ECIES.
4The security considerations are the same as in the case of key agreement schemes (see D.5.2.2.2). As
5indicated in D.5.3.2.1 Note 5, a key derivation function is recommended for use as a stream cipher in
6EME3 only to encrypt relatively short messages. Similar considerations apply to the stream cipher option in
7DL/ECIES, and furthermore, as explained in D.5.3 Note 1, the messages should be fixed-length for the
8stream cipher option in non-DHAES mode. For arbitrary length messages, the key derivation function
9should be used to generate a symmetric key for a symmetric encryption scheme, and the message encrypted
10with the symmetric encryption scheme.
12The recommended hash functions for the encryption schemes in this standard are SHA-1, RIPEMD-160,
13SHA-256, SHA-384 and SHA-512, which are options in all three encoding methods for encryption, as well
14as in KDF2, MGF1 and MAC1, which are used in some of the encryption schemes and encoding methods.
15For EME1, collision-resistance is needed if the encoding parameters are a consideration, since they are
16hashed directly. For EME2 or EME3, this property is not strictly necessary since the message and encoding
17parameters are hashed together with a random seed, but as noted below, since the hash function instantiates
18a random oracle, the property is needed for the security analysis.
19The properties assumed of a hash function for MAC1 are that it should be difficult to find collisions when
20the hash function’s initialization vector is random and secret, and that it should be difficult to determine the
21output of the underlying compression function when the initialization vector is random and secret (see
22Bellare, Canetti, and Krawczyk [BCK96]). The first property is weaker than collision resistance, and the
23second has to do with the “pseudorandomness” of the hash function. The recommended hash functions are
24considered to have these properties.
25A hash function instantiates a random oracle in EME1, EME2 and EME3. As further discussed in D.5.2.2.4
26and D.5.2.2.5, no formal properties for hash functions are available that facilitate security analysis outside
27the random oracle model, but a collision-resistant hash function is a reasonable design approach. For
28similar reasons, a collision-resistant (and robustly designed) hash function is recommended for constructing
29a mask generation function.
30Hash function properties for use with a key derivation function are discussed in D.5.1.2.2.
32The only recommended mask generation function for the encryption schemes in this standard is MGF1,
33which is an option in EME1. The security considerations are similar to those in the case of signature
34schemes; see D.5.2.2.5.
36The only recommended message authentication code for the encryption schemes in this standard is MAC1,
37which is an option in DL/ECIES.
2 324
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1A message authentication code for an encryption scheme in this standard should produce authentication
2tags that are computationally infeasible to generate without the MAC key. MAC1 is considered to have this
3property, provided that the MAC key and tag are sufficiently long (e.g., each 80 bits or longer). Typical
4attacks for forging MAC1 authentication tags involve on the order of 2 l operations assuming an l-bit MAC
5key and an l-bit tag. See Bellare, Canetti, and Krawczyk [BCK96] for further discussion.
6The security of MAC1 depends on the underlying hash function (see D.5.3.2.3).
8The recommended symmetric encryption scheme for the encryption schemes in this standard are Triple-
9DES-CBC-IV0 and AES-CBC-IV0, which are options in DL/ECIES and EME3.
10The primary attribute of a symmetric encryption scheme for DL/ECIES and EME3 is confidentiality with a
11one-time key: it should be difficult, given the encrypted message and some information about the message
12but not the symmetric encryption key, to determine other information about the message. Integrity
13protection is not strictly necessary since it is otherwise provided by DL/ECIES and EME3. In addition,
14provided the encryption key in these DL/ECIES and EME3 is a one-time key as recommended, the same
15message will be encrypted differently at different times, so no randomization is required in the symmetric
16encryption scheme.
17A sufficiently large key size — say, 80 bits or more — is recommended to ensure that brute-force key
18search is difficult. Triple-DES-CBC-IV0, with an effective key size of at least 112 bits, and AES-CBC-IV0,
19with at least 128 bits, are considered to provide the necessary properties for DL/ECIES and EME3. (Both
20schemes are deterministic.) (As also noted in D.5.2.2.6, these are clearly not the only symmetric encryption
21schemes that may provide adequate security in this context.)
22The recommended schemes both allow larger key sizes, which should be considered in applications with
23higher security requirements (in the case of AES-CBC-IV0, the higher key size involves increased
24computational effort as well, so there is a tradeoff, but for relatively small messages this is not likely to be
25an issue).
27The purpose of encoding parameters in an encryption scheme is to associate control information with a
28message. The parameters should have an unambiguous interpretation. Their content depends on the
29implementation, and they may be omitted (i.e., the parameters may be an empty string). The parameters are
30not encrypted by the encryption scheme, but are securely associated with the ciphertext and protected from
31modification. Whether they have been modified or not is verified during the decryption process. For
32information on the encoding parameters, see Johnson and Matyas [B86].
33As indicated in 11.3.1, any parameters to the symmetric encryption scheme underlying DL/ECIES, such as
34a variable initialization vector, should be included in the encoding parameters to ensure their integrity, if
35they are not included in the encrypted message C itself.
36In the non-DHAES mode of DL/ECIES, consideration should be given to the possibility that the encoding
37of the input to the MAC, i.e., C || P2, is ambiguous and may correspond to some other pair C’, P2’ where C
38|| P2 = C’ || P2’ (which could make the encryption scheme malleable in a practical sense). There are several
39straightforward ways to address this concern. For instance, the encoding parameters P2 might be established
40in an authentic manner independent of the transmission of C. One might also specify that the encoding
41parameters have a fixed length (perhaps empty), or end with a fixed-length representation of the length of
42the encoding parameters, or alternatively provide a prefix-free encoding of the message M (see D.5.2.2.2
2 325
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1Note 4 for related discussion in another context). In the DHAES mode of DL/ECIES, a fixed-length
2representation of the encoding parameters is appended, thereby addressing the concern.
3Similar to their purpose for key agreement schemes (see D.5.1.4), the key derivation parameters for
4DL/ECIES influence the selection of the shared secret key. If the sender’s key pair is used for additional
5encryption operations with the same recipient, the key derivation parameters P1 should vary among the
6operations so that the key K varies, as observed in the note to 11.3.2. The parameters may be the empty
7string if the sender’s key pair is used for only one encryption operation.
8As noted in D.5.3, it may be beneficial to include a representation of the sender’s public key v in the input
9to the key derivation function, e.g., as part of the key derivation parameters.
10For EME1, EME2 and EME3 and for DL/ECIES, the length of the encoding parameters can vary from one
11encryption operation to another. For DL/ECIES, the length of the key derivation parameters can also vary.
13If it is desired to verify that a particular party has the ability to decrypt a given ciphertext, the party’s
14ownership of the public key with which the ciphertext is produced should be authenticated.
16As discussed in D.3.3, using invalid keys as inputs to a primitive carries with it certain risks. Specifically,
17for the encryption schemes, the risks are outlined below. Note that the risks will vary with the particular
18implementation:
19
20 failure of the implementation, resulting in an error state
21 loss of confidentiality of the data
22The risk of implementation failure can be addressed by appropriate implementation handling of error cases,
23or by ensuring the validity of the domain parameters and public keys as described in D.3.3.
24The risk of loss of confidentiality can be mitigated by ensuring the validity of the parameters and keys.
25However, validation does not address certain other risks. A key may be valid and still be insecure (for
26example, if the random number generation for the key generation was performed improperly, or if the
27private key is stored insecurely or deliberately disclosed). Even if the key is secure, the recipient may
28(because of insecure implementation or deliberately) leak the content of the message. Therefore, an
29implementer should consider other ways in which the key or the message content may be insecure, and then
30decide how to appropriately mitigate the risk. FIPS 140-1 implementation validation and random number
31generation are typical ways to address some of these concerns (see D.6.1 and D.7). Public key validation
32will ensure that no messages are encrypted with invalid keys. Indeed, public key validation is one of the
33precautions a message sender may apply directly, whereas the other countermeasures mentioned here
34require the sender to rely on representations by another party, e.g., that the implementation is secure.
35For the DL/EC encryption schemes, there are additional risks similar to those for the DL/EC key agreement
36schemes (see D.5.1.6), since the encryption schemes are essentially applications of the key agreement
37schemes. The additional risks include:
38
39 Reduction in size of the key space for derived keys
2 326
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1 Compromise of information about a private key that is combined with the invalid public key in a
2 secret value derivation primitive
3The first risk applies to both the sender and the recipient (although the opponent’s ability to exploit a
4reduced key space may vary depending on which party is attacked). The second risk applies primarily to
5the recipient’s private key, since it is typically involved in many encryption operations, but it would also
6apply to the sender’s private key if the sender’s private key is involved in more than one encryption
7operation as suggested in the notes to 11.3.2.
10In an encryption scheme, if an opponent learns a recipient’s private key, then the opponent can recover all
11messages encrypted with the corresponding public key. The longer the cryptoperiod of a public key in an
12encryption scheme, the more messages are potentially vulnerable to recovery. The longer the private key is
13not erased, the longer it is potentially vulnerable to physical compromise. However, once the private key is
14erased, no data encrypted with the corresponding public key can be decrypted.
15The protection lifetime in an encryption scheme should be determined by how long the data encrypted with
16the public key remains sensitive.
19This different approach provides higher security assurance because the input to the underlying
20RSA operation is random and independent of the message, and the key-encrypting key KEK is
21derived from it in a strong way. As a result, the algorithm enjoys a "tight" security proof in the
22random oracle model. It is also architecturally convenient because the public-key operations are
23separate from the symmetric operations on the keying data.
24
25The security of the IFKEM-RSA Key Transport Algorithm described in this document can be shown to be
26tightly related to the difficulty of either solving the RSA problem or breaking the underlying symmetric
27key-wrapping scheme, if the underlying key derivation function is modeled as a random oracle, and
28assuming that the symmetric key-wrapping scheme satisfies the properties of a data encapsulation
29mechanism [SHOUP]. While in practice a random-oracle result does not provide an actual security proof
30for any particular key derivation function, the result does provide assurance that the general construction is
31reasonable; a key derivation function would need to be particularly weak to lead to an attack that is not
32possible in the random oracle model.
33
34The RSA key size and the underlying components should be selected consistent with the desired
35symmetric security level for an application.
36
37Implementations MUST protect the RSA private key and the content-encryption key. Compromise of the
38RSA private key may result in the disclosure of all messages protected with that key. Compromise of the
39content-encryption key may result in disclosure of the associated encrypted content.
2 327
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
4The security of the algorithm also depends on the strength of the random number generator, which
5SHOULD have a comparable security level. For further discussion on random number generation, please
6see [RANDOM].
8Implementations SHOULD NOT reveal information about intermediate values or calculations, whether by
9timing or other "side channels", or otherwise an opponent may be able to determine information about the
10keying data and/or the recipient's private key. Although not all intermediate information may be useful to
11an opponent, it is preferable to conceal as much information as is practical, unless analysis specifically
12indicates that the information would not be useful.
13
14Generally, good cryptographic practice employs a given RSA key pair in only one scheme. This practice
15avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be
16essential to maintain provable security. While RSA public keys have often been employed for multiple
17purposes such as key transport and digital signature without any known bad interactions, for increased
18security assurance, such combined use of an RSA key pair is NOT RECOMMENDED in the future (unless
19the different schemes are specifically designed to be used together).
20
21Accordingly, an RSA key pair used for the IFKEM-RSA Key Transport Algorithm SHOULD NOT also be
22used for digital signatures. (Indeed, ASC X9 requires such a separation between key establishment key
23pairs and digital signature key pairs.) Continuing this principle of key separation, a key pair used for the
24IFKEM-RSA Key Transport Algorithm SHOULD NOT be used with other key establishment schemes, or
25for data encryption, or with more than one set of underlying algorithm components.
26
27Parties MAY formalize the assurance that one another's implementations are correct through
28implementation validation, e.g. NIST's Cryptographic Module Validation Program (CMVP).
29
30
36
2 328
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
7 IEEE, 2004.
12
16
21
24 February 2003.
25
28 December 1994.
2 329
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
6Key agreement schemes are generally used to provide assurance that nobody but the two legitimate parties
7involved in the protocol can compute the shared secret key. Note that a basic key agreement scheme does
8not provide assurances that the parties are correct about each other’s identities, or that both parties can
9actually compute their shared secret keys. Key confirmation (see Annex D.5.1.3) is often used to provide
10such additional assurances.
11In addition, key agreement schemes are sometimes used to provide forward secrecy. See Annex D.5.1.7 for
12more on forward secrecy and how the key agreement schemes in this standard can provide it.
13The application of key agreement schemes in a key establishment protocol is a particularly challenging
14task, as illustrated by the various attacks on key agreement protocols that have been observed over the
15years. Apparently slight changes, such as the ordering of messages, may well introduce unintended security
16weaknesses. Conversely, slight differences may yield security benefits. For instance, requiring each party to
17commit to its short-term key by sending a hash of the short-term key, prior to exchanging the short-term
18keys, can remove some potential for an opponent to manipulate a protocol. Although the recommendations
19in this clause cover many of the general principles of key agreement, the implementer is encouraged to
20consult recent literature on key agreement protocols for further information.
30This clause describes some of the security concerns related to generating random bit strings. A more
31detailed exposition is given in [MOV96, Chapter 5]; the reader desiring to learn more is referred to that
32chapter. ISO and ANSI have recently started studying random number generation (the ANSI X9F1
33working group has a work item numbered X9.82; in the ISO, ISO/IEC JTC1 SC 27 WG 2 is studying the
34issue); the reader may find the future results of this work useful.
35Random strings in cryptography are commonly generated by the following method: collect enough data
36from a random source to get a seed for a pseudo-random bit generator, and then use the pseudo-random bit
37generator to get the string of the desired length. The two clauses below address both steps of this two-step
38process.
2 330
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2An opponent can be assumed to have full knowledge of the pseudo-random bit generator (see Annex D.2),
3except for its seed input. The random seed is thus the only component of the random number generation
4process that the opponent may not know. Therefore, implementers should ensure that the seed is collected
5from a source that has sufficient variability and cannot be accessed, guessed, or influenced in a predictable
6way by the opponent. In short, the seed should be unpredictable. If the result of the random number
7generation process is to be kept secret, the seed should be kept secret as well.
8Ideally, each bit produced by the random source should be evenly distributed and independent of all the
9other bits. In such a case, there are 2n equally probable random seeds of length n, and the opponent has no
10advantage in guessing the seed. However, in reality, this is often not the case. As random sources usually
11have biased and correlated bits, opponents often have a better chance of guessing the seed of length n than
121 in 2n. When evaluating a random source, it is essential to establish that an opponent with appropriately
13large computational resources and full knowledge of the nature of the random source has a negligible
14probability of guessing a seed output by the random source. Note that the opponent should be considered
15to have as many attempts at guessing as the opponent’s potential computational resources would allow.
16Informally, variability of a random source is measured in bits of randomness (also called “bits of
17variability”) per bits of output. For example, if a random source is said to have variability of “one bit per
18byte,” this generally means that there are about 2 k different strings of more-or-less equal probability of
19length 8k bits. This, in order to get about 160 bits of randomness from such a source, one needs 1280 bits
20of data.
21If the random bits are biased or correlated, it is common to run them through a cryptographic hash function
22in order to “distill” the randomness. This method relies on the assumption that the cryptographic hash
23function will produce a distribution on the outputs that is reasonably close to uniform, because the hash
24function is not correlated to the biases of the random source. In the example above, the 1280 bits of data
25could be given as an input to, for example, SHA-1 to come up with a 160-bit output that has (presumably)
26about 160 bits of randomness. Note that the hash function output should not be longer that the number of
27bits of randomness believed to be provided by the data.
28If the random seed needs to be kept secret, it is essential that the source of the random data be protected
29from eavesdropping. For example, if one is using the timing of a user’s keystrokes as the source of the
30random data, it is important that the keystrokes cannot be observed by the opponent through, for example, a
31hidden camera installed in the room.
32Whether or not the seed needs to be kept secret, it is also essential that the source of random data be
33protected from manipulation by the opponent. For example, if system loads or network statistics are used
34for random data, the opponent having access to the system or the network may be able to manipulate them
35in order to reduce their variability, even if not able to observe them directly.
36A common precaution is to combine many available sources of randomness and to use a hash function, as
37described above, in order to “mix” them. If, for example, one collects enough data for 160 bits of
38variability each from three different sources, then even if two of the sources fail, the remaining source will
39provide about 160 bits of variability in the hash function output. It is generally safer to collect more data
40rather than less data from each of the sources, even if only a short seed is needed.
42
43 photon polarization detected at 45o out of phase
44 elapsed time between emissions of particles from a radioactive source
2 331
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
28The quality of a particular source of randomness for generating random seeds should be tested by one or
29more statistical tests. While statistical tests do not provide a guarantee that the generator is “good,” they
30help detect some weaknesses the generator may have. A number of tests are described in [MOV96, Section
315.4 “Statistical tests”] and FIPS 140-1 [FIP94a, Section 4.11.1] ([FIP94a] also describes a continuous
32random number generator test in Clause 4.11.2); a particular test that detects many weaknesses is given in
33[Mau91] (see also [CN98]). Note that while statistical tests may detect certain weaknesses, they do not
34guarantee unpredictability of the random bit source.
35It is important not to confuse random-looking but public sources of information for secret sources of
36randomness. For example, USENET feeds, TV broadcasts, or tables of pseudo-random numbers, or digits
37of should be assumed to be accessible to the opponent and should not be relied upon as sources of
38random seeds.
40Pseudo-random bit generators are deterministic algorithms that, given a seed as input, produce a pseudo-
41random bit string of a desired length (deterministic here means that they do not use any randomness other
42than that given by the input seed). Because they are algorithms and should be assumed publicly known, the
43unpredictability of their output relies heavily on the unpredictability of the input seed.
2 332
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1A pseudo-random bit generator is generally used to output more bits than the seed provides. Therefore, its
2outputs are not random, even if the seeds are. In fact, the distribution of the outputs cannot possibly be
3close to uniform, because number of possible outputs is limited by the number of possible seeds. For
4example, if a pseudo-random bit generator uses a 160-bit seed as input and returns a 300-bit output, only
52160 out of the possible 2300 (or one in 2140) 300-bit strings can be potentially output by the generator.
6Thus, the appropriate security condition to impose on a pseudo-random bit generator is not that it behave
7like a true random source. Rather, the condition is that it be indistinguishable from a true random source by
8any statistical test that can be computed with resources available to an opponent. More precisely, no
9computation that can be performed with a feasible amount of computational resources should be able to
10distinguish a truly random string from the output of pseudo-random bit generator with probability
11significantly better than 1/2. (It is, of course, easy to distinguish with probability exactly 1/2 by simply
12randomly guessing which one is the random string and which one is the output of the generator.) This
13condition is sometimes called indistinguishability ([B233]).
14A condition that is equivalent to indistinguishability is the following: given all but one bits of the output of
15the pseudo-random bit generator, it is infeasible to predict what the remaining bit is with probability
16significantly better than 1/2. In particular, it is infeasible to predict what the next bit of the output will be,
17even when given all the previous bits. This condition is sometimes called unpredictability ([BM84]).
18It is essential that pseudo-random bit generators used in cryptography can be reasonably believed to satisfy
19the above conditions. Some such generators are defined in [FIP94b], [ANS85], [MS91], [BBS86]; see
20[MOV96, Sections 5.3 and 5.5] for their descriptions. The formal basis for the belief of security varies
21according to the generator. The security of some ([FIP94b], [ANS85]) is based on heuristic assumptions,
22such as the unpredictability of outputs of DES or SHA-1 when a key or other input is unknown. The
23security of others ([MS91], [BBS86]) is based on reduction from a hard problem, such as integer
24factorization. Some attacks on some of the above generators and suggestions for improving pseudo-
25random generator design are contained in [KSW98].
26The above two conditions imply that it is infeasible to guess the seed given just the output of the generator.
27This is why pseudo-random generators may provide assurance that a set of parameters or keys was
28generated from a seed (rather than the seed reconstructed after the generation), as is further detailed in
29D.3.2 and D.4.
30The above two conditions also imply that the output of the pseudo-random generator, if long enough, is
31very unlikely to repeat in any reasonable time. Thus, keys, if generated properly, are very unlikely to be
32repeated or accidentally shared among users.
33Statistical tests described in the previous clause for testing the quality of the seed may also be used to test
34the quality of the pseudo-random bit generator. However, some generators commonly used outside of
35cryptography (such as the linear congruential generator) may pass many of the statistical tests while being
36entirely predictable and therefore insecure for cryptographic purposes.
43As with other security considerations, sources of the potential threats and their capabilities need to be
44examined. For example, opponents may be able to induce errors in systems by operating them under
45unexpected conditions, whether physical (such as change in temperature, power source characteristics,
2 333
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1electromagnetic radiation – e.g. TEMPEST issues [AK98]) or computational (such as ill-formed protocol
2messages or multiple requests overloading a server). Such errors may leak sensitive information, see, e.g.
3the fault-analysis attack of [BDL97], or the story of the “internet worm” in [HM95], [Keh95] or at
4http://www1.minn.net/~darbyt/worm/worm.html. Implementations, therefore, should make sure that they
5handle unexpected or erroneous inputs and environments appropriately at all levels where an adversary
6may be present.
7Implementations should also consider what information they may be giving to an adversary by indirect
8means. For example, by measuring the time a computation takes, an adversary may be able recover some
9information about a private key (see [Koc96] and [DKL98]). By analyzing the error messages sent by an
10implementation, an adversary may also be able to recover information (see, e.g., [Ble98]). Therefore, an
11implementation of any operation that uses secrets (such as key agreement, signature production or
12decryption) should limit the information it provides in case of error. Even partial information about a
13secret may lead to recovery of the entire secret (see, e.g., [BDF98]).
14Due consideration should also be given to protecting the secrets. They should be stored securely in such a
15way that unauthorized copying of even a portion of a secret is prevented. All the copies of the secrets
16should be accounted for. For example, care should be taken that, in a system with paging, a copy of a page
17containing the secret is not made on disk by the operating system without the knowledge of the
18implementation. Implementations should also be aware of the possibility of eavesdropping by, for
19example, the use of the electromagnetic radiation emanating from a video monitor (see [AK98]).
20The authenticity and validity of the machinery (whether hardware or software) performing the
21cryptographic operations needs to be assured. Otherwise, an adversary may be able to plant a so-called
22“Trojan horse” within the implementation by substituting pieces of code, parameters, keys or root
23certificates that are imbedded in the implementation. Protecting the system itself from unauthorized
24modification is as important as protecting cryptographic parameters and keys. Implementation validation is
25addressed in more detail in [FIP94a].
2 334
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
3E.1 Overview
4As outlined in Clause 4, the specifications presented in this standard are functional specifications, rather
5than interface specifications. Therefore, this standard does not specify how the mathematical and
6cryptographic objects (such as field elements, keys, or outputs of schemes) are to be represented for
7purposes of communication or storage. This informative Annex provides references to other relevant
8standards and defines some recommended primitives for that purpose. While the use of this Annex is
9optional, it is recommended for interoperability.
10As octet strings are arguably the most common way to represent data electronically for purposes of
11communication, this Annex focuses on representing objects as octet strings. One way to accomplish this is
12to represent data structures in Abstract Syntax Notation 1 (ASN.1—see [ISO98a], [ISO98b], [ISO98c],
13[ISO98d]) and then to use encoding rules, such as Basic Encoding Rules, Distinguished Encoding Rules or
14others (see [ISO98e], [ISO98f]) to represent them as octet strings. This Annex does not specify ASN.1
15constructs for use in this standard, because the generality of this standard would make such constructs very
16complex. It is likely that particular implementations only utilize a small part of the options available in this
17standard and would be better served by simpler ASN.1 constructs. When the use of ASN.1 is desired,
18ASN.1 constructs defined in the following standards or draft standards may be adapted for use:
19
20 ANSI X9.42 [ANS98b] for DL key agreement
21 ANSI X9.63 [ANS98f] for EC key agreement and EC encryption for key transport
22 ANSI X9.57 [ANS97c] for DL DSA signatures
23 ANSI X9.62 [ANS98e] for EC DSA signatures
24 ANSI X9.31 [ANS98a] for IF signatures
25 ANSI X9.44 [ANS98c] for IF encryption for key transport
26Additional examples of ASN.1 syntax can be found in documents such as PKCS #1 [PKCS1v2_1] and
27SEC-1 [SEC-1]. Alternatives to ASN.1 syntax are also available. In the digital signature specification for
28the eXtensible Markup Language (XML) (see Eastlake, Reagle, and Solo [ERS02]), public keys and digital
29signatures are represented as ASCII text strings, while in Transport Layer Security (TLS) [DA99], various
30cryptographic values are represented an octet strings with a syntax that is similar to data structures in the C
31programming language. A recent alternative proposal for representing elliptic curve keys and domain
32parameters can be found in Schroeppel and Eastlake [SE01].
33Clause E.2 gives recommendations on representing basic mathematical objects as octet strings and Clause
34E.3 gives recommendations on representing the outputs of encryption and signature schemes as octet
35strings.
2 335
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2Integers should be converted to/from octet strings using primitives I2OSP and OS2IP, as defined in the
3Clause 5.5.3 of the standard.
5Finite field elements should be converted to/from octet strings using primitives FE2OSP and OS2FEP, as
6defined in the Clause 5.5.4 of the standard.
8Elliptic curve points should be converted to/from octet strings using one of the pairs of primitives defined
9in 5.5.6.2 or 5.5.6.3. The x-coordinate-only representation in 5.5.6.3 should be employed only if the
10recipient does not need to resolve the ambiguity in the y-coordinate, or can do so by other means.
11NOTE—In general, the elliptic curve signature schemes in this standard depend on the specific y-coordinate, and the
12elliptic curve key agreement and encryption schemes do not.
13An elliptic curve point P (which is not the point at infinity O) can be represented in either compressed or
14uncompressed form. (For internal calculations, it may be advantageous to use other representations, e.g.,
15the projective coordinates of A.9.6. See Annex A.9.6 also for more information on point compression.)
16The uncompressed form of P is simply given by its two coordinates. The compressed form is presented
17below. The octet string format is defined to support both compressed and uncompressed points.
21If p = 2, the coefficients of a polynomial f(t) over GF(2) are elements of GF(2) and are, therefore,
22represented as bits: the element zero of GF(2) is represented by the bit 0, and the element 1 of GF(2) is
23represented by the bit 1 (see Clause 5.5.4). If p 3, the coefficients are represented as integers modulo p.
24Let e be the degree of f(t) and
26where ae = 1. If p = 2, to represent f(t) as an octet string, the bits representing its coefficients should be
27concatenated into a single bit string: a = ae || ae–1 || … || a1 || a0. The bit string a should then be converted
28into an octet string using BS2OSP (see 5.5.2). If p 3, the integer
29a = at–1pt–1 + … + a2p2 + a1p+ a0
30should first be computed and then converted into an octet string using I2OSP (see 5.5.3).
31The primitive that converts polynomials over GF(p) to octet strings is called Polynomial to Octet String
32Conversion Primitive or PN2OSP. It takes a polynomial f(t) and a prime p as input and outputs an octet
33string.
34The primitive that converts octet strings to polynomials over GF(p) is called Octet String to Polynomial
35Conversion Primitive or OS2PNP. It takes the octet string and the prime p as inputs and outputs the
36corresponding polynomial over GF(p). Let l be the length of the input octet string.
2 336
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1If p = 2, OS2PNP should use OS2BSP (see 5.5.2) with the octet string and the length 8l as inputs. It should
2output “error” if OS2BSP outputs “error.” The output of OS2BSP should be parsed into 8l coefficients, one
3bit each. Note that at most 7 leftmost coefficients may be zero. The leftmost zero coefficients should be
4discarded.
5If p 3, OS2PNP should use OS2IP (see 5.5.3) to obtain the integer a defined above. The resulting
6polynomial can be obtained from this integer by successively dividing by p and keeping the remainder as in
75.3.3.
8NOTE—The representation defined here is intended for arbitrary polynomials. More compact representations are
9possible for sparse polynomials; see Schroeppel and Eastlake [SE01] for an example.
15For DL/ECSSA and DL/ECSSR, the output of the signature generation function (see 10.2.2 and 10.4.2) is a
16pair of integers (c, d). Let r denote the order of the generator (g or G) in the DL or EC domain parameters,
17and let l = log256 r (i.e., l is the length of r in octets). The output (c, d) may be formatted as an octet string
18as follows: convert the integers c and d to octet strings C and D, respectively, of length l octets each, using
19the primitive I2OSP, and output the concatenation C || D as the signature. To parse the signature, split the
20octet string into two components C and D, of length l octets each, and convert them to integers c and d,
21respectively, using OS2IP. Note that it is essential that both C and D be of length l octets, even if it means
22that they have leading zero octets.
23For DL/ECSSR-PV, the output of the signature generation function (see 10.5.2) is a pair (C, d) where C is
24an octet string and d is an integer. The output (C, d) may be formatted as an octet string as follows: convert
25the integer d to an octet string D of length l octets (where l is as defined above) using the primitive I2OSP,
26and output the concatenation C || D. To parse the signature, let C be all but the rightmost l octets of the
27signature and let D be the rightmost l octets, and convert D to an integer d using OS2IP.
28NOTE—The output of DL/ECSSA may also be formatted according to the following method, described in more detail
29in ANSI X9.57-1997 [B6] and ANSI X9.62-1998 [B11]: combine c and d into an ASN.1 structure (ISO/IEC 8824-
301:1998 [B72]) and encode the structure using some encoding rules, such as BER or DER (ISO/IEC 8825-1:1998
31[B76]).
33For IFSSA and IFSSR, the output of the signature generation function (see 10.3.2 and 10.6.2) is an integer
34s. Let k = log256 n denote the length in octets of the modulus n in the IF public key. The output s may be
35formatted as an octet string by simply converting it to an octet string of length k octets using the primitive
36I2OSP.
2 337
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2For IFES, the output of the encryption function (see 11.2.2) is an integer g. Let k = log256 n denote the
3length in octets of the modulus n in the IF public key. The output g may be formatted as an octet string by
4simply converting it to an octet string of length k octets using the primitive I2OSP.
5For IFES-EPOC, the output of the encryption function (see 11.4.2) is a pair (g, C) where g is an integer and
6C is an optional octet string. The output (g, C) may be formatted as an octet string as follows: convert the
7integer g to an octet string G of length k octets (where k is as defined above) using the primitive I2OSP, and
8output the concatenation G || C as the ciphertext (if G is absent, then the ciphertext is simply C). To parse
9the ciphertext, let C be all but the leftmost k octets of the ciphertext and let G be the leftmost k octets, and
10convert G to an integer g using OS2IP.
12For DL/ECIES, the output of the encryption function (see 11.3.2) is a triple (V, C, T) where V is an octet
13string, C is a bit string, and T is a bit string. If the lengths of the bit strings C and T are both divisible by 8,
14then the output (V, C, T) may be formatted as an octet string as follows: convert the bit strings C and T to
15octet strings CO and TO, respectively, using B2OSP, and output V || CO || TO as the ciphertext. In the DL
16case, the length of the octet string V will be log256 q where q is the field size; in the EC case, the length
17will be either 1 + log256 q or 1 + 2 log256 q depending on whether the compressed or
18uncompressed/hybrid format is selected.
19To parse the ciphertext, let V be the leftmost log256 q octets in the DL case and the leftmost 1 + log256 q
20or 1 + 2 log256 q octets in the EC case (depending on the format, which can be determined by examining
21the first octet). Let TO be the rightmost tBits/8 octets (where tBits is the length of the authentication tag,
22which is a parameter to the encoding method), and let CO be the remaining middle octets. Let l be the
23length of CO in octets. Convert CO and TO to bit strings C of length 8l bits and T of length tBits,
24respectively, using OS2BSP.
25NOTE—In ANSI X9.63 [B12], the ciphertext is formatted as a bit string V || C || T. The format here produces the
26equivalent octet string when the lengths of the bit strings C and T are both divisible by 8. In the general case, an octet
27string may be obtained by converting the bit string V || C || T to an octet string of comparable length. However, to parse
28such a ciphertext, the recipient will need to know how much padding was added in the conversion to the octet string
29(or, alternatively, the bit length of the encrypted message C), so that the end of the tag T can be identified.
2 338
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2Attention is called to the possibility that implementation of this standard may require use of subject matter
3covered by patent rights. By publication of this standard, no position is taken with respect to the existence
4or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying
5patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal
6validity or scope of those patents that are brought to its attention. The patent holders listed below have filed
7statements of assurance that they will grant licenses under these rights without compensation or under
8reasonable rates and nondiscriminatory, reasonable terms and conditions to all applicants desiring to obtain
9such licenses. The IEEE makes no representation as to the reasonableness of rates and/or terms and
10conditions of the license agreements offered by patent holders. Further information may be obtained from
11the IEEE Standards Department.
12
2 339
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1242030 (CA)
4,745,568 (US)
6,230,179 (US)
6,009,450 (US)
5,982,895 (US)
5,600,725 (US)
and patent applications
2 340
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
Prof. Dr. Claus Peter Schnorr Herr Wehr 0,384,475 (EP) issued in 27-Mar-1998
61231 Bad Nauheim Siemens AG 11 countries
Frankfurter Strasse 81 Rechtsabteilung 2 2,666,191 (JP)
GERMANY Hofmannstr. 51
81359 Munchen
GERMANY
tel: +89 722 62793
fax: +89 722 62793
*RSA Security Inc. has
exclusive rights in 4,995,082
(US) - see above
2 341
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2[B1] Antipa, A., Brown, D., Menezes, A., Struik, R. and Vanstone, S. “Validation of Elliptic Curve Public
3Keys,” Y. G. Desmedt, Ed., Public Key Cryptography, PKC 2003, Lecture Notes in Computer Science
42567 (2003), Springer, pp. 211-223. Presentation available at http://grouper.ieee.org/groups/1363/.
5[B2] [ABR98] Abdalla, M., Bellare, M., and Rogaway, P. “DHAES: An Encryption Scheme Based on the
6Diffie-Hellman Problem,” submission to IEEE P1363a, September 1998. Available at
7http://grouper.ieee.org/groups/1363/. Revised version via URL of authors.
8[B3] [ABV89] D. Ash, I. Blake, and S. Vanstone, “Low Complexity Normal Bases,” Discrete Applied
9Mathematics 25 (1989), 191-210.
10[B4] [AF99] Adams, C. and Farrell, S. “RFC 2510: Internet X.509 Public Key Infrastructure Certificate
11Management Protocols,” March 1999. Available at http://www.rfc-editor.org/.
12[B5] [AHK99] Aoki, K., Hoshino, F., and Kobayashi, T. “OEF Using a Successive Extension,” presented
13at the rump session of CRYPTO ’99.
14[B6] [AK98] Ross Anderson and Markus Kuhn, “Soft Tempest: Hidden Data Transmission Using
15Electromagnetic Emanations,” D. Aucsmith, editor, Second International Workshop on Information Hiding
16– IH’98, Lecture Notes In Computer Science 1525 (1998), Springer-Verlag.
17[B7] [AM95] Adleman, L. M. and McCurley, K. S. “Open Problems in Number Theoretic Complexity,
18II,” L. M. Adleman and M-D. Huang, Eds., Algorithmic Number Theory, ANTS-I, Lecture Notes in
19Computer Science 877 (1994), Springer, pp. 291-322.
20[B8] [ANS01a] ANSI X9.42-2001, Public Key Cryptography for the Financial Services Industry:
21Agreement of Symmetric Keys Using Discrete Logarithm Cryptography.
22[B9] [ANS01b] ANSI X9.80-2001, Public Key Cryptography for the Financial Services Industry: Prime
23Number Generation, Primality Testing, and Primality Certificates.
24[B10] [ANS02] ANSI X9.63-2002, Public Key Cryptography for the Financial Services Industry: Key
25Agreement and Transport Using Elliptic Curve Cryptography.
26[B11] [ANS09] ANSI X9.44 (draft), Public Key Cryptography for the Financial Services Industry: Key
27Establishment Schemes Using Integer Factorization Cryptography, working draft, 2003.
28[B12] [ANS85] ANSI X9.17-1985, Financial institution key management (wholesale).
29[B13] [ANS97a] ANSI X9.30:1-1997, Public Key Cryptography for the Financial Services Industry: Part
301: The Digital Signature Algorithm (DSA) (revision of X9.30:1-1995).
31[B14] [ANS97b] ANSI X9.30:2-1997, Public Key Cryptography for the Financial Services Industry: Part
322: The Secure Hash Algorithm (SHA-1) (revision of X9.30:2-1993).
33[B15] [ANS97c] ANSI X9.57-1997, Public Key Cryptography for the Financial Services Industry:
34Certificate Management.
35[B16] [ANS98a] ANSI X9.31-1998, Digital Signatures Using Reversible Public Key Cryptography for the
36Financial Services Industry (rDSA).
37[B17] [ANS98b] ANSI X9.52-1998, Cryptography for the Financial Services Industry: Triple Data
38Encryption Algorithm Modes of Operation.
39[B18] [ANS98c] ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: The
40Elliptic Curve Digital Signature Algorithm (ECDSA).
41[B19] [ANS98d] ANSI X9.TG-17 Public-Key Cryptography for the Financial Services Industry: Technical
42Guideline on Elliptic Curve Arithmetic, to appear.
43[B20] [ANSI-X9.52] ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation.
2 342
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B21] [ANSI-X9.71] ANSI X9.71-2000, Keyed Hash Message Authentication Code (MAC).
2[B22] [Atk92] O. Atkin, “Square roots and cognate matters modulo p = 8n + 5,” Internet communication to
3Number Theory mailing list (11 Nov 1992), archived at http://listserv.nodak.edu/scripts/wa.exe?
4A2=ind9211&L=nmbrthry&O=T&P=562
5[B23] [BBS86] L. Blum, M. Blum and M. Shub, “A simple unpredictable pseudo-random number
6generator,” SIAM Journal on Computing 15 (1986), 364-383.
7[B24] [BCK96] Bellare, M., Canetti, R., and Krawczyk, H., “Keyed Hash Functions and Message
8Authentication,” N. Koblitz, Ed., Advances in Cryptology, CRYPTO ’96, Lecture Notes in Computer
9Science 1109 (1996), Springer, pp. 1-15. Also available at http://www.research.ibm.com/security/keyed-
10md5.html.
11[B25] [BD86] Brickell, E. F. and DeLaurentis, J. M. “An Attack on a Signature Scheme Proposed by
12Okamoto and Shiraishi,” H.C. Williams, Ed., Advances in Cryptology, CRYPTO ’85, Lecture Notes in
13Computer Science 218 (1986), Springer, pp. 28-32.
14[B26] [BD99] D. Boneh and G. Durfee, “Cryptoanalysis of RSA with private key d less than N0.292,” J.
15Stern, editor, Advances in Cryptology — EUROCRYPT ‘99, Lecture Notes in Computer Science 1592
16(1999), Springer-Verlag, 1-11.
17[B27] [BDF98] D. Boneh, G. Durfee, Y. Frankel, “An attack on RSA given a small fraction of the private
18key bits,” K. Ohta and D. Pei, editors, Advances in Cryptology – ASIACRYPT ’98, Lecture Notes In
19Computer Science 1514 (1998), Springer-Verlag, 25-34.
20[B28] [BDH99] Boneh, D., Durfee, G., Howgrave-Graham, N. “Factoring N = prq for Large r,” M. J.
21Wiener, Ed., Advances in Cryptology, CRYPTO ’99, Lecture Notes in Computer Science 1666 (1999),
22Springer, pp. 326-337.
23[B29] [BDL97] D. Boneh, R. A. DeMillo and R. J. Lipton, “On the Importance of Checking Cryptographic
24Protocols for Faults,” W. Fumy, editor, Advances in Cryptology — EUROCRYPT ‘97, Lecture Notes in
25Computer Science 1223 (1997), Springer-Verlag, 37-51.
26[B30] [BDPR98] M. Bellare, A. Desai, D. Pointcheval and P. Rogaway, “Relations Among Notions of
27Security for Public-Key Encryption Schemes,” H. Krawczyk, editor, Advances in Cryptology — CRYPTO
28‘98, Lecture Notes in Computer Science 1462 (1998), Springer-Verlag, 26-45. Full version appears in
29http://www-cse.ucsd.edu/users/mihir/papers/crypto-papers.html
30[B31] [Ber01] Bernstein, D. J. “Circuits for Integer Factorization: A Proposal,” manuscript, November
319, 2001. Available at http://cr.yp.to/papers.html.
32[B32] [Ber68] E. Berlekamp, Algebraic Coding Theory, McGraw-Hill, 1968, pp. 36-44.
33[B33] [BJ00] Brown, D. R. L., and Johnson, D. B. “Formal Security Proofs for a Signature Scheme with
34Partial Message Recovery,” D. Naccache, Ed., Cryptographers’ Track RSA Conference 2001, Lecture
35Notes in Computer Science 2020 (2001), pp. 126-142.
36[B34] [BJM97] S. Blake-Wilson, D. Johnson and A. Menezes, “Key Agreement Protocols and their
37Security Analysis,” M. Darnell, editor, Cryptography and Coding: Sixth IMA International Conference,
38Lecture Notes in Computer Science 1355 (1997), Springer-Verlag, 30-45. A full version is available from
39http://www.cacr.math.uwaterloo.ca/.
40[B35] [BKL+02] Barreto, P. S. L. M., Kim, H. Y., Lynn, B., and Scott, M. “Efficient Algorithms for
41Pairing-Based Cryptosystems,” M. Yung, Ed., Advances in Cryptology, CRYPTO 2002, Lecture Notes in
42Computer Science 2442 (2002), Springer, 354-368. Revised version available at
43http://eprint.iacr.org/2002/088.
44[B36] [BL96] D. Boneh and R. Lipton, “Algorithms for black box fields and their application to
45cryptography,” N. Koblitz, editor, Advances in Cryptology – CRYPTO ‘96, Lecture Notes in Computer
46Science 1109 (1996), Springer-Verlag, 283-297.
47[B37] [Ble01] Bleichenbacher, D. “On the Generation of DSA One-Time Keys,” manuscript.
2 343
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B38] [Ble98] D. Bleichenbacher, “Chosen Ciphertext Attacks Against Protocols Based on the RSA
2Encryption Standard PKCS #1,” H. Krawczyk, editor, Advances in Cryptology — CRYPTO ‘98, Lecture
3Notes in Computer Science 1462 (1998), Springer-Verlag, 1-12.
4[B39] [BLP93] J.P. Buhler, H. W. Lenstra, Jr. and C. Pomerance, “Factoring integers with the number field
5sieve,” A. K. Lenstra and H.W. Lenstra, Jr., editors, The Development of the Number Field Sieve, Lecture
6Notes in Mathematics 1554 (1993), Springer-Verlag, 50-94.
7[B40] [BLS88] J. Brillhart, D.H. Lehmer, J.L. Selfridge, B. Tuckerman, and S.S. Wagstaff,
8“Factorizations of bn 1, b = 2,3, 5,6,7,10,11,12, up to high powers,” 2nd ed., American Math. Soc., 1988.
9[B41] [BLZ94] J. Buchmann, J. Loho and J. Zayer, “An implementation of the general number field
10sieve,” D. R. Stinson, editor, Advances in Cryptology — CRYPTO ‘93, Lecture Notes in Computer Science
11773 (1994), Springer-Verlag, 159-165.
12[B42] [BM84] M. Blum, S. Micali, “How to generate cryptographically strong sequences of pseudo-
13random bits,” SIAM Journal on Computing 13 (1984), 850-864.
14[B43] [BM98] S. Blake-Wilson and A. Menezes, “Unknown key-share attacks on the station-to-station
15(STS) protocol,” H. Imai and Y. Zheng, editors, Public Key Cryptography: Second International Workshop
16on Practice and Theory in Public Key Cryptography, PKC’99, Lecture Notes in Computer Science 1560
17(1999), 154-170. Also available as technical report CORR 98-42 from http://www.cacr.math.uwaterloo.ca/
18[B44] [BMM00] Biehl, I., Meyer, B., Müller, V. “Differential Fault Attacks on Elliptic Curve
19Cryptosystems,” M. Bellare, Ed., Advances in Cryptology, CRYPTO 2000, Lecture Notes in Compute
20Science 1880 (2000), Springer, pp. 131-146.
21[B45] [BO91] Brickell, E. and Odlyzko, A. “Cryptanalysis: A Survey of Recent Results,” chapter 10 of G.
22J. Simmons, Ed., Contemporary Cryptology, IEEE Press, 1991, pp. 501-540.
23[B46] [BP00] Bailey, D. V., and Paar, C. “Efficient Arithmetic in Finite Field Extensions with Application
24in Elliptic Curve Cryptography,” Journal of Cryptology 14 (2001), pp. 153-176.
25[B47] [BP98] Bailey, D. V. and Paar, C. “Optimal Extension Fields for Fast Arithmetic in Public-Key
26Algorithms,” H. Krawcyzk, Ed., Advances in Cryptology, CRYPTO ’98, Lecture Notes in Computer
27Science 1462 (1998), Springer, 472-485.
28[B48] [BR93] Bellare, M. and Rogaway, P. “Random Oracles are Practical: A Paradigm for Designing
29Efficient Protocols,” Proceedings of the First Annual Conference on Computer and Communications
30Security (1993), CCS ’93, ACM, pp. 62-73. Revised version available via URL of either author.
31[B49] [BR95] M. Bellare and P. Rogaway, “Optimal Asymmetric Encryption – How to Encrypt with
32RSA,” A. De Santis, editor, Advances in Cryptology — EUROCRYPT ‘94, Lecture Notes in Computer
33Science 950 (1995), Springer-Verlag, 92-111. Revised version appears in http://www-
34cse.ucsd.edu/users/mihir/papers/crypto-papers.html
35[B50] [BR96] M. Bellare and P. Rogaway, “The Exact Security of Digital Signatures: How to Sign with
36RSA and Rabin,” U. M. Maurer, editor, Advances in Cryptology — EUROCRYPT ‘96, Lecture Notes in
37Computer Science 1070 (1996), Springer-Verlag, 399-416. Revised version appears in http://www-
38cse.ucsd.edu/users/mihir/papers/crypto-papers.html
39[B51] [Bue89] D. Buell, Binary quadratic forms: classical theory and modern computations, Springer-
40Verlag, 1989.
41[B52] [Bur96] R. J. Burthe, Jr., “Further Investigations with the Strong Probable Prime Test,” Mathematics
42of Computation 65 (1996), 373-381.
43[B53] [BV98] D. Boneh, R. Venkatesan, “Breaking RSA May Not Be Equivalent to Factoring,” K.
44Nyberg, editor, Advances in Cryptology — EUROCRYPT ‘98, Lecture Notes in Computer Science 1403
45(1998), Springer-Verlag, 59-71.
2 344
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B54] [CC87] D.V. Chudnovsky and G.V. Chudnovsky, “Sequences of Numbers Generated by Addition in
2Formal Groups and New Primality and Factorizations Tests,” Advances in Applied Mathematics, 7 (1987),
3385-434.
4[B55] [CFP96] D. Coppersmith, M. Franklin, J. Patarin and M. Reiter, “Low-exponent RSA with related
5messages,” U. M. Maurer, editor, Advances in Cryptology — EUROCRYPT ‘96, Lecture Notes in
6Computer Science 1070 (1996), Springer-Verlag, 1-9.
7[B56] [CGL98] Canetti, R., Goldreich, O., and Halevi, S. “The Random Oracle Methodology, Revisited
8(Preliminary Version),” Proceedings of the 30th Annual ACM Symposium on Theory of Computing (1998),
9STOC ’98, pp. 209-218.
10[B57] [CH98] M. Chen and E. Hughes, “Protocol Failures Related to Order of Encryption and Signature:
11Computation of Discrete Logarithms in RSA Groups,” C. Boyd and E. Dawson, editors, Third Australian
12Conference on Information Security and Privacy – ACISP ’98, Lecture Notes in Computer Science 1438
13(1998).
14[B58] [CHJ99] Coppersmith, D., Halevi, S., and Jutla, C. “ISO 9796-1 and the New Forgery Strategy,”
15presented at the rump session of CRYPTO ’99.
16[B59] [CHJ99] D. Coppersmith, S. Halevi and C. Jutla, “ISO 9796-1 and the new forgery strategy
17(working draft).” Presented at the rump session of CRYPTO ‘99. Available from
18http://grouper.ieee.org/groups/1363/contrib.html.
19[B60] [CN98] J.-S. Coron and D. Naccache, “An Accurate Evaluation of Maurer’s Universal Test,”
20Selected Areas in Cryptography – SAC ’98, Lecture Notes in Computer Science (1998), Springer-Verlag.
21[B61] [CNS99] Coron, J-S., Naccache, D., and Stern, J.P. “On the Security of RSA Padding,” M. J.
22Wiener, Ed., Advances in Cryptology, CRYPTO ’99, Lecture Notes in Computer Science 1666 (1999),
23Springer, pp. 1-18.
24[B62] [CNS99] J.-S. Coron, D. Naccache, and J.P. Stern, “On the security of RSA padding,” M. J. Wiener,
25editor, Advances in Cryptology — CRYPTO ‘99, Lecture Notes in Computer Science 1666 (1999),
26Springer-Verlag, 1-18.
27[B63] [Cor00] Coron, J-S. “On the Exact Security of Full Domain Hash,” M. Bellare, Ed., Advances in
28Cryptology, CRYPTO 2000, Lecture Notes in Computer Science 1880 (2000), Springer, pp. 229-235.
29[B64] [Cor02] Coron, J-S. “Optimal Security Proofs for PSS and Other Signature Schemes,” L. Knudsen,
30Ed., Advances in Cryptology, EUROCRYPT 2002, Lecture Notes in Computer Science 2332 (2002),
31Springer, pp. 272-287.
32[B65] [CW98] Lidong Chen and Charles Williams, “Public Key Sterilization,” unpublished draft, August
331998.
34[B66] [DA99] Dierks, T., and Allen, C. “RFC 2246: The TLS Protocol Version 1.0,” Internet Activities
35Board, January 1999. Available at http://www.rfc-editor.org/.
36[B67] [DBP96] H. Dobbertin, A. Bosselaers and B. Preneel, “RIPEMD-160: a strengthened version of
37RIPEMD,” D. Gollmann, editor, Fast Software Encryption, Third International Workshop, Lecture Notes
38in Computer Science 1039 (1996), Springer-Verlag, 71-82. A corrected and updated version is available
39from http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html.
40[B68] [DH76] W. Diffie and M. Hellman, “New directions in cryptography,” IEEE Transactions on
41Information Theory 22 (1976), 644-654.
42[B69] [DHR98a] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade and L. Repka, “RFC2311: S/MIME
43Version 2 Message Specification,” Internet Activities Board, March 1998. Available from http://www.rfc-
44editor.org/. See also http://www.ietf.org/html.charters/smime-charter.html and
45http://www.ietf.org/ids.by.wg/smime.html for latest developments and drafts.
2 345
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B70] [DHR98b] S. Dusse, P. Hoffman, B. Ramsdell and J. Weinstein, “RFC2312: S/MIME Version 2
2Certificate Handling,” Internet Activities Board, March 1998. Available from http://www.rfc-editor.org/.
3See also http://www.ietf.org/html.charters/smime-charter.html and
4http://www.ietf.org/ids.by.wg/smime.html for latest developments and drafts.
5[B71] [Dif88] W. Diffie, “The first ten years of public-key cryptology,” Proceedings of the IEEE 76
6(1988), 560-577.
7[B72] [DIF94] D. Davis, R. Ihaka, and P. Fenstermacher,“Cryptographic randomness from air turbulence
8in disk drives,” Yvo G. Desmedt, editor, Advances in Cryptology — CRYPTO ‘94, Lecture Notes in
9Computer Science 839 (1994), Springer-Verlag, 114-120.
10[B73] [DKL98] J.-F. Dhem, F. Koeune, P.-A. Leroux, P. Mestré, J.-J. Quisquater and J.-L. Willems, “A
11Practical Implementation of the Timing Attack,” CARDIS ’98, Lecture Notes in Computer Science,
12Springer Verlag, 1998.
13[B74] [DL95] B. Dodson and A. K. Lenstra, “NFS with Four Large Primes: An Explosive Experiment,” D.
14Coppersmith, editor, Advances in Cryptology — CRYPTO ‘95, Lecture Notes in Computer Science 963
15(1995), Springer-Verlag, 372-385.
16[B75] [DLP93] I. Damgard, P. Landrock, and C. Pomerance, “Average Case Error Estimates for the Strong
17Probable Prime Test,” Mathematics of Computation 61 (1993), 177-194.
18[B76] [DOW92] W. Diffie, P. C. van Oorschot and M. J. Wiener, “Authentication and authenticated key
19exchanges,” Designs, Codes and Cryptography 2 (1992), 107-125
20[B77] [ECS94] D. Eastlake, S. Crocker, and J. Schiller. “RFC1750: Randomness Recommendations for
21Security,” Internet Activities Board, December 1994. Available from http://www.rfc-editor.org/.
22[B78] [ENS01] El Mahassni, E., Nguyen, P. Q., and Shparlinski, I. E. “The Insecurity of Nyberg-Rueppel
23and Other DSA-Like Signature Schemes with Partially Known Nonces,” J.H. Silverman, Ed., Proceedings
24of Cryptography and Lattices Conference, CaLC 2001, Lecture Notes in Computer Science 2146 (2001),
25Springer, pp. 97-109. Also available at http://www.comp.mq.edu.au/~igor/Publ.html.
26[B79] [ERS02] Eastlake, D., Reagle, J., and Solo, D. “RFC 3275: XML-Signature Syntax and Processing,”
27Internet Activities Board, March 2002. Available at http://www.rfc-editor.org/.
28[B80] [FIP00] FIPS PUB 186-2, Digital Signature Standard, Federal Information Processing Standards
29Publication 186-2, U.S. Department of Commerce/National Institute of Standards and Technology,
30National Technical Information Service, Springfield, Virginia, January 27, 2000 (supersedes FIPS PUB
31186-1). Available at http://csrc.nist.gov/fips/.
32[B81] [FIP01] FIPS PUB 140-2, Security Requirements for Cryptographic Modules, Federal Information
33Processing Standards Publication 180-2, U.S. Department of Commerce/National Institute of Standards and
34Technology, National Technical Information Service, Springfield, Virginia, May 25, 2001 (supersedes
35FIPS PUB 140-1). Available at http://csrc.nist.gov/fips/.
36[B82] [FIP02] FIPS PUB 180-2, Secure Hash Standard, Federal Information Processing Standards
37Publication 180-2, U.S. Department of Commerce/National Institute of Standards and Technology,
38National Technical Information Service, Springfield, Virginia, August 1, 2002 (supersedes FIPS PUB 180-
391). Available at http://csrc.nist.gov/fips/.
40[B83] [FIPS-197] FIPS PUB 197, Advanced Encryption Standard (AES), Federal Information Processing
41Standards Publication 197, U.S. Department of Commerce/National Institute of Standards and Technology,
42November 26, 2001. Available at http://csrc.nist.gov/fips/.
43[B84] [FIPS-198] FIPS PUB 198, The Keyed-Hash Message Authentication Code (HMAC), Federal
44Information Processing Standards Publication 198, U.S. Department of Commerce, National Institute of
45Standards and Technology, March 6, 2002. Available at http://csrc.nist.gov/fips/.
2 346
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B85] [FIPS-46-3] FIPS PUB 46-3, Data Encryption Standard (DES), Federal Information Processing
2Standards Publication 46-3, U.S. Department of Commerce, National Institute of Standards and
3Technology (NIST), National Technical Information Service, Springfield, Virginia, October 25, 1999
4(supersedes FIPS PUB 46-2). Available at http://csrc.nist.gov/fips/.
5[B86] [FIPS-81] FIPS PUB 81, DES Modes of Operation, Federal Information Processing Standards
6Publication 81, U.S. Department of Commerce, National Institute of Standards and Technology (NIST),
7National Technical Information Service, Springfield, Virginia, December 2, 1980. Available at
8http://csrc.nist.gov/fips/.
9[B87] [FO98] Fujisaki, E. and Okamoto, T., “Security of Efficient Digital Signature Scheme TSH-
10ESIGN,” manuscript, November 1998. (Also available as Appendix A of Okamoto, T., Fujisaki, E. and
11Morita, H., “TSH-ESIGN: Efficient Digital Signature Scheme Using Trisection Size Hash,” submission to
12IEEE P1363a, November 1998. Available at http://grouper.ieee.org/groups/1363/.)
13[B88] [FO99a] Fujisaki, E. and Okamoto, T. “How to Enhance the Security of Public-Key Encryption at
14Minimum Cost,” H. Imai and Y. Zheng, Eds., Public Key Cryptography, PKC ’99, Lecture Notes in
15Computer Science 1560 (1999), Springer, pp. 53-68.
16[B89] [FO99b] Fujisaki, E. and Okamoto, T. “Secure Integration of Asymmetric and Symmetric
17Encryption Schemes,” M. J. Wiener, Ed., Advances in Cryptology, CRYPTO ’99, Lecture Notes in
18Computer Science 1666 (1999), Springer, pp. 537-554.
19[B90] [FOP01] Fujisaki, E., Okamoto, T., Pointcheval, D., and Stern, J. “RSA-OAEP is Secure Under the
20RSA Assumption,” J. Kilian, Ed., Advances in Cryptology, CRYPTO 2001, Lecture Notes in Computer
21Science 2139 (2001), Springer, pp. 260-274.
22[B91] [GGO98] H. Gilbert, D. Gupta, A. Odlyzko and J.-J. Quisquater, “Attacks on Shamir's ‘RSA for
23Paranoids,’” Information Processing Letters vol.68 no.4 (November 30, 1998), pp.197-199. Also
24available from http://www.research.att.com/~amo/doc/crypto.html
25[B92] [GHS02] Gaudry, P., Hess, F. and Smart, N. “Constructive and Destructive Facets of Weil Descent
26on Elliptic Curves,” Journal of Cryptology 15 (2002), pp. 19-46. Also available at
27http://ultralix.polytechnique.fr/Labo/Pierrick.Gaudry/papers.html.
28[B93] [GK86] S. Goldwasser and J. Kilian, “Almost all primes can be quickly certified,” Proceedings of
29the 18th Annual ACM Symposium on Theory of Computing (1986), 316-329.
30[B94] [GLV00] Gallant, R., Lambert, R., and Vanstone, S. “Improving the Parallelized Pollard Lambda
31Search on Binary Anomalous Curves,” Mathematics of Computation 69 (2000), pp. 1699-1705.
32[B95] [GM84] S. Goldwasser and S. Micali, “Probabilistic encryption,” Journal of Computer and System
33Sciences 28 (1984), 270-299.
34[B96] [GM93] D. M. Gordon and K. S. McCurley, “Massively parallel computations of discrete
35logarithms,” E. F. Brickell, editor, Advances in Cryptology — CRYPTO ’92, Lecture Notes in Computer
36Science 740 (1993), Springer-Verlag, 312-323.
37[B97] [GMR88] S. Goldwasser, S. Micali and R. L. Rivest, “A digital signature scheme secure against
38adaptive chosen-message attacks,” SIAM Journal on Computing 17 (1988), 281-308.
39[B98] [GMR98] R. Gennaro, D. Micciancio and T. Rabin, “An efficient non-interactive statistical zero-
40knowledge proof system for quasi-safe prime products,” Proceedings of the Fifth ACM Conference on
41Computer and Communications Security (CCS-5), 1998, pp. 67-72. Available from
42http://www.acm.org/pubs/articles/proceedings/commsec/288090/p67-gennaro/p67-gennaro.pdf
43[B99] [Gor93a] D. M. Gordon, “Designing and detecting trapdoors for discrete log cryptosystems,” E. F.
44Brickell, editor, Advances in Cryptology — CRYPTO ’92, Lecture Notes in Computer Science 740 (1993),
45Springer-Verlag, 66-75.
46[B100] [Gor93b] D. M. Gordon, “Discrete logarithms in GF (p) using the number field sieve,” SIAM
47Journal on Discrete Mathematics, 6 (1993), 124-138.
2 347
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 348
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
2 349
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B139] [Kob94] N. Koblitz, A Course in Number Theory and Cryptography, 2nd ed., Springer-Verlag,
21994.
3[B140] [Kob98] Koblitz, N. Algebraic Aspects of Cryptography, Springer, 1998.
4[B141] [Koc96] P. C. Kocher, “Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and
5other systems,” N. Koblitz, editor, Advances in Cryptology – CRYPTO ‘96, Lecture Notes in Computer
6Science 1109 (1996), Springer-Verlag, 104-113.
7[B142] [Kra93] D. W. Kravitz, “Digital signature algorithm,” U.S. Patent 5,231,668, 27 Jul 1993.
8[B143] [KS98] Kaliski, B. and Staddon, J. “RFC 2437: PKCS #1: RSA Cryptography Specifications
9Version 2.0,” Internet Activities Board, October 1998. Available at http://www.rfc-editor.org/.
10[B144] [KSW98] J. Kelsey, B. Schneier, D. Wagner and C. Hall, “Cryptanalytic attacks on pseudorandom
11number generators,” S. Vaudenay, editor, Fast Software Encryption, Fifth International Workshop
12Proceedings, Lecture Notes in Computer Science 1372 (1998), Springer-Verlag, 168-188.
13[B145] [KY98] Kaliski, B. S., Jr. and Yin, Y. L. “Storage-Efficient Finite Field Basis Conversion,” S.
14Tavares and H. Meijer, Eds., Selected Areas in Cryptography, SAC ’98, Lecture Notes in Computer
15Science 1556 (1999), Springer, pp. 81-93.
16[B146] [Leh69] D. H. Lehmer, “Computer Technology Applied to the Theory of Numbers,” Studies in
17Number Theory (W. J. LeVeque, ed.), Mathematical Association of America, 1969.
18[B147] [Len87] H. W. Lenstra, Jr., “Factoring integers with elliptic curves,” Annals of Mathematics 126
19(1987), 649-673.
20[B148] [Len97] Lenstra, A. K. “Using Cyclotomic Polynomials to Construct Efficient Discrete Logarithm
21Cryptosystems over Finite Fields,” V. Varadharajan, J. Pieprzyk, and Y. Mu, Eds., Information Security
22and Privacy, ACISP ’97, Lecture Notes in Computer Science 1270 (1997), Springer, pp. 127-138.
23[B149] [LL97] C. H. Lim and P. J. Lee, “A key recovery attack on discrete log-based schemes using a
24prime order subgroup,” B. S. Kaliski, Jr., editor, Advances in Cryptology — CRYPTO ‘97, Lecture Notes in
25Computer Science 1294 (1997), Springer-Verlag, 249-263.
26[B150] [LMQ98] L. Law, A. Menezes, M. Qu, J. Solinas, S. Vanstone, “An Efficent Protocol for
27Authenticated Key Agreement,” Technical Report CORR 98-05, Dept. of C&O, University of Waterloo,
28Canada, March 1998 (revised August 28, 1998). Available from http://www.cacr.math.uwaterloo.ca/.
29[B151] [LN94] Lidl, R., and Niederreiter, H. Introduction to Finite Fields and their Applications,
30Cambridge University Press, 1994.
31[B152] [LS03] Leadbitter, P. J. and Smart, N. "Cryptanalysis of MQV with partially known nonces," 6th
32Information Security Conference, ISC 2003, Springer, to appear. Earlier version available from
33http://eprint.iacr.org/2002/145/.
34[B153] [LS98] M. Liskov and R. D. Silverman, “A Statistical Limited-Knowledge Proof for Secure RSA
35Keys,” submitted to Journal of Cryptology, 1998.
36[B154] [LST+02] Lenstra, A. K., Shamir, A., Tomlinson, J., and Tromer, E. “Analysis of Bernstein’s
37Factorization Circuit,” Y. Zheng, Ed., Advances in Cryptology, ASIACRYPT 2002, Lecture Notes in
38Computer Science 2501 (2002), Springer, pp. 1-26. Also available via
39http://www.wisdom.weizmann.ac.il/~tromer/.
40[B155] [LZ94] G. Lay and H. Zimmer, “Constructing elliptic curves with given group order over large
41finite fields,” Algorithmic Number Theory: First International Symposium, Lecture Notes in Computer
42Science 877 (1994), Springer-Verlag, 250-263.
43[B156] [Man01] Manger, J. “A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption
44Padding (OAEP) as Standardized in PKCS #1 v2.0,” J. Kilian, Ed., Advances in Cryptology, CRYPTO
452001, Lecture Notes in Computer Science 2139 (2001), Springer, pp. 230-238.
2 350
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B157] [MASD99] Myers, M., Adams, C., Solo, D., and Kemp, D. “RFC 2511: Internet X.509 Certificate
2Request Format,” Internet Activities Board, March 1999. Available at http://www.rfc-editor.org/..
3[B158] [Mau91] U. M. Maurer, “A universal statistical test for random bit generators,” A.J. Menezes and
4S. A. Vanstone, editors, Advances in Cryptology — CRYPTO ‘90, Lecture Notes in Computer Science 537
5(1991), Springer-Verlag, 409-420.
6[B159] [Mau95] U. M. Maurer, “Fast generation of prime numbers and secure public-key cryptographic
7parameters,” Journal of Cryptology 8 (1995), 123-155.
8[B160] [Men93a] A. Menezes, editor, Applications of Finite Fields, Kluwer Academic Publishers, 1993.
9[B161] [Men93b] A. Menezes, Elliptic Curve Public Key Cryptosystems, Kluwer Academic Publishers,
101993.
11[B162] [Men95] A. Menezes, “Elliptic Curve Cryptosystems,” CryptoBytes vol. 1 no. 2 (Summer 1995),
12RSA Laboratories, ftp://ftp.rsa.com/pub/cryptobytes/crypto1n2.pdf
13[B163] [Mih94] P. Mihailescu, “Fast generation of provable primes using search in arithmetic
14progressions,” Yvo G. Desmedt, editor, Advances in Cryptology — CRYPTO ‘94, Lecture Notes in
15Computer Science 839 (1994), Springer-Verlag, 282-293.
16[B164] [Mih97] Mihailescu, P., “Optimal Galois Bases which are not Normal,” presented at Fast Software
17Encryption rump session, FSE ’97 (Haifa, Israel, January 20-22, 1997).
18[B165] [Mil86] V. S. Miller, “Use of elliptic curves in cryptography,” H. C. Williams, editor, Advances
19in Cryptology – Crypto ’85, Lecture Notes in Computer Science 218 (1986), Springer-Verlag, 417-426.
20[B166] [MLSW00] Myers, M., Liu, X., Schaad, J., and Weinstein, J. “IETF RFC 2797: Certificate
21Management Messages over CMS,” April 2000. Available at http://www.rfc-editor.org/.
22[B167] [MNP+98] M’Raïhi, D., Naccache, D., Pointcheval, D., and Vaudenay, S. “Computational
23Alternatives to Random Number Generators,” S. Tavares and H. Meijer, Eds., Selected Areas in
24Cryptography, SAC ’98, , Lecture Notes in Computer Science 1556 (1999), Springer, pp. 72-80.
25[B168] [Mor91] F. Morain, “Building cyclic elliptic curves modulo large primes,” D. W. Davies, editor,
26Advances in Cryptology - EUROCRYPT ‘91, Lecture Notes in Computer Science 547 (1991), Springer-
27Verlag, 328-336.
28[B169] [MOV93] A. Menezes, T. Okamoto and S. Vanstone, “Reducing elliptic curve logarithms to
29logarithms in a finite field,” IEEE Transactions on Information Theory 39 (1993), 1639-1646.
30[B170] [MOV96] A. Menezes, P. van Oorschot and S. Vanstone, Handbook of Applied Cryptography,
31CRC Press, Boca Raton, Florida, 1996.
32[B171] [MQV95] A. Menezes, M. Qu and S. Vanstone, “Some new key agreement protocols providing
33implicit authentication,” workshop record, 2nd Workshop on Selected Areas in Cryptography (SAC’95),
34Ottawa, Canada, May 18-19, 1995, 22-32.
35[B172] [MRS88] S. Micali, C. Rackoff and B. Sloan, “The notion of security for probabilistic
36cryptosystems,” SIAM Journal on Computing 17 (1988), 412-426.
37[B173] [MS91] S. Micali and C. P. Schnorr, “Efficient, perfect polynomial random number generators,”
38Journal of Cryptology 3 (1991), 157-172.
39[B174] [MTI86] T. Matsumoto, Y. Takashima and H. Imai, “On seeking smart public-key-distribution
40systems,” The Transactions of the IECE of Japan E69 (1986), 99-106.
41[B175] [MV97] MasterCard International, Inc. and Visa International Service Association, SET Secure
42Electronic Transaction Specification, May 31, 1997. Available from http://www.setco.org/.
43[B176] [Ngu01] Nguyen, P. Q. “The Dark Side of the Hidden Number Problem: Lattice Attacks on DSA,”
44K. Lam, I. Shparlinski,, H. Wang, and C. Xing, Eds., Cryptography and Computational Number Theory,
45CCNT ’99, Progress in Computer Science and Applied Logic 20 (2001), Birkhäuser, pp. 321-330.
2 351
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B177] [NIS99] National Institute of Standards and Technology (NIST), “Recommended Elliptic Curves
2for Federal Government Use” (draft), 1999. Available at http://csrc.nist.gov/CryptoToolkit/tkdigsigs.html.
3Published as Appendix 6 of [B56].
4[B178] [NIST03a] National Institute of Standards and Technology. NIST Special Publication 800-56:
5Recommendation on Key Establishment Schemes. Draft 2.0, January 2003. Available at http://csrc.nist.gov/.
6[B179] [NIST03b] National Institute of Standards and Technology. NIST Special Publication 800-57:
7Recommendation for Key Management, Part 1: General Guideline. Draft, January 2003. Available at
8http://csrc.nist.gov/.
9[B180] [NIST03c] National Institute of Standards and Technology. NIST Special Publication 800-57:
10Recommendation for Key Management, Part 2: Best Practices for Key Management Organization. Draft,
11January 2003. Available at http://csrc.nist.gov/.
12[B181] [NMV+95] Naccache, D., M’Raïhi, D., Vaudenay, S., and Raphaeli, D. “Can D.S.A. Be
13Improved? Complexity Trade-offs with the Digital Signature Standard,” A. De Santis, Ed., Advances in
14Cryptology, EUROCRYPT ’94, Lecture Notes in Computer Science 950 (1995), Springer, pp. 77-85.
15[B182] [NR93] K. Nyberg and R. Rueppel, “A new signature scheme based on the DSA giving message
16recovery,” First ACM Conference on Computer and Communcations Security (1993), ACM Press, 58-61.
17[B183] [NS02a] Nguyen, P. Q., and Shparlinski, I. E. “The Insecurity of the Digital Signature Algorithm
18with Partially Known Nonces,” Journal of Cryptology 15 (2002), pp. 151-176. Available at
19http://www.comp.mq.edu.au/~igor/Publ.html.
20[B184] [NS02b] Nguyen, P. Q., and Shparlinski, I. E., “The Insecurity of the Elliptic Curve Digital
21Signature Algorithm with Partially Known Nonces,” Designs, Codes and Cryptography, to appear.
22Available at http://www.comp.mq.edu.au/~igor/Publ.html.
23[B185] [NTT01] NTT, Self-Evaluation of EPOC-2: (Revised) Submission to NESSIE. 2001. Available at
24http://info.isl.ntt.co.jp/epoc/.
25[B186] [Odl95] A. M. Odlyzko, “The Future of Integer Factorization,” CryptoBytes vol. 1 no. 2 (Summer
261995), RSA Laboratories, ftp://ftp.rsa.com/pub/cryptobytes/crypto1n2.pdf
27[B187] [Oka90] Okamoto, T. “A Fast Signature Scheme Based on Congruential Polynomial Operations,”
28IEEE Transactions on Information Theory 36 (1990), pp. 47-53.
29[B188] [OU98] Okamoto, T., and Uchiyama, S. “A New Public-Key Cryptosystem as Secure as
30Factoring,” K. Nyberg, Ed., Advances in Cryptology, EUROCRYPT ’98, Lecture Notes in Computer
31Science 1403 (1998), Springer, pp. 308-318.
32[B189] [OW94] P. van Oorschot and M. Wiener, “Parallel collision search with applications to hash
33functions and discrete logarithms,” 2nd ACM Conference on Computer and Communications Security
34(1994), ACM Press, 210-218.
35[B190] [Per97] Peralta, R. “Bleichenbacher’s Improvement for Factoring Numbers of the Form N = P2Q,”
36unpublished communication, 1997.
37[B191] [PKC93] Public Key Cryptography Standards (PKCS). PKCS #1 v1.5: RSA Encryption Standard.
38November 1, 1993. Available from http://www.rsa.com/rsalabs/pubs/PKCS/.
39[B192] [PKC98] Public Key Cryptography Standards (PKCS). PKCS #1 v2.0: RSA Cryptography
40Standard. 1998. Available from http://www.rsa.com/rsalabs/pubs/PKCS/.
41[B193] [PKCS1v2_1] Public-key Cryptography Standards (PKCS), PKCS #1 v2.1: RSA Cryptography
42Standard, 2002. Available at http://www.rsasecurity.com/rsalabs/pkcs/.
43[B194] [PKCS-5-v1_5] Public-Key Cryptography Standards (PKCS). PKCS #5 v1.5: Password-Based
44Encryption Standard, November 1, 1993. Available at http://www.rsasecurity.com/rsalabs/pkcs/.
45[B195] [PO96] Peralta, R., and Okamoto, E. “Faster Factoring of Integers of a Special Form,” IEICE
46Trans. Fundamentals, E79-A (1996), pp. 489-493.
2 352
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B196] [Pol74] J. M. Pollard, “Theorems on factorization and primality testing,” Proceedings of the
2Cambridge Philosphical Society 76 (1974), 521-528.
3[B197] [Pol75] J. M. Pollard, “A Monte Carlo method for factorization,” BIT 15 (1975), 331-334.
4[B198] [Pol78] J. M. Pollard, “Monte Carlo methods for index computation (mod p),” Mathematics of
5Computation 32 (1978), 918-924.
6[B199] [Pol97] Pollard, J. L. Manuscript (1997).
7[B200] [PV00] Pintsov, L. A. and Vanstone, S. A. “Postal Revenue Collection in the Digital Age,” Y.
8Frankel, Ed., Financial Cryptography, FC ’00, Lecture Notes in Computer Science 1962 (2000), Springer,
9pp. 105-120.
10[B201] [Rab79] M. O. Rabin, “Digitalized signatures and public-key functions as intractable as
11factorization,” Massachusetts Institute of Technology Laboratory for Computer Science Technical Report
12212 (MIT/LCS/TR-212), 1979.
13[B202] [Res99] Rescorla, E. “RFC 2631: Diffie-Hellman Key Agreement Method,” Internet Activities
14Board, June 1999. Available at http://www.rfc-editor.org/.
15[B203] [Rie94] Hans Riesel. Prime Numbers and Computer Methods for Factorization, Birkhäuser, 1994
16(2nd edition).
17[B204] [RSA78] R. L. Rivest, A. Shamir and L. M. Adleman, “A method for obtaining digital signatures
18and public-key cryptosystems,” Communications of the ACM 21 (1978), 120-126.
19[B205] [SA98] T. Satoh and K. Araki, “Fermat quotients and the polynomial time discrete log algorithm
20for anomalous elliptic curves,” Commentarii Mathematici Universitatis Sancti Pauli 47 (1998), 81-92.
21Errata: ibid. 48(1999), 211-213.
22[B206] [Sch93] O. Schirokauer, “Discrete logarithms and local units,” Philosophical transactions of the
23Royal Society of London A, 345 (1993), 409-423.
24[B207] [Sch95] B. Schneier, Applied Cryptography : Protocols, Algorithms, and Source Code in C,
25Second Edition, John Wiley and Sons, 1995.
26[B208] [SE02] Schroeppel, R. C., and Eastlake, D., 3 rd, “ECC KEYs in the DNS,” Internet-Draft
27http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-02.txt, May 2002 (work in progress, expires
28November 2002).
29[B209] [SEC-1] Standards for Efficient Cryptography, SEC1: Elliptic Curve Cryptography, v1.0,
30September 20, 2000. Available at http://www.secg.org/.
31[B210] [SEC99] Standards for Efficient Cryptography, “SEC2: Recommended Elliptic Curve Domain
32Parameters,” September 2002. Available at http://www.secg.org/secg_docs.htm.
33[B211] [Ser98] G. Seroussi, “Compact representation of elliptic curve points over F2n.” Research
34Manuscript, Hewlett-Packard Laboratories, April 1998.
35[B212] [Sha86] J. Shawe-Taylor, “Generating strong primes,” Electronics Letters 22 (July 31, 1986), 875-
36877.
37[B213] [Sha95] A. Shamir, “RSA for Paranoids,” CryptoBytes vol. 1 no. 3 (Autumn 1995), RSA
38Laboratories, ftp://ftp.rsa.com/pub/cryptobytes/crypto1n3.pdf.
39[B214] [Shi01] Shipsey, R. ESIGN, NESSIE public report NES\DOC\RHU\WP3\005\b, January 31, 2001.
40Available at https://www.cosic.esat.kuleuven.ac.be/nessie/reports/rhuwp3-005b.pdf.
41[B215] [Sho01a] Shoup. V. “OAEP Reconsidered,” J. Kilian, Ed., Advances in Cryptology, CRYPTO
422001, Lecture Notes in Computer Science 2139 (2001), Springer, pp. 239-259.
43[B216] [Sho01b] Shoup, V. “A Proposal for an ISO Standard for Public Key Encryption (version 2.1),”
44Dec. 20, 2001. Available at http://shoup.net/.
45[B217] [Sil86] J. Silverman, The Arithmetic of Elliptic Curves, Springer-Verlag, 1986.
2 353
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009
1[B218] [Sil87] R. D. Silverman, “The multiple polynomial quadratic sieve,” Mathematics of Computation
248 (1987), 329-339.
3[B219] [Sim94] Simmons, G. J. “Subliminal Communications is Easy Using the DSA,” T. Helleseth, Ed.,
4Advances in Cryptology, EUROCRYPT ’93, Lecture Notes in Computer Science 765 (1994), pp. 218-232.
5[B220] [Sma99] N. P. Smart, “Elliptic Curve Cryptosystems over Small Fields of Odd Characteristic,” J.
6Cryptology vol. 12. (1999), pp. 141-151.
7[B221] [SOM95] R. Schroeppel, H. Orman, S. O’Malley, and O. Spatscheck. “Fast key exchange with
8elliptic curve systems,” Univ. of Arizona Comp. Sci. Tech. Report 95-03 (1995). A version also appears in
9D. Coppersmith, editor, Advances in Cryptology — CRYPTO ‘95, Lecture Notes in Computer Science 963
10(1995), Springer-Verlag, 43-56.
11[B222] [ST03] Shamir, A. and Tromer, E. “Factoring Large Numbers with the TWIRL Device,” D.
12Boneh, Ed., Advances in Cryptology, CRYPTO 2003, Lecture Notes in Computer Science 2729 (2003),
13Springer, pp. 1-26. Available via http://www.wisdom.weizmann.ac.il/~tromer/.
14[B223] [Sta98] William Stallings, Cryptography and Network Security: Principles and Practice, Second
15Edition, Prentice-Hall, 1998.
16[B224] [Sti95] Douglas R. Stinson, Cryptography: Theory and Practice, CRC Press, 1995.
17[B225] [SWD96] Schirokauer, O., Weber, D., and Denny, T. “Discrete Logarithms: the Effectiveness of
18the Index Calculus Method,” H. Cohen, Algorithmic Number Theory, ANTS-II, Lecture Notes in Computer
19Science 1122 (1996), Springer, pp. 337-361.
20[B226] [Vau96] S. Vaudenay, “Hidden collisions on DSS,” N. Koblitz, editor, Advances in Cryptology –
21CRYPTO ‘96, Lecture Notes in Computer Science 1109 (1996), Springer-Verlag, 83-88.
22[B227] [VGT88a] Vallée, B., Girault, M., and Toffin, P. “How to Break Okamoto’s Cryptosystem by
23Reducing Lattice Bases,” C. G. Günther, Ed., Advances in Cryptology, EUROCRYPT ’88, Lecture Notes
24in Computer Science 330 (1988), Springer, pp. 281-291.
25[B228] [VGT88b] Vallée, B., Girault, M., and Toffin. P. “How to Guess L-th Roots Modulo n by
26Reducing Lattice Bases,” T. Mora, Ed., Applied Algebra, Algebraic Algorithms and Error-Correcting
27Codes, AAECC-6 and ISSAC ’88, Lecture Notes in Computer Science 357 (1988), Springer.
28[B229] [Wie90] M. J. Wiener, “Cryptanalysis of short RSA secret exponents,” IEEE Transactions on
29Information Theory 36 (1990), 553-558
30[B230] [Wil80] H. C. Williams, “A modification on the RSA public-key encryption procedure,” IEEE
31Transactions of Information Theory 26 (1980), 726-729.
32[B231] [Wil82] H. C. Williams, “A p + 1 method of factoring,” Mathematics of Computation 39 (1982),
33225-234.
34[B232] [WZ98] M. J. Wiener and R. Zuccherato, “Faster Attacks on Elliptic Curve Cryptosystems,” S.
35Tavares and H. Meijer, editors, Selected Areas in Cryptography – SAC ’98, Lecture Notes in Computer
36Science (1998), Springer-Verlag.
37[B233] A. C. Yao, “Theory and applications of trapdoor functions,” Proccedings of the IEEE 23rd
38Annual Symposium on Foundations of Computer Science (FOCS ’92), 1992, 80-91.
39[B234] [Kra05] HMQV
40[B235] [Hitt07] L. Hitt, “On the minimal embedding field”, Pairing-Based Cryptography – Pairing 2007,
41Lecture Notes in Computer Science vol 4575, pages 294–301. Springer-Verlag, Berlin, 2007.
2 354
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.