Вы находитесь на странице: 1из 362

1 IEEE P1363/D1-pre, June 2009

1IEEE
2PvarDesignation™/DvarDraftNumber

3DrafttxtTrialUsetxtGorRPorSTD for

4varTitlePAR

5Prepared by the varWorkingGroup Working Group of the

6varCommittee Committee

7Copyright © <year> by the Institute of Electrical and Electronics Engineers, Inc.


8Three Park Avenue
9New York, New York 10016-5997, USA
10All rights reserved.

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

2 Copyright © <year> IEEE. All rights reserved.


3 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009

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

2The Institute of Electrical and Electronics Engineers, Inc.


33 Park Avenue, New York, NY 10016-5997, USA
4
5Copyright © 200X by the Institute of Electrical and Electronics Engineers, Inc.
6All rights reserved. Published XX Month XXXX. Printed in the United States of America.
7
8IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics
9Engineers, Incorporated.
10
11PDF: ISBN 978-0-XXXX-XXXX-X STDXXXXX
12Print: ISBN 978-0-XXXX-XXXX-X STDPDXXXXX
13
14No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written
15permission of the publisher.

16 Copyright © <year> IEEE. All rights reserved.


17 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009

1This page is left blank intentionally.

2 Copyright © <year> IEEE. All rights reserved.


3 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009

1Introduction

2This introduction is not part of IEEE PvarDesignation/DvarDraftNumber, DrafttxtTrialUsetxtGorRPorSTD for


3varTitlePAR.

4<Select this text and type or paste introduction text>

5Notice to users

6Laws and regulations


7Users of these documents should consult all applicable laws and regulations. Compliance with the
8provisions of this standard does not imply compliance to any applicable regulatory requirements.
9Implementers of the standard are responsible for observing or referring to the applicable regulatory
10requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in
11compliance with applicable laws, and these documents may not be construed as doing so.

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.

18Updating of IEEE documents


19Users of IEEE standards should be aware that these documents may be superseded at any time by the
20issuance of new editions or may be amended from time to time through the issuance of amendments,
21corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
22document together with any amendments, corrigenda, or errata then in effect. In order to determine whether
23a given document is the current edition and whether it has been amended through the issuance of
24amendments, corrigenda, or errata, visit the IEEE Standards Association web site at
25http://ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously.

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

3IEEE P1363 / D1-pre (Draft Version 13)

4Standard Specifications
5for Public Key Cryptography
6

7TO DO for entire standard:

8Fix formatting, especially for bulleted and numbered lists.

9Recreate diagrams using Visio.

10Review all security considerations and update with results since 2004.

11Fix all cross-references to be automatically generated and hyperlinked

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.

21Keywords. Public-key cryptography; key agreement; digital signature; encryption.

22

2
1

2Copyright © 1999 by the Institute of Electrical and Electronics Engineers, Inc.


3345 East 47th Street
4New York, NY 10017, USA
5All rights reserved.

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.

14IEEE Standards Department


15Copyright and Permissions
16445 Hoes Lane, P. O. Box 1331
17Piscataway, NJ 08855-1331, USA

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

104. Types of Cryptographic Techniques..........................................................................................................20


11 4.1 General Model.....................................................................................................................................20
12 4.2 Primitives.............................................................................................................................................20
13 4.3 Schemes...............................................................................................................................................21
14 4.4 Additional Methods.............................................................................................................................22
15 4.5 Table Summary....................................................................................................................................23

165. Mathematical Conventions.........................................................................................................................25


17 5.1 Mathematical Notation........................................................................................................................25
18 5.2 Bit Strings and Octet Strings...............................................................................................................26
19 5.3 Finite Fields.........................................................................................................................................27
20 5.3.1 Prime Finite Fields............................................................................................27
21 5.3.2 Characteristic Two Finite Fields.......................................................................27
22 5.3.3 Composite basis over GF(2d)............................................................................28
23 5.3.4 Odd characteristic extension fields...................................................................29
24 5.4 Elliptic Curves and Points...................................................................................................................30
25 5.5 Data Type Conversion.........................................................................................................................30
26 5.5.1 Converting Between Integers and Bit Strings (I2BSP and BS2IP)..................31
27 5.5.2 Converting Between Bit Strings and Octet Strings (BS2OSP and OS2BSP). .31
28 5.5.3 Converting between Integers and Octet Strings (I2OSP and OS2IP)...............32
29 5.5.4 Converting between Finite Field Elements and Octet Strings (FE2OSP and
30 OS2FEP)....................................................................................................................32
31 5.5.5 Converting Finite Field Elements to Integers (FE2IP).....................................32
32 5.5.6 Converting between elliptic curve points and octet strings..............................33
336. Primitives Based on the Discrete Logarithm Problem...............................................................................38
34 6.1 The DL Setting....................................................................................................................................38
35 6.1.1 Notation............................................................................................................38
36 6.1.2 DL Domain Parameters....................................................................................39
37 6.1.3 DL Key Pairs....................................................................................................39
38 6.2 Primitives.............................................................................................................................................40
39 6.2.1 DLSVDP-DH....................................................................................................40
40 6.2.2 DLSVDP-DHC.................................................................................................41
41 6.2.3 DLSVDP-MQV................................................................................................42
42 6.2.4 DLSVDP-MQVC.............................................................................................43
43 6.2.5 DLSVDP-HMQV.............................................................................................45
44 6.2.6 DLSVDP-HMQVC...........................................................................................47

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

107. Primitives Based on the Elliptic Curve Discrete Logarithm Problem........................................................57


11 7.1 The EC Setting.....................................................................................................................................57
12 7.1.1 Notation............................................................................................................57
13 7.1.2 EC Domain Parameters.....................................................................................58
14 7.1.3 EC Key Pairs.....................................................................................................58
15 7.2 Primitives.............................................................................................................................................59
16 7.2.1 ECSVDP-DH....................................................................................................59
17 7.2.2 ECSVDP-DHC.................................................................................................60
18 7.2.3 ECSVDP-MQV................................................................................................61
19 7.2.4 ECSVDP-MQVC..............................................................................................63
20 7.2.5 ECSVDP-HMQV.............................................................................................64
21 7.2.6 ECSVDP-HMQVC...........................................................................................65
22 7.2.7 ECSP-NR..........................................................................................................67
23 7.2.8 ECVP-NR.........................................................................................................68
24 7.2.9 ECSP-DSA.......................................................................................................69
25 7.2.10 ECVP-DSA.....................................................................................................70
26 7.2.11 ECPSP-NR2/PV.............................................................................................70
27 7.2.12 ECSP-NR2......................................................................................................71
28 7.2.13 ECVP-NR2.....................................................................................................72
29 7.2.14 ECSP-PV........................................................................................................73
30 7.2.15 ECVP-PV........................................................................................................75
318. 8. Primitives Based on the Integer Factorization Problem.........................................................................76
32 8.1 8.1 The IF Setting................................................................................................................................76
33 8.1.1 Notation............................................................................................................76
34 8.1.2 Domain Parameters in the IF Family................................................................77
35 8.1.3 Keys in the IF Family.......................................................................................77
36 8.2 Primitives.............................................................................................................................................79
37 8.2.1 IF Private Key Operation..................................................................................79
38 8.2.2 IFEP-RSA.........................................................................................................80
39 8.2.3 IFDP-RSA.........................................................................................................80
40 8.2.4 IFSP-RSA1.......................................................................................................81
41 8.2.5 IFVP-RSA1.......................................................................................................82
42 8.2.6 IFSP-RSA2.......................................................................................................82
43 8.2.7 IFVP-RSA2.......................................................................................................83
44 8.2.8 IFSP-RW...........................................................................................................84
45 8.2.9 IFVP-RW..........................................................................................................84
46 8.2.10 IFEP-OU.........................................................................................................85
2 3
3 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.2.11 IFDP-OU.........................................................................................................87
2 8.2.12 IFSP-ESIGN...................................................................................................87
3 8.2.13 IFVP-ESIGN...................................................................................................88

49. Key Agreement Schemes...........................................................................................................................90


5 9.1 General Model.....................................................................................................................................90
6 9.2 DL/ECKAS-DH1.................................................................................................................................91
7 9.2.1 Scheme options.................................................................................................92
8 9.2.2 Key Agreement Operation................................................................................93
9 9.3 DL/ECKAS-DH2.................................................................................................................................93
10 9.3.1 Scheme Options................................................................................................94
11 9.3.2 Key Agreement Operation................................................................................95
12 9.4 DL/ECKAS-MQV...............................................................................................................................96
13 9.4.1 Scheme Options................................................................................................97
14 9.4.2 Key Agreement Operation................................................................................97
1510. Key Encapsulation Schemes.....................................................................................................................98
16 10.1 General Model...................................................................................................................................98
17 10.2 IFKEM-RSA....................................................................................................................................100
18 10.2.1 Scheme options.............................................................................................100
19 10.2.2 IFKEM-RSA.Encapsulate operation............................................................100
20 10.2.3 IFKEM-RSA.Recover operation..................................................................101
21 10.3 ECKEM-PSEC................................................................................................................................101
22 10.3.1 Scheme options.............................................................................................101
23 10.3.2 IFKEM-PSEC.Encapsulate operation...........................................................102
24 10.3.3 ECKEM-PSEC.Recover operation...............................................................102
2511. Encryption Schemes...............................................................................................................................103
26 11.1 General Model.................................................................................................................................103
27 11.2 IFES.................................................................................................................................................105
28 11.2.1 Scheme Options............................................................................................105
29 11.2.2 Encryption Operation....................................................................................105
30 11.2.3 Decryption Operation...................................................................................106
31 11.3 DL/ECIES........................................................................................................................................107
32 11.3.1 Scheme options.............................................................................................107
33 11.3.2 Encryption operation....................................................................................108
34 11.3.3 Decryption operation....................................................................................110
35 11.4 IFES-EPOC.....................................................................................................................................111
36 11.4.1 Scheme options.............................................................................................111
37 11.4.2 Encryption operation....................................................................................112
38 11.4.3 Decryption operation....................................................................................112

3912. Signature Schemes..................................................................................................................................113


40 12.1 General Model.................................................................................................................................113
41 12.2 DL/ECSSA......................................................................................................................................115
42 12.2.1 Scheme Options............................................................................................116
43 12.2.2 Signature Generation Operation...................................................................116
44 12.2.3 Signature Verification Operation..................................................................117
45 12.3 IFSSA..............................................................................................................................................118
46 12.3.1 Scheme Options............................................................................................118

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

1 12.3.2 Signature Generation Operation...................................................................119


2 12.3.3 Signature Verification Operation..................................................................119
3 12.4 DL/ECSSR.......................................................................................................................................120
4 12.4.1 Scheme options.............................................................................................120
5 12.4.2 Signature generation operation.....................................................................121
6 12.4.3 Signature verification operation...................................................................121
7 12.5 DL/ECSSR-PV................................................................................................................................122
8 12.5.1 Scheme options.............................................................................................123
9 12.5.2 Signature generation operation.....................................................................124
10 12.5.3 Signature verification operation...................................................................124
11 12.6 10.6 IFSSR.......................................................................................................................................126
12 12.6.1 Scheme options.............................................................................................126
13 12.6.2 Signature generation operation.....................................................................127
14 12.6.3 Signature verification operation...................................................................127
1513. Message Encoding Methods...................................................................................................................129
16 13.1 Message Encoding Methods for Signatures with Appendix...........................................................129
17 13.1.1 EMSA1.........................................................................................................129
18 13.1.2 EMSA2.........................................................................................................131
19 13.1.3 EMSA3.........................................................................................................133
20 13.1.4 EMSA4.........................................................................................................134
21 13.1.5 EMSA5.........................................................................................................136
22 13.2 Message Encoding Methods for Encryption...................................................................................137
23 13.2.1 EME1............................................................................................................137
24 13.2.2 EME2............................................................................................................139
25 13.2.3 EME3............................................................................................................141
26 13.3 Message-encoding methods for signatures giving message recovery.............................................144
27 13.3.1 EMSR1.........................................................................................................144
28 13.3.2 EMSR2.........................................................................................................146
29 13.3.3 EMSR3.........................................................................................................149
3014. Key Derivation Functions.......................................................................................................................152
31 14.1 KDF1...............................................................................................................................................152
32 14.2 KDF2...............................................................................................................................................153

3315. Auxiliary Functions................................................................................................................................155


34 15.1 Hash Functions................................................................................................................................155
35 15.1.1 SHA-1...........................................................................................................155
36 15.1.2 RIPEMD-160................................................................................................156
37 15.1.3 SHA-256.......................................................................................................156
38 15.1.4 SHA-384.......................................................................................................156
39 15.1.5 SHA-512.......................................................................................................157
40 15.2 Mask Generation Functions.............................................................................................................157
41 15.2.1 MGF1............................................................................................................157
42 15.3 Symmetric encryption schemes.......................................................................................................158
43 15.3.1 Triple-DES-CBC-IV0...................................................................................159
44 15.3.2 AES-CBC-IV0..............................................................................................161
45 15.4 Message authentication codes.........................................................................................................162
46 15.4.1 MAC1...........................................................................................................162

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

3Annex A (Informative) Number-Theoretic Algorithms...............................................................................173


4 A.1 Integer and Modular Arithmetic: Overview.....................................................................................173
5 A.1.1 Modular arithmetic........................................................................................173
6 A.1.2 Prime finite fields...........................................................................................174
7 A.1.3 Composite Moduli.........................................................................................175
8 A.1.4 Modular Square Roots...................................................................................176
9 A.2 Integer and Modular Arithmetic: Algorithms...................................................................................178
10 A.2.1 Modular Exponentiation................................................................................178
11 A.2.2 The Extended Euclidean Algorithm..............................................................178
12 A.2.3 Evaluating Jacobi Symbols............................................................................179
13 A.2.4 Generating Lucas Sequences.........................................................................179
14 A.2.5 Finding Square Roots Modulo a Prime..........................................................180
15 A.2.6 Finding Square Roots Modulo a Power of 2..................................................181
16 A.2.7 Computing the Order of a Given Integer Modulo a Prime............................181
17 A.2.8 Constructing an Integer of a Given Order Modulo a Prime..........................182
18 A.2.9 An implementation of IF signature primitives (RSA and RW cases)............182
19 A.2.10 Multiplication in (Z/p2Z)..............................................................................184
20 A.2.11 An implementation of IFES-EPOC decryption...........................................184
21 A.3 Binary Finite Fields: Overview........................................................................................................185
22 A.3.1 Finite Fields...................................................................................................185
23 A.3.2 Polynomials over Finite Fields......................................................................185
24 A.3.3 Binary Finite Fields.......................................................................................186
25 A.3.4 Polynomial Basis Representations.................................................................187
26 A.3.5 Normal Basis Representations.......................................................................188
27 A.3.6 Checking for a Gaussian Normal Basis.........................................................188
28 A.3.7 The Multiplication Rule for a Gaussian Normal Basis..................................189
29 A.3.8 A Multiplication Algorithm for a Gaussian Normal Basis............................190
30 A.3.9 Binary Finite Fields (cont'd)..........................................................................191
31 A.3.10 Parameters for Common Key Sizes.............................................................192
32 A.4 Binary Finite Fields: Algorithms......................................................................................................193
33 A.4.1 Squaring and Square Roots............................................................................193
34 A.4.2 The Squaring Matrix......................................................................................193
35 A.4.3 Exponentiation...............................................................................................194
36 A.4.4 Division..........................................................................................................194
37 A.4.5 Trace..............................................................................................................196
38 A.4.6 Half-Trace......................................................................................................197
39 A.4.7 Solving Quadratic Equations over GF (2m)...................................................197
40 A.5 Polynomials over a Finite Field........................................................................................................198
41 A.5.1 Exponentiation Modulo a Polynomial...........................................................198
42 A.5.2 G.C.D.'s over a Finite Field...........................................................................199
43 A.5.3 Factoring Polynomials over GF (p) (Special Case).......................................199
44 A.5.4 Factoring Polynomials over GF (2) (Special Case).......................................200
45 A.5.5 Checking Polynomials over GF (2r) for Irreducibility..................................200
46 A.5.6 Finding a Root in GF (2m) of an Irreducible Binary Polynomial...................200
47 A.5.7 Embedding in an Extension Field..................................................................201
2 6
3 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.6 General Normal Bases for Binary Fields..........................................................................................201


2 A.6.1 Checking for a Normal Basis.........................................................................202
3 A.6.2 Finding a Normal Basis.................................................................................202
4 A.6.3 Computing the Multiplication Matrix............................................................203
5 A.6.4 Multiplication.................................................................................................204
6 A.7 Basis Conversion for Binary Fields..................................................................................................206
7 A.7.1 The Change-of-Basis Matrix.........................................................................206
8 A.7.2 The Field Polynomial of a Gaussian Normal Basis.......................................207
9 A.7.3 Computing the Change-of-Basis Matrix........................................................208
10 A.7.4 Conversion to a Polynomial Basis.................................................................211
11 A.7.5 Storage-efficient conversion techniques........................................................212
12 A.7.6 Storage-efficient import.................................................................................212
13 A.7.7 Multiplication matrix for a polynomial basis................................................214
14 A.7.8 Storage-efficient export.................................................................................215
15 A.8 Bases for Binary Fields: Tables and Algorithms..............................................................................219
16 A.8.1 Basis Table.....................................................................................................219
17 A.8.2 Random Search for Other Irreducible Polynomials.......................................224
18 A.8.3 Irreducibles from Other Irreducibles.............................................................224
19 A.8.4 Irreducibles of Even Degree..........................................................................225
20 A.8.5 Irreducible Trinomials...................................................................................226
21 A.9 Elliptic Curves: Overview................................................................................................................226
22 A.9.1 Introduction....................................................................................................226
23 A.9.2 Operations on Elliptic Curves........................................................................228
24 A.9.3 Elliptic Curve Cryptography..........................................................................228
25 A.9.4 Analogies with DL.........................................................................................229
26 A.9.5 Curve Orders..................................................................................................229
27 A.9.6 Representation of Points................................................................................231
28 A.10 Elliptic Curves: Algorithms...........................................................................................................233
29 A.10.1 Full Addition and Subtraction (prime case).................................................233
30 A.10.2 Full Addition and Subtraction (binary case)................................................233
31 A.10.3 Elliptic Scalar Multiplication.......................................................................234
32 A.10.4 Projective Elliptic Doubling (prime case)...................................................235
33 A.10.5 Projective Elliptic Addition (prime case)....................................................236
34 A.10.6 Projective Elliptic Doubling (binary case)...................................................238
35 A.10.7 Projective Elliptic Addition (binary case)...................................................239
36 A.10.8 Projective Full Addition and Subtraction....................................................241
37 A.10.9 Projective Elliptic Scalar Multiplication......................................................242
38 A.11 Functions for Elliptic Curve Parameter and Key Generation.........................................................243
39 A.11.1 Finding a Random Point on an Elliptic Curve (prime case)........................243
40 A.11.2 Finding a Random Point on an Elliptic Curve (binary case).......................243
41 A.11.3 Finding a Point of Large Prime Order.........................................................244
42 A.11.4 Curve Orders over Small Binary Fields.......................................................244
43 A.11.5 Curve Orders over Extension Fields............................................................245
44 A.11.6 Curve Orders via Subfields..........................................................................245
45 A.12 Functions for Elliptic Curve Parameter and Key Validation..........................................................246
46 A.12.1 The MOV Condition....................................................................................246
47 1) Set t  tp mod r...........................................................................................................................247
48 2) If t = 1 then output “False” and stop.............................................................................................247

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

1 A.12.2 The Weil Pairing..........................................................................................247


2 A.12.3 Verification of Cofactor...............................................................................248
3 A.12.4 Constructing Verifiably Pseudo-Random Elliptic Curves (prime case)......250
4 A.12.5 Verification of Elliptic Curve Pseudo-Randomness (prime case)...............251
5 A.12.6 Constructing Verifiably Pseudo-Random Elliptic Curves (binary case).....252
6 A.12.7 Verification of Elliptic Curve Pseudo-Randomness (binary case)..............253
7 A.12.8 Decompression of y Coordinates (prime case)............................................254
8 A.12.9 Decompression of y coordinates (binary case, LSB form)..........................254
9 A.12.10 Decompression of x Coordinates (binary case).........................................255
10 A.12.11 Decompression of y coordinates (SORT form).........................................256
11 A.13 Class Group Calculations...............................................................................................................256
12 A.13.1 Overview......................................................................................................257
13 A.13.2 Class Group and Class Number...................................................................257
14 A.13.3 Reduced Class Polynomials.........................................................................258
15 A.14 Complex Multiplication..................................................................................................................261
16 A.14.1 Overview......................................................................................................261
17 A.14.2 Finding a Nearly Prime Order over GF (p).................................................262
18 A.14.3 Finding a Nearly Prime Order over GF (2m)................................................265
19 A.14.4 Constructing a Curve and Point (prime case)..............................................266
20 A.14.5 Constructing a Curve and Point (binary case).............................................269
21 A.15 Primality Tests and Proofs..............................................................................................................270
22 A.15.1 A Probabilistic Primality Test......................................................................270
23 A.15.2 Testing a Randomly Generated Integer for Primality..................................271
24 A.15.3 Validating Primality of a Given Integer......................................................271
25 A.15.4 Proving Primality.........................................................................................272
26 A.15.5 Testing for Near Primality...........................................................................273
27 A.15.6 Generating Random Primes.........................................................................274
28 A.15.7 Generating Random Primes with Congruence Conditions..........................274
29 A.15.8 Strong Primes...............................................................................................275
30 A.16 Generation and Validation of Parameters and Keys.......................................................................276
31 A.16.1 An Algorithm for Generating DL Parameters (prime case)........................276
32 A.16.2 An Algorithm for Validating DL Parameters (prime case).........................276
33 A.16.3 An Algorithm for Generating DL Parameters (binary case)........................277
34 A.16.4 An Algorithm for Validating DL Parameters (binary case)........................278
35 A.16.5 An Algorithm for Generating DL Keys.......................................................278
36 A.16.6 Algorithms for Validating DL Public Keys.................................................279
37 A.16.7 An Algorithm for Generating EC Parameters..............................................279
38 A.16.8 An Algorithm for Validating EC Parameters..............................................280
39 A.16.9 An Algorithm for Generating EC Keys.......................................................281
40 A.16.10 Algorithms for Validating EC Public Keys...............................................281
41 A.16.11 An Algorithm for Generating RSA Keys..................................................282
42 A.16.12 An Algorithm for Generating RW Keys....................................................283
43 A.17 Odd characteristic extension fields.................................................................................................283
44 A.17.1 Basic arithmetic in an odd characteristic extension field............................284
45 A.17.2 Optimal extension fields..............................................................................286
46 A.17.3 A.17.3 Optimal extension fields: algorithms...............................................286
47 A.17.4 Elliptic curve algorithms..............................................................................291

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

1 A.17.5 Domain parameters and keys.......................................................................292

2Annex B (Normative) Conformance............................................................................................................294


3 B.1 General Model..................................................................................................................................294
4 B.2 Conformance Requirements..............................................................................................................296
5 B.3 Examples...........................................................................................................................................297
6 B.3.1 DLSP-DSA.....................................................................................................297
7 B.3.2 DLSSA Signature Verification......................................................................298
8 B.3.3 IFSP-RSA2.....................................................................................................300
9 B.3.4 IFSSA Signature Verification........................................................................300

10Annex C (Informative) Rationale.................................................................................................................302


