ISO/IEC 18033-5:2015

Information technology - Security techniques - Encryption algorithms - Part 5: Identity-based ciphers

ISO/IEC 18033-5:2015 specifies identity-based encryption mechanisms. For each mechanism the functional interface, the precise operation of the mechanism, and the ciphertext format are specified. However, conforming systems may use alternative formats for storing and transmitting ciphertexts.

Technologies de l'information — Techniques de sécurité — Algorithmes de chiffrement — Partie 5: Chiffrements identitaires

General Information

• Status: Published
• Publication Date: 22-Nov-2015
• 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: 9093 - International Standard confirmed
• Start Date: 19-Apr-2021
• Completion Date: 30-Oct-2025

Relations

• Amended By: ISO/IEC 18033-5:2015/Amd 1:2021 - Information technology - Security techniques - Encryption algorithms - Part 5: Identity-based ciphers - Amendment 1: SM9 mechanism
• Effective Date: 24-Jul-2021

Overview

ISO/IEC 18033-5:2015 - "Information technology - Security techniques - Encryption algorithms - Part 5: Identity‑based ciphers" specifies identity‑based encryption (IBE) mechanisms and their interfaces. The standard defines the functional behaviour, precise operation and ciphertext formats for identity‑based ciphers and identity‑based hybrid ciphers. It is part of the ISO/IEC 18033 series covering encryption algorithms and complements other parts that address asymmetric, block and stream ciphers.

Key SEO keywords: ISO/IEC 18033-5:2015, identity‑based encryption, IBE, identity‑based ciphers, identity‑based hybrid encryption, key encapsulation.

Key topics and technical requirements

• Functional interfaces and algorithms: Clear specification of the IBE algorithm components (set up, private key extraction, encryption, decryption) and identity‑based key encapsulation mechanisms.
• Specified mechanisms: The document includes the BF identity‑based encryption mechanism and two identity‑based key encapsulation mechanisms (SK and BB1).
• Cryptographic transforms: Definitions and required behaviour for helper functions and hash/transformation primitives referenced in the mechanisms (e.g., labeled functions such as IHF1, SHF1, PHF1 as described).
• Ciphertext format: A precise ciphertext format is specified for each mechanism; implementers may use alternative formats for storage/transmission provided conformance is maintained.
• System parameters and keys: Roles and requirements for system parameters, master‑secret key and corresponding master‑public key, and the Private Key Generator (PKG) that issues private keys.
• Identity‑based hybrid encryption: Model and composition rules for hybrid ciphers that combine identity‑based key encapsulation with data encapsulation primitives.
• Security and testing: Annexes provide object identifiers, security considerations, numerical examples/test vectors, and techniques to reduce PKG trust (mechanisms to prevent key access by third parties).

Practical applications and users

ISO/IEC 18033-5 is applicable where simplified public‑key discovery and reduced certificate management are desirable:

• Secure email and messaging using identity strings (e.g., email addresses) as public keys.
• Short‑lived encryption systems where frequent key rotation reduces reliance on revocation lists.
• IoT and constrained environments where certificate infrastructure is burdensome.
• Enterprise key management designs evaluating trust models involving a Private Key Generator (PKG).

Primary users:

• Cryptographers and security architects designing IBE solutions
• Software and hardware implementers of encryption libraries and protocols
• Standards bodies, auditors and security evaluators

Related standards

• ISO/IEC 18033‑1 (General)
• ISO/IEC 18033‑2 (Asymmetric ciphers)
• ISO/IEC 18033‑3 (Block ciphers)
• ISO/IEC 18033‑4 (Stream ciphers)

Note: ISO/IEC 18033‑5 describes trust implications of using a PKG and includes Annex D techniques to reduce PKG access; it does not prescribe external protocols for public value distribution or proof‑of‑possession.

Standards Content (Sample)

