Information technology - Security techniques - Lightweight cryptography - Part 2: Block ciphers

ISO/IEC 29192-2:2012 specifies two block ciphers suitable for lightweight cryptography: a) PRESENT: a lightweight block cipher with a block size of 64 bits and a key size of 80 or 128 bits; b) CLEFIA: a lightweight block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits.

Technologies de l'information — Techniques de sécurité — Cryptographie pour environnements contraints — Partie 2: Chiffrements par blocs

General Information

Status
Withdrawn
Publication Date
09-Jan-2012
Withdrawal Date
09-Jan-2012
Current Stage
9599 - Withdrawal of International Standard
Start Date
15-Nov-2019
Completion Date
30-Oct-2025
Ref Project

Relations

Standard
ISO/IEC 29192-2:2012 - Information technology -- Security techniques -- Lightweight cryptography
English language
41 pages
sale 15% off
Preview
sale 15% off
Preview

Frequently Asked Questions

ISO/IEC 29192-2:2012 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Security techniques - Lightweight cryptography - Part 2: Block ciphers". This standard covers: ISO/IEC 29192-2:2012 specifies two block ciphers suitable for lightweight cryptography: a) PRESENT: a lightweight block cipher with a block size of 64 bits and a key size of 80 or 128 bits; b) CLEFIA: a lightweight block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits.

ISO/IEC 29192-2:2012 specifies two block ciphers suitable for lightweight cryptography: a) PRESENT: a lightweight block cipher with a block size of 64 bits and a key size of 80 or 128 bits; b) CLEFIA: a lightweight block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits.

ISO/IEC 29192-2:2012 is classified under the following ICS (International Classification for Standards) categories: 35.030 - IT Security; 35.040 - Information coding. The ICS classification helps identify the subject area and facilitates finding related standards.

ISO/IEC 29192-2:2012 has the following relationships with other standards: It is inter standard links to ISO/IEC 29192-2:2019. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

You can purchase ISO/IEC 29192-2:2012 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.

Standards Content (Sample)


INTERNATIONAL ISO/IEC
STANDARD 29192-2
First edition
2012-01-15
Information technology — Security
techniques — Lightweight cryptography
Part 2:
Block ciphers
Technologies de l'information — Techniques de sécurité —
Cryptographie pour environnements contraints
Partie 2: Chiffrements par blocs

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

Contents Page
Foreword . iv
Introduction . v
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 1
4  Symbols . 2
5  Lightweight block cipher with a block size of 64 bits . 2
5.1  PRESENT . 2
6  Lightweight block cipher with a block size of 128 bits . 7
6.1  CLEFIA . 7
Annex A (normative) Object identifiers . 24
Annex B (informative) Test vectors . 26
Annex C (informative) Feature table . 39
Annex D (informative) A limitation of a block cipher under a single key . 40
Bibliography . 41

© ISO/IEC 2012 – All rights reserved iii

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.
ISO/IEC 29192-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Security techniques.
ISO/IEC 29192 consists of the following parts, under the general title Information technology — Security
techniques — Lightweight cryptography:
 Part 1: General
 Part 2: Block ciphers
 Part 3: Stream ciphers
 Part 4: Mechanisms using asymmetric techniques
Further parts may follow.
iv © ISO/IEC 2012 – All rights reserved

Introduction
This part of ISO/IEC 29192 specifies block ciphers suitable for lightweight cryptography, which are tailored for
implementation in constrained environments.
ISO/IEC 29192-1 specifies the requirements for lightweight cryptography.
A block cipher maps blocks of n bits to blocks of n bits, under the control of a key of k bits.
The International Organization for Standardization (ISO) and the International Electrotechnical Commission
(IEC) draw attention to the fact that it is claimed that compliance with this document may involve the use of
patents.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights.
The holder of these patent rights has assured ISO and IEC that he is willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect,
the statement of the holder of these patent rights is registered with ISO and IEC. Information may be obtained
from:
Sony Corporation
System Technologies Laboratories
Attn Masanobu Katagi
Gotenyama Tec. 5-1-12 Kitashinagwa Shinagawa-ku
Tokyo
141-0001 Japan
Tel. +81-3-5448-3701
Fax +81-3-5448-6438
E-mail Masanobu.Katagi@jp.sony.com
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/IEC 2012 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 29192-2:2012(E)

Information technology — Security techniques — Lightweight
cryptography
Part 2:
Block ciphers
1 Scope
This part of ISO/IEC 29192 specifies two block ciphers suitable for applications requiring lightweight
cryptographic implementations:
 PRESENT: a lightweight block cipher with a block size of 64 bits and a key size of 80 or 128 bits;
 CLEFIA: a lightweight block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits.
2 Normative references
There are no normative references for this part of ISO/IEC 29192.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
block
string of bits of defined length
[ISO/IEC 18033-1]
3.2
block cipher
symmetric encipherment system with the property that the encryption algorithm operates on a block of
plaintext, i.e. a string of bits of a defined length, to yield a block of ciphertext
[ISO/IEC 18033-1]
3.3
ciphertext
data which has been transformed to hide its information content
[ISO/IEC 9798-1]
3.4
key
sequence of symbols that controls the operation of a cryptographic transformation (e.g. encipherment,
decipherment)
© ISO/IEC 2012 – All rights reserved 1

NOTE Adapted from ISO/IEC 11770-1.
3.5
n-bit block cipher
block cipher with the property that plaintext blocks and ciphertext blocks are n bits in length
[ISO/IEC 10116]
3.6
plaintext
unenciphered information
NOTE Taken from ISO/IEC 9797-1:1999.
3.7
round key
sequence of symbols derived from the key using the key schedule, and used to control the transformation in
each round of the block cipher
4 Symbols
0x A prefix for a binary string in hexadecimal notation
|| Concatenation of bit strings
a ← b Updating a value of a by a value of b
 Bitwise exclusive-OR operation
5 Lightweight block cipher with a block size of 64 bits
5.1 PRESENT
5.1.1 PRESENT algorithm
The PRESENT algorithm [10] is a symmetric block cipher that can process data blocks of 64 bits, using a key
of length 80 or 128 bits. The cipher is referred to as PRESENT-80 or PRESENT-128 when using an 80-bit or
128-bit key respectively.
5.1.2 PRESENT specific notations
i i
K = k …k 64-bit round key that is used in round i
i 63 0
i
k  bit b of round key K
b i
K = k … k 80-bit key register
79 0
k  bit b of key register K
b
STATE 64-bit internal state
b  bit i of the current STATE
i
w  4-bit word where 0 ≤ i ≤ 15
i
2 © ISO/IEC 2012 – All rights reserved