11 C.1 General..............................................................................................................................................302
12 C.1.1 Why are there three families of cryptographic techniques?...........................302
13 C.1.2 Why are primitives and schemes separated?..................................................302
14 C.1.3 How were the decisions made regarding the inclusion of individual schemes?
15 .................................................................................................................................302
16 C.1.4 Why are constraints on key sizes not specified?............................................303
17 C.1.5 Why are message encoding methods for encryption and signature needed?. 303
18 C.1.6 Why are key derivation functions needed?....................................................303
19 C.1.7 Why are data formats for input/output, keys, and domain parameters not
20 normative?...............................................................................................................303
21 C.2 Keys and domain parameters............................................................................................................303
22 C.2.1 Why allow all finite fields for the DL and EC families?...............................303
23 C.2.2 Why allow multiple representations for GF(2m)?..........................................304
24 C.3 Schemes............................................................................................................................................304
25 C.3.1 For the DL and EC families, why have three key agreement schemes (-DH1,
26 -DH2, and -MQV)?..................................................................................................304
27 C.3.2 For the DL and EC families, why have the “compatibility” option for the DHC
28 and MQVC primitives?............................................................................................304
29 C.3.3 For the EC and DL families, why have both DSA and NR signature schemes
30 with appendix?.........................................................................................................304
31 C.3.4 For the DL and EC families, why have two signature schemes giving message
32 recovery (DL/ECSSR and DL/ECSSR-PV)?..........................................................305
33 C.3.5 For the DL and EC families, why was the DL/ECIES encryption scheme
34 selected?...................................................................................................................305
35 C.3.6 For the IF family, why have RSA, RW and ESIGN signature schemes with the
36 various encoding methods?......................................................................................305
37 C.3.7 For the IF family, why was the IFSSR signature scheme giving message
38 recovery selected?....................................................................................................306
39 C.3.8 For the IF family, why are there no key agreement schemes?.......................306
40 C.3.9 For the IF family, why have two encryption schemes (IFIES and IFIES-
41 EPOC)?....................................................................................................................306
42 C.4 Additional methods...........................................................................................................................307
43 C.4.1 Why were the KDF1 and KDF2 key derivation functions selected?.............307
44 C.4.2 Why was the MGF1 mask generation function selected?..............................307
45 C.4.3 Why have SHA-1, RIPEMD-160, SHA-256, SHA-384 and SHA-512?.......307
46 C.4.4 Why have Triple-DES and AES?...................................................................308

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

1 C.4.5 Why was the MAC1 message authentication code selected?........................308

2Annex D (Informative) Security considerations...........................................................................................309


3 D.1 Introduction.......................................................................................................................................309
4 D.2 General Principles.............................................................................................................................310
5 D.3 Key Management Considerations.....................................................................................................311
6 D.3.1 Generation of Domain Parameters and Keys.................................................311
7 D.3.2 Authentication of Ownership.........................................................................312
8 D.3.3 Validation of Domain Parameters and Keys..................................................313
9 D.3.4 Cryptoperiod and Protection Lifetime of Domain Parameters and Keys......314
10 D.3.5 Usage Restrictions.........................................................................................314
11 D.3.6 Storage of domain parameters and keys........................................................315
12 D.4 Family-Specific Considerations........................................................................................................316
13 D.4.1 DL Family......................................................................................................316
14 D.4.2 EC Family......................................................................................................320
15 D.4.3 IF Family........................................................................................................324
16 D.5 Scheme-Specific Considerations......................................................................................................329
17 D.5.1 Key Agreement Schemes...............................................................................329
18 D.5.2 Signature Schemes.........................................................................................334
19 D.5.3 Encryption Schemes......................................................................................344
20 D.5.4 Key Encapsulation Schemes..........................................................................352
21 D.6 Random Number Generation............................................................................................................356
22 D.6.1 Random Seed.................................................................................................356
23 D.6.2 Pseudo-Random Bit Generation....................................................................358
24 D.7 Implementation Considerations........................................................................................................359

25Annex E (Informative) Formats...................................................................................................................360


26 E.1 Overview...........................................................................................................................................360
27 E.2 Representing basic data types as octet strings...................................................................................360
28 E.2.1 Integers (I2OSP and OS2IP)..........................................................................361
29 E.2.2 Finite Field Elements (FE2OSP and OS2FEP)..............................................361
30 E.2.3 Elliptic Curve Points (EC2OSP and OS2ECP).............................................361
31 E.2.4 Polynomials over GF(p), p  2 (PN2OSP and OS2PNP)..............................361
32 E.3 Representing outputs of schemes as octet strings.............................................................................362
33 E.3.1 Output data format for DL/EC signature schemes.........................................362
34 E.3.2 Output data format for IF signature schemes.................................................362
35 E.3.3 Output data format for IF encryption schemes...............................................363
36 E.3.4 Output data format for DL/EC encryption scheme........................................363

37Annex F (Informative) Information about Patents.......................................................................................364

38Annex G (Informative) Bibliography...........................................................................................................367

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.

171.3 Organization of the Document


18This standard contains two parts: the main document and annexes.

191.3.1 Structure of the Main Document

20  Clause 1 is a general overview.


21  Clause 2 provides references to other standards and publications.
22  Clause 3 defines some terms used throughout this standard.
23  Clause 4 gives an overview of the types of cryptographic techniques that are defined in this
24 standard.
25  Clause 5 describes certain mathematical conventions used in the standard, including notation and
26 representation of mathematical objects. It also defines formats to be used in communicating the
27 mathematical objects as well as primitives for data type conversion.
28  Clauses 6, 7, 8, 9, 10 and 11 define three families of cryptographic techniques: techniques based on
29 the discrete logarithm problem (DL), elliptic curve discrete logarithm problem (EC), and integer
30 factorization problem (IF). Clauses 6, 7 and 8 define the setting and primitives used in the DL, EC
31 and IF families, respectively. Clauses 9, 10 and 11 define key agreement schemes, signature
32 schemes and encryption schemes, respectively.
33  Clause 12 defines message encoding methods for signature and encryption schemes in Clauses 10
34 and 11.

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.

31.3.2 Structure of the Annexes

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

12. Normative references


2The following referenced documents are indispensable for the application of this document (i.e., they must
3be understood and used, so each referenced document is cited in text and its relationship to this document is
4explained). For dated references, only the edition cited applies. For undated references, the latest edition of
5the referenced document (including any amendments or corrigenda) applies.

6CHECK FOR UPDATES

7ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation.


8ANSI X9.71-2000, Keyed Hash Message Authentication Code (MAC).

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.

21ISO/IEC 10118-3:1998, Information Technology—Security techniques—Hash-functions—Part 3:


22Dedicated hash-functions.

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.

27FORMAT SEE ALSOs, etc.

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

13.bit length: See: length.

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.

43.characteristic: the prime integer p for the finite field GF(pm).

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.

383.family: See: cryptographic family.

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.

203.key pair: See: public/private key pair.

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.

273.least significant: See: last bit; last octet.

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
31log256 (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.

333.leftmost bit: See: first bit.

343.leftmost octet: See: first octet.

353.message recovery: See: signature with message recovery.

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

13.most significant: See: first bit; first octet.

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.

63.octet string: An ordered sequence of octets. See also: octet.

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.

103.parameters: See: domain parameters.

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.

303.rightmost bit: See: last bit.

313.rightmost octet: See: last octet.

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.

33.signature: See: digital signature.

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.

313.validation: See: domain parameter validation; 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

14. Types of Cryptographic Techniques


2This clause gives an overview of the types of cryptographic techniques that are specified in this standard as
3well as some requirements for conformance with those techniques. See Annex B for more on conformance.

44.1 General Model


5As stated in Clause 1, the purpose of this standard is to provide a reference for specifications of a variety of
6common public-key cryptographic techniques from which applications may select. Therefore, it is desirable
7to define these techniques in a framework that would allow selection of techniques appropriate for
8particular applications. Different types of cryptographic techniques can be viewed abstractly according to
9the following three-level general model.

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.

17The specification of a primitive consists of the following information:

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.

17The specification of a scheme consists of the following information:

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.

264.4 Additional Methods


27This standard specifies the following additional methods:

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.

94.5 Table Summary


10Table 1 gives a summary of all the schemes in this standard, together with the primitives and additional
11methods that are invoked within a scheme.

12 Table 1 — Summary of techniques in the standard

Scheme name Primitives Additional methods

Key Agreement Schemes

DL/ECKAS-DH1 DL/ECSVDP-DH or -DHC KDF1 or KDF2 (each uses a


hash function)

DL/ECKAS-DH2 DL/ECSVDP-DH and/or -DHC KDF1 or KDF2 (each uses a


hash function)

DL/ECKAS-MQV DL/ECSVDP-MQV or -MQVC KDF1 or KDF2 (each uses a


hash function)

Signature Schemes with Appendix

DL/ECSSA DLSP-NR and DLVP-NR EMSA1 (uses a hash function)

OR

DLSP-DSA and DLVP-DSA

OR

ECSP-NR and ECVP-NR

OR

ECSP-DSA and ECVP-DSA

IFSSA IFSP-RSA1 and IFVP-RSA1 EMSA2 or EMSA3 or


EMSA4 or EMSA5 (each uses
OR a hash function; EMSA4 and
EMSA5 also use a mask
IFSP-RSA2 and IFVP-RSA2 generation function)

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

IFSP-RW and IFVP-RW

OR

IFSP-ESIGN and IFVP-ESIGN

Signature Schemes Giving Message Recovery

DL/ECSSR DLPSP-NR2/PV, DLSP-NR2 EMSR1 (uses a hash function)


and DLVP-NR2

OR

ECPSP-NR2/PV, ECSP-NR2
and ECVP-NR2

DL/ECSSR-PV DLPSP-NR2/PV, DLSP-PV and EMSR2 (uses a key derivation


DLVP-PV function and possibly a
symmetric encryption
OR scheme); a hash function

ECPSP-NR2/PV, ECSP-PV and


ECVP-PV

IFSSR IFSP-RSA1 and IFVP-RSA1 EMSR3 (uses a hash function


and a mask generation
OR function)

IFSP-RSA2 and IFVP-RSA2

OR

IFSP-RW and IFVP-RW

Encryption Schemes

DL/ECIES DL/ECSVDP-DH or -DHC KDF2; MAC1 (each uses a


hash function); possibly a
symmetric encryption scheme

IFES IFEP-RSA and IFDP-RSA EME1 (uses a hash function


and a mask generation
function)

IFES-EPOC IFEP-OU and IFDP-OU EME2 or EME3 (each uses a


hash function and a mask
generation function; EME3
also uses a key derivation
function and possibly a
symmetric encryption scheme)

NOTE—Acronym definitions are as follows:

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

NOTE—Acronym definitions are as follows:

Families—DL: discrete logarithm, EC: elliptic curve, IF: integer factorization

Schemes—KAS: key agreement scheme, SSA: signature scheme with appendix, SSR:
signature scheme giving message recovery, IES: integrated encryption scheme, ES:
encryption scheme

Primitives—SVDP: secret value derivation primitive, PSP: pre-signature primitive, SP:


signature primitive, VP: verification primitive, EP: encryption primitive, DP: decryption
primitive

Additional methods—KDF: key derivation function, EMSA: encoding method for


signatures with appendix, EMSR: encoding method for signatures giving message recovery,
EME: encoding method for encryption, MAC: message authentication code

Names of techniques—DH: Diffie–Hellman, DHC: Diffie–Hellman with cofactor


exponentiation/multiplication, MQV: Menezes–Qu–Vanstone, MQVC: Menezes–Qu–
Vanstone with cofactor exponentiation/multiplication, NR: Nyberg–Rueppel, DSA: Digital
signature algorithm, RSA: Rivest–Shamir–Adleman, RW: Rabin–Williams, PV: Pintsov–
Vanstone, OU: Okamoto–Uchiyama

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

15. Mathematical Conventions


2This clause describes certain mathematical conventions used in the standard, including notation and
3representation of mathematical objects. It also contains primitives for data type conversion. Note that the
4internal representation of mathematical objects is left entirely to the implementation, and may or may not
5follow the one described below.

65.1 Mathematical Notation


7The following mathematical notation is used throughout the document.

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.
19x The smallest integer greater than or equal to the real number x. For example, 5 = 5 and
20 5.3 = 6.
21x 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).

305.2 Bit Strings and Octet Strings


31Bit strings and octet strings are ordered sequences. The terms “first” and “last,” “leftmost” and
32“rightmost,” and “leading” and “trailing” are used to distinguish the ends of these sequences (“first,”
33“leftmost” and “leading” are equivalent; “last,” “rightmost” and “trailing” are equivalent; other publications
34sometimes use “most significant,” which is synonymous with “leading,” and “least significant,” which is
35synonymous with “trailing”).

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

15.3 Finite Fields


2This clause describes the kinds of underlying finite fields GF (q) that shall be used, and how they are to be
3represented for purposes of conversion with the primitives in Clause 5.5. As noted above, the internal
4representation of objects is left to the implementation, and may be different. If the internal representation is
5different, conversion to the representation defined here may be needed at certain points in cryptographic
6operations.

75.3.1 Prime Finite Fields

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.

125.3.2 Characteristic Two Finite Fields

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.

235.3.2.1 Polynomial Basis over GF (2)

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)

29shall be taken to represent the polynomial

30am–1t m–1 + … + a2t2 + a1t + a0

31where the coefficients ai are elements of GF (2).

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.

45.3.2.2 Normal Basis over GF (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)

10shall be taken to represent the element

11a0 + a1 2 + a2 2 + … + am–1 2 ,


2 m–1

12where  is a root of p(t) in GF (2m).


13In particular, for purposes of conversion, the additive identity (zero) element of the field is represented by a
14string of all zero bits, and the multiplicative identity (one) element of the field is represented by a string of
15one bits. (Note, however, that in mathematical expressions in this standard, for typographic convenience,
16the numeral 0 is used to represent the element zero of a field, and the numeral 1 is used to represent the
17element one of the field.)

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.

215.3.3 Composite basis over GF(2d)

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.

285.3.3.1 Polynomial basis over GF(2d)

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

35as–1t s–1 + … + a2t2 + a1t + a0

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).

135.3.3.2 Normal basis over 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

20a0 + a1 2 + a2 2 + … + as–1 2 ,


2 s–1

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).

325.3.4 Odd characteristic extension fields

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, …, pm1} 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

39am–1tm–1 + … + a2t2 + a1t+ a0

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

1shall be represented by the integer

2am–1pm–1 + … + a2p2 + a1p+ a0

3(note that each ai is between 0 and p1, so the result is between 0 and pm1). (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 =
6a / 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.

9A description of the arithmetic of GF(pm) is given in A.17.

10

115.4 Elliptic Curves and Points

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):

21yP2 + xP yP = xP3 + a xP2 + b.

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):

24yP2 = xP3 + a xP2 + b.

25See Annex A.9 and A.10 for more on elliptic curves and elliptic curve arithmetic.

265.5 Data Type Conversion


27TO DO: Update this to present the algorithms in more of an algorithmic (i.e. step by step) way, as in .1
28and .2.

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

OS2IP I2OSP BS2OSP OS2BSP


FE2IP

FE2OSP OS2ECP
Field Element (FE) Octet String (OS) Elliptic Curve
OS2FEP EC2OSP Point (EC)
1

2 Figure 1—Summary of data type conversion primitives

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:

8x = xl–1 2 l–1 + xl–2 2 l–2 + … + x1 2 + x0

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:

4x = xl–1 256 l–1 + xl–2 256 l–2 + … + x1 256 + x0

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.”

305.5.5 Converting Finite Field Elements to Integers (FE2IP)

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

75.5.6 Converting between elliptic curve points and octet strings

8UPDATE THIS BASED ON X9

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.

145.5.6.1 Compressed elliptic curve 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.

215.5.6.1.1 LSB compressed form

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.

315.5.6.1.2 SORT compressed form

32Let (xP, yP) be the inverse of the point (xP, yP). (For GF(pm), yP = yP; for GF(2m), yP = 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 (yP), 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 yP directly, rather than first
5computing FE2IP (yP) and FE2IP (yP).

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 yP.

105.5.6.2 Two-coordinate point representations

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.

145.5.6.2.1 Uncompressed representation: EC2OSP-XY and OS2ECP-XY

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.

195.5.6.2.2 LSB compressed representation: EC2OSP-XL and OS2ECP-XL

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.

255.5.6.2.3 SORT compressed representation: EC2OSP-XS and OS2ECP-XS

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.

315.5.6.2.4 LSB hybrid representation: EC2OSP-XYL and OS2ECP-XYL

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.

35.5.6.2.5 SORT hybrid representation: EC2OSP-XYS and OS2ECP-XYS

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.

95.5.6.3 x-coordinate only representation: EC2OSP-X and OS2ECP-X

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).

255.5.6.4 Summary of representations

26Table 2 summarizes the point representations in 5.5.6.2 and 5.5.6.3.

27 Table 2 — Elliptic curve point representations

Representation Primitives PC X Y Finite fields

Uncompressed EC2OSP-XY and 0000 0100 xP yP All


OS2ECP-XY

LSB compressed EC2OSP-XL and 0000 001 xP Empty GF(p) and


OS2ECP-XL GF(2m)

SORT compressed EC2OSP-XS and 0000 101 xP Empty GF(2m) and

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)

LSB hybrid EC2OSP-XYL and 0000 011 xP yP GF(p) and


OS2ECP-XYL GF(2m)

SORT hybrid EC2OSP-XYS and 0000 111 xP yP GF(2m) and


OS2ECP-XYS GF(pm)

x-coordinate-only EC2OSP-X and 0000 0001 xP Empty All


OS2ECP-X

Point O All 0000 0000 Empty Empty All

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.

26. Primitives Based on the Discrete Logarithm Problem


3This clause specifies the family of cryptographic primitives based on the discrete logarithm problem over
4finite fields, also known as the DL family. For background information on this family, see [DH76], Annex
5A.1.2 and A.3.9.

66.1 The DL Setting

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.

306.1.2 DL Domain Parameters

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.

116.1.3 DL Key Pairs

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:

24 b) Compute a field element z = exp(w, s).


25  2. Output z as the shared secret value.
26Conformance region recommendation. A conformance region should include:

27  at least one valid set of DL domain parameters q, r and g


28  at least one valid private key s for each set of domain parameters
29  all valid public keys w associated with the same set of domain parameters as s
30NOTES

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:

26  at least one valid set of DL domain parameters q, r, g and k


27  at least one valid private key s for each set of domain parameters
28  all elements w in GF (q), where q is from the domain parameters of s
29  compatibility with DLSVDP-DH may be preset by the implementation, or given as an input flag
30NOTES

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

8DLSVDP-MQV is Discrete Logarithm Secret Value Derivation Primitive, Menezes-Qu-Vanstone version.


9It is based on the work of [LMQ98]. This primitive derives a shared secret value from one party’s two key
10pairs and another party’s two public keys, where all the keys have the same set of DL domain parameters.
11If two parties execute this primitive with corresponding keys as inputs, they will produce the same output.
12This primitive can be invoked by a scheme to derive a shared secret key; specifically, it may be used with
13the scheme DLKAS-MQV. It assumes that the input keys are valid (see also Clause 6.2.4).

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:

34  at least one valid set of DL domain parameters q, r and g


35  at least one valid private key s for each set of domain parameters
36  all valid key pairs (u, v) associated with the same set of domain parameters as s
37  all valid public keys w and v associated with the same set of domain parameters as s
38NOTES

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

10DLSVDP-MQVC is Discrete Logarithm Secret Value Derivation Primitive, Menezes-Qu-Vanstone version


11with cofactor exponentiation. It is based on the work of [LMQ98] and [Kal98a]. This primitive derives a
12shared secret value from one party’s two key pairs and another party’s two public keys, where all the keys
13have the same set of DL domain parameters. If two parties execute this primitive with corresponding keys
14as inputs, they will produce the same output. This primitive can be invoked by a scheme to derive a shared
15secret key; specifically, it may be used with the scheme DLKAS-MQV. It does not assume the validity of
16the input public keys, but does assume that the public key is an element of GF(q) (see also Clause 6.2.3).

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:

39  at least one valid set of DL domain parameters q, r, g and k


40  at least one valid private key s for each set of domain parameters

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

22DLSVDP-MQV is Discrete Log Secret Value Derivation Primitive, Hashed Menezes-Qu-Vanstone


23version. It is based on the work of [LMQ98] and [Kra05]. This primitive derives a shared secret value
24from one party’s two key pairs and another party’s two public keys, where all the keys and values have the
25same set of EC domain parameters. The computation of the shared secret also involves the identities of the
26parties and a hash function. If two parties correctly execute this primitive, they will produce the same
27output. This primitive can be invoked by a scheme to derive a shared secret key; specifically, it may be
28used with the scheme DLKAS-MQV (see Clause ***). It does not assume the validity of the input public
29keys, but does assume that the public keys are elements of GF(q)\{0,1}.

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:

7 a) Compute an integer t = OS2IP( H(FE2OSP(v) || id’)


8 b) Compute an integer t’ = OS2IP( H(FE2OSP(v’) || id)
9 c) Compute an integer e = ts + u mod r.
10 d) Compute a field element z = exp(v  exp(w, t), e).
11 e) If z = 1 or z = 0, output “invalid public key” and stop.
12 f) Output z as the shared secret value.
13Conformance region recommendation. A conformance region should include:

14  at least one valid set of DL domain parameters q, r and g


15  at least one valid private key s for each set of domain parameters
16  all valid key pairs (u, v) associated with the same set of domain parameters as s
17  all elements w and v in GF(q)\{0,1}.
18NOTE 1—DLSVDP-HMQV does note require full validation of (ephemeral and long-term) public keys but only
19requires checking that these public keys are in in GF(q)\{0,1} (namely, any element in GF(q) except for the zero and
20identity elements). In particular, it does not require testing the prime order r of the public keys, an operation that may
21be costly depending on the underlying group and which is often performed to prevent the so called small subgroup
22attacks (see ***). In the case of HMQV, small subgroup attacks cannot help an attacker except in cases in which the
23ephemeral key u but not the private key v is learned by the attacker. Thus, any system or application where all secrets
24are equally protected can benefit from the superior performance of DLSVDP-HMQV. (Such systems are not
25uncommon. For example, in the DSA or ECDSA signature schemes ephemeral secrets are as valuable for an attacker as
26long-term ones and hence require equal protection.) Applications that desire to add protection in case of disclosure of
27ephemeral secrets can either test that the value v’ = exp (w’, t’) is of order r (note that there is no need to test the v’ and
28w’keys separately) or use the DLSVDP-HMQVC primitive from Clause ***. The computational cost of these two
29options is an l-bit exponentiation where l depends on the parameters r and q. In the first case l = min{|r|, |(q-1)/r|}, and
30in the second l= |(q-1)/r|.

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:

3 a) Compute an integer t = OS2IP( H(FE2OSP(v) || id’)


4 b) Compute an integer t’ = OS2IP( H(FE2OSP(v’) || id)
5 c) If compatibility with DLSVDP-MQV is desired, then compute an integer e = k–1(ts + u) mod r;
6 otherwise compute an integer e = ts + u mod r.
7 d) Compute a field element z = exp(v  exp(w, t), ke).
8 e) If z = 0 or z = 1, output “invalid public key”; else, output z as the shared secret value.
9Conformance region recommendation. A conformance region should include:

10  at least one valid set of DL domain parameters q, r, k and g


11  at least one valid private key s for each set of domain parameters
12  all valid key pairs (u, v) associated with the same set of domain parameters as s
13  all elements w and v in GF(q)\{0,1}.
14  compatibility with DLSVDP-MQV may be preset by the implementation, or given as an input flag
15NOTE 1—DLSCDP-HMQVC does not require full validation of public keys (ephemeral and long-term) but only
16requires checking that these public keys are in GF(q) \ {0, 1}, that is, that they are elements in the field GF(q) except
17for the zero and identity elements. The primitive explicitly addresses small subgroup attacks (see Annex D.5.1.6) via
18the cofactor exponentiation. This is useful in the case of HMQV to prevent damage from such attacks in a scenario
19where an attacker can learn ephemeral secrets used by a party but not the long term secret (as pointed out in section
206.2.3’, small group attacks against HMQV are relevant only in this scenario). The added cost relative to DLSDVP-
21HMQV is a |(q−1)/r|-bit exponentiation. Therefore, the choice between DLSDVP-HMQV and DLSDVP-HMQVC
22depends on performance considerations and on the security model. Note that even when disclosure of ephemeral secrets
23is deemed more practical than leakage of long-term keys, the option of performing DLSDVP-HMQV with a prime-
24order test as described in the Notes of section 6.2.3’ may be more efficient than performing cofactor exponentiation
25(specifically, this is the case whenever r < √q).

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:

10  the DL domain parameters q, r and g associated with the key s


11  the signer’s private key s
12  the message representative, which is an integer f such that 0  f < r
13Assumptions: private key s and DL domain parameters q, r and g are valid and associated with each other;
140  f < r

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:

22  at least one valid set of DL domain parameters q, r and g


23  at least one valid private key s for each set of domain parameters
24  all message representatives f in the range [0, r – 1] , where r is from the domain parameters of s
25NOTES

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:

2  the DL domain parameters q, r and g associated with the key w


3  the signer’s public key w
4  the signature to be verified, which is a pair of integers (c, d)
5Assumptions: public key w and DL domain parameters q, r and g are valid and associated with each other

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:

