ISO/IEC 15946-3:2002

Information technology - Security techniques - Cryptographic techniques based on elliptic curves - Part 3: Key establishment

Technologies de l'information — Techniques de sécurité — Techniques cryptographiques basées sur les courbes elliptiques — Partie 3: Établissement de clé

General Information

• Status: Withdrawn
• Publication Date: 24-Nov-2002
• Withdrawal Date: 24-Nov-2002
• ICS: 35.030 - IT Security
• ICS: 35.040 - Information coding
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27/WG 2 - Cryptography and security mechanisms
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 02-Jul-2008
• Completion Date: 30-Oct-2025

Relations

• Consolidated By: ISO 10890:2010 - Paints and varnishes - Modelling of biocide release rate from antifouling paints by mass-balance calculation
• Effective Date: 06-Jun-2022
• Revised: ISO/IEC 11770-3:2008 - Information technology - Security techniques - Key management - Part 3: Mechanisms using asymmetric techniques
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 15946-3
First edition
2002-12-01
Information technology — Security
techniques — Cryptographic techniques
based on elliptic curves —
Part 3:
Key establishment
Technologies de l'information — Techniques de sécurité — Techniques
cryptographiques basées sur les courbes elliptiques —
Partie 3: Établissement de clé

Reference number
©
ISO/IEC 2002
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2002
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2002 – All rights reserved

Contents
1 Scope. 1
2 Normative references. 1
3 Terms and definitions. 2
4 Symbols and abbreviated terms . 4
5 Key derivation functions . 5
6 Cofactor multiplication . 5
7 Key commitment . 6
8 Key agreement mechanisms. 6
8.1 Common information. 6
8.2 Non-interactive key agreement of Diffie-Hellman type (KANIDH). 7
8.2.1       Setup . 7
8.2.2       Mechanism. 7
8.2.3       Properties . 7
8.3 Key agreement of ElGamal type (KAEG) . 7
8.3.1       Setup . 7
8.3.2 Mechanism . 8
8.3.3       Properties . 8
8.4 Key agreement of Diffie-Hellman type . 8
8.4.1 Setup. 8
8.4.2 Mechanism . 8
8.4.3 Properties. 9
8.5 Key agreement of Diffie-Hellman type with 2 key pairs (KADH2KP) . 9
8.5.1       Setup . 9
8.5.2       Mechanism. 9
8.5.3       Properties . 10
8.6 Key agreement of Diffie-Hellman type with 2 signatures and key confirmation (KADH2SKC). 10
8.6.1 Setup. 10
© ISO/IEC 2002 – All rights reserved iii

8.6.2 Mechanism.10
8.6.3 Properties.11
9 Key agreement mechanisms not included in ISO/IEC 11770-3. .12
9.1 Common information.12
9.2 The Full Unified Model.12
9.2.1 Setup.12
9.2.2 Mechanism.12
9.2.3 Properties.13
9.3 Key agreement of MQV type with 1 pass (KAMQV1P) .13
9.3.1       Setup .13
9.3.2 Mechanism.13
9.3.3       Properties .14
9.4 Key agreement of MQV type with 2 passes (KAMQV2P) .14
9.4.1       Setup .14
9.4.2       Mechanism.14
9.4.3       Properties .15
10 Key transport mechanisms.15
10.1 Common information.15
10.2 Key transport of ElGamal type (KTEG).15
10.2.1 Setup.15
10.2.2 Mechanism.16
10.2.3 Properties.16
10.3 Key transport of ElGamal type with originator signature (KTEGOS) .16
10.3.1 Setup.16
10.3.2 Mechanism.17
10.3.3 Properties.17
11 Key Confirmation .18
Annex A (informative) Examples of key derivation functions.20
A.1 The IEEE P1363 key derivation function.20
A.1.1 Preconditions.20
A.1.2 Input.20
© ISO/IEC 2002 – All rights reserved
iv
A.1.3 Actions. . 20
A.1.4 Output. 20
A.2 The ANSI X9.42 key derivation function. 20
A.2.1 Prerequisites. 20
A.2.2 Input. 21
A.2.3 Actions. 21
A.2.4 Output. 22
A.2.5 ASN.1 syntax. 22
A.3 The ANSI X9.63 key derivation function. 22
A.3.1 Prerequisites. 23
A.3.2 Input. 23
A.3.3 Actions. 23
A.3.4 Output. 23
Annex B (informative) A comparison of the claimed properties of the mechanisms in this standard. 24
B.1 Security Properties. 24
B.2 Performance Considerations . 27
Bibliography . 29
v
© ISO/IEC 2002 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 15946-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 27, IT Security techniques.
ISO/IEC 15946 consists of the following parts, under the general title Information technology — Security techniques
— Cryptographic techniques based on elliptic curves:
 Part 1: General
 Part 2: Digital signatures
 Part 3: Key establishment
 Part 4: Digital signatures giving message recovery