5.1.3 PRESENT encryption
The PRESENT block cipher consists of 31 ‘rounds’, i.e. 31 applications of a sequence of simple
transformations. A pseudocode description of the complete encryption algorithm is provided in Figure 1, where
STATE denotes the internal state. The individual transformations used by the algorithm are defined in 5.1.5.
Each round of the algorithm uses a distinct round key K (1  i  31), derived as specified in 5.1.6. Two
i
consecutive rounds of the algorithm are shown for illustrative purposes in Figure 2.

Figure 1 — The encryption procedure of PRESENT

Figure 2 — Two rounds of PRESENT

5.1.4 PRESENT decryption
The complete PRESENT decryption algorithm is given in Figure 3. The individual transformations used by the
algorithm are defined in 5.1.5. Each round of the algorithm uses a distinct round key K (1  i  31), derived as
i
specified in 5.1.6.
© ISO/IEC 2012 – All rights reserved 3

Figure 3 — The decryption procedure of PRESENT

5.1.5 PRESENT transformations
5.1.5.1 addRoundKey
i i
Given round key K = k …k for 1 ≤ i ≤ 32 and current STATE b …b , addRoundKey consists of the
i 63 0 63 0
i
operation for 0 ≤ j ≤ 63, b ← b  k .
j j j
5.1.5.2 sBoxLayer
The non-linear sBoxLayer of the encryption process of PRESENT uses a single 4-bit to 4-bit S-box S which is
applied 16 times in parallel in each round. The S-box transforms the input x to an output S(x) as given in
hexadecimal notation in Table 1.
Table 1 — PRESENT S-box
0 1 2 3 4 5 6 7 8 9 A B C D E F
x
S(x)
C 5 6 B 9 0 A D 3 E F 8 4 7 1 2

For sBoxLayer the current STATE b …b is considered as sixteen 4-bit words w …w where w = b || b
63 0 15 0 i 4*i+3 4*i+2
|| b || b for 0 ≤ i ≤ 15 and the output nibble S(w ) provides the updated state values as a concatenation S(w )
4*i+1 4*i i 15
|| S(w ) || . || S(w ).
14 0
5.1.5.3 invsBoxLayer
The S-box used in the decryption procedure of PRESENT is the inverse of the 4-bit to 4-bit S-box S that is
−1
described in 5.1.5.2. The inverse S-box transforms the input x to an output S (x) as given in hexadecimal
notation in Table 2.
Table 2 — PRESENT inverse S-box
0 1 2 3 4 5 6 7 8 9 A B C D E F
x
−1
5 E F 8 C 1 2 D B 4 6 3 0 7 9 A
S (x)
4 © ISO/IEC 2012 – All rights reserved

5.1.5.4 pLayer
The bit permutation pLayer used in the encryption routine of PRESENT is given by Table 3. Bit i of STATE is
moved to bit position P(i).
Table 3 — PRESENT permutation layer pLayer
i 0 1
2 3 4 5 6 7 8 9 10 11 12 13 14 15
P(i) 0 16 32 48 1 17 33 49 2 18 34 50 3 19 35 51

i 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
P(i)
4 20 36 52 5 21 37 53 6 22 38 54 7 23 39 55

i 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
P(i) 8 24 40 56 9 25 41 57 10 26 42 58 11 27 43 59

i 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
P(i) 12 28 44 60 13 29 45 61 14 30 46 62 15 31 47 63

5.1.5.5 invpLayer
The inverse permutation layer invpLayer used in the decryption routine of PRESENT is given by Table 4. Bit i
−1
of STATE is moved to bit position P (i).
Table 4 — PRESENT inverse permutation Layer invpLayer
i 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
−1
P (i) 0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60

i 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
−1
P (i) 1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61

i 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
−1
P (i) 2 6 10 14 18 22 26 30 34 38 42 46 50 54 58 62

i 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
−1
P (i) 3 7 11 15 19 23 27 31 35 39 43 47 51 55 59 63

5.1.6 PRESENT key schedule
5.1.6.1 PRESENT-80 and PRESENT-128
PRESENT can take keys of either 80 or 128 bits. In 5.1.6.2 the version with an 80-bit key (PRESENT-80) and
in 5.1.6.3 the 128-bit version (PRESENT-128) is described.
© ISO/IEC 2012 – All rights reserved 5

5.1.6.2 80-bit key for PRESENT-80
The user-supplied key is stored in a key register K and represented as k k … k . At round i the 64-bit round
79 78 0
i i i
key K = k k … k consists of the 64 leftmost bits of the current contents of register K. Thus at round i we
i 63 62 0
have that:
i i i
K = k k . k = k k . k .
i 63 62 0 79 78 16
After extracting the round key K , the key register K = k k . k is updated as follows.
i 79 78 0
1) k k . k k ← k k . k k
79 78 1 0 18 17 20 19
2) k k k k ← S[k k k k ]
79 78 77 76 79 78 77 76
3) k k k k k ← k k k k k  round_counter
19 18 17 16 15 19 18 17 16 15
In words, the key register is rotated by 61 bit positions to the left, the left-most four bits are passed through the
PRESENT S-box, and the round_counter value i is exclusive-ORed with bits k k k k k of K where the least
19 18 17 16 15
significant bit of round_counter is on the right. The rounds are numbered from 1 ≤ i ≤ 31 and round_counter = i.
Figure 4 depicts the key schedule for PRESENT-80 graphically.

Figure 4 — PRESENT-80 key schedule

5.1.6.3 128-bit key for PRESENT-128
Similar to the 80-bit variant the user-supplied key is stored initially in a key register K and is represented as
i i i
k k … k . At round i the 64-bit round key K = k k … k consists of the 64 leftmost bits of the current
127 126 0 i 63 62 0
contents of register K. Thus at round i we have that:
i i i
K = k k . k = k k . k .
i 63 62 0 127 126 64
After extracting the round key K , the key register K = k k . k is updated as follows.
i 127 126 0
1) k k . k k ← k k . k k
127 126 1 0 66 65 68 67
2) k k k k ← S[k k k k ]
127 126 125 124 127 126 125 124
3) k k k k ← S[k k k k ]
123 122 121 120 123 122 121 120
4) k k k k k ← k k k k k  round_counter
66 65 64 63 62 66 65 64 63 62
6 © ISO/IEC 2012 – All rights reserved

In words, the key register is rotated by 61 bit positions to the left, the left-most eight bits are passed through
the PRESENT S-box, and the round_counter value i is exclusive-ORed with bits k k k k k of K where the
66 65 64 63 62
least significant bit of round_counter is on the right. The rounds are numbered from 1 ≤ i ≤ 31 and round_counter
= i. Figure 5 depicts the key schedule for PRESENT-128 graphically.

