ISO/IEC 18033-2:2006/Amd 2:2026

Technologies de l'information — Techniques de sécurité — Algorithmes de chiffrement — Partie 2: Chiffres asymétriques — Amendement 2

General Information

• Status: Published
• Publication Date: 04-Jun-2026
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Current Stage: 6060 - International Standard published
• Start Date: 05-Jun-2026
• Due Date: 04-May-2026
• Completion Date: 05-Jun-2026

Relations

• Amends: ISO/IEC 18033-2:2006 - Information technology — Security techniques — Encryption algorithms — Part 2: Asymmetric ciphers
• Effective Date: 06-May-2023

Overview

ISO/IEC 18033-2:2006/Amd 2:2026 is an amendment to the international standard for information technology security techniques, with a focus on encryption algorithms. Specifically, this amendment addresses asymmetric ciphers, incorporating recent cryptographic advancements and updating normative references. A major feature of this amendment is the integration of additional key encapsulation mechanisms (KEMs), most notably the Classic McEliece KEM, relevant for post-quantum cryptography.

This standard is maintained by the joint technical committee ISO/IEC JTC 1, subcommittee SC 27, which specializes in information security, cybersecurity, and privacy protection.

Key Topics

• Asymmetric Ciphers: Emphasizes updates to the selection and definitions of public-key encryption and key encapsulation algorithms.
• Classic McEliece KEM: Introduces detailed algorithms, parameter sets, and representations tailored to enhance security against potential quantum computing threats.
• Hybrid Ciphers: Expands the list of generic hybrid ciphers to include mechanisms like ECIES-KEM, RSA-KEM, FrodoKEM, ML-KEM, and more.
• Updated Normative References:
  • Replaces earlier references with ISO/IEC 10118-3:2018 (hash functions) and ISO/IEC 18033-3:2010 (block ciphers).
• Key Generation, Encapsulation, and Decapsulation: Specifies standardized methods for creating secure key pairs and performing cryptographic encapsulation and decapsulation, with clear rules for parameter selection and compliance.
• Parameter Set Definitions: Provides formal guidance for parameter set selection, underpinning the security and interoperability of cryptographic implementations.

Applications

Cybersecurity and Data Protection

Organizations implementing secure communications highly benefit from the adoption and compliance with ISO/IEC 18033-2 amendment 2. The inclusion of post-quantum algorithms such as Classic McEliece KEM ensures future-proof encryption, safeguarding both data in transit and at rest against emerging threats.

Typical application areas:

• Data encryption for cloud services
• Secure email and messaging systems
• Virtual private networks (VPNs)
• Secure digital signatures and authentication systems

Post-Quantum Cryptography

As quantum computing evolves, standardized cryptographic techniques must adapt. The newly implemented Classic McEliece KEM is designed for robust resistance to quantum attacks, making this standard a critical reference for forward-looking cryptographic solutions.

Secure Product Development

Vendors and developers of security devices, operating systems, and applications can rely on the rigorously defined mathematical functions, representations, and parameter sets to ensure conformance and maximize interoperability across products adhering to global encryption standards.

Related Standards

For comprehensive implementation and consistent security across systems, ISO/IEC 18033-2:2006/Amd 2:2026 is often used alongside:

• ISO/IEC 10118-3:2018: Security techniques – Hash-functions – Part 3: Dedicated hash-functions (such as SHAKE256).
• ISO/IEC 18033-3:2010: Security techniques – Encryption algorithms – Part 3: Block ciphers.
• Other parts of ISO/IEC 18033: Providing frameworks for symmetric ciphers and additional encryption mechanisms.
• ISO/IEC 19790: Security requirements for cryptographic modules, supporting robust implementation.

Staying updated with these standards enables organizations to meet regulatory requirements, maintain security best practices, and ensure their cryptographic solutions are resistant to both current and future cyber threats.

Standards Content (Sample)

International
Standard
ISO/IEC 18033-2
First edition
Information technology —
2006-05-01
Security techniques — Encryption
algorithms —
AMENDMENT 2
2026-06
Part 2:
Asymmetric ciphers
AMENDMENT 2
Technologies de l'information — Techniques de sécurité —
Algorithmes de chiffrement —
Partie 2: Chiffres asymétriques
AMENDEMENT 2
Reference number
ISO/IEC 18033-2:2006/Amd. 2:2026(en) © ISO/IEC 2026

ISO/IEC 18033-2:2006/Amd. 2:2026(en)
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
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.
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 or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use
of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of 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
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
A list of all parts in the ISO/IEC 18033 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2026 – All rights reserved
iii
ISO/IEC 18033-2:2006/Amd. 2:2026(en)

Information technology — Security techniques — Encryption
algorithms —
Part 2:
Asymmetric ciphers
AMENDMENT 2
Replace text in the following clause:
Clause 2  Normative references
Replace
ISO/IEC 10118-3:2004, IT Security techniques — Hash-functions — Part 3: Dedicated hash-functions
with
ISO/IEC 10118-3:2018, IT Security techniques — Hash-functions — Part 3: Dedicated hash-functions
Replace
ISO/IEC 18033-3:2005, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
with
ISO/IEC 18033-3:2010, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
Clause 8  Generic hybrid ciphers
Replace the first four bullet points in 8.1.2 with the following bullet points:
— ECIES-KEM (described in 10.2),
— PSEC-KEM (described in 10.3),
— ACE-KEM (described in 10.4),
— FACE-KEM (described in 10.5),
— RSA-KEM (described in 11.5),
— Classic McEliece KEM (described in Clause 13),
— FrodoKEM (described in Clause 14), and
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
— ML-KEM (described in Clause 15).
After Clause 12
Add the following new clauses after Clause 12:
13  The Classic McEliece KEM
13.1  General
This clause defines the Classic McEliece KEM. This KEM consists of three mathematical functions, namely
CM.KeyGen, CM.Encap, and CM.Decap, for each of the “selected parameter sets” listed in 13.16. CM.Encrypt is
a synonym for CM.Encap, and CM.Decrypt is a synonym for CM.Decap.
A broader parameter space for Classic McEliece is specified in 13.3. For each parameter set in that parameter
space, subsequent subclauses define
— exactly which public key and private key are output by CM.KeyGen given random bits;
— exactly which ciphertext and session key are output by CM.Encap given a public key and random bits;
and
— exactly which session key is output by CM.Decap given a ciphertext and a private key.
These subclauses define each mathematical function 𝐹𝐹 by presenting an algorithm to compute 𝐹𝐹. Basic
algorithms such as Gaussian elimination are not repeated here, but CM.MatGen, CM.Encode, CM.Decode,
CM.Irreducible , CM.FieldOrdering , CM.SeededKeyGen , CM.FixedWeight , CM.KeyGen , CM.Encap, and
CM.Decap are specified as numbered lists of steps. See Annex D for a reference to a guide for implementors.
Stating that an algorithm 𝐴𝐴 computes a mathematical function 𝐹𝐹 means the following: the domain of 𝐹𝐹 is the
set of pairs (𝐼𝐼,𝑅𝑅) such that 𝐼𝐼 is the input consumed by a run of 𝐴𝐴 and 𝑅𝑅 is the string of random bits generated
by that run of 𝐴𝐴; 𝐹𝐹(𝐼𝐼,𝑅𝑅) is the output of that run of 𝐴𝐴, or the symbol ∞ if that run of 𝐴𝐴 does not halt.
EXAMPLE 1  The CM.KeyGen algorithm reads exactly ℓ random bits, so the domain of the mathematical function
CM.KeyGen is the set of ℓ-bit strings. Here ℓ, one of the Classic McEliece parameters, is 256 for each of the
selected parameter sets.
EXAMPLE 2  The algorithm CM.FixedWeight is a rejection-sampling algorithm, and the number of random bits it
( )
uses can vary from one run of the algorithm to another. The pairs 𝐼𝐼,𝑅𝑅 in the domain of the function computed
by this algorithm have exactly the same variations in the lengths of 𝑅𝑅. The algorithm halts with probability 1 for
independent uniformly distributed random bits. In the non-halting cases, 𝑅𝑅 has infinite length.
NOTE 1  If an algorithm 𝐴𝐴 is deterministic, i.e., does not consume random bits, then the string 𝑅𝑅 of random bits
generated by a run of 𝐴𝐴 is the empty string.
NOTE 2  Any change in the observed behaviour of an algorithm, where the observations consist of the input, the
random bits used, and the output, is a change in the mathematical function computed by the algorithm. For
example, if algorithms 𝐴𝐴 and 𝐵𝐵 are almost identical but 𝐵𝐵 generates and discards some extra bits beyond what 𝐴𝐴
uses, then the string of random bits used is longer for 𝐵𝐵 than for 𝐴𝐴, so 𝐴𝐴 and 𝐵𝐵 are not computing the same
mathematical function.
Clause 13 consistently uses indices numbered from 0, including row indices, column indices, and 𝛼𝛼 indices.
NOTE 3  Conventions in the mathematical literature sometimes number indices from 0, but sometimes do not:
for example, polynomial exponents are conventionally numbered from 0, while most vectors not related to
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
polynomial exponents are conventionally numbered from 1.
Throughout Clause 13, 𝔽𝔽 means a finite field with 𝑟𝑟 elements, where 𝑟𝑟 is a power of 2.
𝑟𝑟
𝑛𝑛
Elements of 𝔽𝔽 , such as codewords and error vectors, are treated as column vectors.
NOTE 4  This convention avoids all transpositions. This differs from a common convention in coding theory,
namely to write codewords as row vectors but to transpose the codewords for applying parity checks.
13.2  Requirements
To claim conformance to this document regarding Classic McEliece, an algorithm shall (1) name either
CM.KeyGen or CM.Encap or CM.Decap; (2) identify a parameter set listed in 13.16 (not another parameter set
from 13.3); and (3) compute exactly the corresponding mathematical function defined in this document for
that parameter set.
For example, a CM.KeyGen implementation claimed to conform to this document for the mceliece6960119
parameter set shall compute the specified CM.KeyGen function for that parameter set: i.e., the
implementation shall read exactly ℓ = 256 bits of randomness, and shall produce the same output that the
CM.KeyGen algorithm specified below produces given the same 256-bit string.
Conformance to this document for a tuple of three Classic McEliece algorithms, one for each of CM.KeyGen
and CM.Encap and CM.Decap, is defined as conformance to this document for each algorithm, and again shall
identify a parameter set listed in 13.16.
Conformant implementations shall use the encodings specified in Clause 13.
NOTE 1  Clause 13 does not allow the format flexibility described in 7.3.