13  at least one valid set of DL domain parameters q, r and g


14  at least one valid public key w for each set of domain parameters
15  all purported signatures (c, d) that can be input to the implementation; this should at least include
16 all (c, d) such that c and d are in the range [0, r – 1] , where r is from the domain parameters of w

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:

23  the DL domain parameters q, r and g associated with the key s


24  the signer’s private key s
25  the message representative, which is an integer f  0
26Assumptions: private key s and DL domain parameters q, r and g are valid and associated with each other;
27f  0

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:

35  at least one valid set of DL domain parameters q, r and g

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:

19  the DL domain parameters q, r and g associated with the key w


20  the signer’s public key w
21  the message representative, which is an integer f  0
22  the signature to be verified, which is a pair of integers (c, d)
23Assumptions: public key w and DL domain parameters q, r and g are valid and associated with each other;
24f  0
25Output: “valid” if f and (c, d) are consistent given the key and the domain parameters; “invalid” otherwise

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:

32  at least one valid set of DL domain parameters q, r and g


33  at least one valid public key w for each set of domain parameters
34  all message representatives f  0 that can be input to the implementation; this should at least
35 include all f with bit length no greater than that of r, where r is from the domain parameters of w
36  all purported signatures (c, d) that can be input to the implementation; this should at least include
37 all (c, d) such that c and d are in the range [1, r – 1] , where r is from the domain parameters of w

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

2DLPSP-NR2/PV is the Discrete Logarithm Pre-Signature Primitive, Nyberg-Rueppel / Pintsov-Vanstone


3version. It is based on the work of ISO/IEC 9796-3:2000 [B79], Nyberg and Rueppel [B120], and Pintsov
4and Vanstone [PV99]. The primitive generates a randomizer and a pre-signature for a signature scheme. It
5can be invoked in the scheme DLSSR or DLSSR-PV as part of signature generation. DLPSP-NR2/PV
6corresponds to the first two steps of DLSP-NR.

7Input: The DL domain parameters q, r and g

8Assumptions: DL domain parameters q, r and g are valid.

9Output:

10  The randomizer, which is an integer u such that 1  u < r


11  The pre-signature, which is an integer i such that 1  i < q
12Operation: The randomizer u and the pre-signature i shall be computed by the following or an equivalent
13sequence of steps:

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:

19  At least one valid set of DL domain parameters q, r and g


20NOTES

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

1  The DL domain parameters q, r and g associated with the key s


2  The signer’s private key s
3  The randomizer, which is an integer u such that 1  u < r
4  The pre-signature, which is an integer i such that 1  i < q
5  The message representative, which is an integer f such that 0  f < r
6Assumptions: Private key s and DL domain parameters q, r and g are valid and associated with each other;
71  u < r; 1  i < q; 0  f < r.

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:

16  At least one valid set of DL domain parameters q, r and g


17  At least one valid private key s for each set of domain parameters
18  All randomizers u in the range [1, r – 1]
19  All pre-signatures i in the range [1, q – 1]
20  All message representatives f in the range [0, r – 1]
21NOTES

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:

38  The DL domain parameters q, r and g associated with the key w

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

1  The signer’s public key w


2  The signature to be verified, which is a pair of integers (c, d)
3Assumptions: Public key w and DL domain parameters q, r and g are valid and associated with each other.

4Output:

5  The message representative, which is an integer f such that 0  f < r; or “invalid”


6  The pre-signature, which is an integer i such that 1  i < q
7Operation: The message representative f and the pre-signature i shall be computed by the following or an
8equivalent sequence of steps:

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:

16  At least one valid set of DL domain parameters q, r and g


17  At least one valid public key w for each set of domain parameters
18  All purported signatures (c, d) that can be input to the implementation; this should at least include
19 all (c, d) such that c and d are in the range [0, r – 1]

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:

30  The DL domain parameters q, r and g associated with the key s


31  The signer’s private key s
32  The randomizer, which is an integer u such that 1  u < r
33  The randomized hash value, which is a non-negative integer h
34Assumptions: Private key s and DL domain parameters q, r and g are valid and associated with each other;
351  u < r; h  0.

36Output: A signature part, which is an integer d, where 0  d < r


37Operation: The signature part d shall be computed by the following or an equivalent sequence of steps:

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:

5  At least one valid set of DL domain parameters q, r and g


6  At least one valid private key s for each set of domain parameters
7  All randomizers u in the range [1, r – 1]
8  All randomized hash values h in the range [0, r – 1], where r is from the domain parameters of s
9NOTES

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:

21  The DL domain parameters q, r and g associated with the key w


22  The signer’s public key w
23  The randomized hash value, which is an integer h  0
24  The signature part from which the pre-signature is to be recovered, which an integer d
25Assumptions: Public key w and DL domain parameters q, r and g are valid and associated with each other.

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:

35  At least one valid set of DL domain parameters q, r and g


36  At least one valid public key w for each set of domain parameters
37  All randomized hash values h  0
2 53
3 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 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

17. Primitives Based on the Elliptic Curve Discrete Logarithm Problem


2This clause specifies the family of cryptographic primitives based on the discrete logarithm problem over
3elliptic curve groups, also known as the EC family. For background information on this family, see
4[Mil86], [Kob87], Annex A.9.3 and A.9.4.

57.1 The EC Setting

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.

10Apply appropriate style to this list

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.

97.1.2 EC Domain Parameters

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.

397.1.3 EC Key Pairs

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

1  the party’s own private key s


2  the other party’s public key W
3Assumptions: private key s, EC domain parameters q, a, b, r and G, and public key W are valid; both keys
4are associated with the domain parameters

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:

12  at least one valid set of EC domain parameters q, a, b, r and G


13  at least one valid private key s for each set of domain parameters
14  all valid public keys W associated with the same set of domain parameters as s
15NOTES

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:

8  at least one valid set of EC domain parameters q, a, b, r, G and k


9  at least one valid private key s for each set of domain parameters
10  all points W on the curve over GF (q) defined by a and b, where q, a and b are from the domain
11 parameters of s
12  compatibility with ECSVDP-DH may be preset by the implementation, or given as an input flag
13NOTES

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

28ECSVDP-MQV is Elliptic Curve Secret Value Derivation Primitive, Menezes-Qu-Vanstone version. It is


29based on the work of [LMQ98]. This primitive derives a shared secret value from one party’s two key
30pairs and another party’s two public keys, where all the keys and values have the same set of EC domain
31parameters. If two parties correctly execute this primitive, they will produce the same output. This
32primitive can be invoked by a scheme to derive a shared secret key; specifically, it may be used with the
33scheme ECKAS-MQV. It assumes that the input keys are valid (see also Clause 7.2.4).

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 + tW). 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:

14  at least one valid set of EC domain parameters q, a, b, r and g


15  at least one valid private key s for each set of domain parameters
16  all valid key pairs (u, V) associated with the same set of domain parameters as s
17  all valid public keys w and v associated with the same set of domain parameters as s
18NOTES

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

1  the party’s own first private key s


2  the party’s own second key pair (u, V), where V = (x, y)
3  the other party’s first public key W
4  the other party’s second public key V = (x, y)
5  an indication as to whether compatibility with ECSVDP-MQV is desired
6Assumptions: private key s, key pair (u, V), and EC domain parameters q, a, b, r, G and k are valid; private
7key s and key pair (u, V) are associated with the domain parameters; W and V are on the elliptic curve
8defined by a and b over GF (q); GCD (k, r) = 1

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 + tW). 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:

19  at least one valid set of EC domain parameters q, a, b, r, g and k


20  at least one valid private key s for each set of domain parameters
21  all valid key pairs (u, V) associated with the same set of domain parameters as s
22  all points W and V on the curve over GF (q) defined by a and b, where q, a and b are from the
23 domain parameters of s
24  compatibility with ECSVDP-MQV may be preset by the implementation, or given as an input flag
25NOTES

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.

3ECSVDP-MQV is Elliptic Curve Secret Value Derivation Primitive, Menezes-Qu-Vanstone version. It is


4based on the work of [LMQ98] and [Kra05]. This primitive derives a shared secret value from one party’s
5two key pairs and another party’s two public keys, where all the keys and values have the same set of EC
6domain parameters. The computation of the shared secret also involves the identities of the parties and a
7hash function. If two parties correctly execute this primitive, they will produce the same output. This
8primitive can be invoked by a scheme to derive a shared secret key; specifically, it may be used with the
9scheme ECKAS-MQV. It does not assume the validity of the input public keys, but does assume that the
10public keys are elements of GF(q)\{0,1}.

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 + tW). 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:

30  at least one valid set of EC domain parameters q, a, b, r and g


31  at least one valid private key s for each set of domain parameters
32  all valid key pairs (u, V) associated with the same set of domain parameters as s
33  all valid public keys w and v associated with the same set of domain parameters as s
34NOTES

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 + tW). 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:

37  at least one valid set of EC domain parameters q, a, b, r, g and k


38  at least one valid private key s for each set of domain parameters
39  all valid key pairs (u, V) associated with the same set of domain parameters as s

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:

30  the EC domain parameters q, a, b, r and G associated with the key s


31  the signer’s private key s
32  the message representative, which is an integer f such that 0  f < r
33Assumptions: private key s and EC domain parameters q, a, b, r and G are valid and associated with each
34other; 0  f < r

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

1  at least one valid set of EC domain parameters q, a, b, r and G


2  at least one valid private key s for each set of domain parameters
3  all message representatives f in the range [0, r – 1], 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.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:

20  the EC domain parameters q, a, b, r and G associated with the key W


21  the signer’s public key W
22  the signature to be verified, which is a pair of integers (c, d)
23Assumptions: public key W and EC domain parameters q, a, b, r and G are valid and associated with each
24other

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:

33  at least one valid set of EC domain parameters q, a, b, r and G


34  at least one valid public key W for each set of domain parameters
35  all purported signatures (c, d) that can be input to the implementation; this should at least include
36 all (c, d) such that c and d are in the range [0, r – 1] , where r is from the domain parameters of W

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:

7  the EC domain parameters q, a, b, r and G associated with the key s


8  the signer’s private key s
9  the message representative, which is an integer f  0
10Assumptions: private key s and EC domain parameters q, a, b, r and G are valid and associated with each
11other; f  0

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:

20  at least one valid set of EC domain parameters q, a, b, r and G


21  at least one valid private key s for each set of domain parameters
22  a range of message representatives f; this should at least include all f  0 with bit length no greater
23 than that of r, where r is from the domain parameters of s
24NOTES

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

1  the EC domain parameters q, a, b, r and G associated with the key W


2  the signer’s public key W
3  the message representative, which is an integer f  0
4  the signature to be verified, which is a pair of integers (c, d)
5Assumptions: public key W and EC domain parameters q, a, b, r and G are valid and associated with each
6other; f  0
7Output: “valid” if f and (c, d) are consistent given the key and the domain parameters; “invalid” otherwise

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:

15  at least one valid set of EC domain parameters q, a, b, r and G


16  at least one valid public key W for each set of domain parameters
17  all message representatives f  0 that can be input to the implementation; this should at least
18 include all f with bit length no greater than that of r, where r is from the domain parameters of W
19  all purported signatures (c, d) that can be input to the implementation; this should at least include
20 all (c, d) such that c and d are in the range [1, r – 1] , where r is from the domain parameters of W

217.2.11 ECPSP-NR2/PV

22ECPSP-NR2/PV is the Elliptic Curve Pre-Signature Primitive, Nyberg-Rueppel and Pintsov-Vanstone


23version. It is based on the work of ISO/IEC 9796-3:2000 [B79], Koblitz [B94], Miller [B117], and Nyberg
24and Rueppel [B120]. The primitive generates a randomizer and a pre-signature for a signature scheme. It
25can be invoked in the scheme ECSSR or ECSSR-PV as part of signature generation. ECPSP-NR2/PV
26corresponds to the first two steps of ECSP-NR.

27Input: The EC domain parameters q, a, b, r and G

28Assumptions: EC domain parameters q, a, b, r and G are valid.

29Output:

30  The randomizer, which is an integer u such that 1  u < r


31  The pre-signature, which is an integer i such that 1  i < q
32Operation: The randomizer u and the pre-signature i shall be computed by the following or an equivalent
33sequence of steps:

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

1 3. Output u as the randomizer and i as the pre-signature.


2Conformance region recommendation. A conformance region should include:

3  At least one valid set of EC domain parameters q, a, b, r and G


4NOTES

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:

24  The EC domain parameters q, a, b, r and G associated with the key s


25  The signer’s private key s
26  The randomizer, which is an integer u such that 1  u < r
27  The pre-signature, which is an integer i such that 1  i < q
28  The message representative, which is an integer f such that 0  f < r
29Assumptions: Private key s and EC domain parameters q, a, b, r and G are valid and associated with each
30other; 1  u < r; 1  i < q; 0  f < r.

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:

39  At least one valid set of EC domain parameters q, a, b, r and G


2 68
3 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  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:

22  The EC domain parameters q, a, b, r and G associated with the key W


23  The signer’s public key W
24  The signature to be verified, which is a pair of integers (c, d)
25Assumptions: Public key W and EC domain parameters q, a, b, r and G are valid and associated with each
26other.

27Output:

28  The message representative, which is an integer f such that 0  f < r; or “invalid”


29  The pre-signature, which is an integer i such that 1  i < q
30Operation: The message representative f and the pre-signature i shall be computed by the following or an
31equivalent sequence of steps:

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

1  At least one valid set of EC domain parameters q, a, b, r and G


2  At least one valid public key W for each set of domain parameters
3  All purported signatures (c, d) that can be input to the implementation; this should at least include
4 all (c, d) such that c and d are in the range [0, r – 1]

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:

15  The EC domain parameters q, a, b, r and G associated with the key s


16  The signer’s private key s
17  The randomizer, which is an integer u such that 1  u < r
18  The randomized hash value, which is a nonnegative integer h
19Assumptions: Private key s and EC domain parameters q, a, b, r and G are valid and associated with each
20other; 1  u < r; h  0.

21Output: A signature part, which is an integer d, where 0  d < r


22Operation: The signature part d shall be computed by the following or an equivalent sequence of steps:

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:

27  At least one valid set of EC domain parameters q, a, b, r and G


28  At least one valid private key s for each set of domain parameters
29  All randomizers u in the range [1, r – 1]
30  All randomized hash values h in the range [0, r – 1]

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:

13  The EC domain parameters q, a, b, r and G associated with the key W


14  The signer’s public key W
15  The randomized hash value, which is an integer h  0
16  The signature part from which the pre-signature is to be recovered, which an integer d
17Assumptions: Public key W and EC domain parameters q, a, b, r and G are valid and associated with each
18other.

19Output: The pre-signature, which is an integer i such that 1  i < q


20Operation: The pre-signature i shall be computed by the following or an equivalent sequence of steps:

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:

28  At least one valid set of EC domain parameters q, a, b, r and G


29  At least one valid public key W for each set of domain parameters
30  All randomized hash values h  0
31  All signature parts d that can be input to the implementation; this should at least include all d such
32 that d is in the range [0, r – 1]
33 

348. 8. Primitives Based on the Integer Factorization Problem


35This clause specifies the family of cryptographic primitives based on the integer factorization problem, also
36known as the IF family. For background information on this family, see [RSA78], Annex A.1.3 and A.1.4.

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]).

78.1 8.1 The IF Setting

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

18.1.2 Domain Parameters in the IF Family

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).

88.1.3 Keys in the IF Family

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.

118.1.3.1 RSA Key Pairs

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

15d e  1 (mod LCM (p – 1, q – 1)).


16Note that there may be more than one private exponent d corresponding to a public key (n, e).

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)

228.1.3.2 RW Key Pairs

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

28d e  1 (mod LCM (p – 1, q – 1) / 2).


29Note that there may be more than one private exponent d corresponding to a public key (n, e).

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

18.1.3.3 OU key pairs

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.

118.1.3.4 ESIGN key pairs

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.

168.1.3.5 Considerations common to IF key pairs

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.

218.2.1 IF Private Key Operation

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:

25  an RSA or RW private key K represented as one of the following


26 — a pair (n, d)
27 — a quintuple (p, q, d1, d2, c)
28 — a triple (p, q, d)
29  an integer i such that 0  i < n (where n = pq if the second or the third representation of K is used),
30 to which the private key operation is to be applied
31Assumptions: private key K is valid; 0  i < n

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:

14  the recipient’s RSA public key (n, e)


15  the message representative, which is an integer f such that 0  f < n
16Assumptions: public key (n, e) is valid; 0  f < n

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:

20 v) Let g = exp(f, e) mod n.


21  2. Output g.
22Conformance region recommendation. A conformance region should include:

23  at least one valid RSA public key (n, e)


24  all message representatives f in the range [0, n – 1]

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:

30  the recipient’s RSA private key K


31  the encrypted message representative, which is an integer g such that 0  g < n
32Assumptions: private key K is valid; 0  g < n

33Output: the message representative, which is an integer f such that 0  f < n


34Operation. The message representative f shall be computed by the following or an equivalent sequence of
35steps:

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:

4  at least one valid RSA private key K


5  all encrypted message representatives g in the range [0, n – 1], where n is from the private key K

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:

13  the signer’s RSA private key K


14  the message representative, which is an integer f such that 0  f < n
15Assumptions: private key K is valid; 0  f < n

16Output: the signature, which is an integer s such that 0  s < n


17Operation. The signature s shall be computed by the following or an equivalent sequence of steps:

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:

21  at least one valid RSA private key K


22  all message representatives f in the range [0, n – 1], where n is from the private key K

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:

30  the signer’s RSA public key (n, e)


31  the signature to be verified, which is an integer s
32Assumptions: public key (n, e) is valid

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:

6  at least one valid RSA public key (n, e)


7  all purported signatures s that can be input to the implementation; this should at least include all s
8 in the range [0, n – 1]

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:

17  the signer’s RSA private key K


18  the message representative, which is an integer f such that 0  f < n, and f  12 (mod 16)
19Assumptions: private key K is valid, 0  f < n, and f is congruent to 12 modulo 16

20Output: the signature, which is an integer s such that 0  s < n/2


21Operation. The signature s shall be computed by the following or an equivalent sequence of steps:

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:

25  at least one valid RSA private key K


26  all message representatives f in the range [0, n – 1] such that f  12 (mod 16), where n is from the
27 private key K

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:

36  the signer’s RSA public key (n, e)


2 78
3 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 signature to be verified, which is an integer s


2Assumption: public key (n, e) is valid

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:

11  at least one valid RSA public key (n, e)


12  all purported signatures s that can be input to the implementation; this should at least include all s
13 in the range [0, (n – 1)/2]

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:

22  the recipient’s RW private key K


23  the message representative, which is an integer f such that 0  f < n, and f  12 (mod 16)
24Assumptions: private key K is valid, 0  f < n, and f is congruent to 12 modulo 16

25Output: the signature, which is an integer s such that 0  s < n/2


26Operation. The signature s shall be computed by the following or an equivalent sequence of steps:

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:

31  at least one valid RW private key K


32  all message representatives f in the range [0, n – 1] such that f  12 (mod 16), where n is from the
33 private key K
34NOTE—See Annex A.2.9 for a potentially more efficient implementation of the primitive and A.1.4 and A.2.3 for
35evaluating Jacobi symbols.

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:

8  the signer’s RW public key (n, e)


9  the signature to be verified, which is an integer s
10Assumption: public key (n, e) is valid

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:

21  at least one valid RW public key (n, e)


22  all purported signatures s that can be input to the implementation; this should at least include all s
23 in the range [0, (n – 1)/2]

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:

30  The recipient’s OU public key (n, u, v, k)


31  The message representative, which is an integer f such that 0  f < 2k1
32  The randomized hash value, which is an integer r such that 0  r < n
33Assumptions: Public key (n, u, v, k) is valid; 0  f < 2k1; 0  r < n.

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:

5  At least one valid OU public key (n, u, v, k)


6  All message representatives f in the range [0, 2k1 – 1]
7NOTE—The randomized hash value r should be different for encryptions of different message representatives f, as its
8reuse can lead to the recovery of the partial or total information about the message representative f.

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:

6  The recipient’s OU private key (p, q, k, w)


7  The encrypted message representative, which is an integer g such that 0  g < n, where n is from
8 the corresponding public key
9Assumptions: Private key (p, q, k, w) is valid; 0  g < n.

10Output: The message representative, which is an integer f such that 0  f < 2k1; 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 < 2k1.
18 5. If it holds, output f. Otherwise, output “invalid.”
19Conformance region recommendation: A conformance region should include:

20  At least one valid OU private key (p, q, k, w)


21  All encrypted message representatives g in the range [0, n – 1]

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:

29  The signer’s ESIGN private key (p, q, k, e)


30  The message representative, which is an integer f such that 0  f < 2k1
31Assumptions: Private key (p, q, k, e) is valid; 0  f < 2k1.

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

1 1. Generate a random integer r, 0  r < pq, such that GCD (r, n) = 1.


2 2. Compute an integer z = f  22k.
3 3. Compute an integer a = (z – exp(r, e)) mod n.
4 4. Compute an integer w0 = a / pq.
5 5. Compute an integer w1 = w0  pq – a.
6 6. If w1  22k1, then go to step 1.
7 7. Compute an integer t = w0 / (e  exp(r, e – 1)) mod p.
8 8. Compute an integer s = r + tpq mod n.
9 9. Output s as the signature.
10Conformance region recommendation: A conformance region should include:

11  At least one valid ESIGN private key (p, q, k, e)


12  All message representatives f in the range [0, 2k1 – 1]
13NOTES

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:

30  The signer’s ESIGN public key (n, e, k)


31  The signature to be verified, which is an integer s
32Assumptions: Public key (n, e, k) is valid.

33Output: the message representative, which is an integer f such that 0  f < 2k1; 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, 2k1 – 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

1  At least one valid ESIGN public key (n, e, k)


2  All purported signatures s that can be input to the implementation; this should at least include all s
3 in the range [0, n – 1]
4

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

19. Key Agreement Schemes


2The general model for key agreement schemes is given in Clause 9.1. Three specific schemes and their
3allowable options are given in Clauses 9.2, 9.3, and 9.4.

49.1 General Model


5In a key agreement scheme, each party combines its own private key(s) with the other party’s public key(s)
6to come up with a secret key. Other (public or private) information known to both parties may also enter
7the scheme as key derivation parameters. If the parties use the corresponding keys and identical key
8derivation parameters, and the scheme is executed correctly, the parties will arrive at the same secret key
9(see note 1, below). A key agreement scheme can allow two parties to derive shared secret keys without
10any prior shared secret.

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

23— private key not found in step 2

24— public key not found in step 3

25— public key not valid in step 4

26— private key or public key not supported in step 5

27— key derivation parameter not supported in step 6

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.

34Figure 2 illustrates the scheme.

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

39.2.1 Scheme options

4The following options shall be established or otherwise agreed upon between the parties to the scheme:

5  a) A secret value derivation primitive, which shall be: DLSVDP-DH, DLSVDP-DHC,


6 ECSVDP-DH or ECSVDP-DHC
7  b) For a -DHC secret value derivation primitive, an indication as to whether or not compatibility
8 with the corresponding -DH primitive is desired
9  c) A key derivation function, which should be KDF1 (Subclause 13.1), KDF2 (Subclause 13.2),
10 or a function designated for use with DL/ECKAS-DH1 in an amendment to this standard

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.

39.2.2 Key Agreement Operation

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:

20  at least one valid set of domain parameters


21  at least one valid private key s for each set of domain parameters
22  all valid public keys w associated with the same set of domain parameters as s; if key validation is
23 performed or a -DHC primitive is used, invalid public keys that are appropriately handled by the
24 implementation may also be included in the conformance region
25  a range of key derivation parameters P
26NOTE—These schemes, with appropriate restrictions on the scheme options and inputs, may be compatible with a
27techniques in ANSI X9.42 [ANS98b] (in the DL case) and ANSI X9.63 [ANS98f] (in the EC case).

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].

32Figure 3 illustrates the scheme.

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

39.3.1 Scheme Options

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

19.3.2 Key Agreement Operation

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.

4Figure 4 illustrates the scheme.

5
6 Figure 4 — DL/ECKAS-MQV key agreement operation

79.4.1 Scheme Options

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

1  b) For an -MQVC secret value derivation primitive, an indication as to whether or not