Annexes A and B of this part of ISO/IEC 15946 are for information only.
© ISO/IEC 2002 – All rights reserved
vi
Introduction
Some of the most interesting and potentially useful public key cryptosystems that are currently available are
cryptosystems based on elliptic curves defined over finite fields. The concept of an elliptic curve based public key
cryptosystem is rather simple:
 Every elliptic curve is endowed with a binary operation "+" under which it forms a finite abelian group.
 The group law on elliptic curves extends in a natural way to a "discrete exponentiation" on the point group of
the elliptic curve.
 Based on the discrete exponentiation on an elliptic curve one can easily derive elliptic curve analogues of the
well known public key schemes of Diffie-Hellman and ElGamal type.
The security of such a public key system depends on the difficulty of determining discrete logarithms in the group of
points of an elliptic curve. This problem is - with current knowledge - much harder than the factorization of integers
or the computation of discrete logarithms in a finite field. Indeed, since Miller and Koblitz in 1985
independently suggested the use of elliptic curves for public key cryptographic systems, no substantial progress in
tackling the elliptic curve discrete logarithm problem has been reported. In general, only algorithms that take
exponential time are known to determine elliptic curve discrete logarithms. Thus, it is possible for elliptic curve
based public key systems to use much shorter parameters than the RSA system or the classical discrete logarithm
based systems that make use of the multiplicative group of some finite field. This yields significantly shorter digital
signatures and system parameters and allows for computations using smaller integers.
This part of ISO/IEC 15946 describes schemes that can be used for key agreement and schemes that can be used
for key transport. Where possible, the schemes are analogous to methods included in ISO/IEC 11770-3. Schemes
that are not included in ISO/IEC 11770-3 are noted as such.
The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) draw
attention to the fact that it is claimed that compliance with this International Standard may involve the use of
patents.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights.
The holders of these patent rights have assured ISO and IEC that they are willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the
statements of the holders of these patent rights are registered with ISO and IEC. Information may be obtained from:
ISO/IEC JTC 1/SC 27 Standing Document 8 (SD 8)
SD 8 is publicly available at:
http://www.din.de/ni/sc27
Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 15946 may be the subject of
patent rights other than those identified above. ISO and IEC shall not be held responsible for identifying any or all
such patent rights.
© ISO/IEC 2002 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 15946-3:2002(E)
Information technology — Security techniques — Cryptographic
techniques based on elliptic curves — Part 3: Key establishment
1 Scope
International Standard ISO/IEC 15946 specifies public key cryptographic techniques based on elliptic curves. The
standard is split into four parts and includes the establishment of keys for secret key systems and digital signature
mechanisms.
This part of ISO/IEC 15946 specifies techniques for key establishment, which includes key agreement and key
transport, that use elliptic curves.
The scope of this standard is restricted to cryptographic techniques based on elliptic curves defined over finite
fields of prime power order (including the special cases of prime order or characteristic two). The representation of
elements of the underlying finite field is outside the scope of this standard. This standard does not fully specify the
implementation of the techniques it defines. There may be different products that comply with this International
Standard and yet are not compatible.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC 15946. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this part of ISO/IEC 15946 are encouraged to
investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO/IEC 9796 (parts 2 and 3), Information technology — Security techniques — Digital signature schemes giving
message recovery
ISO/IEC 9797 (all parts), Information technology — Security techniques — Message Authentication Codes (MACs)
ISO/IEC 10118 (all parts), Information technology — Security techniques — Hash-functions
ISO/IEC 11770-3:1999, Information technology — Security techniques — Key management — Part 3:
Mechanisms using asymmetric techniques
ISO/IEC 14888 (all parts), Information technology — Security techniques — Digital signatures with appendix
ISO/IEC 15946-1:2001, Information technology — Security techniques — Cryptographic techniques based on
elliptic curves — Part 1: General
ISO/IEC 15946-2:2001, Information technology — Security techniques — Cryptographic techniques based on elliptic
curves — Part 2: Digital signatures
© ISO/IEC 2002 – All rights reserved 1