NOTE 2  Users sometimes place further constraints on algorithms, for example to include various side-channel

countermeasures (which could use their own random bits) or to achieve particular levels of performance. Such
constraints are out of scope here. Clause 13 defines the mathematical functions to be computed; it does not
constrain how these functions are computed.
13.3  Parameters
The CM parameters are implicit inputs to the CM algorithms defined below. A CM parameter set specifies the
following:
𝑚𝑚
— A positive integer 𝑚𝑚. This also defines a parameter 𝑞𝑞 = 2 .
— A positive integer 𝑛𝑛 with 𝑛𝑛≤𝑞𝑞.
— A positive integer 𝑡𝑡≥ 2 with 𝑚𝑚𝑡𝑡 <𝑛𝑛. This also defines a parameter 𝑘𝑘 =𝑛𝑛−𝑚𝑚𝑡𝑡.
— A monic irreducible polynomial 𝑓𝑓(𝑧𝑧)∈𝔽𝔽 [𝑧𝑧] of degree 𝑚𝑚. This defines a representation 𝔽𝔽 [𝑧𝑧]/𝑓𝑓(𝑧𝑧) of
2 2
the field 𝔽𝔽 .
𝑞𝑞
— A monic irreducible polynomial 𝐹𝐹(𝑦𝑦)∈𝔽𝔽 [𝑦𝑦] of degree 𝑡𝑡. This defines a representation 𝔽𝔽 [𝑦𝑦]/𝐹𝐹(𝑦𝑦) of
𝑞𝑞 𝑞𝑞
the field 𝔽𝔽 𝑡𝑡 =𝔽𝔽 𝑚𝑚𝑡𝑡.
𝑞𝑞 2
— Integers 𝜈𝜈≥𝜇𝜇≥ 0 with 𝜈𝜈≤𝑘𝑘 +𝜇𝜇. Parameter sets that do not mention these parameters define them as
(0,0) by default.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
— The symmetric-cryptography parameters, which are the following:
— A positive integer ℓ.
— A cryptographic hash function Hash that outputs ℓ bits.
— An integer 𝜎𝜎 ≥𝑚𝑚.
— An integer 𝜎𝜎 ≥ 2𝑚𝑚.
— A pseudorandom bit generator PRG mapping a string of ℓ bits to a string of 𝑛𝑛 +𝜎𝜎𝑞𝑞 +𝜎𝜎𝑡𝑡 +ℓ bits.
2 1
— Each parameter set is also labeled as either a pc parameter set or a non-pc parameter set.
NOTE  pc is also referred to in the literature as "plaintext confirmation".
13.4  Matrix reduction
13.4.1  Reduced row-echelon form
Saying that a matrix 𝑅𝑅 is in “reduced row-echelon form” means that there is a sequence of column indices
𝑐𝑐 <𝑐𝑐 <⋯ <𝑐𝑐 such that:
0 1 𝑟𝑟−1
— row 0 of 𝑅𝑅 begins with a 1 in column 𝑐𝑐 , and this is the only nonzero entry in column 𝑐𝑐 ;
0 0
— row 1 of 𝑅𝑅 begins with a 1 in column 𝑐𝑐 , the only nonzero entry in column 𝑐𝑐 ;
1 1
— row 2 of 𝑅𝑅 begins with a 1 in column 𝑐𝑐 , the only nonzero entry in column 𝑐𝑐 ;
2 2
— etc;
— row 𝑟𝑟− 1 of 𝑅𝑅 begins with a 1 in column 𝑐𝑐 , the only nonzero entry in column 𝑐𝑐 ; and
𝑟𝑟−1 𝑟𝑟−1
— all subsequent rows of 𝑅𝑅 are 0.
NOTE 1  The rank of 𝑅𝑅 is 𝑟𝑟.
NOTE 2  Gaussian elimination is a well-known algorithm that, given a matrix 𝑋𝑋, computes the unique matrix 𝑅𝑅 in
reduced row-echelon form having the same number of rows as 𝑋𝑋 and the same row space as 𝑋𝑋.
13.4.2  Systematic form
As a special case of reduced row-echelon form, saying that a matrix 𝑅𝑅 is in “systematic form” means that
— 𝑅𝑅 has exactly 𝑟𝑟 rows, i.e., there are no zero rows; and
— 𝑐𝑐 =𝑖𝑖 for 0≤𝑖𝑖 <𝑟𝑟.
𝑖𝑖
NOTE 1  The second condition is equivalent to saying 𝑐𝑐 =𝑟𝑟− 1, except in the degenerate case 𝑟𝑟 = 0.
𝑟𝑟−1
NOTE 2  𝑅𝑅 is in systematic form if and only if 𝑅𝑅 has the form (𝐼𝐼 |𝑇𝑇), where 𝐼𝐼 is an 𝑟𝑟 ×𝑟𝑟 identity matrix.
𝑟𝑟 𝑟𝑟
“Row-reducing a matrix 𝑋𝑋 to systematic form” means computing the unique systematic-form matrix having
the same row space as 𝑋𝑋, if such a matrix exists.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
See Annex D for a reference to a guide for implementors.
13.4.3  Semi-systematic form
The following generalization of the concept of systematic form uses two integer parameters 𝜇𝜇,𝜈𝜈 satisfying
𝜈𝜈≥𝜇𝜇≥ 0.
Let 𝑅𝑅 be a rank-𝑟𝑟 matrix in reduced row-echelon form. Assume that 𝑟𝑟≥𝜇𝜇, and that there are at least 𝑟𝑟−𝜇𝜇 +𝜈𝜈
columns.
( )
We say that 𝑅𝑅 is in “𝜇𝜇,𝜈𝜈 -semi-systematic form” if 𝑅𝑅 has 𝑟𝑟 rows (i.e. no zero rows); 𝑐𝑐 =𝑖𝑖 for 0≤𝑖𝑖 <𝑟𝑟−𝜇𝜇;
𝑖𝑖
and 𝑐𝑐 ≤𝑖𝑖−𝜇𝜇 +𝜈𝜈 for 0≤𝑖𝑖 <𝑟𝑟.
𝑖𝑖
NOTE 1  The 𝑐𝑐 conditions are equivalent to 𝑐𝑐 =𝑟𝑟−𝜇𝜇− 1 and 𝑐𝑐 ≤𝑟𝑟−𝜇𝜇 +𝜈𝜈− 1 except in the

𝑖𝑖 𝑟𝑟−𝜇𝜇−1 𝑟𝑟−1
degenerate case 𝑟𝑟 =𝜇𝜇.
( )
NOTE 2  As a special case, 𝜇𝜇,𝜈𝜈 -semi-systematic form is equivalent to systematic form if 𝜇𝜇 =𝜈𝜈. However, if