2 compatibility with the corresponding -MQV primitive is desired
3  c) A key derivation function, which should be KDF1 (Subclause 13.1), KDF2 (Subclause 13.2),
4 or a function designated for use with DL/ECKAS-MQV in an amendment to this standard
5The above information may remain the same for any number of executions of the key agreement scheme,
6or it may be changed at some frequency. The information need not be kept secret.

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.

199.4.2 Key Agreement Operation

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:

37  at least one valid set of domain parameters


38  at least one valid private key s for each set of domain parameters
39  all valid key pairs (u, v) associated with the same set of domain parameters as s

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).

710. Key Encapsulation Schemes


8The general model for key encapsulation schemes is given in Clause 10.1. Two specific schemes and their
9allowable options are given in Clauses Error: Reference source not found and Error: Reference source not
10found.

1110.1 General Model


12The KEM-DEM framework was introduced by Shoup ***[3]. Informally speaking, a key encapsulation
13mechanism (KEM) provides a framework of a key agreement scheme in public-key cryptosystems, while
14date encapsulation mechanism (DEM) defines a symmetric encryption scheme. If both KEM and DEM
15primitives satisfy the security requirements in [4], a hybrid cipher HC properly obtained from them satisfies
16the strong security notion of so-called indistinguishability against the adaptive chosen-ciphertext attacks
17(IND-CCA) for asymmetric encryption.

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.

35Security considerations for KEM schemes are given in Annex D.5.4.

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

28— Public key not found in sender’s step 1

29— Public key not valid in sender’s step 2

30— Message, encoding parameters, or public key not supported in sender’s step 3

31— Private key not found in recipient’s step 1

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 ***).

38Figure *** (TO BE PROVIDED) illustrates the scheme.

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

1 Figure 2 — IFKEM-RSA operation

210.2.1 Scheme options

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.

1310.2.2 IFKEM-RSA.Encapsulate operation

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

2810.2.3 IFKEM-RSA.Recover operation

29The receiver shall recover the shared key S from the ciphertext g by the following or an equivalent
30sequence of steps:

31 a) Select the private key K for the operation.


32 b) Compute an integer z from g and the selected private key K with the primitive IFDP-RSA.
33 c) Convert the integer z to a string Z of length nLen using I2OSP (Clause 5.5.3)
34 d) Obtain the shared key S by running the agreed KDF using Z as input.

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

1Conformance region recommendation. A conformance region should include:

2  at least one valid RSA private key K


3  all ciphertexts g in the range [0, n – 1], where n is from the private key K
4  at least one KDF
5NOTE—These schemes, with appropriate restrictions on the scheme options and inputs, may be compatible with a
6techniques in ***.

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.

11Figure *** (TO BE PROVIDED) illustrates the scheme.

12

13 Figure 2 — ECKEM-PSEC operation

1410.3.1 Scheme options

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.)

3210.3.2 IFKEM-PSEC.Encapsulate operation

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:

21  At least one valid set of domain parameters


22  All valid public keys w associated with the set of domain parameters; if key validation is
23 performed or a -DHC primitive is used, invalid public keys that are appropriately handled by the
24 implementation may also be included in the conformance region

2510.3.3 ECKEM-PSEC.Recover operation

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

1 h) Let H := KDF(I2OSP(0,4) || o, rLen + 16 + keyLen), where rLen is length in octets of I2OSP(r), r


2 the order of G in the elliptic curve domain parameters; and keyLen is the length of the symmetric
3 key to be output. TODO: Check how many arguments KDF takes
4 i) Parse H := t||S, where the octet length of t is rLen + 16, and the octet length of S is keyLen.
5 j) Let s := OS2IP(t) mod r. If the output of OS2IP is “invalid”, output “invalid” and exit. TODO:
6 Check how many arguments OS2IP takes
7 k) Check that C1 := sG. If this does not hold, output “invalid” and stop.
8 l) Output S.
9Conformance region recommendation: A conformance region should include:

10  At least one valid set of domain parameters


11  At least one valid private key s for each set of domain parameters
12  All valid public keys v associated with the set of domain parameters; if key validation is performed
13 or a -DHC primitive is used, invalid public keys that are appropriately handled by the
14 implementation may also be included in the conformance region
15NOTE—These schemes, with appropriate restrictions on the scheme options and inputs, may be compatible with a
16techniques in ***.

1711. Encryption Schemes


18Discussion of encryption schemes in general is given in Clause 11.1. A specific scheme and its allowable
19options are given in Clause 11.2.

2011.1 General Model


21In an encryption scheme, one party, the sender, generates a ciphertext for a message with another party’s
22public key. The other party, called the recipient, decrypts the ciphertext with the corresponding private key
23to obtain the original message. An encryption scheme can provide confidentiality of a message.

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

26— Public key not found in sender’s step 1

27— Public key not valid in sender’s step 2

28— Message, encoding parameters, or public key not supported in sender’s step 3

29— Private key not found in recipient’s step 1

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.

35Figure 10 illustrates the 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

411.2.1 Scheme Options

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.

1211.2.2 Encryption Operation

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)

911.2.3 Decryption Operation

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:

19  at least one valid RSA private key K


20  all ciphertexts g in the range [0, n – 1], where n is from the private key K
21  a range of messages M and encoding parameters P (where the range of encoding parameters may
22 include only the empty string)
23NOTES

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].

33Figure 11 illustrates the scheme.

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

311.3.1 Scheme options

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.

2111.3.2 Encryption operation

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:

20  At least one valid set of domain parameters


21  All valid public keys w associated with the set of domain parameters; if key validation is
22 performed or a -DHC primitive is used, invalid public keys that are appropriately handled by the
23 implementation may also be included in the conformance region
24  A range of messages M, key derivation parameters P1, and encoding parameters P2 (where the
25 ranges of key derivation parameters and encoding parameters may each include only the empty
26 string)
27NOTES

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

111.3.3 Decryption operation

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:

43  At least one valid set of domain parameters


44  At least one valid private key s for each set of domain parameters
45  All valid public keys v associated with the set of domain parameters; if key validation is performed
46 or a -DHC primitive is used, invalid public keys that are appropriately handled by the
47 implementation may also be included in the conformance region
48  A range of encrypted messages C, authentication tags T, key derivation parameters P1, and
49 encoding parameters P2 (where the ranges of key derivation parameters and encoding parameters
50 may each include only the empty string)

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].

12Figure 12 illustrates the scheme.

13
14 Figure 12 — IFES-EPOC encryption and decryption operations

1511.4.1 Scheme options

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.

1011.4.2 Encryption operation

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)

3111.4.3 Decryption operation

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:

8  At least one valid OU private key (p, q, k, w)


9  All encrypted message representatives g in the range [0, n – 1]
10  A range of encrypted messages C and encoding parameters P (where the range of encrypted
11 messages is optional, depending on the encoding method, and the range of encoding parameters
12 may include only the empty string)
13NOTE—A potentially more efficient implementation of steps 5 and 6 is described in A.2.11.

1412. Signature Schemes


15The general model for signature schemes is given in 10.1. Five specific schemes and their allowable
16options are given in 10.2, 10.3, 10.4, 10.5 and 10.6.

1712.1 General Model


18In a signature scheme, one party, the signer, generates a signature for a message with its own private key,
19and another party, the verifier, verifies the signature with the signer’s corresponding public key. A
20signature scheme can provide assurance of the origin and integrity of a message, and can protect against
21impersonation of parties and modification of messages.

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

1— Private key not found in signer’s step 1

2— Message, recoverable message part, non-recoverable message part, or private key not supported in
3signer’s step 2

4— Public key not found in verifier’s step 1

5— Public key not valid in verifier’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.

16Figure 5 illustrates the scheme.

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

212.2.1 Scheme Options

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.

1412.2.2 Signature Generation Operation

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:

28  at least one valid set of domain parameters


29  at least one valid private key s for each set of domain parameters
30  a range of messages M

3112.2.3 Signature Verification Operation

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:

20  at least one valid set of domain parameters


21  at least one valid public key w for each set of domain parameters; if key validation is performed,
22 invalid public keys w that are appropriately rejected by the implementation may also be included in
23 the conformance region
24  all messages M that can be input to the implementation
25  all purported signatures (c, d) that can be input to the implementation; this should at least include
26 all (c, d) such that c and d are in the range [1, r – 1] for -DSA or [0, r – 1] for -NR, where r is from
27 the domain parameters of w
28NOTES

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.

39Figure 6 illustrates the scheme.

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

412.3.1 Scheme Options

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

112.3.2 Signature Generation Operation

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:

18  At least one valid private key K


19  A range of messages M

2012.3.3 Signature Verification Operation

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 k1, 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.

10Figure 7 illustrates the scheme.

11
12 Figure 7 — DL/ECSSR signature generation and verification operations

1312.4.1 Scheme options

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.

612.4.2 Signature generation operation

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:

23  At least one valid set of domain parameters


24  At least one valid private key s for each set of domain parameters
25  A range of message parts M1 and M2 (where the range of non-recoverable message parts may
26 include only the empty string, i.e., conformance may be claimed for total message recovery only,
27 and where the range of recoverable message parts may explicitly exclude the empty string, i.e., to
28 distinguish from a signature scheme with appendix)
29NOTE—If the one-time key pair in step 2 is generated deterministically as a function of the message and the private
30key as suggested in D.5.2.1, and in step 5 the selected signature primitive outputs “error,” the signature generation
31operation above will enter an infinite loop. Since an “error” output is an extremely rare event for recommended sizes of
32domain parameters, this is not a practical concern, and it only applies in the case that the one-time key pair is generated
33deterministically, not when it is generated at random. If desired, the concern can be addressed by including a counter in
34the key derivation parameters for generating the one-time key pair deterministically, as noted in D.5.2.1.

3512.4.3 Signature verification operation

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:

14  At least one valid set of domain parameters


15  At least one valid public key w for each set of domain parameters; if key validation is performed,
16 invalid public keys w that are appropriately rejected by the implementation may also be included in
17 the conformance region
18  All non-recoverable message parts M2 that can be input to the implementation (which may include
19 only the empty string, i.e., conformance may be claimed for total message recovery only)
20  All purported signatures (c, d) that can be input to the implementation and that correspond to some
21 range of recoverable message parts (for instance, where the range of recoverable message parts
22 may exclude the empty string); this should at least include all (c, d) that correspond to the range of
23 recoverable messages such that c and d are in the range [0, r – 1], where r is from the domain
24 parameters of w
25NOTES

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.

36Figure 8 illustrates the scheme.

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

312.5.1 Scheme options

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.

2112.5.2 Signature generation operation

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:

18  At least one valid set of domain parameters


19  At least one valid private key s for each set of domain parameters
20  A range of messages parts M1 and M2 (where the range of non-recoverable message parts may
21 include only the empty string, i.e., conformance may be claimed for total message recovery only, or
22 where the range of recoverable message parts may explicitly exclude the empty string, i.e., to
23 distinguish from a signature scheme with appendix)

2412.5.3 Signature verification operation

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:

46  At least one valid set of domain parameters

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

112.6 10.6 IFSSR


2IFSSR is Integer Factorization Signature Scheme with Recovery.

3Figure 9 illustrates the scheme.

4
5 Figure 9 — IFSSR signature generation and verification operations

612.6.1 Scheme options

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

112.6.2 Signature generation operation

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:

16  At least one valid private key K


17  A range of message parts M1 and M2 (where the range of non-recoverable message parts may
18 include only the empty string, i.e., conformance may be claimed for total message recovery only,
19 and where the range of recoverable message parts may include octet strings only, i.e., arbitrary-
20 length bit strings do not need to be supported, or may explicitly exclude the empty string, i.e., to
21 distinguish from a signature scheme with appendix)

2212.6.3 Signature verification operation

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

113. Message Encoding Methods


2This clause describes message encoding methods used in this document as building blocks for schemes.
3Unlike cryptographic primitives and schemes, encoding methods do not use keys.

4Each message-encoding method consists of an encoding operation, and of either a decoding or a


5verification operation. In general, an encoding operation encodes the message to produce a non-negative
6integer, called a message representative. It takes the message, optionally the maximum bit length l of the
7output, and possibly other parameters as input, and produces the integer of bit length no more than l (see
83.1 for the definition of bit length of an integer). A decoding operation gives back the original message (or
9part of it) given the message representative, optionally the length l and the same additional parameters as
10were passed to the encoding operation. A verification operation verifies whether the message representative
11is a valid encoding of a message given the message representative, the message, optionally the length l and
12the same parameters as were passed to the encoding operation. (The one exception to the model here is
13EMSR2, which operates on octet string message representatives.)

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.

2413.1 Message Encoding Methods for Signatures with Appendix


25This standard strongly recommends the use of one of the following message encoding methods for
26signature schemes with appendix.

27NOTE—See D.5.2.2.1 for security considerations related to these encoding methods.

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).

31The method is parameterized by the following choice:

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

361—EMSA1 can handle messages of essentially any length in octets.

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.

313.1.1.1 Encoding Operation

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.

1613.1.1.2 Verification Operation

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:

24 r) Use the Encoding Operation of EMSA1 to compute a message representative g, a non-negative


25 integer. If the encoding operation outputs “error,” output “invalid” and stop.
26  2. If f = g, output “valid.” Else, output “invalid.”
27

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).

31The method is parameterized by the following choice:

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

61—EMSA2 can handle messages of essentially any length in octets.

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.

1613.1.2.1 Encoding Operation

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.

813.1.2.2 Verification Operation

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).

40The method is parameterized by the following choice:

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.)

Hash Function HashID

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

61—EMSA3 can handle messages of essentially any length in octets.

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

11DigestInfo ::= SEQUENCE {


12 digestAlgorithm AlgorithmIdentifier, -- hash function algorithm identifier
13 digest OCTET STRING -- hash value }

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.

1813.1.3.1 Encoding operation

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.

1213.1.3.2 Verification operation

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).

43The method is parameterized by the following choices:

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

91—EMSA4 can handle messages of essentially any length in octets.

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.

1313.1.4.1 Encoding operation

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.

2913.1.4.2 Verification operation

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).

12The method is parameterized by the following choices:

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

181—EMSA5 can handle messages of essentially any length in octets.

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.

2113.1.5.1 Encoding operation

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

113.1.5.2 Verification operation

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.”

1313.2 Message Encoding Methods for Encryption


14This standard strongly recommends the use of the following message encoding method for encryption
15schemes.

16NOTE—See D.5.3.2.1 for security considerations related to these encoding methods.

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.

23The method is parameterized by the following choice:

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.

3013.2.1.1 Encoding Operation

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.

1913.2.1.2 Decoding Operation

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”

26The message shall be decoded by the following or an equivalent sequence of steps:

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

1 11. Let T be the leftmost non-zero octet of M.


2 12. Compare the first hLen octets of DB to cHash. If they are not equal, or if X  hexadecimal
3 value 00, or if T  hexadecimal value 01, output “error” and stop. (The same error message
4 should be output for each situation, at the same time—see Note 1.)
5 13. Remove T and all octets to the left of it (which are all zero) from M to produce an octet string
6 M.
7 14. Output the message M.
8NOTES

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.

264—Step 3 may be precomputed, if P is known in advance.

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.

32The method is parameterized by the following choices:

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.

4013.2.2.1 Encoding operation

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.

2913.2.2.2 Decoding operation

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.

22The method is parameterized by the following choices:

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

381—EME3 can handle messages of essentially any length in octets.

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.

4413.2.3.1 Encoding operation

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.

4313.2.3.2 Decoding operation

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.

3813.3 Message-encoding methods for signatures giving message recovery


39This standard strongly recommends the use of one of the following message-encoding methods for
40signature schemes giving message recovery.

41NOTE—See D.5.2.2.2 for security considerations related to these encoding methods.

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

1The method is parameterized by the following choices:

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.

2113.3.1.1 Encoding operation

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

1 5. Let M = OS2BSP (C1 || C2 || M1 || M2) || I.


2 6. Compute Hash (M) with the selected hash function to produce an octet string H of length
3 hLen octets.
4 7. If hash function identification is desired, then let H = H || HashID, where HashID is a single
5 octet identifying the selected hash function (see the table in 12.1.2).
6 8. Let R be the leftmost rLen octets of H.
7 9. Let T = R || M1.
8 10. Convert T to an integer f with the primitive OS2IP.
9 11. Output f as the message representative.

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

113.3.1.2 Decoding operation

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).

32The method is parameterized by the following choices:

33  a) An integer padLen between 1 and 255 inclusive


34b) The method for combining the pre-signature with the (padded) recoverable message part, which shall
35 be either:
36 1) a stream cipher based on a key derivation function, where the key derivation function shall be
37 KDF2 (see 13.2) or a technique designated for use with EMSR2 in an amendment to this
38 standard
39 2) a key derivation function combined with a symmetric encryption scheme, where the key
40 derivation function shall be KDF2 (see 13.2) or a technique designated for use with EMSR2
41 in an amendment to this standard, and the symmetric encryption scheme shall be one of the

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.

1013.3.2.1 Encoding operation

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.

3913.3.2.2 Decoding operation

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).

34The method is parameterized by the following choices:

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.

1713.3.3.1 Encoding operation

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])).

2213.3.3.2 Decoding operation

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

1 7. Verify that the leftmost t bits of maskedDB are zero.


2 8. Apply the mask generation function G to the string H to produce a bit string dbMask of length
3 8oLen – hBits – 8u bits.
4 9. Let DB = maskedDB  dbMask.
5 10. Set the leftmost t bits of DB to zero.
6 11. Let MB1 be the leftmost 8oLen – saltBits – hBits – 8u bits of DB, and let salt be the rightmost
7 saltBits bits.
8 12. Let U be the leftmost nonzero bit of MB1. If MB1 has no nonzero bits, output “invalid” and
9 stop.
10 13. Remove U and all bits to the left of it (which are all zero) from MB1 to produce a bit string
11 MB1. (The bit string MB1 may be empty.) Let m1Bits be the length in bits of MB1.
12 14. Convert m1Bits to a bit string C1 of length 64 bits using I2BSP.
13 15. Let M = C1 || MB1 || H2 || salt.
14 16. Compute Hash (M) with the selected hash function to produce an octet string H of length
15 hBits bits.
16 17. If H  H output “invalid.”
17 18. If the output is to be returned as a bit string, output MB1 as the recoverable message part.
18 Otherwise, convert MB1 to an octet string M1 with the primitive BS2OSP and output M1 as the
19 recoverable message part.

2014. Key Derivation Functions


21This clause describes key derivation functions used in this standard as building blocks for key agreement
22schemes, encryption schemes and encoding methods. A key derivation function computes one or more
23shared secret keys from shared secret value(s) and other mutually-known parameters. The derived secret
24keys are usually used in symmetric cryptography.

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).

34The function is parameterized by the following choice:

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:

39  a shared secret string, which is an octet string Z of length zLen octets


40  key derivation parameters, which is an octet string P of length pLen octets (depending on the hash
41 function chosen, there may be a limitation on zLen + pLen; for SHA-1 and RIPEMD-160, the
42 maximum of zLen + pLen is 2 61 – 1)
43Output: a shared secret key, which is an octet string K of length hLen octets; or “error”

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).

13The function is parameterized by the following choice:

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

115. Auxiliary Functions


2This clause describes a number of additional non-public-key techniques supporting the methods in this
3standard. The list of techniques given here are reflects generally recommended practice, and is limited in
4the interest of encouraging interoperability. (See C.4 for rationale.) However, the list is not intended to be
5exhaustive. Other techniques are allowed within the framework of the schemes, though of course the
6selection of techniques not listed here requires further security analysis by the implementer.

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.

1515.1 Hash Functions


16A hash function is a building block for many techniques described in this standard. It takes a variable-
17length octet string or bit string as input and outputs a fixed-length octet string or bit string. The length of
18the input to a hash function is usually unrestricted or constrained by a very large number. The output
19depends solely on the input—a hash function is deterministic.

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 2611) or a bit string MB of length
5mBits bits (mBits shall be at most 2641)
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 2611) or a bit string MB of length
19mBits bits (mBits shall be at most 2641)
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 21251) or a bit string MB of length
33mBits bits (mBits shall be at most 21281)
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 21251) or a bit string MB of length
11mBits bits (mBits shall be at most 21281)
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.

2115.2 Mask Generation Functions


22This subclause describes a mask generation function used in this standard as a building block for some of
23the encoding methods. A mask generation function takes as input an octet string or bit string and the
24desired length in octets or bits of the output, and outputs an octet string or bit string of that length. The
25lengths of both the input to and the output of a mask generation function are usually unrestricted or
26constrained by a very large number. The output depends solely on the input—a mask generation function is
27deterministic.

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).

36The function is parameterized by the following choice:

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.

3715.3 Symmetric encryption schemes


38This subclause describes the symmetric encryption schemes used in this standard as building blocks for
39some encryption schemes and encoding methods. A symmetric encryption scheme consists of an
40encryption operation and a decryption operation. The encryption operation takes as input a message, which
41is an octet string or a bit string, and a key, and outputs an encrypted message, which is an octet string or a
42bit string. The encryption operation may be deterministic or randomized. The decryption operation takes as
43input an encrypted message and a key, and outputs a message or “error.”

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.

1515.3.1.1 Encryption operation

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  Ci1.
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.

615.3.1.2 Decryption operation

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  Ci1.
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.

315.3.2.1 Encryption operation

4Input:

5  A key, which is a bit string KB of length 128, 192 or 256 bits


6  A message, which is an octet string M of length mLen octets or a bit string MB of length mBits bits
7 (where mBits shall be divisible by 8)
8Output: A encrypted message, which is an octet string C of length cLen octets where cLen =
916(mLen+1)/16 or a bit string CB of length cBits bits where cBits = 128(mBits+8)/128
10The encrypted message shall be computed by the following or an equivalent sequence of steps:

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  Ci1.
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.

3115.3.2.2 Decryption operation

32Input:

33  A key, which is a bit string KB of length 128, 192 or 256 bits


34  An encrypted message, which is an octet string C of length cLen octets (cLen shall be a multiple of
35 16 and cLen shall be greater than or equal to 16) or a bit string CB of length cBits bits (cBits shall
36 be a multiple of 128 and cBits shall be greater than or equal to 128)
37Output: A message, which is an octet string M of length mLen octets where cLen  16  mLen  cLen  1
38or a bit string MB of length mBits bits where cBits  128  mLen  cBits  8; or “error”
39The message shall be recovered by the following or an equivalent sequence of steps:

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  Ci1.
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.

2215.4 Message authentication codes


23This subclause describes message authentication codes used in this standard as building blocks for some
24encryption schemes. A message authentication code computes a tag from a secret key and data.

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

5The tag shall be computed by the following or an equivalent sequence of steps:

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

1Annex A (Informative) Number-Theoretic Algorithms.

2A.1 Integer and Modular Arithmetic: Overview

3A.1.1 Modular arithmetic

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.

9The remainder must satisfy 0  r < m.


10Examples:

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

18a  b (mod m).


19Two integers are congruent modulo m if and only if their difference is divisible by m.

20Example:

2111  19 (mod 8).

22If r = a mod m, then r  a (mod m).

23If a0  b0 (mod m) and a1  b1 (mod m), then

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

30Zm = {0, 1, …, m – 1}.

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.

10G.C.D.'s and L.C.M.'s.

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

16GCD (h, m)  LCM (h, m) = hm


17(for h and m positive), so that the L.C.M. is easily computed if the G.C.D. is known.

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.

26A.1.2 Prime finite fields

27The field GF  (p).

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.

5Exponentiation and discrete logarithms.

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.

21A.1.3 Composite Moduli

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.

31The universal exponent of an RSA modulus n = pq is defined to be

32 (n) := LCM (p – 1, q – 1).

33If c and d are positive integers congruent modulo  (n), then

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

1for every integer a. It follows that, if

2de  1 (mod  (n)),


3then

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.

13A.1.4 Modular Square Roots

14The Legendre symbol.

 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.)

19The Jacobi symbol.

 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
,

23and a is any integer, then the Jacobi symbol is defined to be

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.

4Square roots modulo a prime.

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

20de  1 (mod  (n)/2),


21then

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.

3A.2 Integer and Modular Arithmetic: Algorithms

4A.2.1 Modular Exponentiation

5Modular exponentiation can be performed efficiently by the binary method outlined below.

6Input: a positive integer v, a modulus m, and an integer g modulo m.

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].

15A.2.2 The Extended Euclidean Algorithm

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).