DRAFT INTERNATIONAL STANDARD
ISO/IEC DIS 18033-5
ISO/IEC JTC 1/SC 27 Secretariat: DIN
Voting begins on: Voting terminates on:
2014-07-07 2014-10-07
Information technology — Security techniques —
Encryption algorithms —
Part 5:
Identity-based ciphers
Technologies de l’information — Techniques de sécurité — Algorithmes de chiffrement —
Partie 5: Chiffrements identitaires
ICS: 35.040
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/IEC DIS 18033-5:2014(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO/IEC 2014

ISO/IEC DIS 18033-5:2014(E)
Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as
permitted under the applicable laws of the user’s country, neither this ISO draft nor any extract
from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means,
electronic, photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to 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
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO 2014 – All rights reserved

ISO/IEC DIS 18033-5
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 3
5 Cryptographic transforms . 5
5.1 General . 5
5.2 The function IHF1 . 5
5.3 The function SHF1 . 6
5.4 The function PHF1 . 6
6 General model for identity-based encryption . 7
6.1 Composition of algorithms . 7
6.2 Plaintext length . 8
6.3 Use of labels . 8
6.4 Ciphertext format . 9
6.5 IBE operation . 9
7 General model for identity-based hybrid encryption . 10
7.1 General . 10
7.2 Identity-based key encapsulation . 10
7.2.1 Composition of algorithms . 10
7.2.2 Prefix-freeness . 11
7.3 Data encapsulation . 11
7.3.1 Composition of algorithms . 11
7.4 Identity-based hybrid encryption operation . 11
7.4.1 System parameters . 11
7.4.2 Set up . 12
7.4.3 Private key extraction . 12
7.4.4 Encryption . 12
7.4.5 Decryption . 12
8 Identity-based encryption mechanism . 13
8.1 General . 13
8.2 The BF mechanism . 13
8.2.1 Set up . 13
8.2.2 Private key extraction . 14
8.2.3 Encryption . 15
8.2.4 Decryption . 15
9 Identity-based hybrid encryption mechanisms . 16
9.1 General . 16
9.2 The SK key encapsulation mechanism . 16
9.2.1 Set up . 16
9.2.2 Private key extraction . 17
9.2.3 Session key encapsulation . 18
9.2.4 Session key de-encapsulation . 18
9.3 The BB1 key encapsulation mechanism . 18
9.3.1 Set up . 18
9.3.2 Private key extraction . 19
© ISO/IEC 2014 – All rights reserved iii

ISO/IEC DIS 18033-5
9.3.3 Session key encapsulation .20
9.3.4 Session key de-encapsulation .20
Annex A (normative) Object identifiers .22
Annex B (informative) Security considerations .25
Annex C (informative) Numerical examples .26
Annex D (informative) Mechanisms to prevent access to keys by third parties .36
Bibliography .37

iv © ISO/IEC 2014 – All rights reserved

ISO/IEC DIS 18033-5
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. 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.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 18033-5 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Security techniques.
ISO/IEC 18033 consists of the following parts, under the general title Information technology ― Security
techniques — Encryption algorithms:
 Part 1: General
 Part 2: Asymmetric ciphers
 Part 3: Block ciphers
 Part 4: Stream ciphers
 Part 5: Identity-based ciphers
Further parts may follow.
© ISO/IEC 2014 – All rights reserved v

ISO/IEC DIS 18033-5
Introduction
Use of a public key encryption mechanism requires reliable identification of the correct public key to be used
for encryption. A public key infrastructure (PKI) provides functions to give a trusted link between an entity and
to enable the current status of the public key to be determined. In a PKI, a certification authority (CA) issues a
certificate binding a public key to the owner’s identifier together with other key specific information, e.g. the
validity period. If a public key is deemed to be invalid before its expiry date, then potential users of the public
key need to be notified, e.g. by the issue of a CA-signed Certificate Revocation List (CRL). The generation
and distribution of certificates and CRLs poses a major management problem, which the mechanisms in this
part of ISO/IEC 18033 are designed to address. On encrypting, an encryptor first obtains the CRL and checks
the current status of the certificate. Then the encryptor verifies the certificate, and finally encrypts a message.
Therefore, the encryptor has to be provided with some means of accessing the current CRL, and additionally it
should not require excessive time and computational resources for checking the validity of a certificate
whenever it encrypts a message.
Identity-based encryption (IBE) is a type of asymmetric encryption that allows a decryptor to set its public key
to an arbitrary string. By setting the public key to an easily identifiable string (e.g. an e-mail address), an
encryptor can gain assurance in its correctness without using a certificate. Moreover, if a short validity period
can be arranged, significantly shorter than the updating period of a CRL in a conventional PKI, an encryptor
can generate a ciphertext without checking the current status of the public key because revocation is unlikely
to occur during such a short period. As a result IBE is expected to reduce the certificate management
workload.
The use of IBE requires a Private Key Generator (PKG), which generates private keys for all decryptors using
its master secret key; this contrasts with ‘traditional’ asymmetric encryption mechanisms, such as those
specified in ISO/IEC 18033-2, in which entities generate their own public/private key pairs. As a result, use of
IBE is only appropriate when it is acceptable for a third party to have decryption access to all encrypted data.

The identity-based encryption mechanisms are specified in Clause 8 and Clause 9. The specified
mechanisms are the BF identity-based encryption mechanism, the SK identity-based key encapsulation
mechanism and the BB1 identity-based key encapsulation mechanism.
The specifications in this part of ISO/IEC 18033 do not prescribe protocols for reliably obtaining public values,
for proof of possession of a private key, or for validation of either public values or private keys.
Annex A gives the assignment of object identifiers to the algorithms specified in this part of ISO/IEC 18033.
Annex B describes security considerations for each specified mechanism and Annex C provides test vectors.
Annex D introduces techniques which can be used to remove the decryption capability of the PKG, and
thereby reduce the level of trust required in this entity.

vi © ISO/IEC 2014 – All rights reserved

DRAFT INTERNATIONAL STANDARD ISO/IEC DIS 18033-5

Information technology ― Security techniques — Encryption
algorithms — Part 5: Identity-based ciphers
1 Scope
This part of ISO/IEC 18033 specifies identity-based encryption mechanisms. For each mechanism the
functional interface, the precise operation of the mechanism, and the ciphertext format are specified. However,
conforming systems may use alternative formats for storing and transmitting ciphertexts.
2 Normative references
The following referenced documents are indispensable for the application of this document.
 ISO/IEC 18033-1, Information technology ― Security techniques ― Encryption algorithms ― Part 1:
General.
 ISO/IEC 18033-2, Information technology ― Security techniques ― Encryption algorithms ― Part 2:
Asymmetric ciphers.
 ISO/IEC 18033-3, Information technology ― Security techniques ― Encryption algorithms ― Part 3:
Block ciphers.
3 Terms and definitions
For the purposes of this part of ISO/IEC 18033, the terms and definitions given in ISO/IEC 18033-1, and the
following apply.
3.1
decryptor
entity which decrypts ciphertexts
3.2
encryptor
entity which encrypts plaintexts
3.3
hybrid encryption
encryption performed using a hybrid cipher
3.4
identifier
object that represents something and enables one to identify it
3.5
identity string
string that represents an identity
© ISO/IEC 2014 – All rights reserved 1

ISO/IEC DIS 18033-5
3.6
identity-based cipher
asymmetric cipher in which the encryption algorithm takes an arbitrary string as a public key
3.7
identity-based hybrid cipher
cipher which is both a hybrid cipher and an identity-based cipher
3.8
identity-based key encapsulation mechanism
key encapsulation mechanism for which the encryption process takes an arbitrary string as a public key
3.9
master-public key
public value uniquely determined by the corresponding master-secret key
3.10
master-secret key
secret value used by the private key generator to compute private keys for an IBE algorithm
3.11
private key extraction algorithm
method used by the private key generator to compute private keys for an IBE algorithm
3.12
private key generator
entity or function which generates a set of private keys
3.13
public key encryption
encryption performed using an asymmetric cipher
3.14
string
ordered sequence of symbols
3.15
set up
process by which the system parameters for an IBE algorithm are selected
3.16
set up algorithm
process which generates a master-secret key and the corresponding master-public key, together with some
part of the system parameters
3.17
system parameters
parameters for cryptographic computation including a selection of a particular cryptographic scheme or
function from a family of cryptographic schemes or functions, or from a family of mathematical spaces
3.18
trusted third party
security authority, or its agent, trusted by other entities with respect to security related activities

2 © ISO/IEC 2014 – All rights reserved

ISO/IEC DIS 18033-5
4 Symbols and abbreviated terms
For the purposes of this part of ISO/IEC 18033, the symbols and abbreviated terms given in ISO/IEC 18033-1
and the following apply.
Symbols:
the smallest integer greater than or equal to the real number x.
x
 
[a,K,b) the set of integers {x : a ≤ x < b}.
~ ~ ~ ~
x ⊕ y if x and y are bit/octet strings of the same length, the bit-wise exclusive-or
(XOR) of the two strings.
a tuple x1,K, xl of elements.
x1,Kxl
~ ~ ~ ~ ~
x || y if and y are bit/octet strings, the concatenation of the two strings and
x x
~ ~ ~
y, resulting in the string consisting of followed by y .
x
gcd(a,b) for integers a and b, the greatest common divisor of a and b, i.e., the
largest positive integer that divides both a and b (or 0 if a = b = 0 ).
a | b a relation between integers a and b that holds if and only if a divides b,
i.e., there exists an integer c such that b = ac.

a relation between integers a and b that holds if and only if a does not
a ∤ b
divide b, i.e., there does not exist any integer c such that b = ac.
for a non-zero integer n, a relation between integers a and b that holds if
a ≡ b ( mod n )
and only if a and b are congruent modulo n, i.e., n | (a − b).
a ( mod n ) for integer a and positive integer n, the unique integer r ∈ [0,K,n) such that
r ≡ a ( mod n ).
−1
for integer a and positive integer n, such that gcd(a,n) = 1, the unique
a ( mod n )
[ )
integer b∈ 0,K, n such that ab ≡ 1( mod n ).
( ) the finite field containing q elements, where q is a power of a prime.
GF q
( ) ( )
E / GF q an elliptic curve defined over the field GF q .
( ( )) ( )
E GF q the additive group of points on the elliptic curve E / GF q .
( ( ))[ ] ( ( ))
E GF q n the subgroup of E GF q consisting of all points of order n.
( ( )) ( )
# E GF q the number of points of an elliptic curve defined over the field GF q .

Abbreviations:
CT ciphertext, an octet string.
© ISO/IEC 2014 – All rights reserved 3

ISO/IEC DIS 18033-5
DEM data encapsulation mechanism.
IBE identity-based encryption.
IBhE identity-based hybrid encryption.
ID octet string uniquely assigned to a decryptor.
binary representation of ID.
ID
b
K session key for DEM.
κ security parameter.
KEM key encapsulation mechanism.
L label, an octet string.
mpk master-public key of IBE.
Msg plaintext, an octet string.
binary representation of Msg .
Msg
b
master-secret key of IBE.
msk
parms
system parameters of IBE.
PKG private key generator.
sk private key corresponding to ID of IBE.
ID
(All these functions are defined in ISO/IEC 18033-2.):
Conversion Functions
BS2IP bit string to integer conversion primitive.
BS2OSP bit string to octet string conversion primitive.
EC2OSP elliptic curve to octet string conversion primitive.
FE2OSP field element to octet string conversion primitive.
FE2IP field element to integer conversion primitive.
I 2BSP integer to bit string conversion primitive.
I 2OSP integer to octet string conversion primitive.
OS2ECP octet string to elliptic curve conversion primitive.
OS2FEP octet string to field element conversion primitive.
OS2IP octet string to integer conversion primitive.
4 © ISO/IEC 2014 – All rights reserved

ISO/IEC DIS 18033-5
OS2BSP octet string to bit string conversion primitive.
the octet whose integer value is m.
Oct(m)
the number of octets of an integer n.
Len(n)
5 Cryptographic transforms
5.1 General
The schemes specified in this part of ISO/IEC 18033 make use of three cryptographic transformations, IHF1,
SHF1 and PHF1 as specified below. These transformations make use of hash-functions specified in ISO/IEC
10118-3.
5.2 The function IHF1
IHF1 is based on four hash-functions specified in ISO/IEC 10118-3, namely SHA-224, SHA-256, SHA-384
and SHA-512. It inputs a string of bits and outputs an integer in a specified range.

Input:
*
 A string str ∈{0,1}
 A security parameter κ ∈{112,128,192, 256}
4κ
 An integer n, 0 < n < 2
Output:
 An integer ν , 0 ≤ν < n.
Operation: Perform the following steps.
(a) If κ = 112 then let H be SHA-224;
else if κ = 128 then let H be SHA-256;
else if κ = 192 then let H be SHA-384;
else if κ = 256 then let H be SHA-512.
(b) Let h be an all-zero bit string of length 2κ .
(c) Let t = h || str .
1 0
(d) Let h = H (t ).
1 1
(e) Let v = BS2IP(h ).
1 1
© ISO/IEC 2014 – All rights reserved 5

ISO/IEC DIS 18033-5
(f) Let t = h || str .
2 1
(g) Let h = H (t ).
2 2
(h) Let a = BS2IP(h ).
2 2
2κ
(i) Let ν = 2 ν + a .
2 1 2
(j) Output ν mod n.
5.3 The function
SHF1
Returns an n -bit string that is based on a cryptographic hash function applied to an input string.
Input:
*
 A string str ∈{0,1}
 A security parameter κ ∈{112, 128, 192, 256}
 An integer n, n > 0
Assumptions: The string str is within the allowed range of values for inputs to the relevant hash function. The
integer n has the property that n ≤ 4κ .
Output:
n
 A string ν ∈{0,1}
Operation: Use the following steps.
n
(a) Output I 2BSP(IHF1(str, 2 , κ)).
5.4 The function PHF1
Returns an element of an elliptic curve group E(GF(q))[p] for a supersingular elliptic curve
2 3 2 3
E / GF(q) : y = x + b or E / GF(q) : y = x + ax. There are other types of pairing-friendly elliptic curves for
which PHF1 is not suitable.
Input:
*
 A string str ∈{0,1}
 A security parameter κ ∈{112,128,192, 256}
 A flag j taking the values 0 or 1 which defines a supersingular elliptic curve, with j = 0 representing
2 3 2 3
the elliptic curve E / GF(q) : y = x + b and j = 1 representing the elliptic curve E / GF(q) : y = x + ax.
 A prime q with q = 2(mod3) when j = 0 or q = 3(mod 4) when j = 1 that defines the finite field GF(q).
 An integer a, 0 < a < q if j = 1 or an integer b, 0 < b < q if j = 0
 A prime p with p |# E(GF(q)) and p ∤ # E(GF(q)) for elliptic curve E defined by the flag j
Output:
6 © ISO/IEC 2014 – All rights reserved

ISO/IEC DIS 18033-5
 An element of E(GF(q))[p]for the selected elliptic curve.
Operation: Use the following steps.
(a) Let r = (q +1) / p.
(b) If j = 0 then perform the following steps:
(1) Let y = IHF1(str, q, κ).
2 (2q−1) /3
(2) Let x = (y − b) (mod q).
(3) Let Q = (x, y).
(c) Else if j = 1 perform the following steps:
(1) Let x = IHF1(str, q, κ).
(2) Let z = x + ax (mod q).
(3) If the Jacobi symbol (z / q) = +1 then perform the following steps:
(q+1) / 4
(i) Let y = z (mod q).
(ii) Let Q = (x, y).
(4) If the Jacobi symbol (z / q) = −1 then perform the following steps:
(q+1) / 4
(i) Let y = (−z) (mod q).
(ii) Let Q = (−x, y).
(d) Return rQ.
6 General model for identity-based encryption

6.1 Composition of algorithms
An identity-based encryption scheme consists of the following four algorithms.
IBE.Setup(κ ). Given a security parameter κ, generate a tuple parms, mpk, msk , where parms denotes
system parameters, msk denotes a master-secret key and mpk is the corresponding master-public key.
IBE.Extract(parms, mpk, msk, ID). Given a master-secret key msk, the corresponding master-public key mpk
and an octet string ID with parms, generate a private key sk for ID.
ID
© ISO/IEC 2014 – All rights reserved 7

ISO/IEC DIS 18033-5
IBE.Enc(parms, mpk, ID, L, Msg). Given a plaintext Msg, a label L and an octet string ID with parms and
mpk, do the encryption and output the ciphertext of Msg, CT, for ID. Note that Msg, L and CT are octet
strings.
IBE.Dec(parms, mpk, ID, sk , L, CT ). Given a private key sk with parms, mpk, ID and L, decrypt a
ID ID
ciphertext CT and output the underlying plaintext.
In general, the setup, key extraction and encryption algorithms are probabilistic algorithms, while the
decryption algorithm is deterministic. It is recommended that applications establish a methodology for
authenticating access to private keys by using the ID string as an identity in a trusted authentication system.
The details of authenticating the key request are beyond the scope of this part of ISO/IEC 18033, but are
critical for the security of an implemented application.
NOTE 1 Semantic security against an adaptive chosen ciphertext attack [5] is regarded by the cryptographic research
community as the appropriate security level that a general purpose IBE mechanism should satisfy. Each IBE mechanism
described in this part of ISO/IEC 18033 satisfies this security level. The formal definition of this security notion is described
in Annex B.
NOTE 2 A basic requirement of any IBE mechanism is correctness. For any ID / sk pair and for any plaintext of
ID
defined length, the ciphertext of ID under a master-public key and system parameters ID shall be able to be decrypted
with the private key sk under the master-public key and the system parameters ID to the original plaintext. This
ID
requirement may be relaxed, so that it holds only for all but a negligible fraction of ID / sk pairs.
ID
6.2 Plaintext length
Three types of plaintext length of IBE are defined as follows.
— An arbitrary-plaintext-length IBE encrypts plaintexts of an arbitrary length.
— A fixed-plaintext-length IBE only encrypts plaintexts whose length (in octets) is equal to a fixed value
IBE.MsgLen.
— A bounded-plaintext-length IBE only encrypts plaintexts whose length (in octets) is less than or equal to a
fixed value IBE.MaxMsgLen(mpk). Here, the maximum plaintext length may depend on the system
parameter mpk .
6.3 Use of labels
A label is an octet string whose value is used by the encryption and decryption algorithms. It may contain
public data that is implicit from context and need not be encrypted, but that should nevertheless be bound to
the ciphertext. A label is an octet string that is meaningful to the application using the IBE scheme, and that is
independent of the implementation of the IBE scheme. Three types of label length of IBE are defined as
follows.
 An arbitrary-label-length IBE is one in which the encryption and decryption algorithms accept labels of
arbitrary length.
 A fixed-label-length IBE is one in which the encryption and decryption algorithms only accept labels
whose length (in octets) is equal to a fixed value IBE.LabelLen.
8 © ISO/IEC 2014 – All rights reserved

ISO/IEC DIS 18033-5
 A bounded-label-length IBE is one in which the encryption and decryption algorithms only accept labels
whose length (in octets) is less than or equal to a fixed value IBE.MaxLabelLen.
NOTE The traditional notion of security against an adaptive chosen ciphertext attack has been extended in Annex B,
so that intuitively, for a secure IBE mechanism, the encryption algorithm should bind the label to the ciphertext in an
appropriate “non-malleable” fashion.

6.4 Ciphertext format
This part of ISO/IEC 18033 describes ciphertext formats in an octet string; however, an implementation is free
to store and/or transmit ciphertexts in alternative formats, if it is required. Moreover, ciphertexts in the format
prescribed here may not necessarily appear in the encryption or decryption process, since converting the
format into an alternative format may be collapsed into a single, functionally equivalent process.
NOTE Besides promoting interoperability, prescribing the format of a ciphertext is necessary in order to make
meaningful claims and to reason about the security of an IBE against adaptive chosen ciphertext attacks.

6.5 IBE operation
In an IBE setup, a trusted third party generates a master-secret key, the corresponding master-public key and
system parameters by invoking the IBE.Setup algorithm and makes the master-public key and the system
parameters public, keeping the master-secret key private. When a decryptor requests the private key, a
private key issuer invokes the IBE.Extract algorithm and issues its output to the decryptor as the private key
via a secure channel. An encryptor computes a ciphertext by running the IBE.Enc algorithm with the
decryptor’s identity string. The decryptor derives the underlying plaintext from the received ciphertext by
running IBE.Dec with the private key.
The following mechanisms and protocols are outside of the scope of this part of ISO/IEC 18033. One can refer
to ISO/IEC 11770 for designing key management operation.
 protocol for making a master-public key and system parameters available.
 protocol for distributing private keys to decryptors.
 protocol for making an identity string available to encryptors.
 mechanism for storing a master-secret key or a private key securely.
 mechanism for confirming a link between a master-public key or system parameters and its issuer.
Each of the IBE mechanisms specified in this part of ISO/IEC 18033 are actually members of families of IBE
mechanisms, where a particular IBE is selected from the family by choosing particular values for the system
parameters defining the family of IBE mechanisms. For an IBE mechanism selected from a family of
mechanisms, prior to master-secret key/master-public key pair generation, specific values of the system
parameters for the family should be chosen. Depending on the conventions used for encoding master-public
keys, some of the choices of the system parameters may be embedded in the encoding of the master-public
key as well. These system parameters shall remain fixed throughout the lifetime of the master-public key.
NOTE For example, if an IBE mechanism is parameterized in terms of a cryptographic hash function, the choice of
hash function should be fixed once and for all at some point prior to the generation of a master-secret key/master-public
key pair, and the encryption and decryption algorithms should use the chosen hash function throughout the lifetime of the
master-public key. Failure to abide by this rule not only makes an implementation non-conforming, but also invalidates the
security analysis for the mechanism, and can in some cases expose the implementation to severe security risks.
© ISO/IEC 2014 – All rights reserved 9

ISO/IEC DIS 18033-5
7 General model for identity-based hybrid encryption

7.1 General
An identity-based hybrid encryption scheme is used for encrypting a large plaintext making use of the
advantages of the identity-based encryption scheme, where an IBE is utilized to encrypt a decryption key for
encrypting the actual message using symmetric cryptographic techniques. An identity-based hybrid encryption
scheme is built from two lower-level “building blocks”: an identity-based key encapsulation scheme and a data
encapsulation scheme.
7.2 Identity-based key encapsulation

7.2.1 Composition of algorithms
An identity-based key encapsulation scheme consists of the following four algorithms.
KEM.Setup(κ ). Given a security parameter κ, generate a tuple parms, mpk, msk , where parms denotes
system parameters, msk denotes a master-secret key and mpk is the corresponding master-public key.
KEM.Extract(parms, mpk, msk, ID). Given a master-secret key msk, the corresponding master-public key mpk,
and an octet string ID with parms, generate a private key sk for ID.
ID
KEM.Enc(parms, mpk, ID). Given an octet string ID with parms and mpk, output an octet string K and the
ciphertext of CT , for ID. Note that CT is an octet string.
K,
KEM KEM
KEM.Dec(parms, mpk, ID, sk , CT ). Given a private key sk with parms, mpk and decrypt a
ID,
ID KEM ID
ciphertext CT and output the underlying octet string.
KEM
In the general setup, key extraction and encapsulation algorithms are probabilistic algorithms, while the de-
encapsulation algorithm is deterministic. The de-encapsulation algorithm may fail under some circumstances
with a negligible probability. A key encapsulation scheme also specifies a positive integer KEM .KeyLen - the
length of the secret key output by KEM.Enc and KEM .Dec.
NOTE 1 The required security level that each key encapsulation mechanism should satisfy is described in Annex B.
NOTE 2 Any key encapsulation mechanism should satisfy a correctness property analogous to the correctness
property of an IBE mechanism: for any ID / sk pair and for any octet string K whose length is within its
ID
implementation-defined limits, any encapsulation of K with predetermined system parameters under an ID decrypts with
the system parameters under the ID to the original K . This requirement may be relaxed so that it holds only for all but a
negligible fraction of ID / sk pairs.
ID
10 © ISO/IEC 2014 – All rights reserved

ISO/IEC DIS 18033-5
7.2.2 Prefix-freeness
Additionally, a key encapsulation mechanism shall satisfy the following property. The set of all possible
ciphertext outputs of the encryption algorithm should be a subset of a candidate set of octet strings (that may
depend on the public key), such that the candidate set is prefix free and elements of the candidate set are
easy to recognize (given either the public key or the private key).

7.3 Data encapsulation
7.3.1 Composition of algorithms
A data encapsulation scheme consists of the following two algorithms.
DEM.Enc(K, L, Msg). Given octet strings K and L, compute the encryption of Msg, CT . Note that Msg
DEM
and CT are octet strings, and L and Msg may have length as described in 6.3 and 6.2 respectively. The
DEM
bit length of K is DEM.KeyLen.
DEM.Dec(K, L, CT ). Given octet strings K and L, decrypt a ciphertext CT and output the underlying
DEM DEM
plaintext.
The encryption algorithm may fail if the lengths L or Msg exceed some (very large) implementation-defined
limits. The decryption algorithm may fail under some circumstances with a negligible probability.
The allowable data encapsulation mechanisms are the symmetric encryption mechanisms described in
ISO/IEC 18033-3.
NOTE The encryption and decryption algorithms should be deterministic, and should satisfy the following correctness
requirement: for all session keys K, all labels L, and all plaintexts Msg, such that the lengths of L and Msg do not
exceed the implementation-defined limits, and
DEM.Dec(K, L, DEM.Enc(K, L, Msg)) = Msg .

7.4 Identity-based hybrid encryption operation

7.4.1 System parameters
An identity-based hybrid encryption scheme (for short, IBhE) is a family of IBE schemes parameterized by the
following system parameters:
 KEM: an identity-based key encapsulation scheme, as described in 7.2.
 DEM: a data encapsulation scheme, as described in 7.3.
Any combination of KEM and DEM may be used, provided KEM.KeyLen = DEM.KeyLen.
© ISO/IEC 2014 – All rights reserved 11

ISO/IEC DIS 18033-5
NOTE 1 If DEM is instantiated by a fixed-label-length data encapsulation mechanism, with labels restricted to length
DEM.LabelLen, then IBhE is a fixed-label-length identity-based encryption mechanism with
IBhE.LabelLen = DEM.LabelLen.
NOTE 2 If DEM is instantiated by a fixed-plaintext-length data encapsulation mechanism, with plaintexts restricted to
length DEM .MsgLen, then IBhE is a fixed-plaintext-length identity-based encryption mechanism with
IBhE.MsgLen = DEM.MsgLen.
NOTE 3 For all the allowable choices of KEM, the value of KEM.KeyLen is a system parameter that may be chosen
so as to equal DEM .KeyLen. Thus, all possible combinations of allowable KEM and DEM may be realized by appropriate
choices of system parameters.
7.4.2 Set up
The set up algorithm for IBhE is the same as that of the underlying KEM. Let parms denote system
parameters and msk, mpk denote a master-secret key/master public-key pair.

7.4.3 Private key extraction
The private key extraction algorithm for IBhE is the same as that of the underlying KEM. Let sk denote a
ID
private key of ID.
7.4.4 Encryption
The encryption algorithm IBhE.Enc takes as input a master-public key mpk, a label L and a plaintext Msg
with system parameters parms. It runs as follows.
(a) Compute K, CT = KEM .Enc(parms, mpk, ID).
KEM
(b) Compute CT = DEM.Enc(K, L, Msg).
DEM
(c) Set CT = CT || CT .
KEM DEM
(d) Output CT .
7.4.5 Decryption
The decryption algorithm IBhE.Dec takes as input a private key sk , an octet string ID, a label L, and a
ID
ciphertext CT with system parameters parms. It runs as follows.
(a) Using the prefix-freeness property of the ciphertexts associated with KEM, parse CT as
CT = CT || CT , where CT and CT are octet strings such that CT is an element of
KEM DEM KEM DEM KEM
the candidate set of possible ciphertexts associated with KEM. This step fails if CT cannot be
parsed.
12 © ISO/IEC 2014 – All rights reserved

ISO/IEC DIS 18033-5
(b) Compute K = KEM .Dec(parms, mpk, ID, sk , CT ).
ID KEM
(c) Compute Msg = DEM.Dec(K, L, CT ).
DEM
(d) Output Msg .
NOTE The security of IBhE is discussed in Annex B. It is only remarked here that as long as KEM and DEM satisfy
the appropriate security properties, then IBhE will be secure against adaptive chosen ciphertext attack.

8 Identity-based encryption mechanism

8.1 General
In this clause an identity-based encryption mechanism is specified. This mechanism is specified to use the
following primitives. The hash function H is used for supersingular curves but some other (possibly similar)
scheme of hashing a string to a point is required for other curves.
Take a security parameter κ, and a key size parameter δ, the mechanism requires the following algorithms:
a) A random bit generation algorithm [3]:
δ
 R : a source of random values in the space {0, 1} .