3 Terms and definitions
For the purposes of this part of ISO/IEC 15946, the definitions of Part 1 apply. In addition, the following definitions
from ISO/IEC 11770-3 apply.
3.1 Asymmetric cryptographic technique: a cryptographic technique that uses two related transformations, a
public transformation (defined by the public key) and a private transformation (defined by the private key). The two
transformations have the property that, given the public transformation, it is computationally infeasible to derive the
private transformation.
3.2 Asymmetric encipherment system: a system based on asymmetric cryptographic techniques whose public
transformation is used for encipherment and whose private transformation is used for decipherment.
3.3 Asymmetric key pair: a pair of related keys where the private key defines the private transformation and the
public key defines the public transformation.
3.4 Signature system: a system based on asymmetric cryptographic techniques whose private transformation is
used for signing and whose public transformation is used for verification.
3.5 Cryptographic check function: a cryptographic transformation which takes as input a secret key and an
arbitrary string, and which gives a cryptographic check value as output. The computation of a correct check value
without knowledge of the secret key shall be infeasible [ISO/IEC 9798-1:1997].
3.6 Cryptographic check value: information which is derived by performing a cryptographic transformation on the
data unit [ISO/IEC 9798-4:1995].
NOTE The cryptographic check value is the output of the cryptographic check function.
3.7 Decipherment: the reversal of a corresponding encipherment [ISO/IEC 11770-1:1996].
3.8 Digital signature: data appended to, or a cryptographic transformation of, a data unit that allows the recipient
of the data unit to prove the origin and integrity of the data unit and protect against forgery, e.g. by the recipient
[ISO/IEC 11770-1:1996].
3.9 Distinguishing identifier: information which unambiguously distinguishes an entity [ISO/IEC 11770-1:1996].
3.10 Encipherment: the (reversible) transformation of data by a cryptographic algorithm to produce ciphertext, i.e.
to hide the information content of the data [ISO/IEC 9798-1:1997].
3.11 Entity authentication: the corroboration that an entity is the one claimed [ISO/IEC 9798-1:1997].
3.12 Entity authentication of A to B: the assurance of the identity of entity A for entity B.
3.13 Explicit key authentication from A to B: the assurance for entity B that A is the only other entity that is in
possession of the correct key.
NOTE Implicit key authentication from A to B and key confirmation from A to B together imply explicit key
authentication from A to B.
3.14 Implicit key authentication from A to B: the assurance for entity B that A is the only other entity that can
possibly be in possession of the correct key.
3.15 Key: a sequence of symbols that controls the operation of a cryptographic transformation (e.g. encipherment,
decipherment, cryptographic check function computation, signature generation, signature verification, or key
agreement) [ISO/IEC 11770-1:1996].
2 © ISO/IEC 2002 – All rights reserved