21 v) If h = 1 then output d := 1 and c := g and stop.Set r0  m.Set r1  h mod m.Set s0  0.Set s1  g


22 mod m.
23  6. While r1 > 0
24 6.1 Set q   r0 / r1.
25 6.2 Set r2  r0 – qr1 mod m
26 6.3 Set s2  s0 – qs1 mod m
27 6.4 Set r0  r1
28 Set r1  r2
29 Set s0  s1
30 Set s1  s2
31 w) 7. Output d : = r0.If r0 = 1 then output c := s0
32If m is prime, the quotient exists provided that h ( 0 (mod m), and can be found efficiently using
33exponentiation via

34c := g hm–2 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

1A.2.3 Evaluating Jacobi Symbols

2The following algorithm efficiently computes the Jacobi symbol.

3Input: an integer a and an odd integer n > 1.

 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

22A.2.4 Generating Lucas Sequences

23Let P and Q be nonzero integers. The Lucas sequence Vk for P, Q is defined by

24V0 = 2, V1 = P, and Vk = PVk–1 – QVk–2 for k  2.


25This recursion is adequate for computing Vk for small values of k. For large k, one can compute Vk modulo
26an odd integer n > 2 using the following algorithm (see [JQ96]). The algorithm also computes the quantity
27Q k/2 mod n; this quantity will be useful in the application given in A.2.5.
28Input: an odd integer n > 2, integers P and Q, and a positive integer k.

29Output: Vk mod n and Q k/2 mod n.

30 y) Set v0  2, v1  P, q0  1, q1  1Let k = kr kr–1...k1 k0 be the binary representation of k, where the


31 leftmost bit kr of k is 1. For i from r downto 0 do
32 3.1 Set q0  q0 q1 mod n
33 3.2 If ki = 1 then set
34 q1  q0 Q mod n
35 v0  v0 v1 – P q0 mod n

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.

7A.2.5 Finding Square Roots Modulo a Prime

8The following algorithm computes a square root z modulo p of g  0.


9Input: an odd prime p, and an integer g with 0 < g < p.

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

23 V := V(p+1)/2 mod p and Q0 := Q (p–1)/4 mod p.


24
25 4. Set z  V / 2 mod p.
26 5. If (z 2 mod p) = g then output z and stop.
27 6. If 1 < Q0 < p – 1 then output the message “no square roots exist” and stop.
28 7. Go to Step 2.
29NOTES

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

1A.2.6 Finding Square Roots Modulo a Power of 2

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).

10 z) Set h  1.Set b  1.For j from 2 to r – 2 do


11 If hj+1  aj+1 then
12 Set bj  1.
13 If 2j < r
14 then h  (h + 2j+1b – 22j) mod 2 r.
15 else h  (h + 2j+1b) mod 2 r.
16 aa) 4. If br–2 = 1 then set b  2r–1 – b. Output b.

17A.2.7 Computing the Order of a Given Integer Modulo a Prime

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.

20Input: a prime p and an integer g with 1 < g < p.

21Output: the order k of g modulo 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.

24A.2.8 Constructing an Integer of a Given Order Modulo a Prime

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.

27Input: a prime p and an integer T dividing p – 1.

28Output: an integer u having order T modulo 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.

32A.2.9 An implementation of IF signature primitives (RSA and RW cases)

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

12d1 = (2p – 1) / 3 and d2 = (2q – 1) / 3.

13RW: if e = 2, then

14if p  3 (mod 8), q  7 (mod 8) and d odd, or


15if p  7 (mod 8), q  3 (mod 8) and d even

16d1 = (p + 1)/4 and d2 = (3q – 1)/4

17if p  3 (mod 8), q  7 (mod 8) and d even, or


18if p  7 (mod 8), q  3 (mod 8) and d odd

19d1 = (3p – 1)/4 and d2 = (q + 1)/4.


20In the RW case, one also computes via A.2.1

21w1 := exp (2, p – 1 – d1) mod p


22w2 := exp (2, q – 1 – d2) mod q.

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.)

26Output: the signature s of f.

27The steps marked with an asterisk below are to be implemented only for RW and not for RSA.

28 dd) Set f1  f mod p.


29  2. Compute j1 := exp (f1, d1) mod p via A.2.1.
30  *3. Compute i1 := exp (j1, e) mod p.
31 ee) *4. If i1 = f1 then set u1  0 else set u1  1.Set f2  f mod q.
32  6. Compute j2 := exp (f2, d2) mod q via A.2.1.
33  *7. Compute i2 := exp (j2, e) mod q.
34  *8. If i2 = f2 then set u2  0 else set u2  1.
35  *9. If u1  u2 then compute

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

3 and go to Step 11.


4 ff) Set

5 t 1  j 1, t 2  j 2
6 gg) Compute

7 h := (t1 – t2) c mod p


8 t := t2 + hq
9 hh) If IFSP-RSA1, output s := t. Else (that is, if IFSP-RSA2 or IFSP-RW) output s := (min t, pq – t).
10NOTE—Since the exponents are fixed in Steps 2 and 6, the exponentiations can be made more efficient using addition
11chains rather than the binary method A.2.1; see [Gor98].

12A.2.10 Multiplication in (Z/p2Z)

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
27p2 mod q are precomputed.

28A.2.11 An implementation of IFES-EPOC decryption

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:

36g  exp(u, f)  exp(v, r) mod n,

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
14q1 prior to exponentiation.

15NOTE—The rationale for checking modulo p rather than modulo p2 is based on the group isomorphism

16(, ): (Z/p2Z)*  (Z/pZ)  (Z/pZ)*

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

19f = L(gp)/w mod p,

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).

22A.3 Binary Finite Fields: Overview

23A.3.1 Finite Fields

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.

8A.3.2 Polynomials over Finite Fields

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.

15Example: Over the prime field GF (7),

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.

18A binary polynomial is a polynomial modulo 2.

19Example: Over the field GF (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

33r (t) := a (t) mod m (t).

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

1a (t)  b (t) (mod m(t)).


2One can define addition, multiplication, and exponentiation of polynomials (to integral powers) modulo
3m (t), analogously to how they are defined for integer congruences in A.1.1. In the case of a prime field
4GF (p), each of these operations involves both reduction of the polynomials modulo m (t) and reduction of
5the coefficients modulo p.

6A.3.3 Binary Finite Fields

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,

9GF (23) = {000, 001, 010, 011, 100, 101, 110, 111}.

10The integer m is called the degree of the field.

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,

15(11001) + (10100) = (01101)

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.

22A.3.4 Polynomial Basis 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

26am–1 tm–1 + … + a2t 2 + a1t + a0.

27The polynomial basis is the set

28B = {t m–1, …, t2, t, 1}.

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.

7Trinomials and pentanomials.

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.

15A.3.5 Normal Basis Representations

16Normal bases.

17A normal basis for GF (2m) is a set of the form

18B = {  ,  2 ,  2 , . . .,  2
2 m1
}

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 m1
.

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.

27Gaussian normal bases.

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.

7A.3.6 Checking for a Gaussian Normal Basis

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.)

10Input: an integer m > 1 not divisible by 8; a positive integer T.

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).

17A.3.7 The Multiplication Rule for a Gaussian Normal Basis

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

5Therefore, after simplifying one obtains

6c0 = a0 (b1 + b2 + b3) + a1 (b0 + b2) + a2 (b0 + b1) + a3 (b0 + b3).

7Here c0 is the first coordinate of the product

8(*) (c0 c1 . . . cm–1) = (a0 a1 . . . am–1)  (b0 b1 . . . bm–1).

9The other coordinates of the product are obtained from the formula for c0 by cycling the subscripts modulo
10m. Thus

11c1 = a1 (b2 + b3 + b0) + a2 (b1 + b3) + a3 (b1 + b2) + a0 (b1 + b0),


12c2 = a2 (b3 + b0 + b1) + a3 (b2 + b0) + a0 (b2 + b3) + a1 (b2 + b1),
13c3 = a3 (b0 + b1 + b2) + a0 (b3 + b1) + a1 (b3 + b0) + a2 (b3 + b2).

14A.3.8 A Multiplication Algorithm for a Gaussian Normal Basis

15The formulae given in A.3.7 for c0, …, cm–1 can be implemented in terms of a single expression. For

16u = (u0 u1 … um–1), v = (v0 v1 … vm–1),

17let

18F(u, v)

19be the expression with

20c0 = F (a, b).

21Then the product (*) can be computed as follows.

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

31a := (1000) =  and b := (1101) =  +  2 +  8,


32then

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

1c0 = F ((1000), (1101)) = 0,


2c1 = F ((0001), (1011)) = 0,
3c2 = F ((0010), (0111)) = 1,
4c3 = F ((0100), (1110)) = 0,

5so that c = ab = (0010).

6A.3.9 Binary Finite Fields (cont'd)

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)*.

14Clause A.4.4 contains an efficient method for division.

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,

14then F = {0, 1, t 2 + t, t 2 + t + 1} forms the field GF (22).

15A.3.10 Parameters for Common Key Sizes

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

112 2068 1628456355410411547509613374150158051231656743052344513161858038422-


883778013

128 2880 1919487818858585561290806193694428146403929496534649176795333025024-


9208842371201

1A.4 Binary Finite Fields: Algorithms


2The following algorithms perform operations in a finite field GF (2m) having 2m elements. The elements of
3GF (2m) can be represented either via a polynomial basis modulo the irreducible polynomial p (t) or via a
4normal basis {  ,  2 ,  2 , . . .,  2 }.
2 m1

5A.4.1 Squaring and Square Roots

6Polynomial Basis:

7If

8 = m–1tm–1 + … + 2t2 + 1t + 0,


9then

102 = m–1t2m–2 + … + 2t4 + 1t2 + 0 mod p(t).

11To compute  , take  and square m – 1 times.

12Normal Basis:

13If  has representation

14 = (0 1 . . . m–1),


15then

162 = (m–1 0 1 . . . m–2)


17and

18  = (1 . . . m–2 m–1 0).

19A.4.2 The Squaring Matrix

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).

22Suppose that the field polynomial is

23p(t) := t m + cm–1 t m–1 + …+ c1 t + c0.

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

1Let d0,j  cj for 0  j < m, and compute


m m–1
2t = d0,m–1 t + …+ d0,1 t + d0,0
m+1 m–1
3t = d1,m–1 t + …+ d1,1 t + d1,0
4…
5t 2m–2 = dm–2,m–1 t m–1 + …+ dm–2,1 t + dm–2,0

6by repeated multiplication by t. Define the matrix

 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

13Exponentiation can be performed efficiently by the binary method outlined below.

14Input: a positive integer k, a field GF (2m) and a field element .

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.

27Method I: the Extended Euclidean Algorithm.

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.

4Input: a field GF (2m), and field elements  and   0.

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

161—An efficient hardware implementation of this procedure is described in [Ber68].

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

25k  –1 (mod r),

26where r is the order of . In particular, it is always the case that


m
27 –1 =  2 2
.

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.

32Input: a field GF (2m) and a nonzero field element .

33Output: the reciprocal  –1.

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

7If  is an element of GF (2m), the trace of  is

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:

12If  has representation (0  1... m–1), then

13Tr () = 0  1  ...  m–1.


14Polynomial Basis:

15The basic algorithm inputs GF (2m) and outputs T = Tr ().

16 pp) Set T .


17  2. For i from 1 to m – 1 do
18 2.1 T  T 2 +.
19  3. Output T.
20If many traces are to be computed with respect to a fixed polynomial basis

21{t m–1, …, t, 1},

22then it is more efficient to compute and store the element

23 = (m–1…10)
24where each coordinate

25j = 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

30If m is odd, the half-trace of   GF (2m) is


2 181
3 Copyright © 1999 IEEE. All rights reserved.
4 This is an unapproved IEEE Standards Draft, subject to change.
1 IEEE P1363/D1-pre, June 2009

1HfTr () = + 2 + 2 + ... + 2 .


2 4 m–1

2The following algorithm inputs GF (2m) and outputs H = HfTr ()

3 qq) Set H .


4  2. For i from 1 to (m – 1) /2 do
5 2.1 H  H 2.
6 2.2 H  H 2 +.
7  3. Output H.

8A.4.7 Solving Quadratic Equations over GF (2m)

9If  is an element of GF (2m), then the equation

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.

16Output: an element z for which z 2 + z = , if such an element exists.


17Normal basis:

18 rr) Let (0 1... m–1) be the representation of Set z0  0For i = 1 to m – 1 do


19 3.1 Set zi  zi–1  i
20  4. Output z  (z0 z1...zm–1)
21Polynomial basis:

22If m is odd, then compute z := half-trace of  via A.4.6. For m even, proceed as follows.

23 ss) Choose random   GF (2m)Set z  0 and w .For i from 1 to m – 1 do


24 3.1 Set z  z2 + w 2.
25 3.2 Set w  w2 + .
26 tt) 4. If w = 0 then go to Step 1Output z.
27If the latter algorithm is to be used repeatedly for the same field, and memory is available, then it is more
28efficient to precompute and store  and the values of w. Any element of trace 1 will serve as , and the
29values of w depend only on  and not on 
30Both of the above algorithms produce a solution z provided that one exists. If it is unknown whether a
31solution exists, then the output z should be checked by comparing  := z2 + z with . If  = , then z is a
32solution; otherwise no solutions exist.

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

1A.5 Polynomials over a Finite Field


2The computations below can take place either over a prime field (having a prime number p of elements) or
3over a binary field (having 2m elements).

4A.5.1 Exponentiation Modulo a Polynomial

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).

8Output: the polynomial f(t)k mod m(t).

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].

16A.5.2 G.C.D.'s over a Finite Field

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)).

23 vv) Set a(t)  f(t), b(t)  g(t).


24  2. While b(t)  0
25 2.1 Set c(t)  the remainder when a(t) is divided by b(t).
26 2.2 Set a(t)  b(t).
27 2.3 Set b(t)  c(t).
28 ww) 3. Set   the leading coefficient of a(t).Set d(t)   –1 a(t).
29  5. Output d(t).

30A.5.3 Factoring Polynomials over GF (p) (Special Case)

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

1Output: a random degree-d factor of f(t).

2 xx) Set g(t)  f(t).


3  2. While deg(g) > d
4 2.1 Choose u(t)  a random monic polynomial of degree 2d – 1.
5 2.2 Compute via A.5.1
d
1)/ 2
6 c(t) := u( t )( p mod g(t).
7 2.3 Set h(t)  GCD(c(t) – 1, g(t)).
8 2.4 If h(t) is constant or deg(g) = deg(h) then go to Step 2.1.
9 2.5 If 2 deg(h) > deg(g) then set g(t)  g(t) / h(t); else g(t)  h(t).
10  3. Output g(t).

11A.5.4 Factoring Polynomials over GF (2) (Special Case)

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.

17Output: a random degree-d factor of f(t).

18 yy) Set g(t)  f(t).


19  2. While deg(g) > d
20 2.1 Choose u(t)  a random monic polynomial of degree 2d – 1.
21 2.2 Set c(t)  u(t).
22 2.3 For i from 1 to d – 1 do
23 2.3.1 c(t)  c(t)2 + u(t) mod g(t).
24 2.4 Compute h(t) := GCD(c(t), g(t)) via A.5.2.
25 2.5 If h(t) is constant or deg(g) = deg(h) then go to Step 2.1.
26 2.6 If 2 deg(h) > deg(g) then set g(t)  g(t) / h(t); else g(t)  h(t).
27  3. Output g(t).

28A.5.5 Checking Polynomials over GF (2r) for Irreducibility

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.

31Input: a polynomial f(t) with coefficients in GF (2r).

32Output: the message “True” if f(t) is irreducible; the message “False” otherwise.

33 zz) Set d  degree of f(t).Set u(t)  t.For i from 1 to d/2 do


34 3.1 For j from 1 to r do
35 Set u(t)  u(t)2 mod f(t)
36 Next j
37 3.2 Set g(t)  GCD(u(t) + t, f(t)).
38 3.3 If g(t)  1 then output “False” and stop.

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.”

2A.5.6 Finding a Root in GF (2m) of an Irreducible Binary Polynomial

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.

6Output: a random root of f(t) in GF (2m).

7 aaa) Set g(t)  f(t) (g(t) is a polynomial over GF (2m)).


8  2. While deg(g) > 1
9 2.1 Choose random u  GF (2m).
10 2.2 Set c(t)  ut.
11 2.3 For i from 1 to m – 1 do
12 2.3.1 c(t)  c(t)2 + ut mod g(t).
13 2.4 Set h(t)  GCD(c(t), g(t)).
14 2.5 If h(t) is constant or deg(g) = deg(h) then go to Step 2.1.
15 2.6 If 2 deg(h) > deg(g) then set g(t)  g(t) / h(t); else g(t)  h(t).
16  3. Output g(0).

17A.5.7 Embedding in an Extension Field

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).

21Output: an embedding of F into K; that is a function taking each   F to a corresponding element  of


22K.

23 a) Compute via A.5.6 a root   K of p(t).


24  2. If B is a polynomial basis then output

25  := am–1  m–1 + … + a2 2 + a1 + a0,

26 where (am–1 … a1 a0) is the bit string representing  with respect to B.


27 b) If B is a normal basis then output

2 m 1
28  := a0  a12  a22  am12 ,

29 where (a0 a1 … am–1) is the bit string representing  with respect to B.

30A.6 General Normal Bases for Binary Fields


31The algorithms in this clause allow computation with any normal basis. (In the case of Gaussian normal
32bases, the algorithms of A.3 are more efficient.)

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.

3A.6.1 Checking for a Normal Basis

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.

6Input: an irreducible polynomial p(t) degree m over GF (2).

7Output: if p(t) is normal, two m-by-m matrices over GF (2). If not, the message “not normal.”

8 c) Represent the successive squares of t (mod p(t)) as

9 t = a0,0 + a0,1t + a0,2t2 + …+ a0,m–1t m –1 (mod p(t))

10 t2 = a1,0 + a1,1t + a1,2t2 + …+ a1,m–1t m –1 (mod p(t))

11 t4 = a2,0 + a2,1t + a2,2t2 + …+ a2,m–1t m –1 (mod p(t))

12 …

13 t2m–1 = am–1,0 + a m–1,1t + a m–1,2t2 + …+ a m–1,m–1t m –1 (mod p(t))


14 d) Set

 a 0,0 a0,1  a0,m1 


 
a1,0 a1,1  a1,m1 
15 A:   .
    
 
 a m1, 0 a m1,1  a m1,m1 
16 e) Attempt to compute the inverse B of the matrix A over GF (2).
17  4. If A is not invertible, output the message “not normal” and stop; otherwise output A and B.

18A.6.2 Finding a Normal Basis

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.

28A.6.3 Computing the Multiplication Matrix

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

1Input: a normal polynomial

2p(t) = t m + cm–1 t m–1 + … + c1 t + c0

3over GF (2); the matrices A and B computed by A.6.1.

4Output: the multiplication matrix M for p(t).

5  1. Set

0 1 0  0 
 
0 0 1  0 
6 C:       .
 
0 0 0  1 
 
 c0 c1 c2  c m1 
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,0 0,1  0,m1 


 
1, 0 1,1  1,m1 
9 M :   .
    
 
  m1, 0  m1,1   m1,m1 
10Example: Let p(t) = t4 + t3 + t2 + t + 1. Then

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

8(c0 c1 … cm–1) = (a0 a1… am–1)  (b0 b1 … bm–1),


9then

10c0 = a0 (b1 + b2 + b3) + a1 (b0 + b2) + a2 (b0 + b1) + a3 (b0 + b3).

11Thus the multiplication matrix for B is

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).

18Output: the product c = (c0 c1 … cm–1) of a and b.

19 g) Set x  a.Set y  b.For k from 0 to m – 1 do


20 3.1 Compute via matrix multiplication

21 ck := x M ytr

22 where ytr denotes the matrix transpose of the vector y.

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

16so that c = ab = (0111).

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

1A.7 Basis Conversion for Binary Fields


2In order to use DL and EC protocols over a finite field F = GF (2m), it is necessary for the users to agree on
3a common field degree m but not on a common basis representation of F. If the users do not agree on the
4basis, however, it is necessary for one or both users to perform a change of basis, i.e. to convert incoming
5and/or outgoing field elements between one's own representation and that of the other user's.

6A.7.1 The Change-of-Basis Matrix

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 

14is the bit string representing  in terms of B1.

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

19represents  in terms of B0.

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).

30The inverse of  over GF (2) is

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).

5A.7.2 The Field Polynomial of a Gaussian Normal Basis

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).

12Output: the field polynomial p(t) for the basis.

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

1 (The polynomial f(t) has integer coefficients.)


2 5. Output p(t) := f(t) mod 2.
3NOTE—The complex numbers ek must be computed with sufficient accuracy to identify each coefficient of the
4polynomial f(t). Since each such coefficient is an integer, this means that the error incurred in calculating each
5coefficient should be less than 1/2.
6Example: Let m = 4 and T = 3. By the example of A.3.6, there exists a Gaussian normal basis of type 3 for
7GF (24) over GF (2). Now p = 13, and u = 3 has order T = 3 modulo p = 13.

8The complex numbers ek are

9e1 := e 2 i /13
+ e 6 i /13
– e 5 i /13

10 0.6513878188659973233 + 0.522415803456407715 i

11e2 := e 4 i /13
+ e 12 i /13
+ e 10 i /13

12 –1.1513878188659973233 + 1.7254221884220093641 i

13e3 := e 8 i /13
– e 11 i /13
– e 7 i /13

14 0.6513878188659973233 – 0.522415803456407715 i

15e4 := – e  i /13
– e 3 i /13
– e 9 i /13

16 –1.1513878188659973233 – 1.7254221884220093641 i


17Thus

18f(t) := (t – e1) (t – e2) (t – e3) (t – e4) = t4 + t3 + 2t2 – 4t + 3

19so that p(t) := t4 + t3 + 1 is the field polynomial for the basis.

20A.7.3 Computing the Change-of-Basis Matrix

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.)

26Output: the change-of-basis matrix  from B0 to B1.

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

t m1 j if B1  {t m1 ,..., t 2 , t ,1}


29 ej =  2j 22 2 m1
  if B1  { ,  ,  ,...,  }.
2

30 i) Compute the elements i,j for 0  i < m, 0  j < m as follows.


31 — If B0 is a polynomial basis, then compute

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

m1
1 1= 
j0
m1, j ej
m1
2 u= 
j0
m 2 , j ej

3 
m1
4 u m–2 =  j 0
1, j ej

m1
5 u m–1 =  j0
0, j ej

6 by repeated multiplication by u.
7 — If B0 is a normal basis, then compute

m1
8 u= 
j0
0, j e j

m1

9 2
u =  1, j e j
j 0
m1

10 22
u =  2, j e j
j0

11 
m1

12 u 2m–1 = 
j 0
m1, j e j

13 by repeated squaring.
14  5. Output

  0, 0  0,1   0,m1 
 
  1, 0  1,1   1,m1 
15 
    
 
  m1, 0  m1,1   m1,m1 
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

m1
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

6A.7.4 Conversion to a Polynomial Basis

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).

16If B1 is a Type I optimal normal basis, then the change-of-basis matrix is

  0, 0  0,1   0,m1 
 
  1, 0  1,1   1,m1 
17 :  
    
 
  m1, 0  m1,1   m1,m1 
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 m1
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

1A.7.5 Storage-efficient conversion techniques

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].

18A.7.6 Storage-efficient import

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

23If B0 is a Polynomial Basis:

24  Setup (once per basis)


25 
26 1. Let u be a root of p0(t) represented with respect to B1. (u can be computed via A.5.6; see also
27 Note 2 below.)
28 
29  Conversion (per each element)
30 
31 2. Let a = (am-1 … a2 a1 a0).
32 3. Set e  1 (the element one of GF(2m), represented with respect to B1).
33 4. If am–1 = 0, then set v  0; else set v  e.
34 5. For i from m – 2 downto 0 do
35 5.1 Set v  vu.
36 5.2 If ai = 1, set v  v + e.
37 6. Output v.
38If B0 is a Normal Basis:

39  Setup (once per basis)


40 

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.)

15A.7.7 Multiplication matrix for a polynomial basis

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.

19Input: A field degree m; a polynomial basis B1

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

1so the matrix M is

2M := .

3A.7.8 Storage-efficient export

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.)

7Output: The bit string a of length m such that the representation of v in B0 is a

8If B0 is a Polynomial Basis:

9  Setup (once per basis)