Figure 5 — PRESENT-128 key schedule
6 Lightweight block cipher with a block size of 128 bits
6.1 CLEFIA
6.1.1 CLEFIA algorithm
The CLEFIA algorithm [14] is a symmetric block cipher that can process data blocks of 128 bits using a cipher
key of length 128, 192, or 256 bits. The number of rounds is 18, 22 and 26 for CLEFIA with 128-bit, 192-bit
and 256-bit keys, respectively. The total number of round keys depends on the key length. The CLEFIA
encryption and decryption functions require 36, 44 and 52 round keys for 128-bit, 192-bit and 256-bit keys,
respectively.
6.1.2 CLEFIA specific notations

a bit string of bit length b
(b)
n
{0,1} A set of n-bit binary strings
n
 Multiplication in GF(2 )
 i i-bit left cyclic shift operation
~
a Bitwise complement of bit string a
n
 n times operations of the DoubleSwap function 
© ISO/IEC 2012 – All rights reserved 7

6.1.3 CLEFIA encryption
The encryption process of CLEFIA is based on the 4-branch r-round generalized Feistel structure GFN . Let
4,r
128 32
P, C  {0,1} be a plaintext and a ciphertext. Let P , C  {0,1} (0 i < 4) be divided plaintexts and
i i
ciphertexts where P = P || P || P || P and C = C || C || C || C . Let WK , WK , WK , WK  {0,1} be whitening
0 1 2 3 0 1 2 3 0 1 2 3
keys and RK  {0,1} (0  i < 2r) be round keys provided by the key schedule. Then, r-round encryption
i
function ENC is defined as follows:
r
ENC :
r
1) T || T || T || T ← P || (P  WK ) || P || (P  WK )
0 1 2 3 0 1 0 2 3 1
2) T || T || T || T ← GFN (RK , ., RK , T , T , T , T )
0 1 2 3 4,r 0 2r-1 0 1 2 3
3) C || C || C || C ← T || (T  WK ) || T || (T  WK )
0 1 2 3 0 1 2 2 3 3
6.1.4 CLEFIA decryption
The decryption function DEC is defined as follows:
r
DEC :
r
1) T || T || T || T ← C || (C  WK ) || C || (C  WK )
0 1 2 3 0 1 2 2 3 3
−1
2) T || T || T || T ← GFN (RK , ., RK , T , T , T , T )
0 1 2 3 4,r 0 2r-1 0 1 2 3
3) P || P || P || P ← T || (T  WK ) || T || (T  WK )
0 1 2 3 0 1 0 2 3 1
Figure 6 illustrates both ENC and DEC .
r r
8 © ISO/IEC 2012 – All rights reserved

P P P P C C C C
0 1 2 3 0 1 2 3
32 32 32 32 32 32 32 32
/ / / / / / / /
RK RK
2r−2 2r−1
RK WK RK WK WK WK
0 0 1 1 2 3
F F F F
0 1 0 1
RK RK RK RK
2 3 2r−4 2r−3
F F F F
0 1 0 1
RK RK
RK RK 2r−6 2r−5
4 5
F F F F
0 1 0 1
. . . . . . . .
. . . . . . . .
. . . . . . . .
RK RK
2r−6 2r−5 RK RK
4 5
F F F F
0 1 0 1
RK RK
2r−4 2r−3 RK RK
2 3
F F F F
0 1 0 1
RK RK
RK RK
2r−2 2r−1 0 1
F F F F
0 1 0 1
WK WK WK WK
2 3 0 1
32 32 32 32 32 32 32 32
/ / / / / / / /
C C C C P P P P
0 1 2 3 0 1 2 3
ENC DEC
r r
Figure 6 — The encryption procedure and the decryption procedure of CLEFIA

6.1.5 CLEFIA building blocks
6.1.5.1 GFN
d,r
The fundamental structure of CLEFIA is a generalized Feistel structure. This structure is employed in both a
data processing part and a key schedule part.
CLEFIA uses a 4-branch and an 8-branch generalized Feistel network. The 4-branch generalized Feistel
network is used in the data processing part and the key schedule for a 128-bit key. The 8-branch generalized
Feistel network is applied in the key schedule for a 192-bit/256-bit key. We denote d-branch r-round
generalized Feistel network employed in CLEFIA as GFN . GFN uses two different 32-bit F-functions F and
d,r d,r 0
F .
© ISO/IEC 2012 – All rights reserved 9

For d pairs of 32-bit input X and output Y (0  i < d), and dr/2 32-bit round keys RK (0  i < dr/2), GFN (d = 4,
i i i d,r
−1
8) and the inverse function GFN (d = 4) are defined as follows.
d,r
GFN :
4,r
1) T || T || T || T ← X || X || X || X
0 1 2 3 0 1 2 3
2) For i = 0 to r − 1 do the following:
2.1)  T ← T  F (RK , T )
1 1 0 2i 0
T ← T  F (RK , T )
3 3 1 2i + 1 2
2.2)  T || T || T || T ← T || T || T || T
0 1 2 3 1 2 3 0
3) Y || Y || Y || Y ← T || T || T || T
0 1 2 3 3 0 1 2
GFN :
8,r
1) T || T || . || T ← X || X || . || X
0 1 7 0 1 7
2) For i = 0 to r − 1 do the following:
2.1)  T ← T  F (RK , T )
1 1 0 4i 0
T ← T  F (RK , T )
3 3 1 4i + 1 2
T ← T  F (RK , T )
5 5 0 4i + 2 4
T ← T  F (RK , T )
7 7 1 4i + 3 6
2.2)  T || T || . || T || T ← T || T || . || T || T
0 1 6 7 1 2 7 0
3) Y || Y || . || Y || Y ← T || T || . || T || T
0 1 6 7 7 0 5 6
−1
The inverse function GFN is obtained by changing the order of RK and the direction of word rotation at 2.2)
4,r i
and 3) in GFN .
4,r
−1
GFN :
4,r
1) T || T || T || T ← X || X || X || X
0 1 2 3 0 1 2 3
2) For i = 0 to r − 1 do the following:
2.1)  T ← T  F (RK , T )
1 1 0 2(r - i) - 2 0
T ← T  F (RK , T )
3 3 1 2(r - i) - 1 2
2.2)  T || T || T || T ← T || T || T || T
0 1 2 3 3 0 1 2
3) Y || Y || Y || Y ← T || T || T || T
0 1 2 3 1 2 3 0
10 © ISO/IEC 2012 – All rights reserved

