ISO/IEC 18033-2:2006/Amd 1:2017

INTERNATIONAL ISO/IEC
STANDARD 18033-2
First edition
2006-05-01
AMENDMENT 1
2017-11
Information technology —
Security techniques — Encryption
algorithms —
Part 2:
Asymmetric ciphers
AMENDMENT 1: FACE
Technologies de l'information — Techniques de sécurité —
Algorithmes de chiffrement —
Partie 2: Chiffres asymétriques
AMENDEMENT 1: FACE
Reference number
ISO/IEC 18033-2:2006/Amd.1:2017(E)
©
ISO/IEC 2017
ISO/IEC 18033-2:2006/Amd.1:2017(E)

© ISO/IEC 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2017 – All rights reserved

ISO/IEC 18033-2:2006/Amd.1:2017(E)

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. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www.iso.org/iso/foreword.html.
This document was prepared by ISO/IEC JTC 1, Information technology, Subcommittee SC 27, IT Security
techniques.
A list of all parts in the ISO/IEC 18033 series can be found on the ISO website.
© ISO/IEC 2017 – All rights reserved iii

ISO/IEC 18033-2:2006/Amd.1:2017(E)
Information technology — Security techniques —
Encryption algorithms —
Part 2:
Asymmetric ciphers
AMENDMENT 1: FACE
Introduction
Replace the Introduction with the following:
Introduction
The International Organization for Standardization (ISO) and the International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this document
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 the ISO and IEC that they are willing to negotiate licenses
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
—  IBM Corporation. Address: North Castle Drive, Armonk, NY 10504 USA,
—  NTT Corporation. Address: 9-11 Midori-Cho 3-chome, Musashino-shi, Tokyo 180-8585, Japan, and
—  Hitachi, Ltd. Address: 6-1, Marunouchi 1-chome, Chiyoda-ku, Tokyo, 100-8220, Japan.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights other than those identified above. ISO and/or IEC shall not be held responsible for
identifying any or all such patent rights.
ISO (www.iso.org/patents) and IEC (http://patents.iec.ch) maintain on-line databases of patents
relevant to their standards. Users are encouraged to consult the databases for the most up-to-date
information concerning patents.
Scope, NOTE
Replace:
—  ECIES-HC; PSEC-HC; ACE-HC: generic hybrid ciphers based on ElGamal encryption;
with the following:
— ECIES-HC; PSEC-HC; ACE-HC; FACE-HC: generic hybrid ciphers based on ElGamal encryption;
8.1.2
Replace:
—  ECIES-KEM (described in Clause 10.2),
© ISO/IEC 2017 – All rights reserved 1

ISO/IEC 18033-2:2006/Amd.1:2017(E)

—  PSEC-KEM (described in Clause 10.3),
—  ACE-KEM (described in Clause 10.4), and
—  RSA-KEM (described in Clause 11.5).
with the following:
—  ECIES-KEM (described in 10.2),
—  PSEC-KEM (described in 10.3),
—  ACE-KEM (described in 10.4),
—  FACE-KEM (described in 10.5), and
—  RSA-KEM (described in 11.5).
8.1.2
Replace NOTE 1 with the following:
NOTE 1 As a matter of convention, the corresponding generic hybrid ciphers built from these key
encapsulation mechanisms via the generic hybrid construction in 8.3 should be called (respectively)
ECIES-HC, PSEC-HC, ACE-HC, RSA-HC, and FACE-HC.
Clause 10
Add the following after “ACE-KEM is described in Clause 10.4”:
—  FACE-KEM is described in 10.5.
Clause 10
Add the following after 10.4.4:
10.5  FACE-KEM
The key encapsulation mechanism FACE-KEM is described in 10.5.
NOTE FACE-KEM is based on a series of research papers (see References [43] to [46]).
10.5.1  System parameters
FACE-KEM is a family of key encapsulation mechanisms, parameterized by the following system
parameters:
—  Γ: a concrete group
′′
Γ= HG, , g , μν, , ED, , ED, ;
()
— KDF: a key derivation function, as described in 6.2;
— Hash: a cryptographic hash function, as described in 6.1;
— CofactorMode: one of two values: 0 or 1.
— KeyLen: a positive integer.
2 © ISO/IEC 2017 – All rights reserved

ISO/IEC 18033-2:2006/Amd.1:2017(E)

— TagLen: a positive integer.
Any combination of allowable system parameters (in 6.1.1, 6.2.1, 10.1.1) is allowed, except for the
following restrictions:
— Hash.len shall be less than log μ.
— If ν = 1 , then CofactorMode shall be 0.
— If ν > 1 , then CofactorMode may be 1 provided gcd,μν =1 .
()
NOTE The value of CofactorMode is used only by the decryption algorithm.
10.5.2  Key generation
The key generation algorithm FACE-KEM.KeyGen takes no input, and runs as follows.
a) Generate numbers aa, uniformly at random from the range 0.μ .
)
12 
b) Compute the group elements
gg=⋅aa, gg=⋅ .
11 22
c) Generate numbers xx,, yy, uniformly at random from the range 0.μ .
)
12 12 
d) Compute the group elements
cg=⋅xx+⋅gd, =⋅yygg+⋅ .
11 22 11 22
e) Output the public key gg,,cd, .
f) Output the private key xx,, yy,.∈ 0.μ .
 )