10 
11 1. Compute the matrix  via A.7.3. Let u be a root of p0(t) represented with respect to B1. (It is
12 computed in A.7.3.) Compute w := u–1 via A.4.4. (See Note 3 below.)
13 2. Set    –1 and let s = (0,m–1 1,m–1 … m–1,m–1) be a row-vector whose elements are the (m–1)-
14 st column of .
15 3. Compute the multiplication matrix M for B1 via A.6.3 or A.7.7 (note that A.6.3 includes a
16 separate efficient method for computing the multiplication matrix in the case of a Gaussian
17 normal basis using A.3.7).
18 4. Let z = s M–1. Note that z is an m-element bit string; let z be the element of GF(2m) whose
19 representation in B1 is z.
20 
21  Conversion (per each element)
22 
23 5. Set v  vz.
24 6. For i = 0 to m – 2
25 6.1 Let ai be the leftmost bit of the representation of v in B1.
26 6.2 If ai = 1, then set v  v + z.
27 6.3 Set v := vw.
28 7. Let am–1 be the leftmost bit of the representation of v in B1.
29 8. Output a := (am-1 … a2 a1 a0).
30If B0 is a Normal Basis:

31  Setup (once per basis)


32 
33 1. Compute the matrix  via A.7.3.
34 2. Set    –1 and let s = (0,m–1 1,m–1 … m–1,m–1) be a row-vector whose elements are the (m–
35 1)-st column of .
36 3. Compute the multiplication matrix M for B1 via A.7.7.
37 4. Let z = s M–1. Note that z is an m-element bit string; let z be the element of GF(2m) whose
38 representation in B1 is z.
39 
40  Conversion (per each element)
41 

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 … am1).
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 := u1 = t4 + t3 + t2

11 := 1 =
12s = (11111)

13M :=

14M1 :=
15z = s M–1 = (11100)

16z = t4 + t3 + t2

17(Note that  = 1 and w = z in this example.)

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

21In step 7, the conversion operation computes a4 = 1. The result is a = (10001).

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 :=

2M1 :=
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.)

6A.8 Bases for Binary Fields: Tables and Algorithms

7A.8.1 Basis Table

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

m Coefficients GB m coefficients GB m coefficients GB m coefficients GB


Type Type Type Type

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

1A.8.2 Random Search for Other Irreducible Polynomials

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.

12A.8.3 Irreducibles from Other Irreducibles

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

29f(t) = h0(t 3) + t h1(t 3) + t 2 h2(t 3).

30Then

31g(t) = h0(t) 3 + t h1(t) 3 + t 2 h2(t) 3 + t h0(t) h1(t) h2(t)

32is an irreducible of degree m.

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).

3Define the functions

4wk(t) = t k/r hk(t).

5Let M be the r-by-r matrix with entries

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.

8A.8.4 Irreducibles of Even Degree

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

13is irreducible, then so is

14P(t) = t 2d + t d + t 2d–2 + t d–1 + 1 +  (t


i
2 ki
 t ki ) .

15Note that the sum over i is allowed to be empty.

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.

26Input: an irreducible f(t) of odd degree d.

27Output: an irreducible P(t) of degree 2d.

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.

12A.8.5 Irreducible Trinomials

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.)

22A.9 Elliptic Curves: Overview

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.

35The Weierstrass equation.

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

8 where a and b are elements of GF (2m) with b  0.


9NOTE—there is another kind of Weierstrass equation over GF (2m), giving what are called supersingular
10curves. However, these curves are cryptographically weak (see [MOV93], [Hitt07]); thus they are omitted
11from this Standard.

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)).

16Example: Let E be the curve

17y 2 = x 3 + 10 x + 5

18over the field GF (13). Then the points on E are

19{O, (1,4), (1,9), (3,6), (3,7), (8,5), (8,8), (10,0), (11,4), (11,9)}.

20Thus the order of E is #E (GF (13)) = 10.

21Example: Let E be the curve

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

25{O, ((000), (001)),


26((010), (100)), ((010), (110)), ((011), (100)), ((011), (111)),
27((100), (001)), ((100), (101)), ((101), (010)), ((101), (111)),
28((110), (000)), ((110), (110)), ((111), (001)), ((111), (110))}.

29Thus the order of E is #E (GF (23)) = 14.

30For more information on elliptic curve cryptography, see [Men93b].

31A.9.2 Operations on Elliptic Curves

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

1Define the inverse of the point P = (x, y) to be

( 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.

5The point at infinity.

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

9for all points P.

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

220P = O, (–n) P = n (–P).

23A.9.3 Elliptic Curve Cryptography

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.

11A.9.4 Analogies with DL

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

Setting GF (q)* curve E over GF (q)

Basic operation multiplication in GF (q) addition of points

Main operation exponentiation scalar multiplication

Base element generator g base point G

Base element order prime r prime r

Private key s (integer modulo r) s (integer modulo r)

Public key w (element of GF (q)) W (point on E)

16A.9.5 Curve Orders

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.

25 Thus the order of an elliptic curve over GF (q) is approximately q.

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

1A.9.6 Representation of Points

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.

28The compressed x coordinate, denoted ~


x , is a bit string one bit shorter than the bit string representing x.

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),

2 so that the compressed form of x = (a5 a4 a3 a2 a1 a0) is ~


x = (a5 a4 a3 a2 a0).
3The choice of dropped bit depends only on the representation of the field, not on the choice of point.

4NOTES

51—Algorithms for decompressing coordinates are given in A.12.8 through A.12.10.

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

15The projective coordinates of a point are not unique because

16(X, Y, Z) = ( 2X,  3Y,  Z)

17for every nonzero   GF (q).

18The projective coordinates of the point at infinity are ( 2,  3, 0), where   .


19Other kinds of projective coordinates exist, but the ones given here provide the fastest arithmetic on elliptic
20curves. (See [CC87].)

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.

27A.10 Elliptic Curves: Algorithms

28A.10.1 Full Addition and Subtraction (prime case)

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

1Output: the point P2 := P0 + P1.

2 g) If P0 = O then output P2  P1 and stopIf P1 = O then output P2  P0 and stopIf x0  x1 then


3 3.1 set   (y0 – y1) / (x0 – x1) mod p
4 3.2 go to step 7
5 h) 4. If y0  y1 then output P2  O and stopIf y1 = 0 then output P2  O and stop

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).

10A.10.2 Full Addition and Subtraction (binary case)

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.

15Output: the point P2 := P0 + P1.

16 j) If P0 = O, then output P2  P1 and stopIf P1 = O, then output P2  P0 and stopIf x0  x1 then


17 3.1 set   (y0 + y1) / (x0 + x1)
18 3.2 set x2  a +  2 +  + x0 + x1
19 3.3 go to step 7
20 k) 4. If y0  y1 then output P2  O and stopIf x1 = 0 then output P2  O and stop
21  6. Set
22 6.1   x1 + y1 / x1
23 6.2 x2  a +  2 + 
24 l) 7. y2  (x1 + x2)  + x2 + y1P2  (x2, y2)
25The above algorithm requires 2 general multiplications, a squaring, and a multiplicative inversion.

26To subtract the point P = (x, y), one adds the point –P = (x, x + y).

27Further Speedup.

28The two steps

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].)

8A.10.3 Elliptic Scalar Multiplication

9Scalar multiplication can be performed efficiently by the addition-subtraction method outlined below.

10Input: an integer n and an elliptic curve point P.

11Output: the elliptic curve point nP.

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.

15  6. For i from l – 1 downto 1 do


16 Set S  2S.
17 If hi = 1 and ki = 0 then compute S  S + Q via A.10.1 or A.10.2.
18 If hi = 0 and ki = 1 then compute S  S – Q via A.10.1 or A.10.2.
19  7. Output S.
20There are several modifications that improve the performance of this algorithm. These methods are
21summarized in [Gor98].

22A.10.4 Projective Elliptic Doubling (prime case)

23The projective form of the doubling formula on the curve y 2 = x 3 + ax + b modulo p is

242 (X1, Y1, Z1) = (X2, Y2, Z2),

25where

26M = 3 X 12 + a Z14 ,
27Z2 = 2Y1Z1,
28S = 4X1 Y12 ,
2
29X2 = M – 2S,
30T = 8 Y14 ,
31Y2 = M (S – X2) – T.

32The algorithm Double given below performs these calculations.

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

1 n) T1  X1T2  Y1 T3  Z1If T2 = 0 or T3 = 0 then output (1, 1, 0) and stop.If a = p – 3 then


2 T4  T32
3 T5  T1 – T4
4 T4  T1 + T4
5 T5  T4  T5
6 T4  3  T5
7 =M
8  else
9 T4  a
10 T5  T32
11 T5  T52
12 T5  T4  T5
13 T4  T12
14 T4  3  T4
15 T4  T4 + T5
16 =M
17 o) 6. T3  T2  T3T3  2  T3
18 = Z2T2  T22 T5  T1  T2T5  4  T5
19 = ST1  T42 T1  T1 – 2  T5
20 = X2T2  T22 T2
21  8  T2 = TT5  T5 –
22 T1T5  T4  T5T2  T5 – T2
23 = Y2 X2  T1Y2  T2
24  20. Z2  T3
25This algorithm requires 10 field multiplications and 5 temporary variables. If a is small enough that
26multiplication by a can be done by repeated addition, only 9 field multiplications are required. If a = p – 3,
27then only 8 field multiplications are required (see [CC87]). The proportion of elliptic curves modulo p that
28can be rescaled so that a = p – 3 is about 1/4 if p  1 (mod 4) and about 1/2 if p  3 (mod 4). (See Annex
29A.9.5, Basic Facts.)

30A.10.5 Projective Elliptic Addition (prime case)

31The projective form of the adding formula on the curve y 2 = x 3 + ax + b modulo p, is

32(X0, Y0, Z0) + (X1, Y1, Z1) = (X2, Y2, Z2),

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.

6The algorithm Add given below performs these calculations.

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

1A.10.6 Projective Elliptic Doubling (binary case)

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 2m2 ,

5computed from b by m – 2 squarings. (Thus b = c 4.) The formula is

62 (X1, Y1, Z1) = (X2, Y2, Z2),

7where

8Z2 = X1 Z12 ,
9X2 = (X1 + c Z12 )4,
10U = Z2 + X12 + Y1Z1,
11Y2 = X14 Z2 + UX2.

12The algorithm Double given below performs these calculations.

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.

16 t) T1  X1T2  Y1 T3  Z1T4  cIf T1 = 0 or T3 = 0 then output (1, 1, 0) and stop.T2  T2  T3T3 


17 T32 T4  T3  T4T3  T1  T3
18 = Z2T2  T2 + T3T4  T1 + T4T4  T42 T4  T42
19 = X2T1  T12 T2  T1 + T2
20 = UT2  T2  T4T1  T12 T1  T1  T3T2  T1 + T2
21 = Y2T1  T4X2  T1Y2  T2Z2 
22 T3
23This algorithm requires 5 field squarings, 5 general field multiplications, and 4 temporary variables.

24A.10.7 Projective Elliptic Addition (binary case)

25The projective form of the adding formula on the curve y 2 + xy = x 3 + ax2 + b over GF (2m) is

26(X0, Y0, Z0) + (X1, Y1, Z1) = (X2, Y2, Z2),

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.

9The algorithm Add given below performs these calculations.

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.)

12A.10.8 Projective Full Addition and Subtraction

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

24A.10.9 Projective Elliptic Scalar Multiplication

25Input: an integer n and an elliptic curve point P = (X, Y, Z).

26Output: the elliptic curve point nP = (X*, Y*, Z*).

27 aa) If n = 0 or Z = 0 then output (1, 1, 0) and stop.


28  2. Set
29 2.1 X*  X
30 2.2 Z*  Z
31 2.3 Z1  1
32 bb) 3. If n < 0 then go to Step 6Set
33 4.1 kn
34 4.2 Y*  Y

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].

12A.11 Functions for Elliptic Curve Parameter and Key Generation

13A.11.1 Finding a Random Point on an Elliptic Curve (prime case)

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).

16Input: a prime p > 3 and the parameters a, b of an elliptic curve E modulo p.

17Output: a randomly generated point (other than O) on E.

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).

25A.11.2 Finding a Random Point on an Elliptic Curve (binary case)

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).

29Output: a randomly generated point (other than O) on E.

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

1A.11.3 Finding a Point of Large Prime Order

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.

10A.11.4 Curve Orders over Small Binary Fields

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

13 = (–1) Tr (a).

14For each nonzero x  GF (2d), let

15 (x) = Tr (x + b/x2).


16Then

17#E(GF (2d)) = 2d + 1 +   ( 1)
(x)
.
x 0

18A.11.5 Curve Orders over Extension Fields

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).

23Output: the order u of E over GF (2de).

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.

27A.11.6 Curve Orders via Subfields

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.

3A.12 Functions for Elliptic Curve Parameter and Key Validation

4A.12.1 The MOV Condition

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

12where 2m  q < 2m+1 and

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

128-142 6 281-297 14 407-420 22

143-165 7 298-313 15 421-434 23

166-186 8 314-330 16 435-448 24

187-206 9 331-346 17 449-462 25

207-226 10 347-361 18 463-475 26

227-244 11 362-376 19 476-488 27

245-262 12 377-391 20 489-501 28

263-280 13 392-406 21 502-512 29

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

1 a) Determine the prime p dividing q.


2 b) Set t  1.
3 c) For i from 1 to B logpq do
4 1) Set t  tp mod r.
5 2) If t = 1 then output “False” and stop.
6 d) Output “True.”

7A.12.2 The Weil Pairing

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

15 (3x12 + a) (u  x1)  2 y1 (v  y1) if x0 = x1 and y0 = y1

16 (x0  x1) v  (y0  y1) u  (x0 y1  x1 y0) if x0  x1

17 if E is the curve y2 = x3 + ax + b over GF(p), and by

18 u + x1 if x0 = x1 and y0 = x1 + y1

19 x13 + (x12 + y1) u + x1 v if x0 = x1 and y0 = y1

20 (x0 + x1) v + (y0 + y1) u + (x0 y1 + x1 y0) if x0  x1

21 if E is the curve y2 + xy = x3 + ax2 + b over GF(2m).

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

26 g(A, B, C) := f(A, B, C) / f(A + B, – A – B, C).


27 
28  The Weil function h is computed via the following algorithm.
29Input: A prime l > 2; a curve E; finite points D, C on E

30Output: The Weil function h(D, C)

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

1 3. Set hb  hb  hb  g(B, B, C).


2 4. Set B  2B.
3 5. If n is odd then
4 5.1 Set ha  ha  hb  g(A, B, C).
5 5.2 Set A  A + B.
6 6. If n > 1 then go to Step 2.
7 7. Output ha.
8 
9  Given points R and S on E, let

10 j(R, S) := h(R, S) / h(S, R).


11 
12  Given points P and Q on E with lP = lQ = O, the Weil pairing <P, Q> is computed as follows:
13
14 Choose random finite points T  P, U  Q on E and let

15 V = P + T, W = Q + U.
16
17 Then

18 <P, Q> = j(T, U) j(U, V) j(V, W) j(W, T).


19If, in evaluating <P, Q>, one encounters f((x0, y0), (x1, y1), (u, v)) = 0, then the calculation fails. In this
20(unlikely) event, repeat the calculation with newly chosen T and U.

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.

24A.12.3 Verification of Cofactor

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

18 k:  l1v1 ... lsvs

19 where the li’s are distinct primes and each vi is positive.


20  4. For i from 1 to s do
21 4.1 Set l  li, v  vi.
22 4.2 Set

 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

1 4.10 If  < v then go to Step 4.5


2  5. Output “cofactor confirmed.”

3A.12.4 Constructing Verifiably Pseudo-Random Elliptic Curves (prime case)

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.

9It is assumed that the following quantities have been chosen:

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:

18v = log2 p,


19s = (v – 1)/B,
20w = v – B s – 1.

21Input: a prime modulus p; lower and upper bounds rmin and rmax for r; a trial division bound lmax < rmin.

22Output: a bit string X; EC parameters q = p, a, b, r, and G.

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

32 cb2  a3 (mod p).

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.

5A.12.5 Verification of Elliptic Curve Pseudo-Randomness (prime case)

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.

10Input: a bit string X of length L; EC parameters q = p, a, b, r, and G = (x, y).

11Output: “True” or “False.”

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 GO
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.”

28A.12.6 Constructing Verifiably Pseudo-Random Elliptic Curves (binary case)

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.

34It is assumed that the following quantities have been chosen:

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  a cryptographic hash function H with output length B bits, where

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.

9Output: a bit string X; EC parameters q = 2m, a, b, r, and G.

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.

26A.12.7 Verification of Elliptic Curve Pseudo-Randomness (binary case)

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.

31Input: a bit string X of length L; EC parameters q = 2m, a, b, r, and G = (x, y).

32Output: “True” or “False.”

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 b0
6 7.2 b = b
7 7.3 GO
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.”

11A.12.8 Decompression of y Coordinates (prime case)

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.

15Output: the y coordinate of the point.

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.

21A.12.9 Decompression of y coordinates (binary case, LSB form)

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.

25Output: the y coordinate of the point.

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

1A.12.10 Decompression of x Coordinates (binary case)

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.

14Output: the x coordinate of P.

15If F is represented by a normal basis or m is odd:

16 r) ~ || 0)If Tr (x*) = Tr (a) then set x  x*; else set x := ( x~ || 1)Output x


Set x* := ( x
17If F is represented by a polynomial basis and m is even:

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

24 wj = uj+1 for 0  j < s.

25 That is, x* is the polynomial

26 um–1 t m–1 + …+ us+1 t s+1 + us t s–1 + … + u1.


27 t) If Tr (x ) = Tr (a) then output x  x*; else ouput x  x* + t s
*

28A.12.11 Decompression of y coordinates (SORT form)

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.

33Output: The y coordinate of the point.

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.

15A.13 Class Group Calculations


16The following computations are necessary for the complex multiplication technique described in A.14.

17A.13.1 Overview

18A reduced symmetric matrix is one of the form

 A B
19 S   
 B C

20where the integers A, B, C satisfy the following conditions:

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

1A.13.2 Class Group and Class Number

2The following algorithm produces a list of the reduced symmetric matrices of a given determinant D. See
3[Bue89].

4Input: a squarefree determinant D > 0.

5Output: the class group H (D).

6 v) Let s be the largest integer less than D/3.


7  2. For B from 0 to s do
8 2.1 List the positive divisors A1, …, Ar of D + B 2 that satisfy 2B  A  D  B2 .
9 2.2 For i from 1 to r do
10 2.2.1 Set C  (D + B 2) / Ai
11 2.2.2 If GCD (Ai, 2B, C) = 1 then
12 list [Ai, B, C].
13 if 0 < 2B < Ai < C then list [Ai, – B, C].
14  3. Output list.
15Example: D = 71. The values of B that need to be checked are 0  B < 5.

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

23H (71) = {[1,0,71], [3, 1,24], [8, 1,9], [5, 2, 15]} .


24and the class number is h (71) = 7.

25A.13.3 Reduced Class Polynomials

26Let

 (1)  z 

( 3 j 2  j )/ 2 2
27F(z) = 1 +
j
 z (3 j  j )/ 2

j 1

28= 1 – z – z2 + z5 + z7 – z12 – z15 + ...

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 .

8If [A, B, C] is a matrix of determinant D, then its class invariant is

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 if D  1,2,6 (mod 8),



14 K  1 if D  3,7 (mod 8),
4 if D  5 (mod 8),

 A  C  A2 C if AC odd or D  5 (mod 8) and C even,



 A  2C  AC
2
if D  1,2,3,6,7 (mod 8) and C even,
15 L  
 A  C  5 AC
2
if D  3 (mod 8) and A even,
 A  C  AC 2 if D  1,2,5,6,7 (mod 8) and A even,

( 1)( A 1)/ 8


2
if A odd ,
17 M 2
( 1)( C 1)/ 8 if 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

6The reduced class polynomial has integer coefficients.

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  e23i / 24 
t  f2 8,1,9  t  f2 8,1,9
 2  2 
14
 e5i /12  e5i /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.

11A.14 Complex Multiplication

12A.14.1 Overview

13If E is a non-supersingular elliptic curve over GF (q) of order u, then

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+1W

21for some W and V.

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.

14A.14.2 Finding a Nearly Prime Order over GF (p)

15A.14.2.1 Congruence Conditions

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, ….

28If p  1 (mod 8) and K = 2 or 3, then


29D = 1, 2, 3, 5, 6, 10, 11, 13, 14, 17, 19, 21, ….

30If p  1 (mod 8) and K  4, then

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

1D = 1, 2, 3, 5, 6, 7, 10, 11, 13, 14, 15, 17, ….

2If p  3 (mod 8) and K = 2 or 3, then


3D = 2, 3, 10, 11, 19, 26, 34, 35, 42, 43, 51, 58, ….

4If p  3 (mod 8) and K  4, then


5D = 2, 3, 7, 10, 11, 15, 19, 23, 26, 31, 34, 35, ….

6If p  5 (mod 8) and K = 2 or 3, then


7D = 1, 3, 5, 11, 13, 17, 19, 21, 29, 33, 35, 37, ….

8If p  5 (mod 8) and K  4, then


9D = 1, 3, 5, 7, 11, 13, 15, 17, 19, 21, 23, 29, ….

10If p  7 (mod 8) and K = 2 or 3, then


11D = 3, 6, 11, 14, 19, 22, 30, 35, 38, 43, 46, 51, ….

12If p  7 (mod 8) and K  4, then


13D = 3, 6, 7, 11, 14, 15, 19, 22, 23, 30, 31, 35, ….

14A.14.2.2 Testing for CM Discriminants (prime case)

15Input: a prime p and a squarefree positive integer D satisfying the congruence conditions from A.14.2.1.

16Output: if D is a CM discriminant for p, an integer W such that

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.”

5A.14.2.3 Finding a Nearly Prime Order (prime case)

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,

30and r is the prime

31r = 6277101735386680763835789423337720473986773608255189015329.

32Thus there is a curve modulo p of order r having complex multiplication by D.

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

1A.14.3 Finding a Nearly Prime Order over GF (2m)

2A.14.3.1 Testing for CM Discriminants (binary case)

3Input: a field degree d and a squarefree positive integer D  7 (mod 8).


4Output: if D is a CM discriminant for 2 d, an odd integer W such that

52 d+2 = W 2 + DV 2,

6for some odd V. If not, the message “not a CM discriminant.”

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

10  4. Until |2B|  A  C, repeat the following steps.


 B 1
11 4.1 Let     .
C 2
 0  1
12 4.2 Let T   
1  
13 4.3 Replace U by T –1U.
14 4.4 Replace S by T t S T, where T t denotes the transpose of T.
15  5. Let X and Y be the entries of U. That is,

 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.”

19A.14.3.2 Finding a Nearly Prime Order (binary case)

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

1Example: Let q = 2155. Then

24q = X 2 + DY 2 and q + 1 – X = 4r

3where D = 942679, X = 229529878683046820398181, Y = –371360755031779037497, and r is the prime

4r = 11417981541647679048466230373126290329356873447.

5Thus there is a curve over GF (q) of order 4r having complex multiplication by D.

6A.14.4 Constructing a Curve and Point (prime case)

7A.14.4.1 Constructing a Curve with Prescribed CM (prime case)

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.)

12For nine values of D, the coefficients of E can be written down at once:

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

163 –8697680 9873093538

13For other values of D, the following algorithm may be used.

14Input: a prime modulus p and a CM discriminant D > 3for p.

15Output: a0 and b0 such that the elliptic curve

16y 2  x 3 + a0x + b0 (mod p)


17has CM by D.

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

3 V := (–1)D 2 4I/K s 24/(GK) mod p,

4 where G, I and K are as in A.13.3. Finally, let

5 a0 := –3(V + 64)(V + 16) mod p,


6 b0 := 2(V + 64)2 (V – 8) mod p.
7 ff) If W is odd, then use A.5.3 with d = 3 to find a cubic factor g (t) of wD(t) modulo p. Perform the
8 following computations, in which the coefficients of the polynomials are integers modulo p.

  t 24 mod g( t ) if 3 | D,
9 V ( t ):  
 256t mod g ( t ) if 3 | D,
8

10 a1(t) := –3(V(t) + 64) (V(t) + 256) mod g(t),


11 b1(t) := 2(V(t) + 64)2 (V(t) – 512) mod g(t),