6.1.5.2 F-functions
Two F-functions F and F used in GFN are defined as follows:
0 1 d,r
F : (RK , x )  y
0 (32) (32) (32)
1) V ← RK  x
2) Let V = V || V || V || V , V  {0,1} .
0 1 2 3 i
V ← S (V )
0 0 0
V ← S (V )
1 1 1
V ← S (V )
2 0 2
V ← S (V )
3 1 3
3) Let y = y || y || y || y , y  {0,1} .
0 1 2 3 i
 y  V 
0 0
   
y V
   
1 1
 M
  0 
y V
2 2
   
   
y V
3 3
   
F : (RK , x )  y
1 (32) (32) (32)
1) V ← RK  x
2) Let V = V || V || V || V , V  {0,1} .
0 1 2 3 i
V ← S (V )
0 1 0
V ← S (V )
1 0 1
V ← S (V )
2 1 2
V ← S (V )
3 0 3
3) Let y = y || y || y || y , y  {0,1} .
0 1 2 3 i
y V
   
0 0
   
y V
   
1 1
 M
   
y V
2 2
   
   
y V
 3  3
S and S are nonlinear 8-bit S-boxes, and M and M are 4x4 diffusion matrices described in the following
0 1 0 1
clause. In each F-function two S-boxes and a matrix are used, but the S-boxes are used in a different order
and the matrices differ. Figure 7 shows a graphical representation of the F-functions.
© ISO/IEC 2012 – All rights reserved 11

k k k k
0 1 2 3
k k k k
0 1 2 3
//// 8888
////
8 8
8 8
x y
0 / S / 0 x y
0 0 / / 0
S
8 8
8 8
x y
1 / S / 1 x y
1 1 / S / 1
M
M
8 8
8 8
x y
2 / S / 2 x y
0 2 / S / 2
8 8
8 8
x y
3 / S / 3 x y
1 3 / S / 3
F
0 F
Figure 7 — F-functions
6.1.5.3 S-boxes
CLEFIA employs two different types of 8-bit S-boxes S and S : S is based on four 4-bit random S-boxes, and
0 1 0
S is based on the inverse function over GF(2 ).
Tables 5 and 6 show the output values of S and S , respectively. In these tables all values are expressed in a
0 1
hexadecimal notation. For an 8-bit input of an S-box, the upper 4 bits indicate a row and the lower 4 bits
indicate a column. For example, if a value 0xab is input, 0x7e is output by S because it is on the cross line of
the row indexed by 'a.' and the column indexed by '.b'.
Table 5 — S
.0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .a .b .c .d .e .f
0. 57 49 d1 c6 2f 33 74 fb 95 6d 82 ea 0e b0 a8 1c
1. 28 d0 4b 92 5c ee 85 b1 c4 0a 76 3d 63 f9 17 af
2. bf a1 19 65 f7 7a 32 20 06 ce e4 83 9d 5b 4c d8
3. 42 5d 2e e8 d4 9b 0f 13 3c 89 67 c0 71 aa b6 f5
4. a4 be fd 8c 12 00 97 da 78 e1 cf 6b 39 43 55 26
5. 30 98 cc dd eb 54 b3 8f 4e 16 fa 22 a5 77 09 61
6. d6 2a 53 37 45 c1 6c ae ef 70 08 99 8b 1d f2 b4
7. e9 c7 9f 4a 31 25 fe 7c d3 a2 bd 56 14 88 60 0b
8. cd e2 34 50 9e dc 11 05 2b b7 a9 48 ff 66 8a 73
9. 03 75 86 f1 6a a7 40 c2 b9 2c db 1f 58 94 3e ed
a. fc 1b a0 04 b8 8d e6 59 62 93 35 7e ca 21 df 47
b. 15 f3 ba 7f a6 69 c8 4d 87 3b 9c 01 e0 de 24 52
c. 7b 0c 68 1e 80 b2 5a e7 ad d5 23 f4 46 3f 91 c9
d. 6e 84 72 bb 0d 18 d9 96 f0 5f 41 ac 27 c5 e3 3a
e. 81 6f 07 a3 79 f6 2d 38 1a 44 5e b5 d2 ec cb 90
f. 9a 36 e5 29 c3 4f ab 64 51 f8 10 d7 bc 02 7d 8e
12 © ISO/IEC 2012 – All rights reserved

Table 6 — S
.0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .a .b .c .d .e .f
0.
6c da c3 e9 4e 9d 0a 3d b8 36 b4 38 13 34 0c d9
1. bf 74 94 8f b7 9c e5 dc 9e 07 49 4f 98 2c b0 93
2. 12 eb cd b3 92 e7 41 60 e3 21 27 3b e6 19 d2 0e
3. 91 11 c7 3f 2a 8e a1 bc 2b c8 c5 0f 5b f3 87 8b
4. fb f5 de 20 c6 a7 84 ce d8 65 51 c9 a4 ef 43 53
5. 25 5d 9b 31 e8 3e 0d d7 80 ff 69 8a ba 0b 73 5c
6. 6e 54 15 62 f6 35 30 52 a3 16 d3 28 32 fa aa 5e
7.
cf ea ed 78 33 58 09 7b 63 c0 c1 46 1e df a9 99
8. 55 04 c4 86 39 77 82 ec 40 18 90 97 59 dd 83 1f
9. 9a 37 06 24 64 7c a5 56 48 08 85 d0 61 26 ca 6f
a. 7e 6a b6 71 a0 70 05 d1 45 8c 23 1c f0 ee 89 ad
b. 7a 4b c2 2f db 5a 4d 76 67 17 2d f4 cb b1 4a a8
c.
b5 22 47 3a d5 10 4c 72 cc 00 f9 e0 fd e2 fe ae
d. f8 5f ab f1 1b 42 81 d6 be 44 29 a6 57 b9 af f2
e. d4 75 66 bb 68 9f 50 02 01 3c 7f 8d 1a 88 bd ac
f. f7 e4 79 96 a2 fc 6d b2 6b 03 e1 2e 7d 14 95 1d