3.16 Key agreement: the process of establishing a shared secret between entities in such a way that neither of
them can predetermine the value of that key.
3.17 Key confirmation from A to B: the assurance for entity B that entity A is in possession of the correct key.
3.18 Key control: the ability to choose the key or the parameters used in the key computation.
3.19 Key establishment: the process of making available a shared secret to one or more entities. Key
establishment includes key agreement and key transport.
3.20 Key token: key management message sent from one entity to another entity during the execution of a key
management mechanism.
3.21 Key transport: the process of transferring a key from one entity to another entity, suitably protected.
3.22 Mutual entity authentication: entity authentication which provides both entities with assurance of each
other's identity.
3.23 One-way function: a function with the property that it is easy to compute the output for a given input but it is
computationally infeasible to find for a given output an input which maps to this output.
3.24 Private key: that key of an entity's asymmetric key pair which should only be used by that entity.
NOTE In the case of an asymmetric signature system the private key defines the signature transformation. In the
case of an asymmetric encipherment system the private key defines the decipherment transformation.
3.25 Public key: that key of an entity's asymmetric key pair which can be made public
NOTE In the case of an asymmetric signature system the public key defines the verification transformation. In the
case of an asymmetric encipherment system the public key defines the encipherment transformation. A key that is
'publicly known' is not necessarily globally available. The key may only be available to all members of a pre-specified
group.
3.26 Secret key: a key used with symmetric cryptographic techniques by a set of specified entities.
3.27 Sequence number: a time variant parameter whose value is taken from a specified sequence which is non-
repeating within a certain time period [ISO/IEC 11770-1:1996].
3.28 Time stamp: a data item which denotes a point in time with respect to a common reference [ISO/IEC 11770-
1:1996].
The following definition from ISO/IEC 10118-1 applies.
3.29 hash-function: a function which maps strings of bits to fixed-length strings of bits, satisfying two properties.
- it is computationally infeasible to find for a given output, an input which maps to this output;
- it is computationally infeasible to find for a given input, a second input which maps to the same output.
NOTES
1 – The literature on this subject contains a variety of terms which have the same or similar meaning as hash-function.
Compressed encoding and condensing function are some examples.
2 – Computational feasibility depends on the user’s specific security requirements and environment.
Additional definitions which are required are as follows.
© ISO/IEC 2002 – All rights reserved 3

3.30 Forward secrecy with respect to A: the property that knowledge of A’s long-term private key subsequent to
a key agreement operation does not enable an opponent to recompute previously derived keys.
3.31 Forward secrecy with respect to both A and B individually: the property that knowledge of A’s long-term
private key or knowledge of B’s long-term private key subsequent to a key agreement operation does not enable an
opponent to recompute previously derived keys.
NOTE This differs from mutual forward secrecy in which knowledge of both A’s and B’s long-term private keys does
not enable recomputation of previously derived keys.
3.32 Key derivation function: a key derivation function outputs one or more shared secrets, used as keys, given
shared secrets and other mutually known parameters as input.
3.33 Mutual forward secrecy: the property that knowledge of both A’s and B’s long-term private keys subsequent
to a key agreement operation does not enable an opponent to recompute previously derived keys.
3.34 Prefix free representation: a representation of a data element for which concatenation with any other data
does not produce a valid representation.
4 Symbols and abbreviated terms
Throughout this part of ISO/IEC 15946, the following symbols and notations are used in addition to those given in
ISO/IEC 15946-1.
E Symmetric encryption function using secret key K.
K
f A cryptographic check function.
f (Z) A cryptographic check value which is the result of applying the cryptographic check
K
function f using as input a secret key K and an arbitrary data string Z.
h The cofactor used in performing cofactor multiplication.
kdf A key derivation function.
l A supplementary value used in performing cofactor multiplication.
MAC A Message Authentication Code algorithm.
MAC(K,Z) A Message Authentication Code value which is the result of applying the MAC algorithm
using as input the secret key K and an arbitrary data string Z.
parameters Parameters used in the key derivation function.
S Entity X’s private signature transformation.
X
NOTE No assumption is made on the nature of the signature transformation. In the case of a signature system with
message recovery, S (m) denotes the signature itself. In the case of a signature system with appendix, S (m) denotes
A A
the message m together with the signature.
[|| Text1], [|| Text2] Optional text, data or other information that may be included in a data block, if desired.
V Entity X’s public signature verification transformation.
X
* ρ 2 ρ 2
�� ��
π (Q) (π (Q) mod 2 )+ 2 where ρ = log n .
� �
4 © ISO/IEC 2002 – All rights reserved