b) Four hash functions:
*
 H :{0,1} → G where H (s) = PHF1(s, κ, j, q, c, p) with j = 0 representing the elliptic curve
1 1 1
2 3 2 3
E /GF(q) : y = x + c and j = 1 representing the elliptic curve E / GF(q) : y = x + cx and p is
a prime with p |# E(GF(q)) and p ∤ #E(GF(q)) for elliptic curve E defined by the flag j
δ
 H : G →{0,1} where H (x) = SHF1(OS2BSP(z), δ , κ ) and z = FE2OSP(x)
2 3 2
δ δ *
 H :{0,1} ×{0,1} → Z where H (s , s ) = IHF1(s || s , p −1, κ )+1
3 p 3 1 2 1 2
δ δ
 H :{0,1} → {0,1} where H (s) = SHF1(s, δ , κ )
4 4
8.2 The BF mechanism
8.2.1 Set up
The setup operation creates public system parameters and a master-secret key. The master-secret key shall
be secured by the private key issuer, as all private keys calculated within the system depend on it. It is
recommended that applications establish a methodology for changing the master-secret key, the
corresponding master-public key and system parameters on a regular basis, and have a methodology for
handling the disclosure of a master-secret key. However this is out of scope of this part of ISO/IEC 18033.
The steps to setup the private key issuer and system parameters are:
(a) Establish the set of base groups G, G , G and a pairing e : G × G → G . G shall be of the form
1 2 3 1 2 3 1
E(GF(q))[p], where p and q are primes.
© ISO/IEC 2014 – All rights reserved 13