a) S-box S
8 8
S : {0,1} → {0,1} : x  y = S (x) is generated by combining four 4-bit S-boxes SS , SS , SS and SS in the
0 0 0 1 2 3
following way. The values of these S-boxes are defined in Table 7.
1) t ← SS (x ), t ← SS (x ), where x = x || x , x{0, 1}
0 0 0 1 1 1 0 1 i
2) u ← t  0x2 t , u ← 0x2 t  t
0 0 1 1 0 1
3) y ← SS (u ), y ← SS (u ), where y = y || y , y  {0, 1}
0 2 0 1 3 1 0 1 i
4 4
The multiplication in 0x2 t is performed in GF(2 ) defined by the lexicographically first primitive polynomial z
i
+ z + 1. Figure 8 shows the construction of S .
Table 7 — SS (0  i  4)
i
x 0 1 2 3 4 5 6 7 8 9 a b c d e f
e 6 c a 8 7 2 f b 1 4 0 5 9 d 3
SS (x)
SS (x) 6 4 0 d 2 b a 3 9 c e f 8 7 5 1
b 8 5 e a 6 4 c f 7 2 3 1 0 d 9
SS (x)
SS (x) a 2 6 d 3 4 5 e 0 7 8 9 b f c 1
© ISO/IEC 2012 – All rights reserved 13

4 4
x SS SS y
0 / 0 2 / 0
×2
×2
4 4
x y
1 / SS SS / 1
1 3
Figure 8 — S
b) S-box S
8 8
S : {0,1} → {0,1} : x  y = S (x) is defined as follows:
1 1
1
 g(( f (x)) ) if f (x) 0
y

g(0) if f (x) 0

8 8 4 3 2
The inverse function is performed in GF(2 ) defined by a primitive polynomial z + z + z + z + 1 (= 0x11d).
f and g are affine transformations over GF(2), which are defined as follows.
8 8
f : {0,1} → {0,1} : x  y = f(x),
y 0 0 0 1 1 0 0 0 x 0
      
0 0
      
y 0 1 0 1 0 0 0 1 x 0
      
1 1
      
y 0 0 0 0 0 0 0 1 x 0
2 2
      
 y  0 0 0 0 0 1 1 0 x  1
3 3
 
      
y 0 1 1 0 0 1 0 1 x 1
4 4
      
      
y 0 1 0 1 1 1 0 0 x 1
5 5
      
y 0 1 1 0 0 0 0 0 x 1
 6   6  
 
    
y 1 0 0 0 0 0 0 1 x 0
 7   7  
8 8
g : {0,1} → {0,1} : x  y = g(x),
y x
  0 0 0 0 1 0 1 0  0
0 0

     
y x
0 1 0 0 0 0 0 1 1
      
1 1
      
y x
0 1 0 1 1 0 0 0 1
2 2
      
y x
  0 0 1 0 0 0 0 0  0
3 3
 
      
y x
0 0 1 1 0 0 0 0 1
4 4

     
      
y x
0 0 0 0 0 0 1 0 0
5 5

     
y x
1 0 0 1 0 0 0 0 0
 6   6  
      
y x
0 1 0 0 0 1 0 0 1
7   7  

Here, x = x || x || x || x || x || x || x || x and y = y || y || y || y || y || y || y || y , x , y  {0,1}. The constants in f
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 i i
and g can be represented as 0x1e and 0x69, respectively.
14 © ISO/IEC 2012 – All rights reserved

6.1.5.4 Diffusion matrices
The matrices M and M are defined as follows.
0 1
01 02 04 06 01 08 02 0a
   
   
02 01 06 04 08 01 0a 02
   
M = ,   M = .
0 1
   
04 06 01 02 02 0a 01 08
   
   
06 04 02 01 0a 02 08 01
   
The multiplications of a matrix and a vector are performed in GF(2 ) defined by the lexicographically first
8 4 3 2
primitive polynomial z + z + z + z + 1 ( = 0x11d).
6.1.6 CLEFIA key schedule
6.1.6.1 Overall structure
The key schedule of CLEFIA supports 128, 192 and 256-bit keys and outputs whitening keys WK (0  i < 4)
i
and round keys RK (0  j < 2r) for the data processing part. Let K be the key and L be an intermediate key.
j
The key schedule consists of the following two steps.
1) Generating L from K.
2) Expanding K and L (Generating WK and RK ).
i j
To generate L from K, the key schedule for a 128-bit key uses a 128-bit permutation GFN , while the key
4,12
schedules for 192/256-bit keys use a 256-bit permutation GFN .
8,10
6.1.6.2 Key schedule for a 128-bit key

The 128-bit intermediate key L is generated in step 1 by applying GFN which takes twenty-four 32-bit
4,12
(128)
constant values CON (0  i < 24) as round keys and K = K || K || K || K as an input. Then K and L are
i 0 1 2 3
used to generate WK (0  i < 4) and RK (0  j < 36) in steps 2 and 3. The thirty-six 32-bit constant values
i j
(128)

CON (24 i < 60) used in step 3 are defined in 6.1.6.6. The DoubleSwap function  is defined in 6.1.6.5.
i
(Generating L from K)
(128) (128)
1) L ← GFN (CON , ., CON , K , ., K )
4,12 0 23 0 3
(Expanding K and L)
2) WK || WK || WK || WK ← K
0 1 2 3
3) For i = 0 to 8 do the following:
(128) (128) (128) (128)

T ← L (CON || CON || CON || CON )
24 + 4i 24 + 4i + 1 24 + 4i + 2 24 + 4i + 3
L ←  (L)
if i is odd: T ← T  K
RK || RK || RK || RK ← T
4i 4i + 1 4i + 2 4i + 3
© ISO/IEC 2012 – All rights reserved 15

Table 8 shows the relationship between generated round keys and related data.
Table 8 — Expanding K and L (128-bit key)
WK WK WK WK K
0 1 2 3
(128) (128) (128) (128)
RK RK RK RK
0 1 2 3
L           (CON || CON || CON || CON )
24 25 26 27
(128) (128) (128) (128)
RK RK RK RK
4 5 6 7
 (L)  K  (CON || CON || CON || CON )
28 29 30 31
2 (128) (128) (128) (128)
RK RK RK RK
8 9 10 11
 (L)      (CON || CON || CON || CON )
32 33 34 35
3 (128) (128) (128) (128)
RK RK RK RK
12 13 14 15
 (L)  K  (CON || CON || CON || CON )
36 37 38 39
4 (128) (128) (128) (128)
RK RK RK RK
16 17 18 19
 (L)      (CON || CON || CON || CON )
40 41 42 43
5 (128) (128) (128) (128)
RK RK RK RK
20 21 22 23
 (L)  K  (CON || CON || CON || CON )
44 45 46 47
6 (128) (128) (128) (128)
RK RK RK RK
24 25 26 27
 (L)      (CON || CON || CON || CON )
48 49 50 51
7 (128) (128) (128) (128)
RK RK RK RK
28 29 30 31
 (L)  K  (CON || CON || CON || CON )
52 53 54 55
8 (128) (128) (128) (128)
RK RK RK RK
32 33 34 35
 (L)      (CON || CON || CON || CON )