( )
𝜈𝜈 >𝜇𝜇 > 0 then 𝜇𝜇,𝜈𝜈 -semi-systematic form allows more matrices than systematic form.
( ) ( )
“Row-reducing a matrix 𝑋𝑋 to 𝜇𝜇,𝜈𝜈 -semi-systematic form” means computing the unique 𝜇𝜇,𝜈𝜈 -semi-
systematic-form matrix having the same row space as 𝑋𝑋, if such a matrix exists.
This specification gives various definitions first for the simpler case (𝜇𝜇,𝜈𝜈) = (0,0) and then for the general
case. The list of selected parameter sets provides, for each key size, one parameter set with (𝜇𝜇,𝜈𝜈) = (0,0),
and one parameter set labeled “f” with (𝜇𝜇,𝜈𝜈) = (32,64).
See Annex D for a guide for implementors.
13.5  Matrix generation for Goppa codes
13.5.1  General
( )
The following algorithm CM.MatGen takes as input 𝛤𝛤 = 𝑔𝑔,𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 where
0 1 𝑛𝑛−1
[ ]
— 𝑔𝑔 is a monic irreducible polynomial in 𝔽𝔽 𝑥𝑥 of degree 𝑡𝑡 and
𝑞𝑞
— 𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 are distinct elements of 𝔽𝔽 .
0 1 𝑛𝑛−1 𝑞𝑞
The output CM.MatGen(𝛤𝛤) is defined first in the simpler case of systematic form, and then in the general case
( ) ( )
of semi-systematic form. The output is either ⊥ or a 𝜇𝜇 + 2 -tuple 𝑇𝑇, … , where 𝑇𝑇 is the CM public key, an
𝑚𝑚𝑡𝑡 ×𝑘𝑘 matrix over 𝔽𝔽 .
13.5.2  Systematic form
( ) ( ) ( ) ( )
For 𝜇𝜇,𝜈𝜈 = 0,0 , the output CM.MatGen𝛤𝛤 is either ⊥ or of the form 𝑇𝑇,𝛤𝛤 , where 𝑇𝑇 is an 𝑚𝑚𝑡𝑡 ×𝑘𝑘 matrix
. The algorithm is as follows:
over 𝔽𝔽
𝑖𝑖
1. Compute the 𝑡𝑡 ×𝑛𝑛 matrix 𝑀𝑀 =�ℎ � over 𝔽𝔽 , where ℎ =𝛼𝛼 /𝑔𝑔�𝛼𝛼� for 𝑖𝑖 = 0, … ,𝑡𝑡− 1 and 𝑗𝑗 = 0, … ,𝑛𝑛− 1.
𝑖𝑖,𝑗𝑗 𝑞𝑞 𝑖𝑖,𝑗𝑗 𝑗𝑗 𝑗𝑗
𝑚𝑚−1
2. Form an 𝑚𝑚𝑡𝑡 ×𝑛𝑛 matrix 𝑁𝑁 over 𝔽𝔽 by replacing each entry 𝑢𝑢 +𝑢𝑢𝑧𝑧 +⋯ +𝑢𝑢 𝑧𝑧 of 𝑀𝑀 with a column
2 0 1 𝑚𝑚−1
of 𝑚𝑚 bits 𝑢𝑢 ,𝑢𝑢 , … ,𝑢𝑢 .
0 1 𝑚𝑚−1
3. Row-reduce 𝑁𝑁 to systematic form (𝐼𝐼 |𝑇𝑇), where 𝐼𝐼 is the 𝑚𝑚𝑡𝑡 ×𝑚𝑚𝑡𝑡 identity matrix over 𝔽𝔽 . If this fails,
𝑚𝑚𝑚𝑚 𝑚𝑚𝑚𝑚 2
return ⊥.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
4. Return (𝑇𝑇,𝛤𝛤).
13.5.3  Semi-systematic form
For general (𝜇𝜇,𝜈𝜈), the output CM.MatGen(𝛤𝛤) is either ⊥ or a (𝜇𝜇 + 2)-tuple of the form
′
, … ,𝑐𝑐 ,𝛤𝛤�, where
�𝑇𝑇,𝑐𝑐
𝑚𝑚𝑚𝑚−𝜇𝜇 𝑚𝑚𝑚𝑚−1
— 𝑇𝑇 is an 𝑚𝑚𝑡𝑡 ×𝑘𝑘 matrix over 𝔽𝔽 ;
— 𝑐𝑐 , … ,𝑐𝑐 are integers with 𝑚𝑚𝑡𝑡−𝜇𝜇≤𝑐𝑐 <𝑐𝑐 <⋯ <𝑐𝑐 <𝑚𝑚𝑡𝑡−𝜇𝜇 +𝜈𝜈;
𝑚𝑚𝑚𝑚−𝜇𝜇 𝑚𝑚𝑚𝑚−1 𝑚𝑚𝑚𝑚−𝜇𝜇 𝑚𝑚𝑚𝑚−𝜇𝜇+1 𝑚𝑚𝑚𝑚−1
′ ′ ′ ′
— 𝛤𝛤 = (𝑔𝑔,𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 );
0 1 𝑛𝑛−1
— 𝑔𝑔 is the same as in the input; and
′ ′ ′
— 𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 are distinct elements of 𝔽𝔽 .
𝑞𝑞
0 1 𝑛𝑛−1
The algorithm is as follows:
𝑖𝑖
1. Compute the 𝑡𝑡 ×𝑛𝑛 matrix 𝑀𝑀 =�ℎ � over 𝔽𝔽 , where ℎ =𝛼𝛼 /𝑔𝑔�𝛼𝛼� for 𝑖𝑖 = 0, … ,𝑡𝑡− 1 and 𝑗𝑗 = 0, … ,𝑛𝑛− 1.
𝑖𝑖,𝑗𝑗 𝑞𝑞 𝑖𝑖,𝑗𝑗 𝑗𝑗 𝑗𝑗
𝑚𝑚−1
2. Form an 𝑚𝑚𝑡𝑡 ×𝑛𝑛 matrix 𝑁𝑁 over 𝔽𝔽 by replacing each entry 𝑢𝑢 +𝑢𝑢𝑧𝑧 +⋯ +𝑢𝑢 𝑧𝑧 of 𝑀𝑀 with a column
2 0 1 𝑚𝑚−1
of 𝑚𝑚 bits 𝑢𝑢 ,𝑢𝑢 , … ,𝑢𝑢 .
0 1 𝑚𝑚−1
3. Row-reduce 𝑁𝑁 to (𝜇𝜇,𝜈𝜈)-semi-systematic form, obtaining a matrix 𝐻𝐻; if this fails, return ⊥. Define 𝑐𝑐 such
𝑖𝑖
that row 𝑖𝑖 has its leading 1 in column 𝑐𝑐 . (By definition of semi-systematic form, 𝑐𝑐 =𝑖𝑖 for 0≤𝑖𝑖 <𝑚𝑚𝑡𝑡−
𝑖𝑖 𝑖𝑖
𝜇𝜇; and 𝑚𝑚𝑡𝑡−𝜇𝜇≤𝑐𝑐 <𝑐𝑐 <⋯ <𝑐𝑐 <𝑚𝑚𝑡𝑡−𝜇𝜇 +𝜈𝜈. The matrix 𝐻𝐻 is a variable that can
𝑚𝑚𝑚𝑚−𝜇𝜇 𝑚𝑚𝑚𝑚−𝜇𝜇+1 𝑚𝑚𝑚𝑚−1
change later.)
′ ′ ′ ′
4. Set (𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 )← (𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 ). (Each 𝛼𝛼 is a variable that can change later.)
0 1 𝑛𝑛−1 0 1 𝑛𝑛−1
𝑖𝑖
5. For 𝑖𝑖 =𝑚𝑚𝑡𝑡−𝜇𝜇, then 𝑖𝑖 =𝑚𝑚𝑡𝑡−𝜇𝜇 + 1, and so on through 𝑖𝑖 =𝑚𝑚𝑡𝑡− 1, in this order: swap column 𝑖𝑖 with
′ ′
column 𝑐𝑐 in 𝐻𝐻, while swapping 𝛼𝛼 with 𝛼𝛼 . (After the swap, row 𝑖𝑖 has its leading 1 in column 𝑖𝑖. The swap
𝑖𝑖 𝑐𝑐
𝑖𝑖
𝑖𝑖
does nothing if 𝑐𝑐 =𝑖𝑖.)
𝑖𝑖
6. The matrix 𝐻𝐻 now has systematic form (𝐼𝐼 |𝑇𝑇), where 𝐼𝐼 is the 𝑚𝑚𝑡𝑡 ×𝑚𝑚𝑡𝑡 identity matrix over 𝔽𝔽 . Return
𝑚𝑚𝑚𝑚 𝑚𝑚𝑚𝑚 2
′ ′ ′
′ ′
( )
�𝑇𝑇,𝑐𝑐 , … ,𝑐𝑐 ,𝛤𝛤� where 𝛤𝛤 = 𝑔𝑔,𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 .
𝑚𝑚𝑚𝑚−𝜇𝜇 𝑚𝑚𝑚𝑚−1 0 1 𝑛𝑛−1
( ) ( )
NOTE  In the special case 𝜇𝜇,𝜈𝜈 = 0,0 , the 𝑐𝑐 , … ,𝑐𝑐 portion of the output is empty, and the 𝑖𝑖
𝑚𝑚𝑚𝑚−𝜇𝜇 𝑚𝑚𝑚𝑚−1
′
loop is empty, so 𝛤𝛤 is guaranteed to be the same as 𝛤𝛤. The reduction to (0,0)-semi-systematic form is
exactly reduction to systematic form. The general algorithm definition thus matches the (0,0) algorithm
definition.
13.6  Encoding subroutine
𝑛𝑛
The following algorithm CM.Encode takes two inputs: a column vector 𝑒𝑒∈𝔽𝔽 of Hamming weight 𝑡𝑡 and a
𝑚𝑚𝑚𝑚
public key 𝑇𝑇, i.e. an 𝑚𝑚𝑡𝑡 ×𝑘𝑘 matrix over 𝔽𝔽 . The algorithm output CM.Encode(𝑒𝑒,𝑇𝑇) is a vector 𝐶𝐶∈𝔽𝔽 . The
algorithm is as follows:
( )
1. Define 𝐻𝐻 = 𝐼𝐼 |𝑇𝑇 .
𝑚𝑚𝑚𝑚
𝑚𝑚𝑚𝑚
2. Compute and return 𝐶𝐶 =𝐻𝐻𝑒𝑒∈𝔽𝔽 .
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
13.7  Decoding subroutine
𝑚𝑚𝑚𝑚 ′
The following algorithm CM.Decode takes two inputs: a vector 𝐶𝐶∈𝔽𝔽 ; and 𝛤𝛤 , the last component of
( ) ( ) ( )
CM.MatGen𝛤𝛤 for some 𝛤𝛤 such that CM.MatGen𝛤𝛤 ≠⊥. Write 𝑇𝑇 for the first component of CM.MatGen𝛤𝛤 .
By definition of CM.MatGen,
— 𝑇𝑇 is an 𝑚𝑚𝑡𝑡 ×𝑘𝑘 matrix over 𝔽𝔽 ;
′ ′ ′ ′
— 𝛤𝛤 has the form (𝑔𝑔,𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 );
0 1 𝑛𝑛−1
— 𝑔𝑔 is a monic irreducible polynomial in 𝔽𝔽 [𝑥𝑥] of degree 𝑡𝑡; and
𝑞𝑞
′ ′ ′
— 𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 are distinct elements of 𝔽𝔽 .
0 1 𝑛𝑛−1 𝑞𝑞
′
There are two possibilities for CM.Decode�𝐶𝐶,𝛤𝛤�:
′
( ) ( )
— If 𝐶𝐶 = CM.Encode𝑒𝑒,𝑇𝑇 then CM.Decode𝐶𝐶,𝛤𝛤 =𝑒𝑒. In other words, if there exists a weight-𝑡𝑡 vector 𝑒𝑒∈
𝑛𝑛 ′
𝔽𝔽 such that 𝐶𝐶 =𝐻𝐻𝑒𝑒, where 𝐻𝐻 is defined as (𝐼𝐼 |𝑇𝑇), then CM.Decode�𝐶𝐶,𝛤𝛤� =𝑒𝑒.
𝑚𝑚𝑚𝑚
𝑛𝑛 ′
— If 𝐶𝐶 does not have the form 𝐻𝐻𝑒𝑒 for any weight-𝑡𝑡 vector 𝑒𝑒∈𝔽𝔽 , then CM.Decode�𝐶𝐶,𝛤𝛤� =⊥.
The algorithm is as follows:
𝑛𝑛
1. Extend 𝐶𝐶 to 𝑣𝑣 = (𝐶𝐶, 0, … ,0)∈𝔽𝔽 by appending 𝑘𝑘 zeros.
𝑛𝑛
2. Find the unique 𝑐𝑐∈𝔽𝔽 such that (1) 𝐻𝐻𝑐𝑐 = 0 and (2) 𝑐𝑐 has Hamming distance ≤𝑡𝑡 from 𝑣𝑣. If there is no
such 𝑐𝑐, return ⊥. (See Annex D for a guide for implementors.)
3. Set 𝑒𝑒 =𝑣𝑣 +𝑐𝑐.
4. If wt(𝑒𝑒) =𝑡𝑡 and 𝐶𝐶 =𝐻𝐻𝑒𝑒, return 𝑒𝑒. Otherwise return ⊥.
13.8  Irreducible-polynomial generation
The following algorithm CM.Irreducible takes a string of 𝜎𝜎𝑡𝑡 input bits 𝑑𝑑 ,𝑑𝑑 , … ,𝑑𝑑 . It outputs either ⊥ or
1 0 1 𝜎𝜎𝑚𝑚−1
a monic irreducible degree-𝑡𝑡 polynomial 𝑔𝑔∈𝔽𝔽 [𝑥𝑥]. The algorithm is as follows:
𝑞𝑞
𝑚𝑚−1 𝑖𝑖
{ }
1. Define 𝛽𝛽 =∑ 𝑑𝑑 𝑧𝑧 for each 𝑗𝑗∈ 0,1, … ,𝑡𝑡− 1 . (Within each group of 𝜎𝜎 input bits, this uses only
𝑗𝑗 𝜎𝜎𝑗𝑗+𝑖𝑖 1
𝑖𝑖=0
the first 𝑚𝑚 bits. The algorithm ignores the remaining bits.)
𝑚𝑚−1
2. Define 𝛽𝛽 =𝛽𝛽 +𝛽𝛽𝑦𝑦 +⋯ +𝛽𝛽 𝑦𝑦 ∈𝔽𝔽 [𝑦𝑦]/𝐹𝐹(𝑦𝑦).
0 1 𝑚𝑚−1 𝑞𝑞
( )
3. Compute the minimal polynomial 𝑔𝑔 of 𝛽𝛽 over 𝔽𝔽 . (By definition 𝑔𝑔 is monic and irreducible, and 𝑔𝑔𝛽𝛽 =
𝑞𝑞
0. See Annex D for a guide for implementors.)
4. Return 𝑔𝑔 if 𝑔𝑔 has degree 𝑡𝑡. Otherwise return ⊥.
13.9  Field-ordering generation
The following algorithm CM.FieldOrdering takes a string of 𝜎𝜎𝑞𝑞 input bits. It outputs either ⊥ or a sequence
�𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 � of 𝑞𝑞 distinct elements of 𝔽𝔽 . The algorithm is as follows:
0 1 𝑞𝑞−1 𝑞𝑞
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
𝜎𝜎−1
1. Take the first 𝜎𝜎 input bits 𝑏𝑏 ,𝑏𝑏 , … ,𝑏𝑏 as a 𝜎𝜎 -bit integer 𝑎𝑎 =𝑏𝑏 + 2𝑏𝑏 +⋯ + 2 𝑏𝑏 , take the
2 0 1 𝜎𝜎−1 2 0 0 1 𝜎𝜎−1
2 2
next 𝜎𝜎 bits as a 𝜎𝜎 -bit integer 𝑎𝑎 , and so on through 𝑎𝑎 .
2 2 1 𝑞𝑞−1
2. If 𝑎𝑎 ,𝑎𝑎 , … ,𝑎𝑎 are not distinct, return ⊥.
0 1 𝑞𝑞−1
( ) ( )
3. Sort the pairs 𝑎𝑎 ,𝑖𝑖 in lexicographic order to obtain pairs �𝑎𝑎 ,𝜋𝜋𝑖𝑖� where 𝜋𝜋 is a permutation of
𝑖𝑖 𝜋𝜋(𝑖𝑖)
{0,1, … ,𝑞𝑞− 1}.
𝑚𝑚−1
𝑚𝑚−1−𝑗𝑗
∑ ( ) ( ) ( )
4. Define 𝛼𝛼 = 𝜋𝜋𝑖𝑖 ⋅𝑧𝑧 where 𝜋𝜋𝑖𝑖 denotes the 𝑗𝑗th least significant bit of 𝜋𝜋𝑖𝑖 . (Recall that the
𝑖𝑖 𝑗𝑗 𝑗𝑗
𝑗𝑗=0
is constructed as 𝔽𝔽 [𝑧𝑧]/𝑓𝑓(𝑧𝑧).)
finite field 𝔽𝔽
𝑞𝑞 2
5. Output �𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 �.
0 1 𝑞𝑞−1
13.10  Key generation
13.10.1  CM.KeyGen
The following randomized algorithm CM.KeyGen takes no input (beyond the parameters). It outputs a public
key and private key. The algorithm is as follows, using a subroutine CM.SeededKeyGen defined below:
1. Generate a uniform random ℓ-bit string 𝛿𝛿. (This is called a seed.)
2. Output CM.SeededKeyGen(𝛿𝛿).
13.10.2  CM.SeededKeyGen
The following algorithm CM.SeededKeyGen takes an ℓ-bit input 𝛿𝛿. It outputs a public key and private key.
The algorithm is as follows:
( )
1. Compute 𝐸𝐸 = PRG𝛿𝛿 , a string of 𝑛𝑛 +𝜎𝜎𝑞𝑞 +𝜎𝜎𝑡𝑡 +ℓ bits.
2 1
′
2. Define 𝛿𝛿 as the last ℓ bits of 𝐸𝐸.
3. Define 𝑠𝑠 as the first 𝑛𝑛 bits of 𝐸𝐸.
4. Compute 𝛼𝛼 , … ,𝛼𝛼 from the next 𝜎𝜎𝑞𝑞 bits of 𝐸𝐸 by the CM.FieldOrdering algorithm. If this fails, set
0 𝑞𝑞−1 2
′
𝛿𝛿←𝛿𝛿 and restart the algorithm.
′
5. Compute 𝑔𝑔 from the next 𝜎𝜎𝑡𝑡 bits of 𝐸𝐸 by the CM.Irreducible algorithm. If this fails, set 𝛿𝛿←𝛿𝛿 and restart
the algorithm.
6. Define 𝛤𝛤 = (𝑔𝑔,𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 ). (Note that 𝛼𝛼 , … ,𝛼𝛼 are not used in 𝛤𝛤.)
0 1 𝑛𝑛−1 𝑛𝑛 𝑞𝑞−1
′ ′
( )
7. Compute �𝑇𝑇,𝑐𝑐 , … ,𝑐𝑐 ,𝛤𝛤�← CM.MatGen𝛤𝛤 . If this fails, set 𝛿𝛿←𝛿𝛿 and restart the algorithm.
𝑚𝑚𝑚𝑚−𝜇𝜇 𝑚𝑚𝑚𝑚−1
′ ′ ′ ′
( )
8. Write 𝛤𝛤 as 𝑔𝑔,𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 .
0 1 𝑛𝑛−1
( )
9. Output 𝑇𝑇 as public key and 𝛿𝛿,𝑐𝑐,𝑔𝑔,𝛼𝛼,𝑠𝑠 as private key, where 𝑐𝑐 =�𝑐𝑐 , … ,𝑐𝑐 � and
𝑚𝑚𝑚𝑚−𝜇𝜇 𝑚𝑚𝑚𝑚−1
′ ′
𝛼𝛼 =�𝛼𝛼 , … ,𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 �.
𝑛𝑛 𝑞𝑞−1
0 𝑛𝑛−1
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
13.11  Fixed-weight-vector generation
𝑛𝑛
The following randomized algorithm CM.FixedWeight takes no input. It outputs a vector 𝑒𝑒∈𝔽𝔽 of weight 𝑡𝑡.
The algorithm uses a precomputed integer 𝜏𝜏≥𝑡𝑡 defined below. The algorithm is as follows:
1. Generate 𝜎𝜎𝜏𝜏 uniform random bits 𝑏𝑏 ,𝑏𝑏 , … ,𝑏𝑏 .
1 0 1 𝜎𝜎𝜏𝜏−1
𝑚𝑚−1 𝑖𝑖
2. Define 𝑑𝑑 =∑ 𝑏𝑏 2 for each 𝑗𝑗∈ {0,1, … ,𝜏𝜏− 1}. (Within each group of 𝜎𝜎 random bits, this uses
𝑗𝑗 𝑖𝑖=0 𝜎𝜎𝑗𝑗+𝑖𝑖 1
only the first 𝑚𝑚 bits. The algorithm ignores the remaining bits.)
3. Define 𝑎𝑎 ,𝑎𝑎 , … ,𝑎𝑎 as the first 𝑡𝑡 entries in 𝑑𝑑 ,𝑑𝑑 , … ,𝑑𝑑 in the range {0,1, … ,𝑛𝑛− 1}. If there are fewer
0 1 𝑚𝑚−1 0 1 𝜏𝜏−1
than 𝑡𝑡 entries in 𝑑𝑑 ,𝑑𝑑 , … ,𝑑𝑑 in the range {0,1, … ,𝑛𝑛− 1}, restart the algorithm.
0 1 𝜏𝜏−1
4. If 𝑎𝑎 ,𝑎𝑎 , … ,𝑎𝑎 are not all distinct, restart the algorithm.
0 1 𝑚𝑚−1
𝑛𝑛
5. Define 𝑒𝑒 = (𝑒𝑒 ,𝑒𝑒 , … ,𝑒𝑒 )∈𝔽𝔽 as the weight-𝑡𝑡 vector such that 𝑒𝑒 = 1 for each 𝑖𝑖∈ 0,1, … ,𝑡𝑡− 1 and all
0 1 𝑛𝑛−1 𝑎𝑎
𝑖𝑖
other entries of 𝑒𝑒 are 0.
6. Return 𝑒𝑒.
The integer 𝜏𝜏 is defined as 𝑡𝑡 if 𝑛𝑛 =𝑞𝑞; as 2𝑡𝑡 if 𝑞𝑞/2≤𝑛𝑛 <𝑞𝑞; as 4𝑡𝑡 if 𝑞𝑞/4≤𝑛𝑛 <𝑞𝑞/2; etc.
{ }
NOTE  All of the selected parameter sets have 𝑞𝑞/2≤𝑛𝑛≤𝑞𝑞, so 𝜏𝜏∈ 𝑡𝑡, 2𝑡𝑡 .
13.12  Encapsulation
13.12.1  General
The randomized algorithm CM.Encap takes as input a public key 𝑇𝑇. It outputs a ciphertext 𝐶𝐶 and a session
key 𝐾𝐾.
13.12.2  CM.Encap for non-pc parameters
For non-pc parameter sets, the CM.Encap algorithm is as follows:
𝑛𝑛
1. Use CM.FixedWeight to generate a vector 𝑒𝑒∈𝔽𝔽 of weight 𝑡𝑡.
2. Compute 𝐶𝐶 = CM.Encode(𝑒𝑒,𝑇𝑇).
3. Compute 𝐾𝐾 = Hash(1,𝑒𝑒,𝐶𝐶); see 13.15.5 for Hash input encodings.
4. Output ciphertext 𝐶𝐶 and session key 𝐾𝐾.
13.12.3  CM.Encap for pc parameters
For pc parameter sets, the CM.Encap algorithm is as follows:
𝑛𝑛
1. Use CM.FixedWeight to generate a vector 𝑒𝑒∈𝔽𝔽 of weight 𝑡𝑡.
( )
2. Compute 𝐶𝐶 = CM.Encode𝑒𝑒,𝑇𝑇 .
( ) ( )
3. Compute 𝐶𝐶 = Hash 2,𝑒𝑒 . Put 𝐶𝐶 = 𝐶𝐶 ,𝐶𝐶 ; see 13.15.6 for Hash input encodings.
1 0 1
( )
4. Compute 𝐾𝐾 = Hash 1,𝑒𝑒,𝐶𝐶 .
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
5. Output ciphertext 𝐶𝐶 and session key 𝐾𝐾.
13.13  Decapsulation
13.13.1  General
The algorithm CM.Decap takes as input a ciphertext 𝐶𝐶 and a private key, and outputs a session key 𝐾𝐾.
13.13.2  CM.Decap for non-pc parameters
For non-pc parameter sets, the algorithm CM.Decap is as follows:
1. Set 𝑏𝑏← 1.
𝑛𝑛 ′ ′ ′ ′
2. Extract 𝑠𝑠∈𝔽𝔽 and 𝛤𝛤 = (𝑔𝑔,𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 ) from the private key.
0 1 𝑛𝑛−1
′
3. Compute 𝑒𝑒← CM.Decode(𝐶𝐶,𝛤𝛤 ). If 𝑒𝑒 =⊥, set 𝑒𝑒←𝑠𝑠 and 𝑏𝑏← 0.
( )
4. Compute 𝐾𝐾 = Hash𝑏𝑏,𝑒𝑒,𝐶𝐶 ; see 13.15.5 for Hash input encodings.
5. Output 𝐾𝐾 as session key.
13.13.3  CM.Decap for pc parameters
For pc parameter sets, the algorithm CM.Decap is as follows:
𝑚𝑚𝑚𝑚 ℓ
( )
1. Split the ciphertext 𝐶𝐶 as 𝐶𝐶 ,𝐶𝐶 with 𝐶𝐶 ∈𝔽𝔽 and 𝐶𝐶 ∈𝔽𝔽 .
0 1 0 2 1 2
2. Set 𝑏𝑏← 1.
𝑛𝑛 ′ ′ ′
′
( )
3. Extract 𝑠𝑠∈𝔽𝔽 and 𝛤𝛤 = 𝑔𝑔,𝛼𝛼 ,𝛼𝛼 , … ,𝛼𝛼 from the private key.
2 0 1 𝑛𝑛−1
′
( )
4. Compute 𝑒𝑒← CM.Decode𝐶𝐶 ,𝛤𝛤 . If 𝑒𝑒 =⊥, set 𝑒𝑒←𝑠𝑠 and 𝑏𝑏← 0.
′
= Hash(2,𝑒𝑒); see 13.15.6 for Hash input encodings.
5. Compute 𝐶𝐶
′
6. If 𝐶𝐶 ≠𝐶𝐶 , set 𝑒𝑒←𝑠𝑠 and 𝑏𝑏← 0.
1 1
7. Compute 𝐾𝐾 = Hash(𝑏𝑏,𝑒𝑒,𝐶𝐶); see 13.15.6 for Hash input encodings.
8. Output 𝐾𝐾 as session key.
13.14  Choices of symmetric-cryptography parameters
{ }
In this subclause and 13.15, Uint8 means the set 0,1, . . . ,255 ; a Uint8 string means a string of elements of
Uint8; a 𝑏𝑏-Uint8 string means a string of 𝑏𝑏 elements of Uint8, i.e. a Uint8 string of length 𝑏𝑏; 𝑏𝑏 Uint8s mean 𝑏𝑏
elements of Uint8. 13.15 specifies how various objects are represented as Uint8 strings.
NOTE 1  The usage of Uint8 in this subclause and 13.15 is designed to fit Classic McEliece into the conventional