12 a3(t) := a1(t)3 mod g(t),


13 b2(t) := b1(t)2 mod g(t).

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.

21If p = 2192 – 264 – 1, then

22wD (t)  (t 3 – (5 + )t 2 + (1 – )t – 2) (t 3 – (5 – )t 2 + (1 + )t – 2) (mod p),

23where  = 1254098248316315745658220082226751383299177953632927607231. The resulting


24coefficients are

25a0 = –2089023816294079213892272128,
26b0 = –36750495627461354054044457602630966837248.

27Thus the curve y 2  x 3 + a0x + b0 modulo p has CM by D = 235.

28A.14.4.2 Choosing the Curve and Point (prime case)

29Input: EC parameters p, k, and r, and coefficients a0, b0 produced by A.14.4.1.

30Output: a curve E modulo p and a point G on E of order r, or a message “wrong order.”

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).

19A.14.5 Constructing a Curve and Point (binary case)

20A.14.5.1 Constructing a Curve with Prescribed CM (binary case)

21Input: a field GF (2m), a CM discriminant D for 2m, and the desired curve order u.

22Output: a and b such that the elliptic curve

23y2 + xy = x3 + ax2 + b

24over GF (2m) has order u.

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.

19If t is a root of p(t), then the curve

20y 2+xy = x 3 + t 3

21over GF (2155) has order 4r, where r is the prime

22r = 11417981541647679048466230373126290329356873447.

23A.14.5.2 Choosing the Curve and Point (binary case)

24Input: a field size GF (2m), an appropriate D, the corresponding k and r from A.14.3.2.

25Output: a curve E over GF (2m) and a point G on E of order r.

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.

28A.15 Primality Tests and Proofs


29Techniques for generating and testing primes are also provided in ANSI X9.80 [ANS98g].

30A.15.1 A Probabilistic Primality Test

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.

35Output: the message “prime” or “composite.”

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

1 ll) Compute v and odd w such that n – 1 = 2vw.


2  2. For j from 1 to t do
3 2.1 Choose random a in the interval 0 < a < n.
4 2.2 Set b  aw mod n.
5 2.3 If b = 1 or n – 1 go to Step 2.6.
6 2.4 For i from 1 to v – 1 do
7 2.4.1 Set b  b2 mod n.
8 2.4.2 If b = n – 1 go to step 2.6.
9 2.4.3 If b = 1 output “composite” and stop.
10 2.4.4 Next i.
11 2.5 Output “composite” and stop.
12 2.6 Next j.
13  3. Output “prime.”
14If the algorithm outputs “composite,” then n is composite. If the algorithm outputs “prime” then n is
15almost certainly prime.

16A.15.2 Testing a Randomly Generated Integer for Primality

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

20(provided that t > 1 and k  88; see [DLP93]).


21To achieve a probability of error less than 2 –100 for a random k-bit integer, one should choose the number t
22of trials according to the following list.

k t k t k t

160 34 202-208 23 335-360 12

161-163 33 209-215 22 361-392 11

164-166 32 216-222 21 393-430 10

167-169 31 223-231 20 431-479 9

170-173 30 232-241 19 480-542 8

174-177 29 242-252 18 543-626 7

178-181 28 253-264 17 627-746 6

182-185 27 265-278 16 747-926 5

186-190 26 279-294 15 927-1232 4

191-195 25 295-313 14 1233-1853 3

196-201 24 314-334 13 1854-up 2


2 248
3 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 t in this table can be lowered in many cases; see [DLP93] and [Bur96].

2A.15.3 Validating Primality of a Given Integer

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.

6A.15.4 Proving Primality

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}

11in which each component Ci consists of positive integers

12Ci = (pi ,ri , ai, bi, xi, yi),

13where:

14 
15  For all i, (xi, yi) is a point of order ri on the elliptic curve

16 y2  x3 + aix + bi (mod pi),


17 
18  ri  4 pi  1 for all i,

19  p1 = n,
20  pi+1 = ri for 1  i < s,
21  rs < lmax
2
,

22  rs is proved prime by trial division.


23If a primality certificate exists for n, then n is prime by the following result (see [GK86]):

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

26y2  x3 + ax + b (mod p).


27Then p is prime if r is.

28The GKA algorithm can be implemented as follows.

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

1Output: a primality certificate for n, or an error message.

2 mm) Set C  {}.Set i  0.Set r  n.


3  4. 2
While r > lmax do
4 4.1 Set i  i + 1.
5 4.2 Set p  r.
6 Set rmin  ( 4 p  1) .
2
4.3
7 4.4 Find positive integers D, k, r (via A.14.2.3) such that
8 — r  rmin,
9 — r tests “prime” in A.15.3,
10 — kr is an order of an elliptic curve over GF (p) with CM by D.
11 4.5 Set Ci  (p, r, D, k).
12 4.6 Append Ci to C.
13 nn) 5. s  i.Confirm primality of r by trial division. (If it is found that r is composite, then
14 output an error message and stop.)
15  7. For i from 1 to s do
16 7.1 Recover (p, r, D, k)  Ci.
17 7.2 Find via A.14.4.2 a curve

18 E : y2  x3 + ax + b (mod p)

19 over GF (p) and a point (x,y) on E of order r.


20
21 7.3 Set Ci  (p, r, a, b, x, y).
22  8. Output C.

23A.15.5 Testing for Near Primality

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.”

4A.15.6 Generating Random Primes

5The following algorithm generates random primes within a given interval.

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.

18A.15.7 Generating Random Primes with Congruence Conditions

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.

36A.15.8 Strong Primes

37A large prime p is called strong if

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.

24A.16 Generation and Validation of Parameters and Keys

25A.16.1 An Algorithm for Generating DL Parameters (prime case)

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

1  8. Output p, r, g. If desired, also output k.

2A.16.2 An Algorithm for Validating DL Parameters (prime case)

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.

5Output: “True” or “False.”

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.

13A.16.3 An Algorithm for Generating DL Parameters (binary case)

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.”

19 xx) For i from 1 to l do


20 1.1 Set m  mi
21 1.2 If m does not appear in the list given in Annex A.3.10, then go to Step 1.5
22 1.3 Set r to the value in the list that corresponds to m.
23 1.4 If rmin  r  rmax then go to Step 4.
24 1.5 Next i
25  2. For i from 1 to l do
26 2.1 Set m  mi
27 2.2 Obtain the known primitive prime factors of 2m – 1 (see Note 1 below)
28 2.3 Remove those factors r from the list that are not between rmin and rmax
29 2.4. If the parameters will be used for DLSVDP-DHC or DLSVDP-MQVC, remove those prime
30 factors r from the list for which r2 divides 2m – 1.
31 2.5 If any factors remain, then let r be one of them and go to Step 4.
32 2.6 Next i
33 yy) 3. Output the message “no such parameters” and stop.Set k  (2m – 1)/r.Choose a
34 polynomial or normal basis for the field GF (2m) (see Note 2 below)Choose an element h of
35 GF (2m) not already chosen.Compute g := h k in GF (2m) via A.4.3.If g = 1 then go to Step 6.
36  9. Output 2m, r, g and k.
37NOTES

381—See Annex A.3.9 for the definition of a primitive prime factor of 2 m – 1.

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.

11A.16.4 An Algorithm for Validating DL Parameters (binary case)

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.

14Output: “True” or “False.”

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.

28A.16.5 An Algorithm for Generating DL Keys

29Input: valid DL parameters q, r and g

30Output: a public key w, a private key s

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.

33A.16.6 Algorithms for Validating DL Public Keys

34The following algorithm verifies if a DL public key is valid.

35Input: valid DL parameters q, r and g; the public key w.

36Output: “True” or “False.”

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.

8Input: valid DL parameters q, r and g; the public key w.

9Output: “True” or “False.”

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.

13A.16.7 An Algorithm for Generating EC Parameters

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 .

18Output: EC parameters q, a, b, r and G; the cofactor k if desired.

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).

25A.16.8 An Algorithm for Validating EC Parameters

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).

30Output: “True” if validation was possible; otherwise “False.”

31 eee) If k is not supplied


32 1.1 If r  4 q and the parameters will be used for key validation, ECSVDP-DHC or ECSVDP-
33 MQVC, then output “False” and stop.
34 1.2 Go to Step 4.
35 fff) 2. If r < q +1 and the parameters will be used for key validation, ECSVDP-DHC or
36 ECSVDP-MQVC, then verify that r does not divide k. If this is NOT the case (i.e., if r divides k)
37 then output “False” and stop.Verify the cofactor k via A.12.3. If the result is “cofactor rejected,”
38 then output “False” and stop.Check that r is an odd integer and that r > 2. Check primality of r via
39 A.15.3.If q = p, then
40 5.1 Check that p is an odd integer and p > 2. Check primality of p via A.15.3.
2 255
3 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.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.

39A.16.9 An Algorithm for Generating EC Keys

40Input: valid EC parameters q, a, b, r, and G.

41Output: a public key W, a private key s

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

1A.16.10 Algorithms for Validating EC Public Keys

2The following algorithm verifies if a EC public key is valid.

3Input: valid EC parameters q, a, b, r, G and k such that r does not divide k; a public key W.

4Output: “True” or “False.”

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.

12Input: valid EC parameters q, a, b, r, and G; a public key W.

13Output: “True” or “False.”

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.

18A.16.11 An Algorithm for Generating RSA Keys

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.

28Output: an RSA modulus n of bit length L, and the secret exponent d.

29 jjj) Generate a prime p from the interval

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 L1   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.

6A.16.12 An Algorithm for Generating RW Keys

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.

16Output: an RW modulus n of bit length L, and the secret exponent d.

17 mmm) Generate a prime p  3 (mod 8) from the interval

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 L1   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

28A.17 Odd characteristic extension fields


29As defined in A.3.1, a finite field (or Galois field) is a set with finitely many elements in which the usual
30algebraic operations (addition, subtraction, multiplication, division by nonzero elements) are possible, and
31in which the usual algebraic laws (commutative, associative, distributive) hold. The order of a finite field is
32the number of elements it contains. A finite field is identified with the notation GF(pm) for a prime p and
33positive integer m. When m > 1, field elements are represented as polynomials with coefficients from

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.

7A.17.1 Basic arithmetic in an odd characteristic extension field

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:

14A(t) = am-1 tm-1 + … + a1 t + a0, ai  GF(p)


15All arithmetic operations are performed modulo the field polynomial. The choice of field polynomial
16determines the complexity of the modular reduction.

17A.17.1.1 Addition and subtraction

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.

21A.17.1.2 Extension field multiplication

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 2m2:

25C (t) = A(t)  B(t) = c2m2 t2m-2 + … + c1 t + c0, ci  GF(p).

26The schoolbook method to calculate the coefficients ci, i = 0, 1, …, 2m2, requires m2 multiplications and
27(m1)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

1A.17.1.3 Square roots in odd-characteristic extension fields

2The following algorithm tests whether an element of GF(pm) is a square.

3Input: A field GF(pm), and an element g.

4Output: The message “square” or “not a square”.

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).

9Input: A field GF(pm), and an element g.

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].

25A.17.2 Optimal extension fields

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:

29 rrr) 1. p is a pseudo-Mersenne prime, a positive rational integer of the form 2 n  c, log2 c 


30 n/2.An irreducible binomial f(t) = tm –  exists over GF(p). (See Note.)
31(To check if the binomial is irreducible in this case, it suffices to check that w(p – 1)/s ¹ 1 mod p, for all primes
32s dividing e, where e is the order of  in GF(p)*. See Lidl and Niederreiter [LN94] for further discussion.)
33The characteristic p is often chosen based on the implementation platform. Thus, for a machine with
34efficient 32-bit arithmetic, one would choose p slightly less than 232. There are two special cases of OEF
35which yield additional arithmetic advantages, which are referred to as Type I and Type II.
2 260
3 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.17.2.1 Type I optimal extension fields

2A Type I Optimal Extension Field has p = 2n  1.


3A Type I OEF allows for subfield modular reduction with very low complexity. An OEF may be of both
4Type I and Type II.

5A.17.2.2 Type II optimal extension fields

6A Type II Optimal Extension Field has an irreducible binomial f(t) = tm – 2.

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.

10A.17.3 A.17.3 Optimal extension fields: algorithms

11A.17.3.1 Subfield multiplication

12The following algorithm implements subfield multiplication in an OEF.

13Input: A prime p = 2n  c, log2 c  n/2, integers 0  a, b < p

14Output: The integer r  ab (mod p)

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.

32A.17.3.2 Extension field modular reduction

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

1A.17.3.3 Extension field inversion

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.

5Input: A field GF(pm) and a nonzero field element 

6Output: The reciprocal 1

7 
8 1. Set r  (pm – 1) / (p – 1).
9 2. Set b   r1.
10 3. Set c  b.
11 4. Set   c1.
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:

17r = pm1 + pm2 + … + p + 1


18This corresponds to the p-adic representation (r – 1) = (11…10)p. Exponentiation, then, may be performed
19by repeatedly multiplying and taking p-th powers, in an analogous manner to the algorithm in A.5.1. Since
20(r – 1) will be fixed for a given field, an addition chain can be used to further reduce the computation
21required. Using such an addition chain constructed from the p-adic representation of (r – 1) requires:

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.

28Input: An OEF GF(pm),  =  j t j  GF(pm), an integer i

29Output:  = exp(, pi)

30 

31 1. For j from m1 downto 1


32 1.1 Set (j)  j ij where (j) = jpi mod m and ij = exp(, jpi / m). (Note that ij 
33 GF(p).)
34 2. Set 0  0.
35 3. Output  =  j t j.
36Since the ij i values will be fixed for a particular field, they may be precomputed and stored. Thus, this
37algorithm requires (m – 1) subfield multiplications by fixed elements.

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

1A.17.3.4 Subfield inversion

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

8Output:  where tm –  is an irreducible binomial over GF(p).

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.

22A.17.3.6 Table of Type I OEFs for the EC setting

23The following table provides Type I OEFs with 2160  pm  2256.


24

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

2A.17.3.7 Construction in the DL setting

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.)

14The cyclotomic polynomials are given by Riesel [Rie94] as:

15m(p) = d | m (pd – 1)(m/d)

16where  is the Mobius function defined thus:

17(n) = 1 if n = 1

18(n) = 0 if n contains a repeated prime factor

19(n) = (-1)k if n is the product of k distinct primes.


20Thus, for example, to construct an OEF-based DL system with a p represented by 64 bits, one could choose
21an extension degree of 18 so that the extension field has approximately 2 1152 elements. This field order
22exceeds the common choice of a finite field with 21024 elements (see D.4.1.4 Note 1). It remains to
23determine if an appropriate subgroup exists.

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.

6A.17.3.8 Table of OEFs for the DL setting

log2 p p m log2 r r log2 pm

58 258- 234+1 18 161 3138320610132998497688144463853339613367952900057 1044

59 259-211+1 18 200 188222062239279730297769010625303600800297687351641233- 1062


7546233

59 259-214+1 18 170 2883345718368813094767002645029934631071589910312231 1062

59 259-235+1 18 316 164538667844615172998044896749279151834878314403135329- 1062


309699817283705564219174694625868584754553

60 260+233+1 18 288 784240371916466401270766923850864525046862402195369285- 1080


957380422128317734027860785898339

64 264-232+1 18 314 428828727546722615308311411476958152266834944388400620- 1152


87196651222703068076952299219309748312417

8NOTE—The values log2p, log2r and log2pm have been rounded to the nearest integer.

9A.17.4 Elliptic curve algorithms

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(ux1) 
6 2y1(vy1) when x0 = x1 and y0 = y1.

7A.17.4.1 Full addition and subtraction (p = 3)

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

12Output: The point P2 := P0 + P1

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).

27A.17.5 Domain parameters and keys

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.

33Validating DL parameters: Same as A.16.2, except that:

34  The field polynomial f(t) is also included as an input;


35  A new step between steps 2 and 3 checks that m is a positive integer, that f(t) is of degree m, and
36 that f(t) is irreducible;
37  Step 3 checks g with respect to GF(pm) rather than GF(p) and also checks that r > m and that r |
38 m(p) where m is the m-th cyclotomic polynomial (see 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

1  Step 4 checks that gr  1 (mod f(t)); and


2  Steps 5 and 6 operate on pm – 1 rather than p – 1.
3Generating DL keys: Same as A.16.5.

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).

6Generating EC parameters: Same general approach as A.16.7.

7Validating EC parameters: Same general approach as A.16.8, with some differences in details (e.g., the
8curve equation for p = 3).

9Generating EC keys: Same as A.16.9.

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

1Annex B (Normative) Conformance

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.

16B.1 General Model


17A claim of conformance is an assertion by an implementation that it operates in accordance with some
18specification, over some set of inputs. Thus, a claim of conformance has fundamentally two parts:

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.

43B.2 Conformance Requirements


44An implementation claiming conformance with a primitive or scheme specified in this standard shall meet
45the requirements specified in the clauses of the standard indicated below, in addition to the general criteria

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.

11The following is a template for a claim of conformance:

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.

20 Table B.1 — Required subclauses for conformance with primitives

Primitive Subclauses

DLSVDP-DH 4.2, 6.1, 6.2.1

DLSVDP-DHC 4.2, 6.1, 6.2.2

DLSVDP-MQV 4.2, 6.1, 6.2.3

DLSVDP-MQVC 4.2, 6.1, 6.2.4

DLSP-NR 4.2, 6.1, 6.2.5

DLVP-NR 4.2, 6.1, 6.2.6

DLSP-DSA 4.2, 6.1, 6.2.7

DLVP-DSA 4.2, 6.1, 6.2.8

DLPSP-NR2/PV 4.2, 6.1, 6.2.9

DLSP-NR2 4.2, 6.1, 6.2.10

DLVP-NR2 4.2, 6.1, 6.2.11

DLSP-PV 4.2, 6.1, 6.2.12

DLVP-PV 4.2, 6.1, 6.2.13

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

ECSVDP-DH 4.2, 7.1, 7.2.1

ECSVDP-DHC 4.2, 7.1, 7.2.2

ECSVDP-MQV 4.2, 7.1, 7.2.3

ECSVDP-MQVC 4.2, 7.1, 7.2.4

ECSP-NR 4.2, 7.1, 7.2.5

ECVP-NR 4.2, 7.1, 7.2.6

ECSP-DSA 4.2, 7.1, 7.2.7

ECVP-DSA 4.2, 7.1, 7.2.8

ECPSP-NR2/PV 4.2, 7.1, 7.2.9

ECSP-NR2 4.2, 7.1, 7.2.10

ECVP-NR2 4.2, 7.1, 7.2.11

ECSP-PV 4.2, 7.1, 7.2.12

ECVP-PV 4.2, 7.1, 7.2.13

IFEP-RSA 4.2, 8.1, 8.2.2

IFDP-RSA 4.2, 8.1, 8.2.1, 8.2.3

IFSP-RSA1 4.2, 8.1, 8.2.1, 8.2.4

IFVP-RSA1 4.2, 8.1, 8.2.5

IFSP-RSA2 4.2, 8.1, 8.2.1, 8.2.6

IFVP-RSA2 4.2, 8.1, 8.2.7

IFSP-RW 4.2, 8.1, 8.2.1, 8.2.8

IFVP-RW 4.2, 8.1, 8.2.9

IFEP-OU 4.2, 8.1, 8.2.10

IFDP-OU 4.2, 8.1, 8.2.11

IFSP-ESIGN 4.2, 8.1, 8.2.12

IFVP-ESIGN 4.2, 8.1, 8.2.13

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

1 Table B.2 — Required subclauses for conformance with schemes

Scheme Operation Subclauses

DL/ECKAS-DH1 Key agreement 4.3, 9.1, 9.2

DL/ECKAS-DH2 Key agreement 4.3, 9.1, 9.3

DL/ECKAS-MQV Key agreement 4.3, 9.1, 9.4

DL/ECSSA Signature generation 4.3, 10.1, 10.2.1, 10.2.2

Signature verification 4.3, 10.1, 10.2.1, 10.2.3

IFSSA Signature generation 4.3, 10.1, 10.3.1, 10.3.2

Signature verification 4.3, 10.1, 10.3.1, 10.3.3

DL/ECSSR Signature generation 4.3, 10.1, 10.4.1, 10.3.2

Signature verification 4.3, 10.1, 10.4.1, 10.3.3

DL/ECSSR-PV Signature generation 4.3, 10.1, 10.5.1, 10.5.2

Signature verification 4.3, 10.1, 10.5.1, 10.5.3

IFSSR Signature generation 4.3, 10.1, 10.6.1, 10.6.2

Signature verification 4.3, 10.1, 10.6.1, 10.6.3

IFES Encryption 4.3, 11.1, 11.2.1, 11.2.2

Decryption 4.3, 11.1, 11.2.1, 11.2.3

DL/ECIES Encryption 4.3, 11.1, 11.3.1, 11.3.2

Decryption 4.3, 11.1, 11.3.1, 11.3.3

IFES-EPOC Encryption 4.3, 11.1, 11.4.1, 11.4.2

Decryption 4.3, 11.1, 11.4.1, 11.4.3

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.

27B.3.2 DLSSA Signature Verification

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.

39An example conformance statement for this case is:

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.

29B.3.4 IFSSA Signature Verification

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

1Annex C (Informative) Rationale.

2This annex is presented in the form of questions and answers.

3C.1 General

4C.1.1 Why are there three families of cryptographic techniques?

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.

11C.1.2 Why are primitives and schemes separated?

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

1C.1.4 Why are constraints on key sizes not specified?

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.

16C.1.6 Why are key derivation functions needed?

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.

32C.2 Keys and domain parameters

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.

3C.2.2 Why allow multiple representations for GF(2m)?

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.

5C.4 Additional methods

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).

16C.4.2 Why was the MGF1 mask generation function selected?

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).

23C.4.3 Why have SHA-1, RIPEMD-160, SHA-256, SHA-384 and SHA-512?

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.

35C.4.4 Why have Triple-DES and AES?

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.

7C.4.5 Why was the MAC1 message authentication code selected?

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

1Annex D (Informative) Security considerations

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].

39NIST’s recent (draft) recommendations on key management [NIST03a][NIST03b][NIST03b] also offer an


40excellent treatment of the use of methods such as those in this standard to achieve specific security
41objectives.

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

1D.2 General Principles


2The storage and transmission of data in modern computer and communications systems is vulnerable to a
3number of threats, including unauthorized disclosure and modification, as well as impersonation of parties
4in the system. Parties’ assurances of where data is from, whether data is in its original form, who has access
5to data, and whether a party claiming a certain identity is authentic, all depend on appropriate protection of
6data.

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.

26D.3 Key Management Considerations


27This clause provides general information on key management. Proper key management is an essential
28component of cryptographic security. It is needed, in particular to ensure integrity, authenticity, and where
29appropriate, secrecy of domain parameters and keys.

30D.3.1 Generation of Domain Parameters and Keys

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.

42A public-private key pair may be generated as follows:


43 
44  by the owner of the keys (this is the most commonly used method)

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.

30D.3.2 Authentication of Ownership

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.

37Further considerations related to authentication are given by type of scheme in D.5.

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.

16D.3.3 Validation of Domain Parameters and Keys

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.

3D.3.4 Cryptoperiod and Protection Lifetime of Domain Parameters and Keys

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]).

36D.3.5 Usage Restrictions

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.

40Examples of usage restrictions include:

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.

20D.3.6 Storage of domain parameters and keys

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.

11D.4 Family-Specific Considerations


12This clause gives further information on security parameters for each of the three families, as well as
13generation of domain parameters (if any) and key pairs.

14D.4.1 DL Family

15D.4.1.1 Security Parameters

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.)

21D.4.1.2 Generation Method

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.)

8D.4.1.3 Other considerations

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:

32 logg w = logh w / logh g mod r .

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

1 DLSVDP-MQVC, ECSVDP-MQV, and ECSVDP-MQVC primitives. (See D.6 for more on


2 random number generation.)
3 bbbb) (Domain parameters, public key and private key sharing.) A set of domain parameters
4 may be shared, since by definition, the set of domain parameters may be common to any number of
5 keys. A private key should not be shared.
6 cccc)(Field representation.) The field representation is not known to affect security; its only
7 cryptographic roles are in the conversion of field elements to integers in the signature and
8 verification primitives, and to octet strings in the key agreement schemes. The choice of field
9 representation for domain parameters and keys is otherwise a matter of data formatting. In the two
10 cryptographic roles mentioned, no reason is currently known why the field representation should
11 have any impact on security. However, it is important that the parties to a scheme agree on the
12 representation in which conversion is to take place, since otherwise an opponent may be able to
13 trick the parties into operating with a different representation for conversion in an attempt to forge
14 signatures or obtain information about keys.