56 57 58 59
6.1.6.3 Key schedule for a 192-bit key
Two 128-bit values K and K are generated from a 192-bit key K = K || K || K || K || K || K , where K 
L R 0 1 2 3 4 5 i
32 (192)
{0,1} . Then two 128-bit values L and L are generated by applying GFN which takes CON (0  i < 40)
L R 8,10 i
as round keys and K || K as a 256-bit input. Figure 9 shows the construction of GFN .
L R 8,10
K , K and L , L are used to generate WK (0  i < 4) and RK (0  j < 44) in steps 4 and 5 below. In the latter
L R L R i j
(192)
part, forty-four 32-bit constant values CON (40  i < 84) are used.
i
The following steps show the 192-bit/256-bit key schedule. For the 192-bit key schedule, the value of k is set
as 192.
(Generating L , L from K , K for a k-bit key)
L R L R
1) Set k = 192 or k = 256
~ ~
2) If k = 192    : K ← K || K || K || K ,  K ← K || K || K || K
L 0 1 2 3 R 4 5 0 1
else if k = 256 : K ← K || K || K || K ,  K ← K || K || K || K
L 0 1 2 3 R 4 5 6 7
3) Let K = K || K || K || K , K = K || K || K || K
L L0 L1 L2 L3 R R0 R1 R2 R3
(k) (k)
L || L ← GFN (CON , . , CON , K , . , K , K , . , K )
L R 8,10 0 39 L0 L3 R0 R3
(Expanding K , K and L , L for a k-bit key)
L R L R
4) WK || WK || WK || WK ← K  K
0 1 2 3 L R
5) For i = 0 to 10 (if k = 192), or 12 (if k = 256) do the following:
If (i mod 4) = 0 or 1:
(k) (k) (k) (k)
T  ← L  (CON || CON || CON || CON )
L 40 + 4i 40 + 4i + 1 40 + 4i + 2 40 + 4i + 3
L ←  (L )
L L
if i is odd: T ← T  K
R
16 © ISO/IEC 2012 – All rights reserved

else:
(k) (k) (k) (k)
T ← L  (CON || CON || CON || CON )
R 40 + 4i 40 + 4i + 1 40 + 4i + 2 40 + 4i + 3
L ← (L )
R R
 K
if i is odd: T ← T
L
RK || RK || RK || RK ← T
4i 4i + 1 4i + 2 4i + 3
K K K K K K K K
L0 L1 L2 L3 R0 R1 R2 R3
32 32 32 32 32 32 32 32
/ / / / / / / /
(k) (k) (k) (k)
CON CON CON CON
0 1 2 3
F F F F
0 1 0 1
(k) (k)
(k) (k)
CON CON CON CON
4 6
5 7
F F F F
0 1 0 1
(k) (k)
(k) (k)
CON CON
CON CON
8 10
9 11
F F F F
0 1 0 1
. . . . . . . .
. . . . . . . .
. . . . . . . .
(k) (k) (k) (k)
CON CON CON CON
28 29 30 31
F F F F
0 1 0 1
(k) (k) (k) (k)
CON CON CON CON
32 33 34 35
F F F F
0 1 0 1
(k) (k) (k) (k)
CON CON CON CON
36 37 38 39
F F F F
0 1 0 1
32 32 32 32 32 32 32 32
/ / / / / / / /
L L L L L L L L
L0 L1 L2 L3 R0 R1 R2 R3
Figure 9 — Structure of GFN
8,10
© ISO/IEC 2012 – All rights reserved 17

Table 9 shows the relationship between generated round keys and related data.
Table 9 — Expanding K , K , L and L (192-bit key)
L R L R
WK WK WK WK
0 1 2 3 K     K
L R
(192) (192) (192) (192)
RK RK RK RK
0 1 2 3
L           (CON || CON || CON || CON )
L 40 41 42 43
(192) (192) (192) (192)
RK RK RK RK
4 5 6 7
 (L )  K  (CON || CON || CON || CON )
L R 44 45 46 47
(192) (192) (192) (192)
RK RK RK RK
8 9 10 11
L           (CON || CON || CON || CON )
R 48 49 50 51
(192) (192) (192) (192)
RK RK RK RK
12 13 14 15
 (L )  K  (CON || CON || CON || CON )
R L 52 53 54 55
2 (192) (192) (192) (192)
RK RK RK RK
16 17 18 19
 (L )       (CON || CON || CON || CON )
L 56 57 58 59
3 (192) (192) (192) (192)
RK RK RK RK
20 21 22 23
 (L )  K  (CON || CON || CON || CON )
L R 60 61 62 63
2 (192) (192) (192) (192)
RK RK RK RK
24 25 26 27
 (L )       (CON || CON || CON || CON )
R 64 65 66 67
3 (192) (192) (192) (192)
RK RK RK RK
28 29 30 31
 (L )  K (CON || CON || CON || CON )
R L 68 69 70 71
4 (192) (192) (192) (192)
RK RK RK RK
32 33 34 35
 (L )       (CON || CON || CON || CON )
L 72 73 74 75
5 (192) (192) (192) (192)
RK RK RK RK
36 37 38 39
 (L )  K (CON || CON || CON || CON )
L R 76 77 78 79
4 (192) (192) (192) (192)
RK RK RK RK
40 41 42 43
 (L )       (CON || CON || CON || CON )
R 80 81 82 83
6.1.6.4 Key schedule for a 256-bit key

The key schedule for a 256-bit key is almost the same as that for 192-bit key, except for constant values, the
required number of RK , and the initialization of K .
i R
For a 256-bit key, the value of k is set as 256, and the steps are almost the same as in the 192-bit key case
(256)
(see description in 6.1.6.3). The difference is that we use CON (0  i < 40) as round keys to generate L
i L
(256)
and L , and then to generate RK (0  j < 52), we use fifty-two 32-bit constant values CON (40  i < 92).
R j i
Table 10 shows the relationship between generated round keys and related data.
Table 10 — Expanding K , K , L and L (256-bit key)
L R L R
WK WK WK WK
0 1 2 3      K
K
L R
(256) (256) (256) (256)
RK RK RK RK
0 1 2 3
L           (CON || CON || CON || CON )
L 40 41 42 43
(256) (256) (256) (256)
RK RK RK RK
4 5 6 7
 (L )  K  (CON || CON || CON || CON )
L R 44 45 46 47
(256) (256) (256) (256)
RK RK RK RK
8 9 10 11
L           (CON || CON || CON || CON )
R 48 49 50 51
(256) (256) (256) (256)
RK RK RK RK
12 13 14 15
 (L )  K  (CON || CON || CON || CON )