interface used in cryptographic software, in which private keys, public keys, ciphertexts, and session keys are
Uint8 strings (often expressed in programming languages as arrays of "uint8_t" or arrays of "unsigned char").
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
In this subclause, SHAKE256(𝑥𝑥,𝑖𝑖) takes as input a Uint8 string 𝑥𝑥 and an integer 𝑖𝑖, which is a multiple of 8,
and produces an (𝑖𝑖/8)-Uint8 string. SHAKE256 shall be implemented in accordance with ISO/IEC 10118-
3:2018, C.2. Specifically, it is the Uint8-string (“sequence of bytes”) function defined in that annex, not the
bit-string function.
NOTE 2  The most common interface to SHAKE256 software is that the inputs are a Uint8 string and i/8, and the

output is an (i/8)-Uint8 string. However, in specifications, it is more common to define a SHAKE256 function
that takes i rather than i/8 as an input. This difference in SHAKE256 notation can be confusing.
NOTE 3  13.15 specifies how Clause 13 represents i-bit strings as (i/8)-Uint8 strings. That representation

covers all (i/8)-Uint8 strings, allowing those strings to be viewed as i-bit strings without further comment.
All of the selected parameter sets use the following symmetric-cryptography parameters.
— The integer ℓ is 256.
( ) ( )
— The ℓ-bit string Hash𝑥𝑥 is defined as SHAKE256𝑥𝑥, ℓ .
— The integer 𝜎𝜎 is 16. (All of the selected parameter sets have 𝑚𝑚≤ 16, so 𝜎𝜎 ≥𝑚𝑚.)
1 1
— The integer 𝜎𝜎 is 32.
— The (𝑛𝑛 +𝜎𝜎𝑞𝑞 +𝜎𝜎𝑡𝑡 +ℓ)-bit string PRG(𝛿𝛿) is defined as SHAKE256�(64,𝛿𝛿),𝑛𝑛 +𝜎𝜎𝑞𝑞 +𝜎𝜎𝑡𝑡 +ℓ�. Here
2 1 2 1
64,𝛿𝛿 means the 33-Uint8 string that begins with the element 64 of Uint8 and continues with 𝛿𝛿.
NOTE 4  For each hash input used in Classic McEliece, the first Uint8 entry of the input is 0 or 1 (or 2 for pc) (see
13.15). Thus, the hash inputs do not overlap the SHAKE256 inputs used in PRG.
13.15  Representation of objects as Uint8 strings
13.15.1  Bit vectors
𝑟𝑟
( ) ( )
If 𝑟𝑟 is a multiple of 8 then an 𝑟𝑟-bit vector 𝑣𝑣 = 𝑣𝑣 ,𝑣𝑣 , … ,𝑣𝑣 ∈𝔽𝔽 is represented as the following 𝑟𝑟/8 -
0 1 𝑟𝑟−1 2
Uint8 string:
(𝑣𝑣 + 2𝑣𝑣 + 4𝑣𝑣 +⋯ + 128𝑣𝑣 ,𝑣𝑣 + 2𝑣𝑣 + 4𝑣𝑣 +⋯ + 128𝑣𝑣 , … ,𝑣𝑣 + 2𝑣𝑣 + 4𝑣𝑣 +⋯ + 128𝑣𝑣 ).
0 1 2 7 8 9 10 15 𝑟𝑟−8 𝑟𝑟−7 𝑟𝑟−6 𝑟𝑟−1
𝑟𝑟
If 𝑟𝑟 is not a multiple of 8 then an 𝑟𝑟-bit vector 𝑣𝑣 = (𝑣𝑣 ,𝑣𝑣 , … ,𝑣𝑣 )∈𝔽𝔽 is zero-padded on the right to length
0 1 𝑟𝑟−1 2
between 𝑟𝑟 + 1 and 𝑟𝑟 + 7, whichever is a multiple of 8, and then represented as above.
Here are two definitions: “Simply Decoded Classic McEliece” ignores padding bits on input, while “Narrowly
Decoded Classic McEliece” rejects inputs (ciphertexts and public keys) where padding bits are nonzero;
rejection means returning ⊥. For some parameter sets (but not all), 𝑟𝑟 is always a multiple of 8, so there are
no padding bits, so Simply Decoded Classic McEliece and Narrowly Decoded Classic McEliece are identical.
The definitions of Simply Decoded and Narrowly Decoded are provided for convenience in discussions of
situations where the distinction is potentially relevant. Applications should avoid relying on whether non-
zero padding bits are always allowed, always rejected, or some intermediate option. Conformance to this
document for Classic McEliece does not require a Simply Decoded or Narrowly Decoded label.
13.15.2  Session keys
ℓ
A session key 𝐾𝐾 is an element of 𝔽𝔽 . It is represented as a ⌈ℓ/8⌉-Uint8 string.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
13.15.3  Ciphertexts for non-pc parameter sets
𝑚𝑚𝑚𝑚
⌈ ⌉
For non-pc parameter sets: a ciphertext 𝐶𝐶 is an element of 𝔽𝔽 . It is represented as a 𝑚𝑚𝑡𝑡/8 -Uint8 string.
13.15.4  Ciphertexts for pc parameter sets
𝑚𝑚𝑚𝑚 ℓ
∈𝔽𝔽 and 𝐶𝐶 ∈𝔽𝔽 . The ciphertext is
For pc parameter sets, a ciphertext 𝐶𝐶 has two components: 𝐶𝐶
0 2 1 2
represented as the concatenation of the ⌈𝑚𝑚𝑡𝑡/8⌉-Uint8 string representing 𝐶𝐶 and the ⌈ℓ/8⌉-Uint8 string
representing 𝐶𝐶 .
13.15.5  Hash inputs for non-pc parameter sets
𝑛𝑛
For non-pc parameter sets, there are two types of hash inputs: (1,𝑣𝑣,𝐶𝐶), and (0,𝑣𝑣,𝐶𝐶). Here 𝑣𝑣∈𝔽𝔽 , and 𝐶𝐶 is a
ciphertext.
⌈ ⌉
The initial 0 or 1 is represented as a Uint8. The vector 𝑣𝑣 is represented as the next 𝑛𝑛/8 Uint8s. The
⌈ ⌉
ciphertext is represented as the next 𝑚𝑚𝑡𝑡/8 Uint8s.
NOTE  All hash inputs thus begin with Uint8 0 or 1, as mentioned earlier.