12 12

10.5.3  Encryption
The encryption algorithm FACE-KEM.Encrypt takes as input a public key, consisting of
gg,,cd,,∈
together with an encryption option fmt that specifies the format to be used for encoding group
elements. It runs as follows.
a) Generate a number r uniformly at random from the range 0.μ .
 )

b) Compute group elements
uu=⋅rrgg, =⋅ .
11 22
c) Compute the octet strings
EU =uu,,fmtEUf= , mt .
() ()
11 22
d) Compute the integer
α =OS2IP Hash.eval EU EU .
()
()
e) Compute the integer
rr′=αμmod .
© ISO/IEC 2017 – All rights reserved 3

ISO/IEC 18033-2:2006/Amd.1:2017(E)

f) Compute the group element
′
vc=⋅rr+⋅d .
g) Set EV = v , fmt .
()
h) Set LenK=+eyLenTagLen .
i) Set WK= DF EV ,Len .
()
j) Parse W as WW=〈 ,,…〉W of Len octets.
1 Len
k) Set KW=〈 ,,…〉W of KeyLen octets.
1 KeyLen
l) Set TW=〈 ,,…〉W of TagLen octets.
KeyLen+1 Len
m) Set CE= UEUT .
01 2
n) Output the ciphertext C and the secret key K .
10.5.4  Decryption
The decryption algorithm FACE-KEM.Decrypt takes as input a private key, consisting of
xx,, yy,.∈ 0.,μ
 )
12 12

and ciphertext C . It runs as follows.
a) Parse C as CE= UEUT , where EU ,EU are octet strings such that for some (uniquely
0 01 2 12
determined) group elements uu, ∈ , uu=EU , = EU . This step fails if C cannot
() ()
12 11 22 0
be so parsed. Check that EU ,EU is a consistent set of valid encodings; if not, then fail.
{}
b) If CofactorMode = 0 and ν > 1 : test if u ∈ and u ∈ ; if either u ∉ or u ∉ , then fail.
1 2 1 2
c) If CofactorMode = 0 , set
ˆ ˆ
uu==, uu ;
11 22
ˆˆ ˆˆ
xx==,,xx yy==, yy .
11 22 11 22
d) If CofactorMode = 1 , set:
ˆ ˆ
uu=⋅νν, uu=⋅ ;
11 22
−−1 1 −−1 1
ˆˆ ˆˆ
xx==νμxxmodm,,νμod yy==νμmodm, yyνμod .
1 12 21 12 2
e) Compute the integer:
α =OS2IP Hash.eval EU EU .
()
()
f) Compute the integers:
ˆˆ ˆˆ
tx=+ αμytmodm, =+xyαμod .
11 12 22
4 © ISO/IEC 2017 – All rights reserved

ISO/IEC 18033-2:2006/Amd.1:2017(E)