ISO/IEC DIS 18033-5
(b) Select a random generator Q in G .
*
(c) Generate a random master secret s in Z . Calculate the corresponding R as sQ.
p
(d) Make the system parameters and the master-public key set parms = Q, G , G , G , e and mpk = R
1 2 3
available. Secure the master-secret key s.

ISO/IEC 15946-1 contains recommendations for the generation of the groups, group generators and pairing.

8.2.2 Private key extraction
*
The extract operation takes an arbitrary identity string ID in {0, 1} and calculates the corresponding private
b
key sk in G . The algorithm to compute the private key sk corresponding to an identity string ID is as
ID 1 ID b
follows:
Input:
 The system parameters parms = Q, G , G , G , e
1 2 3
 The master-public key mpk = R
 The master-secret key msk = s
 an identity string ID
b
Output:
 The derived private key sk that is an element of G .
ID 1
Operation: Use the following steps to compute sk .
ID
( )
(a) Compute the identity element M = H ID .
1 b
(b) Set sk = sM .
ID
(c) Output sk .
ID
The correctness of the value sk can be verified by using the following algorithm:
ID
Input:
 The system parameters parms = Q, G , G , G , e
1 2 3
 The master-public key mpk = R
 an identity string ID
b
 The corresponding private key sk = sM