5 Key derivation functions
The use of a shared secret as derived in Clauses 8 and 9 as a key for a symmetric cryptosystem without further
processing is not recommended. It most often will be the case that the form of a shared secret will not conform to
the form needed for a shared symmetric key, so some processing will be needed. The shared secret (often) has
arithmetic properties and relationships that might result in a shared symmetric key not being chosen from the full
key space. It is advisable to pass the shared secret through a key derivation function, which includes the use of a
hash function. The use of an inadequate key derivation function compromises the security of the key agreement
scheme in which it is used.
A key derivation function should produce keys that are computationally indistinguishable from randomly generated
keys. The key derivation function should take as input the shared secret and a set of key derivation parameters
and produce an output of the desired length.
Key derivation functions are also used in Clause 10 to encrypt the secret key before transport.
In order for the two parties in a key establishment mechanism to agree on a common secret key, the key derivation
function must be agreed upon. The method of coming to such an agreement is outside the scope of this standard.
See Annex A for three examples of key derivation functions.
6 Cofactor multiplication
The key agreement mechanisms in Clauses 8 and 9 and the key transport mechanisms in Clause 10 require that
the user’s private key or key token be combined with another entity’s public key or key token. If the other entity’s
public key or key token is not valid (i.e. it is not a point on the elliptic curve, or is not in the subgroup of order n)
then performing this operation may result in some bits of the private key being leaked to an attacker. An example
of this attack is the ‘small subgroup attack’.
In order to prevent the ‘small subgroup attack’ and similar attacks, one option is to validate public keys and key
tokens received from the other party using public key validation. See Part 1 of this standard for a description of
public key validation.
As an alternative to verifying the order of the public key or key token, a technique called cofactor multiplication can
be used. The values h and l, defined below, are used for cofactor multiplication in Clauses 8, 9 and 10.
If cofactor multiplication is desired, there are two options:
• If cofactor multiplication is used, and incompatibility with those not using cofactor multiplication is desired then
let hE= # n and l= 1. If this option is chosen, both parties involved must agree to use this option,
otherwise the mechanism will not work.
• If cofactor multiplication is used, and compatibility with those not using cofactor multiplication is desired then let
−1
hE= # n and l= h mod n . When this option is chosen, the mechanisms described in Clauses 8 and 10
are consistent with ISO/IEC 11770-3.
-1
NOTE The value h mod n will always exist since n is required to be greater than 4 q (see Part 1) and therefore
gcd(n,h)=1.
If cofactor multiplication is not desired, there is one option:
• If cofactor multiplication is not used, then let h= 1 and l= 1. When this option is chosen, the mechanisms
described in Clauses 8 and 10 are consistent with ISO/IEC 11770-3.
© ISO/IEC 2002 – All rights reserved 5