R L 52 53 54 55
2 (256) (256) (256) (256)
RK RK RK RK
16 17 18 19
 (L )       (CON || CON || CON || CON )
L 56 57 58 59
3 (256) (256) (256) (256)
RK RK RK RK
20 21 22 23
 (L )  K  (CON || CON || CON || CON )
L R 60 61 62 63
2 (256) (256) (256) (256)
RK RK RK RK
24 25 26 27
 (L )       (CON || CON || CON || CON )
R 64 65 66 67
3 (256) (256) (256) (256)
RK RK RK RK
28 29 30 31
 (L )  K  (CON || CON || CON || CON )
R L 68 69 70 71
4 (256) (256) (256) (256)
RK RK RK RK
32 33 34 35
 (L )       (CON || CON || CON || CON )
L 72 73 74 75
5 (256) (256) (256) (256)
RK RK RK RK
36 37 38 39
 (L )  K  (CON || CON || CON || CON )
L R 76 77 78 79
4 (256) (256) (256) (256)
RK RK RK RK
40 41 42 43
 (L )       (CON || CON || CON || CON )
R 80 81 82 83
5 (256) (256) (256) (256)
RK RK RK RK
44 45 46 47
 (L )  K  (CON || CON || CON || CON )
R L 84 85 86 87
6 (256) (256) (256) (256)
RK RK RK RK
48 49 50 51
 (L )       (CON || CON || CON || CON )
L 88 89 90 91
18 © ISO/IEC 2012 – All rights reserved

6.1.6.5 DoubleSwap function
128 128
The DoubleSwap function  : {0,1} → {0,1} is defined as follows:
X  Y
(128) (128)
Y = X[7-63] || X[121-127] || X[0-6] || X[64-120],
where X[a-b] denotes a bit string cut from the a-th bit to the b-th bit of X. Bit 0 is the most significant bit.
The DoubleSwap function is illustrated in Figure 10.
128 bits
7757 57
57 77 57
Figure 10 — DoubleSwap Function Σ
6.1.6.6 Constant values
(k)
32-bit constant values CON are used in the key schedule algorithm. We need 60, 84 and 92 constant values
i
16 16
for 128, 192 and 256-bit keys, respectively. Let P = 0xb7e1 (= ( − 2) 2 ) and Q = 0x243f (= (− 3) 2 ),
e
(16) (16)
(k)
where e is the base of the natural logarithm (2.71828.) and  is the circle ratio (3.14159.). CON , for k =
i
(k)
128,192, 256 are generated in the following way (See Table 11 for the repetition numbers l and the initial
(k)
values IV ).
(k) (k)
1) T ← IV
(k)
2) For i = 0 to l − 1 do the following:
(k) (k) ~ (k)
2.1) CON ← (T  P) || ( T <<< 1)
2i i i
(k) ~ (k) (k)
2.2) CON ← ( T  Q) || (T <<< 8)
2i+1 i i
(k) (k)
-1
2.3) T ← T  0x0002
i + 1 i
16 16 15 13
In step 2.3, the multiplication is performed in the field GF(2 ) defined by a primitive polynomial z + z + z +
11 5 4 -1
1)
z + z + z + 1 ( = 0x1a831) . 0x0002 is a constant denoting the multiplicative inverse of a finite field
element z ( = 0x0002).
Table 11 — Required numbers of constant values
(k) (k) (k)
k # of CON l IV
i
128 60 30
0x428a ( ( 21) 2 )
192 84 42
0x7137 ( ( 31) 2 )
256 92 46
0xb5c0 ( ( 51) 2 )
(k) (k)
Tables 12 - 14 show the values of T and Tables 15 - 17 show the values of CON .
i i
3 16
1)
The lower 16-bit value is defined as 0xa831 = ( 101 4) 2 . '101' is the smallest prime number satisfying the

primitive polynomial condition in this form.
© ISO/IEC 2012 – All rights reserved 19

(128)
Table 12 — T
i
i 0 1 2 3 4 5 6 7
(128)
T 428a 2145 c4ba 625d e536 729b ed55 a2b2
i
i 8 9 10 11 12 13 14 15
(128)
T 5159 fcb4 7e5a 3f2d cb8e 65c7 e6fb a765
i
i 16 17 18 19 20 21 22 23
(128)
T 87aa 43d5 f5f2 7af9 e964 74b2 3a59 c934
i
i 24 25 26 27 28 29
(192)
T 649a 324d cd3e 669f e757 a7b3
i
(192)
Table 13 — T
i
i 0 1 2 3 4 5 6 7
(192)
7137 ec83 a259 8534 429a 214d c4be 625f
T
i
i 8 9 10 11 12 13 14 15
(192)
e537 a683 8759 97b4 4bda 25ed c6ee 6377
T
i
i 16 17 18 19 20 21 22 23
(192)
e5a3 a6c9 877c 43be 21df c4f7 b663 8f29
T
i
i 24 25 26 27 28 29 30 31
(192)
938c 49c6 24e3 c669 b72c 5b96 2dcb c2fd
T
i
i 32 33 34 35 36 37 38 39
(192)
b566 5ab3 f941 a8b8 545c 2a2e 1517 de93
T
i
i 40 41
(192)
bb51 89b0
T
i
(256)
Table 14 — T
i
i 0 1 2 3 4 5 6 7
(256)
T b5c0 5ae0 2d70 16b8 0b5c 05ae 02d7 d573
i
i 8 9 10 11 12 13 14 15
(256)
T bea1 8b48 45a4 22d2 1169 dcac 6e56 372b
i
i 16 17 18 19 20 21 22 23
(256)
T cf8d b3de 59ef f8ef a86f 802f 940f 9e1f
i
i 24 25 26 27 28 29 30 31
(256)
T 9b17 9993 98d1 9870 4c38 261c 130e 0987
i
i 32 33 34 35 36 37 38 39
(256)
T d0db bc75 8a22 4511 f690 7b48 3da4 1ed2
i
i 40 41 42 43 44 45
(256)
T 0f69 d3ac 69d6 34eb ce6d b32e
i
20 © ISO/IEC 2012 – All rights reserved