13.15.6  Hash inputs for pc parameter sets
𝑛𝑛
( ) ( ) ( )
For pc parameter sets, there are three types of hash inputs: 2,𝑣𝑣 ; 1,𝑣𝑣,𝐶𝐶 ; and 0,𝑣𝑣,𝐶𝐶 . Here 𝑣𝑣∈𝔽𝔽 , and 𝐶𝐶
is a ciphertext.
The initial 0, 1, or 2 is represented as a Uint8. The vector 𝑣𝑣 is represented as the next ⌈𝑛𝑛/8⌉ Uint8s. The
ciphertext, if present, is represented as the next ⌈𝑚𝑚𝑡𝑡/8⌉ +⌈ℓ/8⌉ Uint8s.
NOTE  All hash inputs thus begin with Uint8 0, 1, or 2, as mentioned earlier.
13.15.7  Public keys
The public key 𝑇𝑇, which is an 𝑚𝑚𝑡𝑡 ×𝑘𝑘 matrix, is represented in a row-major fashion. Each row of 𝑇𝑇 is
⌈ ⌉ ⌈ ⌉
represented as a 𝑘𝑘/8 -Uint8 string, and the public key is represented as the 𝑚𝑚𝑡𝑡𝑘𝑘/8 -Uint8 concatenation of
these strings.
13.15.8  Field elements
𝑚𝑚−1 𝑖𝑖
Each element of 𝔽𝔽 ≅𝔽𝔽 [𝑧𝑧]/𝑓𝑓(𝑧𝑧) has the form ∑ 𝑐𝑐𝑧𝑧 where 𝑐𝑐 ∈𝔽𝔽 . The representation of the field
𝑞𝑞 2 𝑖𝑖=0 𝑖𝑖 𝑖𝑖 2
𝑚𝑚
( )
element is the representation of the vector 𝑐𝑐 ,𝑐𝑐 , … ,𝑐𝑐 ∈𝔽𝔽 .
0 1 𝑚𝑚−1 2
13.15.9  Monic irreducible polynomials
𝑚𝑚−1 𝑚𝑚
⌈ ⌉
The monic irreducible degree-𝑡𝑡 polynomial 𝑔𝑔 =𝑔𝑔 +𝑔𝑔𝑥𝑥 +⋯ +𝑔𝑔 𝑥𝑥 +𝑥𝑥 is represented as 𝑡𝑡𝑚𝑚/8
0 1 𝑚𝑚−1
Uint8s, namely the concatenation of the representations of the field elements 𝑔𝑔 ,𝑔𝑔 , … ,𝑔𝑔 .
0 1 𝑚𝑚−1
13.15.10  Field orderings
The obvious representation of a sequence �𝛼𝛼 , … ,𝛼𝛼 � of 𝑞𝑞 distinct elements of 𝔽𝔽 would be as a sequence
0 𝑞𝑞−1 𝑞𝑞
of 𝑞𝑞 field elements. This clause instead specifies the following representation.
𝑚𝑚
An “in-place Beneš network” is a series of 2𝑚𝑚− 1 stages of swaps applied to an array of 𝑞𝑞 = 2 objects
�𝑎𝑎 ,𝑎𝑎 , … ,𝑎𝑎 �. The first stage conditionally swaps 𝑎𝑎 and 𝑎𝑎 , conditionally swaps 𝑎𝑎 and 𝑎𝑎 , conditionally
0 1 𝑞𝑞−1 0 1 2 3
swaps 𝑎𝑎 and 𝑎𝑎 , etc. as specified by a sequence of 𝑞𝑞/2 control bits (1 meaning swap, 0 meaning leave in
4 5
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
place). The second stage conditionally swaps 𝑎𝑎 and 𝑎𝑎 , conditionally swaps 𝑎𝑎 and 𝑎𝑎 , conditionally swaps
0 2 1 3
𝑎𝑎 and 𝑎𝑎 , etc., as specified by the next 𝑞𝑞/2 control bits. This continues through the 𝑚𝑚th stage, which
4 6
conditionally swaps 𝑎𝑎 and 𝑎𝑎 , conditionally swaps 𝑎𝑎 and 𝑎𝑎 , etc. The (𝑚𝑚 + 1)st stage is just like the
0 𝑞𝑞/2 1 𝑞𝑞/2+1
( ) ( ) ( )
𝑚𝑚− 1 st stage (with new control bits), the 𝑚𝑚 + 2 nd stage is just like the 𝑚𝑚− 2 nd stage, and so on
( )
through the 2𝑚𝑚− 1 st stage.
𝑚𝑚−1 𝑚𝑚−1−𝑗𝑗
Define 𝜋𝜋 as the permutation of {0,1, … ,𝑞𝑞− 1} such that 𝛼𝛼 =∑ 𝜋𝜋(𝑖𝑖) ⋅𝑧𝑧 for all 𝑖𝑖∈ {0,1, … ,𝑞𝑞− 1}.
𝑖𝑖 𝑗𝑗
𝑗𝑗=0
𝑗𝑗
( ) ( ) ( ) { }
Here, 𝜋𝜋𝑖𝑖 denotes the coefficient of 2 in the binary expansion of the integer 𝜋𝜋𝑖𝑖 , i.e. 𝜋𝜋𝑖𝑖 ∈ 0,1 for all 𝑖𝑖
𝑗𝑗
𝑚𝑚−1
𝑗𝑗 𝑚𝑚−1
( ) ∑ ( ) ( )
and we have 𝜋𝜋𝑖𝑖 = 𝜋𝜋𝑖𝑖 2 . The ordering is represented as a sequence of 2𝑚𝑚− 1 2 control bits
𝑗𝑗=0 𝑗𝑗
𝑚𝑚−4
for an in-place Beneš network for 𝜋𝜋. This vector is represented as ⌈(2𝑚𝑚− 1)2 ⌉ Uint8s as above.
Mathematically, each permutation has multiple choices of control-bit vectors. However, for conformance to
this document regarding Classic McEliece, a permutation 𝜋𝜋 shall be converted to the same control bits as the
output of the function controlbits in the following Python 3.9.2 script. This is not a requirement for the
decapsulation algorithm reading control bits to check uniqueness.
def composeinv(c,pi):
return [y for x,y in sorted(zip(pi,c))]