ID
Output:
 The value "valid" if sk is consistent with parms, mpk and ID , and "invalid" otherwise
ID b
Operation: Use the following steps.
14 © ISO/IEC 2014 – All rights reserved

ISO/IEC DIS 18033-5
(a) Compute the identity element M = H (ID ).
1 b
(b) Compute T = e(sk , Q).
0 ID
(c) Compute T = e(M , R).
If T = T then output the value "valid", otherwise output the value "invalid."
0 1
8.2.3 Encryption
*
The encrypt operation takes an arbitrary identity string ID in {0, 1} , a message Msg of length δ and the
b b
master-public key mpk = R with the system parameters parms, and outputs the ciphertext CT of the message.
The steps to encrypt the message are:
(a) Using R, compute a δ -bit randomizer o.
(b) Compute the identity element M = H (ID ).
1 b
(c) Compute r = H (o, Msg ).
3 b
(d) Compute C = rQ.
(e) Compute B = e(rM , R).
(f) Compute C = o ⊕ H (B).
2 2
(g) Compute C = Msg ⊕ H (o).
3 b 4
(h) Output CT = C , C , C .
1 2 3
8.2.4 Decryption
The decrypt operati
...

INTERNATIONAL ISO/IEC
STANDARD 18033-5
First edition
2015-12-01
Information technology — Security
techniques — Encryption algorithms —
Part 5:
Identity-based ciphers
Technologies de l’information — Techniques de sécurité —
Algorithmes de chiffrement —
Partie 5: Chiffrements identitaires
Reference number
©
ISO/IEC 2015
© ISO/IEC 2015, 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. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols, abbreviated terms and conversion functions . 2
4.1 Symbols . 3
4.2 Abbreviated terms . 3
4.3 Conversion functions . 4
5 Cryptographic transforms . 5
5.1 General . 5
5.2 The function IHF1 . 5
5.3 The function SHF1 . 5
5.4 The function PHF1 . 6
6 General model for identity-based encryption . 7
6.1 Composition of algorithms . 7
6.2 Plaintext length . 7
6.3 Use of labels . 8
6.4 Ciphertext format . 8
6.5 IBE operation . . 8
7 General model for identity-based hybrid encryption . 9
7.1 General . 9
7.2 Identity-based key encapsulation . 9
7.2.1 Composition of algorithms . 9
7.2.2 Prefix-freeness .10
7.3 Data encapsulation .10
7.3.1 Composition of algorithms .10
7.4 Identity-based hybrid encryption operation .10
7.4.1 System parameters .10
7.4.2 Set up .11
7.4.3 Private key extraction .11
7.4.4 Encryption .11
7.4.5 Decryption .11
8 Identity-based encryption mechanism .11
8.1 General .11
8.2 The BF mechanism .12
8.2.1 Set up .12
8.2.2 Private key extraction .12
8.2.3 Encryption .13
8.2.4 Decryption .14
9 Identity-based hybrid encryption mechanisms .14
9.1 General .14
9.2 The SK key encapsulation mechanism .14
9.2.1 Set up .14
9.2.2 Private key extraction .15
9.2.3 Session key encapsulation .16
9.2.4 Session key de-encapsulation .16
9.3 The BB1 key encapsulation mechanism .17
9.3.1 Set up .17
9.3.2 Private key extraction .17
9.3.3 Session key encapsulation .18
© ISO/IEC 2015 – All rights reserved iii

9.3.4 Session key de-encapsulation .18
Annex A (normative) Object identifiers .20
Annex B (informative) Security considerations .21
Annex C (informative) Numerical examples .22
Annex D (informative) Mechanisms to prevent access to keys by third parties .35
Bibliography .36
iv © ISO/IEC 2015 – 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. 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 document 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 and IEC 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 meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT), see the following URL: Foreword — Supplementary information.
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 27, IT
Security techniques.
ISO/IEC 18033 consists of the following parts, under the general title Information technology ― Security
techniques — Encryption algorithms:
— Part 1: General
— Part 2: Asymmetric ciphers
— Part 3: Block ciphers
— Part 4: Stream ciphers
— Part 5: Identity-based ciphers
Further parts may follow.
Annex A forms a normative part of this part of ISO/IEC 18033. Annex B, Annex C and Annex D are
informative only.
© ISO/IEC 2015 – All rights reserved v