(128)
Table 15 — CON
i
i 0 1 2 3
(128)
f56b7aeb 994a8a42 96a4bd75 fa854521
CON
i
i 4 5 6 7
(128)
735b768a 1f7abac4 d5bc3b45 b99d5d62
CON
i
i 8 9 10 11
(128)
52d73592 3ef636e5 c57a1ac9 a95b9b72
CON
i
i 12 13 14 15
(128)
5ab42554 369555ed 1553ba9a 7972b2a2
CON
i
i 16 17 18 19
(128)
e6b85d4d 8a995951 4b550696 2774b4fc
CON
i
i 20 21 22 23
(128)
c9bb034b a59a5a7e 88cc81a5 e4ed2d3f
CON
i
i 24 25 26 27
(128)
7c6f68e2 104e8ecb d2263471 be07c765
CON
i
i 28 29 30 31
(128)
511a3208 3d3bfbe6 1084b134 7ca565a7
CON
i
i 32 33 34 35
(128)
304bf0aa 5c6aaa87 f4347855 9815d543
CON
i
i 36 37 38 39
(128)
4213141a 2e32f2f5 cd180a0d a139f97a
CON
i
i 40 41 42 43
(128)
5e852d36 32a464e9 c353169b af72b274
CON
i
i 44 45 46 47
(128)
8db88b4d e199593a 7ed56d96 12f434c9
CON
i
i 48 49 50 51
(128)
d37b36cb bf5a9a64 85ac9b65 e98d4d32
CON
i
i 52 53 54 55
(128)
7adf6582 16fe3ecd d17e32c1 bd5f9f66
CON
i
i 56 57 58 59
(128)
50b63150 3c9757e7 1052b098 7c73b3a7
CON
i
© ISO/IEC 2012 – All rights reserved 21

(192)
Table 16 — CON
i
i 0 1 2 3
(192)
CON c6d61d91 aaf73771 5b6226f8 374383ec
i
i 4 5 6 7
(192)
CON 15b8bb4c 799959a2 32d5f596 5ef43485
i
i 8 9 10 11
(192)
CON f57b7acb 995a9a42 96acbd65 fa8d4d21
i
i 12 13 14 15
(192)
CON 735f7682 1f7ebec4 d5be3b41 b99f5f62
i
i 16 17 18 19
(192)
CON 52d63590 3ef737e5 1162b2f8 7d4383a6
i
i 20 21 22 23
(192)
CON 30b8f14c 5c995987 2055d096 4c74b497
i
i 24 25 26 27
(192)
CON fc3b684b 901ada4b 920cb425 fe2ded25
i
i 28 29 30 31
(192)
CON 710f7222 1d2eeec6 d4963911 b8b77763
i
i 32 33 34 35
(192)
CON 524234b8 3e63a3e5 1128b26c 7d09c9a6
i
i 36 37 38 39
(192)
CON 309df106 5cbc7c87 f45f7883 987ebe43
i
i 40 41 42 43
(192)
CON 963ebc41 fa1fdf21 73167610 1f37f7c4
i
i 44 45 46 47
(192)
CON 01829338 6da363b6 38c8e1ac 54e9298f
i
i 48 49 50 51
(192)
CON 246dd8e6 484c8c93 fe276c73 9206c649
i
i 52 53 54 55
(192)
CON 9302b639 ff23e324 7188732c 1da969c6
i
i 56 57 58 59
(192)
CON 00cd91a6 6cec2cb7 ec7748d3 8056965b
i
i 60 61 62 63
(192)
CON 9a2aa469 f60bcb2d 751c7a04 193dfdc2
i
i 64 65 66 67
(192)
CON 02879532 6ea666b5 ed524a99 8173b35a
i
i 68 69 70 71
(192)
CON 4ea00d7c 228141f9 1f59ae8e 7378b8a8
i
i 72 73 74 75
(192)
CON e3bd5747 8f9c5c54 9dcfaba3 f1ee2e2a
i
i 76 77 78 79
(192)
CON a2f6d5d1 ced71715 697242d8 055393de
i
i 80 81 82 83
(192)
CON 0cb0895c 609151bb 3e51ec9e 5270b089
i
22 © ISO/IEC 2012 – All rights reserved

(256)
Table 17 — CON
i
i 0 1 2 3
(256)
CON 0221947e 6e00c0b5 ed014a3f 8120e05a
i
i 4 5 6 7
(256)
CON 9a91a51f f6b0702d a159d28f cd78b816
i
i 8 9 10 11
(256)
CON bcbde947 d09c5c0b b24ff4a3 de6eae05
i
i 12 13 14 15
(256)
CON b536fa51 d917d702 62925518 0eb373d5
i
i 16 17 18 19
(256)
CON 094082bc 6561a1be 3ca9e96e 5088488b
i
i 20 21 22 23
(256)
CON f24574b7 9e64a445 9533ba5b f912d222
i
i 24 25 26 27
(256)
CON a688dd2d caa96911 6b4d46a6 076cacdc
i
i 28 29 30 31
(256)
CON d9b72353 b596566e 80ca91a9 eceb2b37
i
i 32 33 34 35
(256)
CON 786c60e4 144d8dcf 043f9842 681edeb3
i
i 36 37 38 39
(256)
CON ee0e4c21 822fef59 4f0e0e20 232feff8
i
i 40 41 42 43
(256)
CON 1f8eaf20 73af6fa8 37ceffa0 5bef2f80
i
i 44 45 46 47
(256)
CON 23eed7e0 4fcf0f94 29fec3c0 45df1f9e
i
i 48 49 50 51
(256)
CON 2cf6c9d0 40d7179b 2e72ccd8 42539399
i
i 52 53 54 55
(256)
CON 2f30ce5c 4311d198 2f91cf1e 43b07098
i
i 56 57 58 59
(256)
CON fbd9678f 97f8384c 91fdb3c7 fddc1c26
i
i 60 61 62 63
(256)
CON a4efd9e3 c8ce0e13 be66ecf1 d2478709
i
i 64 65 66 67
(256)
CON 673a5e48 0b1bdbd0 0b948714 67b575bc
i
i 68 69 70 71
(256)
CON 3dc3ebba 51e2228a f2f075dd 9ed11145
i
i 72 73 74 75
(256)
CON 417112de 2d5090f6 cca9096f a088487b
i
i 76 77 78 79
(256)
CON 8a4584b7 e664a43d a933c25b c512d21e
i
i 80 81 82 83
(256)
CON b888e12d d4a9690f 644d58a6 086cacd3
i
i 84 85 86 87
(256)
CON de372c53 b216d669 830a9629 ef2beb34
i
i 88 89 90 91
(256)
CON 798c6324 15ad6dce 04cf99a2 68ee2eb3
i
© ISO/IEC 2012 – All rights reserved 23

Annex A
(normative)
Object identifiers
This annex lists the object identifiers assigned to algorithms specified in this part of ISO/IEC 29192.
--
-- ISO/IEC 29192-2 ASN.1 Module
--
LightweightCryptography-2 {
iso(1) standard(0) lightweight-cryptography(29192) part2(2
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...