Regardless of whether or not cofactor multiplication is used and the type of compatibility that is chosen, if the
shared key (or a component of the shared key) evaluates to the point at infinity (0 ) then the user shall assume that
E
the key agreement has failed.
It should be noted that it is most appropriate to perform these operations (public key validation or cofactor
multiplication) if the other entity’s public key or key token is not authenticated or the user’s public key is long term.
Performing public key validation for long-term keys and cofactor multiplication for ephemeral (short term) keys may
also have performance advantages.
It should also be noted that if the other entity’s public key is authenticated and the cofactor is small, then the
amount of information that can be leaked is limited. Thus, it may not always be desired that these tests be
performed.
7 Key commitment
Clauses 8 and 9 describe key agreement mechanisms where the established key is the result of applying a one-
way function of the private key-agreement keys. However, one entity may know the other entity’s public key or key
token prior to choosing their private key. The entity can control the value of s bits in the established key, at the cost
s
of generating 2 candidate values for their private key-agreement key in the time interval between discovering the
other entity’s public key or key token and choosing their own private key [4].
A way to address this concern (if it is a concern) at the cost of one additional message/pass in the protocol is
through the use of key commitment. Commitment can be done by having the first party hash the public key or key
token and send the hash-code to the second party, the second party replies with his public key or key token and
the first party replies with his public key or key token, which the second party can hash and verify that the result is
equal to the hash-code sent earlier.
8 Key agreement mechanisms
Key agreement is the process of establishing a shared secret between two entities A and B in such a way that
neither of them can predetermine the value of the shared secret.
Where authentic copies of the other party’s public keys are required, they can be obtained using the techniques
specified in ISO/IEC 11770-3, Clause 8.
NOTE All computations in this Clause must be performed in the order given by the formulae.
8.1 Common information
For all key agreement mechanisms, prior to the process of agreeing upon a shared secret, the following common
information must be established between the parties and optionally validated (see Part 1 of this standard for a
description of parameter validation):
— the elliptic curve parameters with which the key pairs shall be associated, which shall be the same for both
m m m m
parties’ key pairs. This includes p, p or 2 , a description of F(p), F(p ) or F(2 ) and an indication of the
basis used, E, n and G.
In each of the mechanisms defined below, the resulting agreed key should not be used as a cryptographic key
directly. Instead, it should be used as the input to a key derivation function, allowing both parties to derive the
same cryptographic keys from it. Hence, it is also necessary for the two parties to agree on the following
information:
— a key derivation function, kdf;
— any parameters to the key derivation function, and
— the type of cofactor multiplication that is to be performed (if any).
6 © ISO/IEC 2002 – All rights reserved

8.2 Non-interactive key agreement of Diffie-Hellman type (KANIDH)
This key agreement mechanism non-interactively establishes a shared secret between two entities A and B.
8.2.1 Setup
Prior to the process of agreeing upon a shared secret, in addition to the common information, the following must be
established:
 for each entity X, a private key-agreement key d and a public key-agreement key P , which is an elliptic curve
X X
point satisfying P =d G. See Part 1 of this standard for a description of how to generate this key pair.
X X
 for each entity, access to an authentic copy of the public key-agreement key of the other party.
Each entity should independently verify that the other entity’s public key is indeed a point on the elliptic curve. See
Part 1 of this standard for a description of how to do this.
8.2.2 Mechanism
8.2.2.1  Key construction (A): Entity A computes, using its own private key-agreement key d and B’s public key-
A
agreement key P , the shared key as
B
K = (d ⋅l)(hP ).
AB A B
8.2.2.2  Key construction (B): Entity B computes, using its own private key-agreement key d and A’s public key-
B
agreement key P , the shared key as
A
K =(d ⋅l)(hP ).
AB B A
8.2.3 Properties
This key agreement mechanism has the following properties:
a) Number of passes: 0.
b) The mechanism provides mutual implicit key authentication.
NOTE As a consequence of the first property, the established secret between the same two users always has the
same value. For this reason it is suggested that the input to the key derivation function in this case include time-varying
information.
8.3 Key agreement of ElGamal type (KAEG)
This key agreement mechanism establishes a shared secret between two entities A and B in one pass.
8.3.1 Setup
Prior to the process of agreeing upon a shared secret, in addition to the common information, the following must be
established:
 for entity B, a private key-agreement key d and a public key-agreement key P , which is an elliptic curve point
B B
satisfying P =d G. See Part 1 of this standard for a description of how to generate this key pair.
B B
 for entity A, access to an authentic copy of the public key-agreement key of entity B.
Entity A should verify that entity B’s public key is indeed a point on the elliptic curve. See Part 1 of this standard for
a description of how to do this.
© ISO/IEC 2002 – All rights reserved 7