Introduction
Use of a public key encryption mechanism requires reliable identification of the correct public key
to be used for encryption. A public key infrastructure (PKI) provides functions to give a trusted link
between an entity and to enable the current status of the public key to be determined. In a PKI, a
certification authority (CA) issues a certificate binding a public key to the owner’s identifier together
with other key specific information, e.g. the validity period. If a public key is deemed to be invalid
before its expiry date, then potential users of the public key need to be notified, e.g. by the issue of
a CA-signed Certificate Revocation List (CRL). The generation and distribution of certificates and
CRLs poses a major management problem, which the mechanisms in this part of ISO/IEC 18033 are
designed to address. On encrypting, an encryptor first obtains the CRL and checks the current status
of the certificate. Then the encryptor verifies the certificate, and finally encrypts a message. Therefore,
the encryptor has to be provided with some means of accessing the current CRL, and additionally it
should not require excessive time and computational resources for checking the validity of a certificate
whenever it encrypts a message.
Identity-based encryption (IBE) is a type of asymmetric encryption that allows a decryptor to set its
public key to an arbitrary string. By setting the public key to an easily identifiable string (e.g. an e-mail
address), an encryptor can gain assurance in its correctness without using a certificate. Moreover, if
a short validity period can be arranged, significantly shorter than the updating period of a CRL in a
conventional PKI, an encryptor can generate a ciphertext without checking the current status of the
public key because revocation is unlikely to occur during such a short period. As a result IBE is expected
to reduce the certificate management workload.
The use of IBE requires a Private Key Generator (PKG), which generates private keys for all decryptors
using its master secret key; this contrasts with ‘traditional’ asymmetric encryption mechanisms, such
as those specified in ISO/IEC 18033-2, in which entities generate their own public/private key pairs. As
a result, use of IBE is only appropriate when it is acceptable for a third party to have decryption access
to all encrypted data.
The identity-based encryption mechanisms are specified in Clauses 8 and 9. The specified mechanisms
are the BF identity-based encryption mechanism, the SK identity-based key encapsulation mechanism,
and the BB1 identity-based key encapsulation mechanism.
The specifications in this part of ISO/IEC 18033 do not prescribe protocols for reliably obtaining public
values, for proof of possession of a private key, or for validation of either public values or private keys.
Certain sections of Clause 5, Clause 8 and Clause 9 of this part of ISO/IEC 18033 have been reprinted
with permission from [7] IEEE Std 1363.3-2013 - IEEE Standard for Identity-Based Cryptographic
Techniques using Pairings. Reprinted with permission from IEEE. Copyright 2013. All rights reserved.
Annex A gives the assignment of object identifiers to the algorithms specified in this part of
ISO/IEC 18033. Annex B describes security considerations for each specified mechanism and Annex C
provides numerical examples. Annex D introduces techniques which can be used to remove the
decryption capability of the PKG, and thereby reduce the level of trust required in this entity.
The International Organization for Standardization (ISO) and International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this part of
ISO/IEC 18033 may involve the use of patents. The 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
licences under reasonable and non-discriminatory terms and conditions with applicants throughout
vi © ISO/IEC 2015 – All rights reserved

the world. In this respect, the statements of the holders of these patent rights are registered with the
ISO and IEC. Information may be obtained from the following:
Patent holder name: Nippon Telegraph and Telephone Corporation
Postal address: Licensing Group, Intellectual Property Center
9-11, Midori-cho, 3-Chome Musashino-Shi, Tokyo 180-8585 Japan
Patent holder name: IBM Corporation
Postal address: IBM Intellectual Property Licensing
North Castle Drive, Armonk, NY 10504 USA
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 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.
© ISO/IEC 2015 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 18033-5:2015(E)
Information technology — Security techniques —
Encryption algorithms —
Part 5:
Identity-based ciphers
1 Scope
This part of ISO/IEC 18033 specifies identity-based encryption mechanisms. For each mechanism the
functional interface, the precise operation of the mechanism, and the ciphertext format are specified.
However, conforming systems may use alternative formats for storing and transmitting ciphertexts.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 18033-1, Information technology — Security techniques — Encryption algorithms — Part 1: General
ISO/IEC 18033-2, Information technology — Security techniques — Encryption algorithms — Part 2:
Asymmetric ciphers
ISO/IEC 18033-3, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 18033-1 and the
following apply.
3.1
decryptor
entity which decrypts ciphertexts
3.2
encryptor
entity which encrypts plaintexts
3.3
hybrid encryption
encryption performed using a hybrid cipher
3.4
identifier
object that represents something and enables one to identify it
3.5
identity string
string that represents an identity
© ISO/IEC 2015 – All rights reserved 1

3.6
identity-based cipher
asymmetric cipher in which the encryption algorithm takes an arbitrary string as a public key
3.7
identity-based hybrid cipher
cipher which is both a hybrid cipher and an identity-based cipher
3.8
identity-based key encapsulation mechanism
key encapsulation mechanism for which the encryption process takes an arbitrary string as a public key
3.9
master-public key
public value uniquely determined by the corresponding master-secret key
3.10
master-secret key
secret value used by the private key generator to compute private keys for an IBE algorithm
3.11
private key extraction algorithm
method used by the private key generator to compute private keys for an IBE algorithm
3.12
private key generator
entity or function which generates a set of private keys
3.13
public key encryption
encryption performed using an asymmetric cipher
3.14
string
ordered sequence of symbols
3.15
set up
process by which the system parameters for an IBE algorithm are selected
3.16
set up algorithm
process which generates a master-secret key and the corresponding master-public key, together with
some part of the system parameters
3.17
system parameters
parameters for cryptographic computation including a selection of a particular cryptographic scheme or
function from a family of cryptographic schemes or functions, or from a family of mathematical spaces
3.18
trusted third party
security authority, or its agent, trusted by other entities with respect to security related activities
4 Symbols, abbreviated terms and conversion functions
For the purposes of this part of ISO/IEC 18033, the symbols and abbreviated terms given in
ISO/IEC 18033-1 and the following apply.
2 © ISO/IEC 2015 – All rights reserved

4.1 Symbols
[a,…,b) the set of integers {x : a ≤ x < b}.
 
xy⊕ if x and ỹ are bit/octet strings of the same length, the bit-wise exclusive-or (XOR) of
the two strings.
a tuple xx1,,… l of elements.
xx1,,… l
xy|| if x and ỹ are bit/octet strings, the concatenation of the two strings x and ỹ, resulting
in the string consisting of x followed by ỹ.
gcd(a,b) for integers a and b, the greatest common divisor of a and b, i.e., the largest positive
integer that divides both a and b (or 0 if a = b = 0).
a|b a relation between integers a and b that holds if and only if a divides b i.e., there exists
an integer c such that b = ac.
a∤b a relation between integers a and b that holds if and only if a does not divide b i.e.,
there does not exist any integer c such that b = ac.
a ≡ b(mod n) for a non-zero integer n, a relation between integers a and b that holds if and only
if a and b are congruent modulo n, i.e., n|(a − b).
a (mod n) for integer a and positive integer n, the unique integer r∈[0,…,n) such that
r ≡ a (mod n).
−1
a (mod n) for integer a and positive integer n, such that gcd(a,n) = 1, the unique integer b∈[0,…,n)
such that ab ≡ 1(mod n).
GF(q) the finite field containing q elements, where q is a power of a prime.
E / GF(q) an elliptic curve defined over the field GF(q).
E(GF(q)) the additive group of points on the elliptic curve E / GF(q).
E(GF(q))[n] the subgroup of E(GF(q)) consisting of all points of order n.
#E(GF(q)) the number of points of an elliptic curve defined over the field GF(q).
4.2 Abbreviated terms
ciphertext, an octet string.
CT
DEM data encapsulation mechanism.
IBE identity-based encryption.
IBhE identity-based hybrid encryption.
octet string uniquely assigned to a decryptor.
ID
binary representation of ID.
ID
b
session key for DEM.
K
κ security parameter.
© ISO/IEC 2015 – All rights reserved 3

KEM key encapsulation mechanism.
label, an octet string.
L
master-public key of IBE.
mpk
plaintext, an octet string.
Msg
binary representation of Msg.
Msg
b
master-secret key of IBE.
msk
parms system parameters of IBE.
PKG private key generator.
private key corresponding to ID of IBE.
sk
ID
4.3 Conversion functions
The following conversion functions are given in ISO/IEC 18033-2.
bit string to integer conversion primitive.
BS2IP
bit string to octet string conversion primitive.
BS2OSP
elliptic curve to octet string conversion primitive.
EC2OSP
field element to octet string conversion primitive.
FE2OSP
field element to integer conversion primitive.
FE2IP
integer to bit string conversion primitive.
IB2 SP
integer to octet string conversion primitive.
IO2 SP
octet string to elliptic curve conversion primitive.
OS2ECP
octet string to field element conversion primitive.
OS2FEP
octet string to integer conversion primitive.
OS2IP
octet string to bit string conversion primitive.
OS2BSP
the octet whose integer value is m.
Octm
()
the number of octets of an integer n.
Lenn
()
4 © ISO/IEC 2015 – All rights reserved