def controlbits(pi):
n = len(pi)
m = 1
while 1< assert 1< if m == 1: return [pi[0]]
p = [pi[x^1] for x in range(n)]
q = [pi[x]^1 for x in range(n)]

piinv = composeinv(range(n),pi)
p,q = composeinv(p,q),composeinv(q,p)

c = [min(x,p[x]) for x in range(n)]
p,q = composeinv(p,q),composeinv(q,p)
for i in range(1,m-1):
cp,p,q = composeinv(c,q),composeinv(p,q),composeinv(q,p)
c = [min(c[x],cp[x]) for x in range(n)]

f = [c[2*j]%2 for j in range(n//2)]
F = [x^f[x//2] for x in range(n)]
Fpi = composeinv(F,piinv)
l = [Fpi[2*k]%2 for k in range(n//2)]
L = [y^l[y//2] for y in range(n)]
M = composeinv(Fpi,L)
subM = [[M[2*j+e]//2 for j in range(n//2)] for e in range(2)]
subz = map(controlbits,subM)
z = [s for s0s1 in zip(*subz) for s in s0s1]
return f+z+l
13.15.11  Column selections
Part of the private key generated by CM.KeyGen is a sequence 𝑐𝑐 =�𝑐𝑐 , … ,𝑐𝑐 � of 𝜇𝜇 integers in
𝑚𝑚𝑚𝑚−𝜇𝜇 𝑚𝑚𝑚𝑚−1
increasing order between 𝑚𝑚𝑡𝑡−𝜇𝜇 and 𝑚𝑚𝑡𝑡−𝜇𝜇 +𝜈𝜈− 1.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
This sequence 𝑐𝑐 is represented as the ⌈𝜈𝜈/8⌉-Uint8 string �𝑢𝑢 ,𝑢𝑢 , … , 𝑢𝑢 � such that 𝑢𝑢 +𝑢𝑢 2 +⋯ +
⌈ ⌉
0 1 𝜈𝜈/8−1 0 1
8(⌈𝜈𝜈/8⌉−1)
𝑢𝑢 2 is equal to
⌈𝜈𝜈/8⌉−1
𝜇𝜇−1
𝑐𝑐 −(𝑚𝑚𝑚𝑚−𝜇𝜇)
𝑚𝑚𝑡𝑡−𝜇𝜇+𝑖𝑖
� 2 .
𝑖𝑖=0
However, for (𝜇𝜇,𝜈𝜈) = (0,0), the sequence 𝑐𝑐 is instead represented as the 8-Uint8 string starting with 4
Uint8s of value 255 followed by 4 Uint8s of value 0.
13.15.12  Private keys
A private key (𝛿𝛿,𝑐𝑐,𝑔𝑔,𝛼𝛼,𝑠𝑠) is represented as the concatenation of five parts:
ℓ
⌈ ⌉
— The ℓ/8 -Uint8 string representing 𝛿𝛿∈𝔽𝔽 .
⌈ ⌉ ( )
— The string representing the column selections 𝑐𝑐. This string has 𝜈𝜈/8 Uint8s, or 8 Uint8s if 𝜇𝜇,𝜈𝜈 =
( )
0,0 .
⌈ ⌉
— The 𝑡𝑡𝑚𝑚/8 -Uint8 string representing the polynomial 𝑔𝑔.
𝑚𝑚−4
⌈( ) ⌉
— The 2𝑚𝑚− 1 2 Uint8s representing the field ordering 𝛼𝛼.
𝑛𝑛
⌈ ⌉
— The 𝑛𝑛/8 -Uint8 string representing 𝑠𝑠∈𝔽𝔽 .
13.16  Selected parameter sets
13.16.1  General
Table 13.16.1-1 lists the names of the selected parameter sets, and the sizes in bytes of private keys, public
keys, ciphertexts, and session keys. The definitions of the selected parameter sets appear in 13.16.2
to 13.16.17. For the specification of symmetric-cryptography parameters, see 13.14. See Annex D for
references to literature describing further characteristics of these parameter sets, including security
characteristics.
Table 13.16.1-1 - Sizes (in bytes) of Classic McEliece inputs and outputs
parameter set private key public key ciphertext session key
mceliece460896 13 608 524 160 156 32
mceliece6688128 13 932 1 044 992 208 32
mceliece6960119 13 948 1 047 319 194 32
mceliece8192128 14 120 1 357 824 208 32
any of the above + f same same same same
any of the above + pc same same same + 32 same
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
13.16.2  Parameter set mceliece460896
13 4 3 96
( ) ( )
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 4 608, 𝑡𝑡 = 96. Field polynomials 𝑓𝑓𝑧𝑧 =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹𝑦𝑦 =𝑦𝑦 +
10 9 6
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. This is a non-pc parameter set.
13.16.3  Parameter set mceliece460896f
13 4 3 96
( ) ( )
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 4 608, 𝑡𝑡 = 96. Field polynomials 𝑓𝑓𝑧𝑧 =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹𝑦𝑦 =𝑦𝑦 +
10 9 6
( ) ( )
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. Semi-systematic parameters 𝜇𝜇,𝜈𝜈 = 32,64 . This is a non-pc parameter set.
13.16.4  Parameter set mceliece460896pc
13 4 3 96
( )
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 4 608, 𝑡𝑡 = 96. Field polynomials 𝑓𝑓(𝑧𝑧) =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹𝑦𝑦 =𝑦𝑦 +
10 9 6
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. This is a pc parameter set.
13.16.5  Parameter set mceliece460896pcf
13 4 3 96
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 4 608, 𝑡𝑡 = 96. Field polynomials 𝑓𝑓(𝑧𝑧) =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹(𝑦𝑦) =𝑦𝑦 +
10 9 6
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. Semi-systematic parameters (𝜇𝜇,𝜈𝜈) = (32,64). This is a pc parameter set.
13.16.6  Parameter set mceliece6688128
13 4 3 128
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 6 688, 𝑡𝑡 = 128. Field polynomials 𝑓𝑓(𝑧𝑧) =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹(𝑦𝑦) =𝑦𝑦 +
7 2
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. This is a non-pc parameter set.
13.16.7  Parameter set mceliece6688128f
13 4 3 128
( ) ( )
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 6 688, 𝑡𝑡 = 128. Field polynomials 𝑓𝑓𝑧𝑧 =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹𝑦𝑦 =𝑦𝑦 +
7 2
( ) ( )
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. Semi-systematic parameters 𝜇𝜇,𝜈𝜈 = 32,64 . This is a non-pc parameter set.
13.16.8  Parameter set mceliece6688128pc
13 4 3 128
( ) ( )
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 6 688, 𝑡𝑡 = 128. Field polynomials 𝑓𝑓𝑧𝑧 =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹𝑦𝑦 =𝑦𝑦 +
7 2
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. This is a pc parameter set.
13.16.9  Parameter set mceliece6688128pcf
13 4 3 128
( ) ( )
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 6 688, 𝑡𝑡 = 128. Field polynomials 𝑓𝑓𝑧𝑧 =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹𝑦𝑦 =𝑦𝑦 +
7 2
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. Semi-systematic parameters (𝜇𝜇,𝜈𝜈) = (32,64). This is a pc parameter set.
13.16.10  Parameter set mceliece6960119
13 4 3 119
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 6 960, 𝑡𝑡 = 119. Field polynomials 𝑓𝑓(𝑧𝑧) =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹(𝑦𝑦) =𝑦𝑦 +
𝑦𝑦 + 1. This is a non-pc parameter set.
13.16.11  Parameter set mceliece6960119f
13 4 3 119
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 6 960, 𝑡𝑡 = 119. Field polynomials 𝑓𝑓(𝑧𝑧) =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹(𝑦𝑦) =𝑦𝑦 +
𝑦𝑦 + 1. Semi-systematic parameters (𝜇𝜇,𝜈𝜈) = (32,64). This is a non-pc parameter set.
13.16.12  Parameter set mceliece6960119pc
13 4 3 119
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 6 960, 𝑡𝑡 = 119. Field polynomials 𝑓𝑓(𝑧𝑧) =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹(𝑦𝑦) =𝑦𝑦 +
𝑦𝑦 + 1. This is a pc parameter set.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
13.16.13  Parameter set mceliece6960119pcf
13 4 3 119
( ) ( )
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 6 960, 𝑡𝑡 = 119. Field polynomials 𝑓𝑓𝑧𝑧 =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹𝑦𝑦 =𝑦𝑦 +
( ) ( )
𝑦𝑦 + 1. Semi-systematic parameters 𝜇𝜇,𝜈𝜈 = 32,64 . This is a pc parameter set.
13.16.14  Parameter set mceliece8192128
13 4 3 128
( ) ( )
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 8 192, 𝑡𝑡 = 128. Field polynomials 𝑓𝑓𝑧𝑧 =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹𝑦𝑦 =𝑦𝑦 +
7 2
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. This is a non-pc parameter set.
13.16.15  Parameter set mceliece8192128f
13 4 3 128
( )
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 8 192, 𝑡𝑡 = 128. Field polynomials 𝑓𝑓(𝑧𝑧) =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹𝑦𝑦 =𝑦𝑦 +
7 2
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. Semi-systematic parameters (𝜇𝜇,𝜈𝜈) = (32,64). This is a non-pc parameter set.
13.16.16  Parameter set mceliece8192128pc
13 4 3 128
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 8 192, 𝑡𝑡 = 128. Field polynomials 𝑓𝑓(𝑧𝑧) =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹(𝑦𝑦) =𝑦𝑦 +
7 2
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. This is a pc parameter set.
13.16.17  Parameter set mceliece8192128pcf
13 4 3 128
KEM with 𝑚𝑚 = 13, 𝑛𝑛 = 8 192, 𝑡𝑡 = 128. Field polynomials 𝑓𝑓(𝑧𝑧) =𝑧𝑧 +𝑧𝑧 +𝑧𝑧 +𝑧𝑧 + 1 and 𝐹𝐹(𝑦𝑦) =𝑦𝑦 +
7 2
𝑦𝑦 +𝑦𝑦 +𝑦𝑦 + 1. Semi-systematic parameters (𝜇𝜇,𝜈𝜈) = (32,64). This is a pc parameter set.
14  FrodoKEM
14.1  General
Clause 14 defines the key encapsulation mechanism FrodoKEM.
FrodoKEM is parameterized by the pseudorandom generator that is used for the generation of a matrix
denoted 𝑨𝑨. This clause allows two main variants, which are determined by the use of either AES128, as
defined in ISO/IEC 18033-3:2010, 5.2, or SHAKE128, as defined in ISO/IEC 10118-3:2018, C.2, for the
generation of 𝑨𝑨.
In addition, FrodoKEM consists of two main variants: a “standard” variant that does not impose any
restriction on the reuse of key pairs, and an “ephemeral” variant that is intended for applications in which
the number of ciphertexts produced relative to any single public key is small. Concretely, the use of standard
FrodoKEM is recommended for applications in which the number of ciphertexts produced for a single public
key is expected to be equal or greater than 2 . Ephemeral FrodoKEM shall be used only for applications in
which that same figure is guaranteed to be smaller than 2 .
The selected parameter sets for all variants are specified in 14.9.
NOTE  In the third-round submission to the NIST post-quantum standardization process of FrodoKEM
(Reference [52]), only the “ephemeral” variant eFrodoKEM had been specified and was called FrodoKEM in that
document. It differs from the variant defined in this clause by the introduction of the salt. Applications are
expected, however, to always choose the highest security level affordable by the application independent of the
choice of the “standard” or “ephemeral” variant. Choosing the “standard” variant over the “ephemeral” variant
does not increase the bit-security for key recovery or single message recovery; it only makes a difference in the
multi-ciphertext scenario.
© ISO/IEC 2026 – All rights reserved
ISO/IEC 18033-2:2006/Amd. 2:2026(en)
14.2  Requirements
To claim conformance to this document regarding FrodoKEM, an algorithm shall:
(1) name either Frodo.KeyGen or Frodo.Encaps or Frodo.Decaps;
(2) identify a parameter set listed in 14.9; and
(3) compute exactly the corresponding mathematical function defined in this document for that parameter
set.
For example, a Frodo.KeyGen implementation claimed to conform to this document for the FrodoKEM-976-
AES parameter set shall compute the specified Frodo.KeyGen function for that parameter set, i.e., the
implementation shall read exactly 704 bits of randomness, and shall produce the same output that the
Frodo.KeyGen algorithm specified below produces given the same 704-bit string. Conformance to this
document for a tuple of three FrodoKEM algorithms, one for each of Frodo.KeyGen and Frodo.Encaps and
Frodo.Decaps, is defined as conformance to this docum
...