g) Compute the group element:
ˆˆ
v =⋅ttuu+⋅ .
11 22
h) Set EV = v , fmt .
()
i) Set LenK=+eyLenTagLen .
j) Set WK= DF EV ,Len .
()
k) Parse W as LW=〈 ,,…〉W of Len octets.
1 Len
l) Set KW=〈 ,,…〉W of KeyLen octets.
1 KeyLen
m) Set TW=〈 ,,…〉W of TagLen octets.
decKeyLenL+1 en
n) Test if TT= ; if not then fail.
dec
o) Output the secret key K .
Annex A
Replace the title:
ASN.1 syntax for object identifiers
with the following:
Object identifiers
Annex A
Replace the first paragraph:
This annex gives ASN.1 syntax for object identifiers, public keys, and parameter structures to be
associated with the algorithms specified in this part of ISO/IEC 18033.
with the following:
Annex A gives object identifiers, public keys, and parameter structures to be associated with the
algorithms specified in this document.
Annex A
Replace:
-- Key encapsulation mechanisms --
id-kem-ecies OID::= { id-kem ecies(1) }
id-kem-psec OID::= { id-kem psec(2) }
id-kem-ace OID::= { id-kem ace(3) }
id-kem-rsa OID::= { id-kem rsa(4) }
with the following:
-- Key encapsulation mechanisms --
id-kem-ecies OID::= { id-kem ecies(1) }
© ISO/IEC 2017 – All rights reserved 5

ISO/IEC 18033-2:2006/Amd.1:2017(E)

id-kem-psec OID::= { id-kem psec(2) }
id-kem-ace OID::= { id-kem ace(3) }
id-kem-rsa OID::= { id-kem rsa(4) }
id-kem-face OID::= { id-kem face(5) }
Annex A
Replace:
-- KEM information objects
KeyEncapsulationMechanism::= AlgorithmIdentifier {{ KEMAlgorithms }}
KEMAlgorithms ALGORITHM::= {
{ OID id-kem-ecies PARMS EciesKemParameters } |
{ OID id-kem-psec PARMS PsecKemParameters } |
{ OID id-kem-ace  PARMS AceKemParameters }  |
{ OID id-kem-rsa  PARMS RsaKemParameters },
... -- Expect additional algorithms --
}
with the following:
-- KEM information objects
KeyEncapsulationMechanism::= AlgorithmIdentifier {{ KEMAlgorithms }}
KEMAlgorithms ALGORITHM::= {
{ OID id-kem-ecies PARMS EciesKemParameters } |
{ OID id-kem-psec PARMS PsecKemParameters } |
{ OID id-kem-ace  PARMS AceKemParameters }  |
{ OID id-kem-rsa  PARMS RsaKemParameters }  |
{ OID id-kem-face PARMS FaceKemParameters },
... -- Expect additional algorithms --
}
Annex A
Add the following before ~”-- DEM specifications”:
-- FACE-KEM
-- all components of public key are elements of the group given in
-- FaceKemParameters
FaceKemPublicKey::= SEQUENCE {
g1 FieldElement,
g2 FieldElement,
c FieldElement,
d FieldElement
}
FaceKemParameters::= SEQUENCE {
group Group OPTIONAL,
keyDerivationFunction KeyDerivationFunction,
hashFunction HashFunction,
keyLength KeyLength,
tagLength TagLength
}
--###################################################################
6 © ISO/IEC 2017 – All rights reserved

ISO/IEC 18033-2:2006/Amd.1:2017(E)

Annex B
Add the following after B.15:
B.16  Security of FACE-KEM
The key encapsulation mechanism FACE-KEM, defined in 10.5, has the following security properties.
Recall that FACE-KEM is parameterized by a group Γ (see 10.1), a hash function Hash (see 6.1), and
a key derivation KDF (see 6.2).
FACE-KEM can be proven secure against adaptive chosen ciphertext attack, assuming that the DDH
problem (defined in B.8.2) is hard for group Γ. The security proof does not make use of the random
oracle model. Instead, in the security proof, Hash is assumed to be secure against second preimage
collision attacks, and KDF is assumed to transform the encoding of a random group element to a
random octet string. For the security proof of FACE-KEM, see Reference [44] (indirect security
reduction to the DDH problem), or Reference [46] (direct security reduction to the DDH problem).
Annex C
Replace all the following words in Annex C:
Test vector(s)
with the following:
Numerical example(s)
Annex C
Add the following after C.8.6:
C.9  Numerical examples for FACE-KEM
C.9.1  Numerical examples over elliptic curve P224
-------------
FACE-KEM
-------------
Kdf = Kdf2(Hash = Sha256(outlen = 20 octets))
Hash = Sha256(outlen = 20 octets)
CofactorMode = 0
KeyLen = TagLen = 16 (octets)
-----
Group = ECModp-Group:
p = 0xffffffffffffffffffffffffffffffff000000000000000000000001
a
...