5 Cryptographic transforms
5.1 General
The schemes specified in this part of ISO/IEC 18033 make use of three cryptographic transformations,
IHF1, SHF1 and PHF1 as specified below. These transformations make use of hash-functions specified in
ISO/IEC 10118-3.
5.2 The function IHF1
IHF1 is based on four hash-functions specified in ISO/IEC 10118-3, namely SHA-224, SHA-256, SHA-384
and SHA-512. It inputs a string of bits and outputs an integer in a specified range.
Input:
*
— A string str∈ 01,
{}
— A security parameter κ∈ 112,,128 192,256
{}
4κ
— An integer n, 02< Output:
— An integer νν,.0≤< n
Operation: Perform the following steps.
a) If κ =112 then let H be SHA-224;
else if κ =128 then let H be SHA-256;
else if κ =192 then let H be SHA-384;
else if κ =256 then let H be SHA-512.
b) Let h be an all-zero bit string of length 2κ .
c) Let th= ||str.
d) Let hH= t .
()
e) Let vB= SI2 Ph .
()
f) Let th= ||str.
g) Let hH= t .
()
h) Let aB= SI2 Ph .
()
2κ
i) Let νν=+2 a .
2 12
j) Output ν mod n.
5.3 The function SHF1
Returns an n -bit string that is based on a cryptographic hash function applied to an input string.
Input:
*
— A string str∈ 01,
{}
© ISO/IEC 2015 – All rights reserved 5

— A security parameter κ∈ 112,,128 192,256
{}
— An integer n,n> 0
Assumptions: The string str is within the allowed range of values for inputs to the relevant hash
function. The integer n has the property that n≤4κ .
Output:
n
— A string ν∈ 01,
{}
Operation: Use the following steps.
n
— Output IB21SP IHFs(,tr 2 ,)κ .
()
5.4 The function PHF1
Returns an element of an elliptic curve group EGFq p for a supersingular elliptic curve
()() []
23 23
EG/(Fq): yx=+b or EG/(Fq): yx=+ax. There are other types of pairing-friendly elliptic
curves for which PHF1 is not suitable.
Input:
*
— A string str∈ 01,
{}
— A security parameter κ∈ 112,,128 192,256
{}
— A flag j taking the values 0 or 1 which defines a supersingular elliptic curve, with j= 0 representing
the elliptic curve EG/(Fq): yx=+b and j= 1 representing the elliptic curve
EG/(Fq): yx=+ax.
— A prime q with q=23(mod ) when j= 0 or q=34(mod ) when j= 1 that defines the finite field GF()q .
— An integer aa,0< — A prime p with pE|# ((GF q)) and p ∤#(EGFq()) for elliptic curve E defined by the flag j
Output:
— An element of EGFq p for the selected elliptic curve.
()() []
Operation: Use the following steps.
a) Let rq=+()1 /.p
b) If j= 0 then perform the following steps:
1) Let yI= HF1(strq,,κ).
22()q−13/
2) Let xy=−()bq(mod ).
3) Let Jx=(, y).
c) Else if j= 1 perform the following steps:
1) Let xI= HF1(strq,,κ).
2) Let zx=+ax(modq).
6 © ISO/IEC 2015 – All rights reserved

3) If the Jacobi symbol (/zq)=+1 then perform the following steps:
()q+14/
i) Let yz= (mod q).
ii) Let Jx=(, y).
4) If the Jacobi symbol (/zq)=−1 then perform the following steps:
()q+14/
i) Let yz=−() (modq).
ii) Let Jx=−(, y).
d) Return rJ.
6 General model for identity-based encryption
6.1 Composition of algorithms
An identity-based encryption scheme consists of the following four algorithms.
IBES.etup κ Given a security parameter κ, generate a tuple parmsm,,pk msk , where parms denotes
()
system parameters, msk denotes a master-secret key and mpk is the corresponding master-public key.
IBEE.,xtract parmsmpk,,mskID . Given a master-secret key msk, the corresponding master-public
()
key mpk and an octet string ID with parms, generate a private key sk for ID.
ID
IBEE.,nc parmsmpk,,ID LM,.sg Given a plaintext Msg, a label L and an octet string ID with parms
()
and mpk, do the encryption and output the ciphertext of Msg, CT, for ID. Note that Msg, L and CT
are octet strings.
IBED.,ec parmsmpk,,ID sk ,,LCT . Given a private key sk with parms, mpk, ID and L, decrypt a
()
ID ID
ciphertext CT and output the underlying plaintext.
In general, the setup, key extraction and encryption algorithms are probabilistic algorithms, while the
decryption algorithm is deterministic. It is recommended that applications establish a methodology for
authenticating access to private keys by using the ID string as an identity in a trusted authentication
system. The details of authenticating the key request are beyond the scope of this part of ISO/IEC 18033,
but are critical for the security of an implemented application.
[4]
NOTE 1 Semantic security against an adaptive chosen ciphertext attack is regarded by the cryptographic
research community as the appropriate security level that a general purpose IBE mechanism should satisfy. Each
IBE mechanism described in this part of ISO/IEC 18033 satisfies this security level. The formal definition of this
security notion is described in Annex B.
NOTE 2 A basic requirement of any IBE mechanism is correctness. For any ID/sk pair and for any plaintext
ID
of defined length, the ciphertext of ID under a master-public key and system parameters ID should be able to be
decrypted with the private key sk under the master-public key and the system parameters ID to the original
ID
plaintext. This requirement may be relaxed, so that it holds only for all but a negligible fraction of ID/sk pairs.
ID
6.2 Plaintext length
Three types of plaintext length of IBE are defined as follows.
— An arbitrary-plaintext-length IBE encrypts plaintexts of an arbitrary length.
— A fixed-plaintext-length IBE only encrypts plaintexts whose length (in octets) is equal to a fixed
value IBEM.sgLen
© ISO/IEC 2015 – All rights reserved 7

— A bounded-plaintext-length IBE only encrypts plaintexts whose length (in octets) is less than or
equal to a fixed value IBEM.axMsgLen mpk Here, the maximum plaintext length may depend on
()
the system parameter mpk .
6.3 Use of labels
A label is an octet string whose value is used by the encryption and decryption algorithms. It may
contain public data that is implicit from context and need not be encrypted, but that should nevertheless
be bound to the ciphertext. A label is an octet string that is meaningful to the application using the IBE
scheme, and that is independent of the implementation of the IBE scheme. Three types of label length of
IBE are defined as follows.
— An arbitrary-label-length IBE is one in which the encryption and decryption algorithms accept
labels of arbitrary length.
— A fixed-label-length IBE is one in which the encryption and decryption algorithms only accept labels
whose length (in octets) is equal to a fixed value IBEL.abelLen
— A bounded-label-length IBE is one in which the encryption and decryption algorithms only accept
labels whose length (in octets) is less than or equal to a fixed value IBEM.axLabelLen
NOTE The traditional notion of security against an adaptive chosen ciphertext attack has been extended in
Annex B, so that intuitively, for a secure IBE mechanism, the encryption algorithm should bind the label to the
ciphertext in an appropriate “non-malleable” fashion.
6.4 Ciphertext format
This part of ISO/IEC 18033 describes ciphertext formats in an octet string; however, an implementation
is free to store and/or transmit ciphertexts in alternative formats, if it is required. Moreover, ciphertexts
in the format prescribed here may not necessarily appear in the encryption or decryption process,
since converting the format into an alternative format may be collapsed into a single, functionally
equivalent process.
NOTE Besides promoting interoperability, prescribing the format of a ciphertext is necessary in order to
make meaningful claims and to reason about the security of an IBE against adaptive chosen ciphertext attacks.
6.5 IBE operation
In an IBE setup, a trusted third party generates a master-secret key, the corresponding master-public
key and system parameters by invoking the IBES. etup algorithm and makes the master-public key and
the system parameters public, keeping the master-secret key private. When a decryptor requests the
private key, a private key issuer invokes the IBEE. xtract algorithm and issues its output to the
decryptor as the private key via a secure channel. An encryptor computes a ciphertext by running the
IBEE. nc algorithm with the decryptor’s identity string. The decryptor derives the underlying plaintext
from the received ciphertext by running IBED. ec with the private key.
The following mechanisms and protocols are outside of the scope of this part of ISO/IEC 18033. One can
refer to ISO/IEC 11770 for designing key management operation.
— protocol for making a master-public key and system parameters available.
— protocol for distributing private keys to decryptors.
— protocol for making an identity string available to encryptors.
— mechanism for storing a master-secret key or a private key securely.
— mechanism for confirming a link between a master-public key or system parameters and its issuer.
8 © ISO/IEC 2015 – All rights reserved