15D.4.2 EC Family

16D.4.2.1 Security Parameters

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.)

21D.4.2.2 Generation Method

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.)

10D.4.2.3 Other Considerations

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)

128 4.0 x 105

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

1 Table D.1: Estimated Cryptographic Strength for EC Generator Order Sizes

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

38D.4.3.1 Security Parameter

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

1D.4.3.2 Generation Method

2Considerations for generating keys in the IF family include the following:

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.)

24D.4.3.3 Other Considerations

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

Modulus size Processing time Memory requirements Storage


(MIPS-years) (bytes) requirements
(bytes)

Sieving process Linear Algebra

512 4.0 x 105 1.3 x 108 2.0 x 1010 5.0 x 1010

1024 3 x 1012 3 x 1011 1 x 1014 2 x 1014

2048 3 x 1021 8 x 1015 3 x 1018 7 x 1018

4096 2 x 1033 8 x 1021 3 x 1024 7 x 1024

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 2p1  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 

33D.5 Scheme-Specific Considerations


34This clause gives further information on security implications of choices for each of the three types of
35scheme, including primitives, key derivation function or encoding method, key derivation or encoding
36parameters, and authentication, validation, and cryptoperiod specifics for keys in the schemes.

37D.5.1 Key Agreement Schemes

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, r1] (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.

32D.5.1.2 Additional methods

33D.5.1.2.1 Key derivation functions

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.

9D.5.1.2.2 Hash functions

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.

18D.5.1.3 Key Confirmation

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]).

7D.5.1.4 Key Derivation Parameters

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.

19D.5.1.5 Authentication of Ownership

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

Scheme Authenticated Public Key

DH1 The party’s public key

DH2 Either of the party’s public keys

MQV The party’s first public key

25Table D.3: Summary of typical means of associating


26public keys with parties in a key agreement scheme

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

1D.5.1.6 Validation of domain parameters and keys

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

1D.5.1.7 Cryptoperiod and Protection Lifetime

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

Scheme Short-Term Private Key Short-Term Private Keys


(One-Party Forward Secrecy) (Two-Party Forward Secrecy)

DH1 Party’s private key Both parties’ private keys

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

19Table D.4: Summary of typical means for achieving


20forward secrecy in a key agreement scheme

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.

30D.5.2 Signature Schemes

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,
821601], and then reducing the integer modulo r. As a result the private key is biased toward the lower end of the
9interval [1, r1], 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, 22l1], 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,
182l1], and if the integer isn’t between 1 and r1, 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.

25D.5.2.2 Additional methods

26D.5.2.2.1 Message-encoding methods for signatures with appendix

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 r1.
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.

8D.5.2.2.2 Message-encoding methods for signatures giving message recovery

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 256. 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.)

7D.5.2.2.3 Key derivation functions

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.

14D.5.2.2.4 Hash functions

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

1D.5.2.2.5 Mask generation functions

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.

17D.5.2.2.6 Symmetric encryption schemes

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.

11D.5.2.4 Authentication of Ownership

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.)

31D.5.2.5 Validation of Domain Parameters and Keys

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.

10D.5.2.6 Cryptoperiod and Protection Lifetime

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.

25D.5.3 Encryption Schemes

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.

16D.5.3.2 Additional methods

17D.5.3.2.1 Message-encoding methods for encryption

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 n1 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

1D.5.3.2.2 Key derivation functions

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.

11D.5.3.2.3 Hash functions

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.

31D.5.3.2.4 Mask generation functions

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.

35D.5.3.2.5 Message authentication codes

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).

7D.5.3.2.6 Symmetric encryption schemes

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).

26D.5.3.3 Encoding and key derivation parameters

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.

12D.5.3.4 Authentication of Ownership

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.

15D.5.3.5 Validation of Domain Parameters and Keys

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.

8Both risks can be addressed by a number of means, as outlined further in D.5.1.6.

9D.5.3.6 Cryptoperiod and Protection Lifetime

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.

17D.5.4 Key Encapsulation Schemes

18TODO: Edit this down from the pasted-in primary text.

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

2Additional considerations related to key management may be found in [NIST-GUIDELINE].

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

31 ANS-X9.44 ASC X9F1 Working Group. Draft American National

32 Standard X9.44: Public Key Cryptography for the

33 Financial Services Industry -- Key Establishment

34 Using Integer Factorization Cryptography. Draft

35 D11, January 2006.

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

1 CMS-OAEP Housley, R. Use of the RSAES-OAEP Key Transport

2 Algorithm in the Cryptographic Message Syntax

3 (CMS). RFC 3560. July 2003.

5 IEEE-P1363a IEEE Std 1363a-2004: Standard Specifications for

6 Public Key Cryptography: Additional Techniques.

7 IEEE, 2004.

9 ISO-IEC-18033-2 ISO/IEC 18033-2:2005 Information technology --

10 Security techniques -- Encryption algorithms –

11 Part 2: Asymmetric Ciphers. ISO/IEC, 2005.

12

13 NESSIE NESSIE Consortium. Portfolio of Recommended

14 Cryptographic Primitives. February 27, 2003.

15 Available via http://www.cryptonessie.org/.

16

17 NIST-GUIDELINE National Institute of Standards and Technology.

18 Special Publication 800-57: Recommendation for Key

19 Management. Part 1: General Guideline. August 2005.

20 Available via http://csrc.nist.gov/publications/index.html.

21

22 PKCS1 Jonsson, J. and B. Kaliski. PKCS #1: RSA

23 Cryptography Specifications Version 2.1. RFC 3447.

24 February 2003.

25

26 RANDOM Eastlake, D., S. Crocker, and J. Schiller.

27 Randomness Recommendations for Security. RFC 1750.

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

2 SHOUP Shoup, V. A Proposal for an ISO Standard for

3 Public Key Encryption. Version 2.1, December 20,

4 2001. Available via http://www.shoup.net/papers/.

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.

21D.6 Random Number Generation


22As indicated throughout this standard, and this Annex in particular, generation of random numbers (or,
23more generally, random bit strings) is a tool commonly used in cryptography. Proper generation of random
24bit strings for cryptographic purposes is essential to security, particularly because secrets, such as private
25keys, are commonly derived from such strings. A failure of a random number generator (resulting in, for
26example, generation of predictable or repeating keys) is likely to make a system extremely vulnerable to an
27opponent. As opposed to random number generation in some other settings, where security is not a
28concern, cryptographic random number generation cannot generally be accomplished by simply invoking
29the software subroutine “random” in one’s favorite software library.

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

1D.6.1 Random Seed

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.

41Some sources of randomness that may be used include:

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

1  quantum effects in a semiconductor, such as a noisy diode or a noisy resistor


2  the frequency fluctuations of free-running oscillators
3  the fluctuations in the amount a metal insulator semiconductor capacitor is charged during a fixed
4 period of time
5  fluctuations in read times caused by air turbulence within a sealed disk drive dedicated to this task
6 [DIF94]
7  the difference between the output of two microphones in two different points in a room (provided
8 their amplification is normalized to minimize the difference signal)
9  the noise within the signal of a microphone or video-camera in a room (tends to provide less
10 variability and is easier to predict and observe than the previous method)
11  the electronic noise of an A-D converter with an unplugged microphone (the variability depends
12 heavily on the particular converter and environment)
13  variation in mouse movements or keystrokes and their timing (for example, the user may be asked
14 to sign his or her name with the mouse; note that accessibility of correct high-resolution timing data
15 for mouse movements and key strokes varies among different systems)
16  the system clock (tends to provide very little variability and can be assumed to be known to the
17 opponent except for the last few digits, but may be used in combination with other sources; note
18 also that the resolution of the system clock that is available to the application varies among
19 different systems)
20  operating system statistics that cannot be observed by a potential opponent (tend to provide little
21 variability)
22When using any of these sources, it is essential not to overestimate the amount of variability that is
23inaccessible to the opponent. For example, if the user is asked to sign his or her name, the signature may
24be known to the opponent, and only the deviations from the usual signature should be considered to provide
25variability. Or if the room sounds in a particular frequency range are used are used as a source of
26randomness, the opponent may be able to inject noises in that frequency range in order to bias the result. A
27more detailed analysis of some of these, as well as other, sources is provided in [ECS94].

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.

39D.6.2 Pseudo-Random Bit Generation

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.

37D.7 Implementation Considerations


38This standard (and this Annex in particular) focuses on the cryptographic methods and algorithms to
39implement them. Many engineering-related considerations are just as important in a secure
40implementation. This clause gives a sampling of the problems an implementer needs to consider. It is not
41meant to be comprehensive, as solutions to these problems are outside the scope of this standard. For more
42on secure implementation, see [FIP94a] and [MV97, Book 2, Appendix P].

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

1Annex E (Informative) Formats.

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.

36E.2 Representing basic data types as octet strings


37When integers, finite field elements, elliptic curve points, or binary polynomials need to be represented as
38octet strings, it should be done as described in this Clause. Other primitives for converting between
39different data types (including bit strings) are defined in Clause 5.

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

1E.2.1 Integers (I2OSP and OS2IP)

2Integers should be converted to/from octet strings using primitives I2OSP and OS2IP, as defined in the
3Clause 5.5.3 of the standard.

4E.2.2 Finite Field Elements (FE2OSP and OS2FEP)

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.

7E.2.3 Elliptic Curve Points (EC2OSP and OS2ECP)

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.

18E.2.4 Polynomials over GF(p), p  2 (PN2OSP and OS2PNP)


19Polynomials over GF(p), p prime (e.g., field polynomials, when represented as domain parameters) should
20be converted to/from octet string using primitives PN2OSP and OS2PNP, as defined below.

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

25f(t) = ae t e + ae–1 t e–1 + … + a1 t + a0,

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.

10E.3 Representing outputs of schemes as octet strings


11The signature and encryption schemes in this standard do not produce octet strings as their outputs. When
12a scheme output (e.g., a signature) needs to be represented as an octet string, it may be done as defined in
13this clause.

14E.3.1 Output data format for DL/EC signature schemes

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]).

32E.3.2 Output data format for IF signature schemes

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

1E.3.3 Output data format for IF encryption schemes

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.

11E.3.4 Output data format for DL/EC encryption scheme

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

1Annex F (Informative) Information about Patents

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

Patent Owner Contact for License Patent Number(s) Letter Date(s)

Certicom Corp. Hervé Séguin 4,745,568 (US) 19-Mar-1997


5520 Explorer Drive, 4th Floor Director of Licensing 5,600,725 (US) 25-Jun-1998
Mississauga, ON, L4W 5L1 tel: +1-905-501-3827 unspecified patent 6-Nov-2002
CANADA applications related to
“Elliptic Curve Discrete
Logarithm Method”,
“Discrete Logarithm
Problem Methods”, and
“Integer Factorization
Methods”;
6,349,318 (US)
6,337,909 (US)
6,336,188 (US)
9712690 (FR)
9801047 (FR)
2322775 (GB)
2318709 (GB)
6,279,110 (US)
6,212,281 (US)
6,195,433 (US)
6,178,507 (US)
2313272 (GB)
6,141,420 (US)
6,134,325 (US)
2321741 (GB)
6,122,736 (US)
9705976 (FR)
6,097,813 (US)
6,078,667 (US)
6,049,815 (US)
2309809 (UK)
5,999,626 (US)
9801204 (FR)
5,955,717 (US)
5,933,504 (US)
5,896,455 (US)
5,889,865 (US)
5,787,028 (US)
5,761,305 (US)
0337985 (EPO)
2176325 (GB)

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

CYLINK Robert B. Fougner 4,587,627 (US) 18-Aug-1999


Corporate Headquarters General Counsel
910 Hermosa Court tel: 408-735-5800
PO Box 3759 fax: 408-735-6643
Sunnyvale, CA 94088-3759
USA

Entrust Technologies Limited Michael F. Morgan 0,639,907 (EP) 14-Feb-2001


750 Heron Rd. Suite E080 General Counsel, Canadian
Ottawa, Ontario K1V1A7 Operations
CANADA email:
mike.morgan@entrust.com

Hewlett Packard Company Legal Department patent application titled 9-Sep-1998


PO Box 10301 Intellectual Property Section “Compression and
MS 20B0 tel: 415-857-6255 Decompression of Elliptic
Palo Alto, CA 94303-0809 fax: 415-857-5487 Curve Data Points”
USA

Hitachi Software Development Katsuo Ogawa unspecified patents related 3-Aug-1998


Center Director & General Manager to “RIPEMD-160,
Hitachi Ltd. Hitachi Ltd. RIPEMD-128 and SHA-1
New Marunouchi Building Intellectual Property Office hash functions”
5-1, Marunouchi 1-chome tel: +81-3-3212-1111
Chiyoda-ku fax: +81-3-3214-3110/3116
Tokyo 100-8220
JAPAN

Phoenix Technologies Ltd. Scott_Taylor@phoenix.com 6,226,383 (US) and 24-May-1999


411 E. Plumeria Drive Associate General Counsel unspecified patent (revised letter
San Jose, CA 95134 tel: 408-570-1000 applications related to requested)
(formerly Integrity Sciences, password-based key
Inc.) agreement

International Business Director of Licensing 5,177,791 (US) 2-Feb-1998


Machines Corporation IBM 5,432,849 (US)
522 South Road 500 Columbus Avenue 5,103,478 (US)
Poughkeepsie, NY 12602 Thornwood, NY 10594 5,007,089 (US)
USA tel: 914-742-6258 4,993,069 (US)
fax: 914-742-6729 4,924,515 (US)
email: jerry@us.ibm.com 4,924,514 (US)
4,918,728 (US)
4,941,176 (US)
4,850,017 (US)
08/603,771 (US)
08/736,774 (US)

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

United States Department of William Burr 5,231,668 (US) 24-Jun-1998


Commerce Manager Security Technology
National Institute of Standards Group
and Technology tel: 301-975-2914
Gaithersburg, MD
USA

Nippon Telegraph and Koh Inoue unspecified patents 27-Feb-2001


Telephone Corporation Associate Manager relating to EPOC and
9-11, Midori-Cho 3-Chome, Intellectual Property Center ESIGN
Musashino-Shi, Tokyo, tel: +81 422 59 7192
180-8585 Japan fax: +81 422 59 5563
email: inoue.koh@lab.ntt.co.jp

Public Key Partners Robert B. Fougner 4,200,770 (US) 20-Apr-1990


130 B Kifer Court Director of Licensing 4,218,582 (US)
Sunnyvale, CA 94086 tel: 408-735-6779 4,405,829 (US)
USA fax: 408-735-6779 4,424,414 (US)
corresponding foreign
patents

r3 security engineering ag Dr. Rainer A. Rueppel not identified - US and 25-Feb-1998,


Züricherstrasse 151 President and CEO European patent 19-Mar-1997
CH-8607 Aathal/Zürich tel: +41(0)1 934 56 56
SWITZERLAND fax: +41(0)1934 56 57

RSA Security Inc. Michelle Rosenberg 4,405,829 (US) 9-Nov-1995


174 Middlesex Turnpike Assistant General Counsel 4,995,082 (US) 6-Aug-1998
Bedford, MA 01730 USA tel: 781-515-5441 5,854,759 (US) 22-Apr-1999
USA fax: 781-515-5450 8-Mar-2000

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

Leon Stambler Douglas E. Whitney 5,267,314 (US) 27-Oct-2000


Morris, Nichols, Arsht & 5,524,073 (US)
Tunnell 5,555,303 (US)
1201 North Market Street 5,646,998 (US)
P.O.Box 1347 5,793,302 (US)
Wilmington, Delaware 19899- 5,936,541 (US)
1347 5,794,148 (US)
tel: 302-658-9200

University of California Mathew L. Grell unspecified patent 15-Jun-1999


Sr. Licensing Officer applications related to
mathew.grell@ucop.edu “PSS and PSS-R
signature-formatting
methods”

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

1Annex G (Informative) Bibliography.

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

1[B101] [Gor98] D. M. Gordon, “A survey of fast exponentiation methods,” Journal of Algorithms 27


2(1998), 129-146.
3[B102] [Gos90] K. C. Goss, “Cryptographic method and apparatus for public key exchange with
4authentications,” U. S. Patent 4,956,863, 11 Sep 1990.
5[B103] [GQW91] C. Guillou, J.-J. Quisquater, M. Walker, P. Landrock and C. Shaer, “Precautions taken
6against various potential attacks in ISO/IEC DIS 9796,” I.B. Damgard, editor, Advances in Cryptology —
7EUROCRYPT ‘90, Lecture Notes in Computer Science 473 (1991), Springer-Verlag, 465-473.
8[B104] [GTV88] Girault, M., Toffin, P., and Vallée, B. “Computation of Approximate L-th Roots Modulo
9n and Application to Cryptography,” S. Goldwasser, Ed., Advances in Cryptology, CRYPTO ’88, Lecture
10Notes in Computer Science 403 (1990), Springer, pp. 100-117.
11[B105] [Gun90] C. G. Gunther, “An identity-based key-exchange protocol,” J.-J. Quisquater and J.
12Vandewalle, editors, Advances in Cryptology — EUROCRYPT ’89, Lecture Notes in Computer Science 434
13(1990), Springer-Verlag, 29-37.
14[B106] [Has88] J. Hastad, “Solving simultaneous modular equations of low degree,” SIAM Journal on
15Computing 17 (1988), 336-341.
16[B107] [HM95] Katie Hafner and John Markoff, Cyberpunk: Outlaws and hackers on the computer
17frontier, updated edition, Touchstone Books, 1995.
18[B108] [Hou02] Housley, R. “RFC 3370: Cryptographic Message Syntax (CMS) Algorithms.” Internet
19Activities Board, August 2002. Available at http://www.rfc-editor.org/.
20[B109] [HPFS98] Housley, R., Polk, W., Ford, W., and Solo, D. “RFC 3280: Internet X.509 Public Key
21Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002. Available at
22http://www.rfc-editor.org/.
23[B110] [HS01] Howgrave-Graham, N. A., and Smart, N. “Lattice Attacks on Digital Signature Schemes,”
24Designs, Codes and Cryptography 23:3 (August 2001), pp. 283-290.
25[B111] [ISO02a] ISO/IEC 8824-1:2002, Information Technology – Abstract Syntax Notation One
26(ASN.1): Specification of Basic Notation. Equivalent to ITU-T Rec. X.680 (2002).
27[B112] [ISO02b] ISO/IEC 8824-2:2002, Information Technology – Abstract Syntax Notation One
28(ASN.1): Information Object Specification. Equivalent to ITU-T Rec. X.681 (2002).
29[B113] [ISO02c] ISO/IEC 8824-3:2002, Information Technology – Abstract Syntax Notation One
30(ASN.1): Constraint Specification. Equivalent to ITU-T Rec. X.682 (2002).
31[B114] [ISO02d] ISO/IEC 8824-4:2002, Information Technology – Abstract Syntax Notation One
32(ASN.1): Parameterization of ASN.1 Specifications. Equivalent to ITU-T Rec. X.683 (2002).
33[B115] [ISO02e] ISO/IEC 8825-1:2002, Information Technology – ASN.1 Encoding Rules: Specification
34of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules
35(CER). Equivalent to ITU-T Rec. X.690 (2002).
36[B116] [ISO-10118-3] ISO/IEC 10118-3:1998, Information Technology—Security techniques—Hash-
37functions—Part 3: Dedicated hash-functions.
38[B117] [ISO-15946-4] ISO/IEC FCD 15946-4, Information Technology—Security Techniques—
39Cryptographic techniques based on elliptic curves—Part 4: Digital signatures with message recovery,
40draft, May 20, 2002.
41[B118] [ISO91] ISO/IEC 9796:1991 Information Technology – Security techniques – Digital signature
42scheme giving message recovery.
43[B119] [ISO-9796-2] ISO/IEC 9796-2:1997, Information technology—Security techniques—Digital
44signature schemes giving message recovery—Part 2: Mechanisms using a hash-function.

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

1[B120] [ISO-9796-2-revision] ISO/IEC FDIS 9796-2, Information technology—Security techniques—


2Digital signature scheme giving message recovery—Part 2: Integer factorization based mechanisms, draft,
3December 16, 2001. (Revision of ISO/IEC 9796-2:1997.)
4[B121] [ISO98g] ISO/IEC 9796-4 Information Technology – Security techniques – Digital signature
5schemes giving message recovery – Part 4: Methods based on the Discrete Logarithm, draft, 1998.
6[B122] [ISO98h] ISO/IEC DIS 14888-3 Information technology – Security techniques – Digital signature
7with appendix – Part 3: Certificate-based mechanisms, Draft International Standard, 1998.
8[B123] [ITT86] T. Itoh, O. Teechai and S. Tsujii, “A Fast Algorithm for Computing Multiplicative
9Inverses in GF (2t) using normal bases,” J. Society for Electronic Communications (Japan) 44 (1986), 31-
1036.
11[B124] [ITU97] ITU-T, Recommendation X.509 (03/00), Information technology – Open Systems
12Interconnection – The Directory: Public-key and Attribute Certificate Frameworks, International
13Telecommunications Union, March 2000.
14[B125] [JM96] D. B. Johnson and S. M. Matyas, “Asymmetric encryption: Evolution and enhancements,”
15CryptoBytes vol. 2 no. 1 (Spring 1996), RSA Laboratories, ftp://ftp.rsa.com/pub/cryptobytes/crypto2n1.pdf
16[B126] [Joh] D. B. Johnson, unpublished communication to ANSI X9F1 and IEEE P1363 working
17groups.
18[B127] [JQ01] Joye, M. and Quisquater, J-J. “On Rabin-Type Signatures,” B. Honary, Ed., Cryptography
19and Coding, Lecture Notes in Computer Science 2260 (2001), Springer, pp. 99-113.
20[B128] [JQ96] M. Joye and J.J. Quisquater, “Efficient computation of full Lucas sequences,” Electronics
21Letters vol. 32 (1996), pp. 537-538. Corrected version available at
22http://www.dice.ucl.ac.be/crypto/publications.html
23[B129] [JQ99] M. Joye and J.-J. Quisquater, “On Rabin-type signatures (working draft).” Presented at the
24rump session of CRYPTO ‘99. Available from http://grouper.ieee.org/groups/1363/contrib.html.
25[B130] [Kal02] Kaliski, B. “On Hash Function Firewalls in Signature Schemes,” B. Preneel, Ed.,
26Cryptographers’ Track RSA Conference 2002, Lecture Notes in Computer Science 2271 (2002), Springer,
27pp. 1-16.
28[B131] [Kal98a] B. S. Kaliski, Jr., “Compatible cofactor multiplication for Diffie-Hellman primitives,”
29Electronics Letters vol. 34 no. 25 (December 10, 1998), pp. 2396-2397.
30[B132] [Kal98b] B. S. Kaliski, Jr., “MQV vulnerability,” Internet communication to ANSI X9F1 and
31IEEE P1363 mailing lists, June 17, 1998.
32[B133] [KBC97] Krawczyk, H., Bellare, M., and Canetti, R. “RFC 2104: HMAC: Keyed-Hashing for
33Message Authentication,” Internet Activities Board, February 1997. Available at http://www.rfc-
34editor.org/.
35[B134] [Keh95] Brendan P. Kehoe, Zen and the Art of the Internet : A Beginner's Guide, fourth edition,
36Prentice Hall Computer Books, 1995.
37[B135] [Ker83] A. Kerckhoffs, “La cryptographie militaire,” Journal des Sciences Militaires, 9th Series
38(February 1883), 161-191.
39[B136] [KL99] Kaliski, B. S., Jr., and Liskov, M. “Efficient Finite Field Basis Conversion Involving Dual
40Bases,” C. K. Koç and C. Paar, Eds., Cryptographic Hardware and Embedded Systems, CHES ’99, Lecture
41Notes in Computer Science 1717 (1999), Springer, pp. 135-143.
42[B137] [Knu81] D. E. Knuth, The Art of Computer Programming. Vol. 2: Seminumerical Algorithms, 2nd
43edition, Addison-Wesley, 1981, p. 379.
44[B138] [Kob87] N. Koblitz, “Elliptic curve cryptosystems,” Mathematics of Computation 48 (1987), 203-
45209.

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.

Вам также может понравиться