8.3.2 Mechanism
8.3.2.1  Key token construction (A): Entity A randomly and secretly generates r in the range {1,.,n-1}, computes
rG, constructs the key token,
KT = rG
A1
and sends it to B.
8.3.2.2  Key construction (A): Entity A computes the shared key
K = (r⋅l)(hP ).
B
AB
8.3.2.3  Key construction (B): Entity B should verify that KT is indeed a point on the elliptic curve. See Part 1
A1
for a description of how to do this. Using its own private key, entity B computes the shared key from KT as
A1
follows:
K =(d ⋅l)(hKT ).
B
AB A1
8.3.3 Properties
This key agreement mechanism has the following properties:
a) Number of passes: 1.
b) The mechanism provides implicit key authentication from B to A since B is the only entity other than A that can
compute the shared secret.
c) The mechanism provides forward secrecy with respect to A.
8.4 Key agreement of Diffie-Hellman type
This key agreement mechanism establishes a shared secret between entities A and B in two passes.
8.4.1 Setup
This key agreement mechanism does not require any initial information other than the common information to be
set up.
8.4.2 Mechanism
8.4.2.1 Key Token Construction
(A): Entity A randomly and secretly generates r in the range {1,.,n-1}, computes r G, constructs the key token,
A
A
KT = r G
A1 A
and sends it to B.
8.4.2.2 Key Token Construction (B): Entity B randomly and secretly generates r in the range {1,.,n-1},
B
computes r G, constructs the key token,
B
KT = r G
B1 B
and sends it to A.
8.4.2.3 Key Construction (A): Entity A should verify that KT is indeed a point on the elliptic curve. See Part 1 for
B1
a description of how to do this. Entity A computes the shared key
K = (r ⋅l)(hKT ).
AB A B1
8 © ISO/IEC 2002 – All rights reserved

8.4.2.4 Key Construction (B): Entity B should verify that KT is indeed a point on the elliptic curve. See Part 1 for
A1
a description of how to do this. Entity B computes the shared key
K = (r ⋅l)(hKT ).
B A1
AB
8.4.3 Properties
This key agreement mechanism has the following properties:
a) Number of passes: 2.
b) The mechanism provides mutual forward secrecy.
8.5 Key agreement of Diffie-Hellman type with 2 key pairs (KADH2KP)
This key agreement mechanism establishes a shared secret between entities A and B in two passes.
8.5.1 Setup
Prior to the process of agreeing upon a shared secret, in addition to the common information, the following must be
established:
 for each entity X, a private key-agreement key d and a public key-agreement key P , which is an elliptic curve
X X
point satisfying P =d G. See Part 1 of this standard for a description of how to generate this key pair.
X X
 for each entity, access to an authentic copy of the public key-agreement key of the other party.
Each entity should independently verify that the other entity’s public key is indeed a point on the elliptic curve. See
Part 1 of this standard for a description of how to do this.
8.5.2 Mechanism
8.5.2.1  Key token construction (A): Entity A randomly and secretly generates r in the range {1,.,n-1},
A
computes r G, constructs the key token,
A
KT = r G
A1 A
and sends it to B.
8.5.2.2  Key token construction (B): Entity B randomly and secretly generates r in the range {1,.,n-1},
B
computes r G, constructs the key token,
B
KT = r G
B
B1
and sends it to A.
8.5.2.3  Key construction (A): Entity A should verify that KT is indeed a point on the elliptic curve. See Part 1
B1
for a description of how to do this. Entity A computes the shared key
K = (d ⋅l)(hKT ) || (r ⋅l)(hP ).
AB A B1 A B
8.5.2.4  Key construction (B): Entity B should verify that KT is indeed a point on the elliptic curve. See Part 1
A1
for a description of how to do this. Entity B computes the shared secret
K = (r ⋅l)(hP ) || (d ⋅l)(hKT ).
AB B A B A1
© ISO/IEC 2002 – All rights reserved 9

NOTE Concatenation of a representation of the points is not the only alternative for the construction of the key. Any
prefix free representation (such as ASN.1) will also work. As there are choices, the method to combine the two values
becomes part of what is needed to be agreed upon by all parties. See also Annex A for further discussion.
8.5.3 Properties
This key agree
...