Each of the IBE mechanisms specified in this part of ISO/IEC 18033 are actually members of families
of IBE mechanisms, where a particular IBE is selected from the family by choosing particular values
for the system parameters defining the family of IBE mechanisms. For an IBE mechanism selected
from a family of mechanisms, prior to master-secret key/master-public key pair generation, specific
values of the system parameters for the family should be chosen. Depending on the conventions used
for encoding master-public keys, some of the choices of the system parameters may be embedded in the
encoding of the master-public key as well. These system parameters shall remain fixed throughout the
lifetime of the master-public key.
NOTE For example, if an IBE mechanism is parameterized in terms of a cryptographic hash function, the
choice of hash function should be fixed once and for all at some point prior to the generation of a master-secret
key/master-public key pair, and the encryption and decryption algorithms should use the chosen hash function
throughout the lifetime of the master-public key. Failure to abide by this rule not only makes an implementation
non-conforming, but also invalidates the security analysis for the mechanism, and can in some cases expose the
implementation to severe security risks.
7 General model for identity-based hybrid encryption
7.1 General
An identity-based hybrid encryption scheme is used for encrypting a large plaintext making use of the
advantages of the identity-based encryption scheme, where an IBE is utilized to encrypt a decryption
key for encrypting the actual message using symmetric cryptographic techniques. An identity-based
hybrid encryption scheme is built from two lower-level “building blocks”: an identity-based key
encapsulation scheme and a data encapsulation scheme.
7.2 Identity-based key encapsulation
7.2.1 Composition of algorithms
An identity-based key encapsulation scheme consists of the following four algorithms.
KEMS.etup κ Given a security parameter κ, generate a tuple parmsm,,pk msk , where parms
()
denotes system parameters, msk denotes a master-secret key and mpk is the corresponding
master-public key.
KEME.,xtract parmsmpk,,mskID . Given a master-secret key msk, the corresponding master-public
()
key mpk, and an octet string ID with parms, generate a private key sk for ID.
ID
KEME.,nc parmsmpk,.ID Given an octet string ID with parms and mpk, output an octet string K
()
and the ciphertext of K, CT , for ID. Note that CT is an octet string.
KEM KEM
KEMD.,ec parmsmpk,,ID sk ,.CT Given a private key sk with parms, mpk and ID, decrypt a
()
ID KEM ID
ciphertext CT and output the underlying octet string.
KEM
In the general setup, key extraction and encapsulation algorithms are probabilistic algorithms, while
the de-encapsulation algorithm is deterministic. The de-encapsulation algorithm may fail under some
circumstances with a negligible probability. A key encapsulation scheme also specifies a positive integer
KEMK. eyLen — the length of the secret key output by KEME. nc and KEMD.ec
NOTE 1 The required security level that each key encapsulation mechanism should satisfy is described in
Annex B.
© ISO/IEC 2015 – All rights reserved 9

NOTE 2 Any key encapsulation mechanism should satisfy a correctness property analogous to the correctness
property of an IBE mechanism: for any ID /sk pair and for any octet string K whose length is within its
ID
implementation-defined limits, any encapsulation of K with predetermined system parameters under an ID
decrypts with the system parameters under the ID to the original K . This requirement may be relaxed so that
it holds only for all but a negligible fraction of ID /sk pairs.
ID
7.2.2 Prefix-freeness
Additionally, a key encapsulation mechanism shall satisfy the following property. The set of all possible
ciphertext outputs of the encryption algorithm should be a subset of a candidate set of octet strings
(that may depend on the public key), such that the candidate set is prefix free and elements of the
candidate set are easy to recognize (given either the public key or the private key).
7.3 Data encapsulation
7.3.1 Composition of algorithms
A data encapsulation scheme consists of the following two algorithms.
a) DEME.,nc KL,.Msg Given octet strings K and L, compute the encryption of Msg, CT . Note
()
DEM
that Msg and CT are octet strings, and L and Msg may have length as described in 6.3 and 6.2
DEM
respectively. The bit length of K is DEMK.eyLen
b) DEMD.,ec KL,.CT Given octet strings K and L, decrypt a ciphertext CT and output the
()
DEM DEM
underlying plaintext.
The encryption algorithm may fail if the lengths L or Msg exceed some (very large) implementation-
defined limits. The decryption algorithm may fail under some circumstances with a negligible probability.
The allowable data encapsulation mechanisms are the symmetric encryption mechanisms described in
ISO/IEC 18033-3.
NOTE The encryption and decryption algorithms should be deterministic, and should satisfy the following
correctness requirement: for all session keys K, all labels L, and all plaintexts Msg, such that the lengths of L
and Msg do not exceed the implementation-defined limits, and
c) DEMD.,ec KL,.DEMEnc KL,, MsgM= sg.
()()
7.4 Identity-based hybrid encryption operation
7.4.1 System parameters
An identity-based hybrid encryption scheme (for short, IBhE) is a family of IBE schemes parameterized
by the following system parameters:
— KEM: an identity-based key encapsulation scheme, as described in 7.2.
— DEM: a data encapsulation scheme, as described in 7.3.
Any combination of KEM and DEM may be used, provided KEMK.eyLenD= EMKeyLen.
NOTE 1 If DEM is instantiated by a fixed-label-length data encapsulation mechanism, with labels restricted to
length DEML. abelLen,then IBhE is a fixed-label-length identity-based encryption mechanism with
IBhE.LabelLen=DEMLabelLen.
NOTE 2 If DEM is instantiated by a fixed-plaintext-length data encapsulation mechanism, with plaintexts
restricted to length DEMM. sgLen,then IBhE is a fixed-plaintext-length identity-based encryption mechanism
with IBhE.MsgLen=DEMMsgLen.
10 © ISO/IEC 2015 – All rights reserved

NOTE 3 For all the allowable choices of KEM, the value of KEMK. eyLen is a system parameter that may be
chosen so as to equal DEMK.eyLen Thus, all possible combinations of allowable KEM and DEM may be realized
by appropriate choices of system parameters.
7.4.2 Set up
The set up algorithm for IBhE is the same as that of the underlying KEM. Let parms denote system
parameters and mskm, pk denote a master-secret key/master public-key pair.
7.4.3 Private key extraction
The private key extraction algorithm for IBhE is the same as that of the underlying KEM. Let sk
ID
denote a private key of ID.
7.4.4 Encryption
The encryption algorithm IBhE.Enc takes as input a master-public key mpk, a label L and a plaintext
Msg with system parameters parms . It runs as follows.
a) Compute KC,.TK= EMEncparms,,mpkID .
()
KEM
b) Compute CT =DEME.,nc KL,.Msg
()
DEM
c) Set CT=CT ||CT .
KEMDEM
d) Output CT .
7.4.5 Decryption
The decryption algorithm IBhE.Dec takes as input a private key sk , an octet string ID, a label L, and
ID
a ciphertext CT with system parameters parms . It runs as follows.
a) Using the prefix-freeness property of the ciphertexts associated with KEM, parse CT as
CT=CT ||CT , where CT and CT are octet strings such that CT is an element of
KEMDEM KEM DEM KEM
the candidate set of possible ciphertexts associated with KEM. This step fails if CT cannot be parsed.
b) Compute KK= EM.,Decparms mpkI,,DskC,.T
()
ID KEM
c) Compute MsgD= EM.,DecK LC,.T
()
DEM
d) Output Msg.
NOTE The security of IBhE is discussed in Annex B. It is only remarked here that as long as KEM and DEM
satisfy the appropriate security properties, then IBhE will be secure against adaptive chosen ciphertext attack.
8 Identity-based encryption mechanism
8.1 General
In this clause an identity-based encryption mechanism is specified. This mechanism is specified to use
the following primitives. The hash function H is used for supersingular curves but some other
(possibly similar) scheme of hashing a string to a point is required for other curves.
© ISO/IEC 2015 – All rights reserved 11

Take a security parameter κ, and a key size parameter δ, the mechanism requires the following
algorithms:
a) A random bit generation algorithm [1]:
δ
— R : a source of random values in the space {,01}.
b) Four hash functions:
*
— HG:{01,} → where Hs()=PHFs1(,κ,,jq,,cp) with j= 0 representing the elliptic curve
11 1
23 23
EG/(Fq): yx=+c and j= 1 representing the elliptic curve EG/(Fq): yx=+cx and p i
...