CLOC and SILC ⋆Name: CLOC and SILC v3
Designers/Submitters: Tetsu Iwata, Nagoya University, Japan
Kazuhiko Minematsu, NEC Corporation, Japan
Jian Guo, Nanyang Technological University, Singapore
Sumio Morioka, Interstellar Technologies, Japan
Eita Kobayashi, NEC Corporation, Japan
Contact Address: Tetsu Iwata, iwata@cse.nagoya-u.ac.jp
Date: September 15, 2016⋆

This document was prepared based on [19,20,21,22,23,24,39,12,18].

1

Introduction

This document describes CLOC, Compact Low-Overhead CFB (pronounced as “clock”), and SILC, SImple Lightweight CFB (pronounced as “silk”), which are blockcipher modes of operation for authenticatedencryption with associated data (AEAD).
The design of CLOC aims at being provably secure and optimizing the implementation overhead
beyond the blockcipher, the precomputation complexity, and the memory requirement. CLOC handles
short input data eﬃciently, and is suitable for use with embedded processors.
CLOC was presented in [19], and the main diﬀerence of our CAESAR submission from [19] is thatthe minimum data unit is deﬁned to be a byte (8 bits) string, and we instantiate CLOC based on AES
blockcipher for 16-byte block length and TWINE blockcipher [39] for 8-byte block length.
SILC is built upon CLOC, and the design of SILC aims at optimizing the hardware implementation
cost of CLOC. SILC also maintains the provable security based on the pseudorandomness of the underlying
blockcipher. SILC is suitable for use within constrained hardware devices, and we instantiate SILC basedon AES blockcipher for 16-byte block length and present [12] and LED [18] for 8-byte block length.
There are many strategies in designing AEAD, and our focus is a blockcipher based scheme without
using heavy operations like multiplication over a ﬁnite ﬁeld. This line of research includes CCM [40],
EAX [10], and EAX-prime [33], and CLOC and SILC improve these schemes in various ways.

2

Notation, Syntax, and Parameters

Notation. Let {0, 1}∗ be the set of all ﬁnite bit strings, including the empty string ε. For an integerℓ ≥ 0, let {0, 1}ℓ be the set of all bit strings of ℓ bits. We let B = {0, 1}8 be the set of bytes (8-bit
strings), and B∗ be the set of all ﬁnite byte strings. For X, Y ∈ {0, 1}∗ , we write X ∥ Y , (X, Y ), or XY
to denote their concatenation. For ℓ ≥ 0, we write 0ℓ ∈ {0, 1}ℓ to denote the bit string that consistsof ℓ zeros, and 1ℓ ∈ {0, 1}ℓ to denote the bit string that consists of ℓ ones. For X ∈ {0, 1}∗ , |X| is its
length in bits, and for ℓ ≥ 1, |X|ℓ = ⌈|X|/ℓ⌉ is the length in ℓ-bit blocks. For X ∈ {0, 1}∗ and ℓ ≥ 0such that |X| ≥ ℓ, msbℓ (X) is the most signiﬁcant (the leftmost) ℓ bits of X. For instance we have
msb1 (1100) = 1 and msb3 (1100) = 110. For X ∈ {0, 1}∗ and ℓ ≥ 1, we write its partition into ℓ-bitℓℓ
blocks as (X[1], . . . , X[x]) ← X, which is deﬁned as follows. If X = ε, then x = 1 and X[1] ← X, where∗
X[1] = ε. Otherwise X[1], . . . , X[x] ∈ {0, 1} are unique bit strings such that X[1] ∥ · · · ∥ X[x] = X,
|X[1]| = · · · = |X[x − 1]| = ℓ, and 1 ≤ |X[x]| ≤ ℓ.
In what follows, we ﬁx a block length n and a blockcipher E : KE × {0, 1}n → {0, 1}n , where KE is a
non-empty set of keys. Let Perm(n) be the set of all permutations over {0, 1}n . We write EK ∈ Perm(n)for the permutation speciﬁed by K ∈ KE , and C = EK (M ) for the ciphertext of plaintext M ∈ {0, 1}nunder key K ∈ KE . Following the CAESAR call for submissions, we restrict all input and output variablesof CLOC and SILC as byte-strings. Also we assume the big-endian format for all variables.
Syntax and Parameters. Let Π ∈ {CLOC, SILC}. Π takes three parameters, a blockcipher E : KE ×{0, 1}n → {0, 1}n , a nonce length ℓN , and a tag length τ , where ℓN and τ are in bits. Here, a nonce
corresponds to a public message number speciﬁed by the CAESAR call for submissions, and we mayinterchangeably use both names. Π does not have the secret message number, i.e. it is always assumed to
be of length zero. We require 1 ≤ ℓN ≤ n − 9 and 1 ≤ τ ≤ n, and assume that ℓN /8 and τ /8 are integers,
and n ∈ {64, 96, 128}.⋆ We write Π[E, ℓN , τ ] for Π that is parameterized by E, ℓN , and τ , and we often
omit the parameters if they are irrelevant or they are clear from the context. Π[E, ℓN , τ ] = (Π-E, Π-D)
consists of the encryption algorithm Π-E and the decryption algorithm Π-D.
Π-E and Π-D have the following syntax.
{
Π-E : KΠ × NΠ × AΠ × MΠ → CT Π
Π-D : KΠ × NΠ × AΠ × CT Π → MΠ ∪ {⊥}KΠ = KE is the key space, which is identical to the key space of the underlying blockcipher, NΠ = BℓN /8
is the nonce space, AΠ = B∗ is the associated data space, MΠ = B∗ is the plaintext space, CT Π =CΠ × TΠ is the ciphertext space, where CΠ = B∗ and TΠ = Bτ /8 is the tag space, and ⊥ ̸∈ MΠ is⋆n = 96 is added from version 3. An example for this case appears in Appendix D.

1

Algorithm CLOC-EK (N, A, M )Algorithm CLOC-DK (N, A, C, T )1. V ← HASHK (N, A)
2. C ← ENCK (V, M )3. T ← PRFK (V, C)
4. return (C, T )1. V ← HASHK (N, A)
2. T ∗ ← PRFK (V, C)
3. if T ̸= T ∗ then return ⊥4. M ← DECK (V, C)
5. return M

Fig. 1. Pseudocode of the encryption and the decryption algorithms of CLOC

the distinguished reject symbol. We write (C, T ) ← Π-EK (N, A, M ) and M ← Π-DK (N, A, C, T ) or⊥ ← Π-DK (N, A, C, T ). For Π = SILC, we make a restriction that the maximum lengths of A, M , andC are all 2n/2 − 1 bytes.⋆⋆3

Specification of CLOC

In this section, we present the speciﬁcation of Π = CLOC.
3.1

Algorithm of CLOC

CLOC-E and CLOC-D are deﬁned in Fig. 1. In these algorithms, we use four subroutines, HASH, PRF,
ENC, and DEC. They have the following syntax.

HASH : KCLOC × NCLOC × ACLOC → {0, 1}nPRF : KCLOC × {0, 1}n × CCLOC → TCLOC
ENC : KCLOC × {0, 1}n × MCLOC → CCLOC
DEC : KCLOC × {0, 1}n × CCLOC → MCLOC
These subroutines are deﬁned in Fig. 2, and illustrated in Fig. 3, Fig. 4, and Fig. 5. We also present
equivalent ﬁgures in Fig. 6, Fig. 7, and Fig. 8. In the ﬁgures, i is the identity function, and i(X) = X
for all X ∈ {0, 1}n . In HASH, the nonce N is padded with param ∈ B which is an 8-bit constantthat depends on the parameters, E, ℓN , and τ . See Sect. 3.2 and Sect. 5 for the concrete values ofparam. In the subroutines, we use the one-zero padding function ozp : B∗ → B∗ , the bit-ﬁxing functions
fix0, fix1 : B∗ → B∗ , and ﬁve tweak functions f1 , f2 , g1 , g2 , and h, which are functions over {0, 1}n .
The one-zero padding function ozp is used to adjust the length of an input string so that the total
length becomes a positive multiple of n bits. For X ∈ B∗ , ozp(X) is deﬁned as ozp(X) = X if |X| = ℓn
for some ℓ ≥ 1, and ozp(X) = X ∥ 10n−1−(|X| mod n) otherwise. We note that ozp(ε) = 10n−1 , and we also
note that, in general, the function is not invertible.
The bit-ﬁxing functions fix0 and fix1 are used to ﬁx the most signiﬁcant bit of an input string to zeroand one, respectively. For X ∈ B∗ , fix0(X) is deﬁned as fix0(X) = X ∧ 01|X|−1 , and fix1(X) is deﬁned as
fix1(X) = X ∨ 10|X|−1 , where ∧ and ∨ are the bit-wise AND operation, and the bit-wise OR operation,
respectively.
The tweak function h is used in HASH if the most signiﬁcant bit of ozp(A[1]) is one. We use f1 and f2
in HASH and PRF, where f1 is used if the last input block is full (i.e., if |A[a]| = n or |C[m]| = n) and f2 isused otherwise. We use g1 and g2 in PRF, where we use g1 if the second argument of the input is the empty
n/4
string (i.e., |C| = 0), and otherwise we use g2 . Now for X ∈ {0, 1}n , let (X[1], X[2], X[3], X[4]) ← X.
Then f1 , f2 , g1 , g2 , and h are deﬁned as follows.

f1 (X) = (X[1, 3], X[2, 4], X[1, 2, 3], X[2, 3, 4])





f2 (X) = (X[2], X[3], X[4], X[1, 2])
g1 (X) = (X[3], X[4], X[1, 2], X[2, 3])
g2 (X) = (X[2], X[3], X[4], X[1, 2])h(X) = (X[1, 2], X[2, 3], X[3, 4], X[1, 2, 4])⋆⋆This does not mean that CLOC does not have a restriction. See Sect. 7.

2

Algorithm HASHK (N, A)

Algorithm PRFK (V, C)n

1. (A[1], . . . , A[a]) ← A
1. if |C| = 0 then
2. SH [1] ← EK (fix0(ozp(A[1])))
2.
T ← msbτ (EK (g1 (V )))3. if msb1 (ozp(A[1])) = 1 then3.
return Tn4.
SH [1] ← h(SH [1])4. (C[1], . . . , C[m]) ← C
5. if a ≥ 2 then
5. SP [0] ← EK (g2 (V ))6.
for i ← 2 to a − 1 do
6. for i ← 1 to m − 1 do
7.
SH [i] ← EK (SH [i − 1] ⊕ A[i])7.
SP [i] ← EK (SP [i − 1] ⊕ C[i])8.
SH [a] ← EK (SH [a − 1] ⊕ ozp(A[a]))8. if |C[m]| = n then
9. if |A[a]| = n then9.
SP [m] ← EK (f1 (SP [m − 1] ⊕ C[m]))10.
V ← f1 (SH [a] ⊕ ozp(param ∥ N ))10. else// 1 ≤ |C[m]| ≤ n − 1
11. else// 0 ≤ |A[a]| ≤ n − 1 11.
SP [m] ← EK (f2 (SP [m − 1] ⊕ ozp(C[m])))12.
V ← f2 (SH [a] ⊕ ozp(param ∥ N ))12. T ← msbτ (SP [m])13. return V
13. return T
Algorithm ENCK (V, M )Algorithm DECK (V, C)
1. if |M | = 0 then
2.
C←ε
3.
return Cn
4. (M [1], . . . , M [m]) ← M
5. SE [1] ← EK (V )6. for i ← 1 to m − 1 do
7.
C[i] ← SE [i] ⊕ M [i]8.
SE [i + 1] ← EK (fix1(C[i]))9. C[m] ← msb|M [m]| (SE [m]) ⊕ M [m]
10. C ← (C[1], . . . , C[m])11. return C

1. if |C| = 0 then
2.
M ←ε
3.
return M
n4. (C[1], . . . , C[m]) ← C
5. SD [1] ← EK (V )6. for i ← 1 to m − 1 do
7.
M [i] ← SD [i] ⊕ C[i]8.
SD [i + 1] ← EK (fix1(C[i]))9. M [m] ← msb|C[m]| (SD [m]) ⊕ C[m]10. M ← (M [1], . . . , M [m])11. return M

Fig. 2. Subroutines used in the encryption and decryption algorithms of CLOC

Here X[a, b] stands for X[a] ⊕ X[b] and X[a, b, c] stands for X[a] ⊕ X[b] ⊕ X[c].
Alternatively the tweak functions can be speciﬁed by a matrix. Let0001
1 0 0 1

M=0 1 0 0
0010

(1)

be a 4 × 4 binary matrix, and let Mi for i ≥ 0 be exponentiations of M, where M0 denotes the identity
matrix. Then we have f1 (X) = X·M8 , f2 (X) = X·M, g1 (X) = X·M2 , g2 (X) = X·M, and h(X) = X·M4 ,where X = (X[1], X[2], X[3], X[4]) is interpreted as a vector.
3.2

Parameter Spaces

As the CAESAR submission we specify the parameter spaces of CLOC as follows.
– Blockcipher E: AES-128 (AES with 128-bit key), or TWINE-80 (TWINE with 80-bit key).
– Nonce length ℓN : For AES-128, ℓN ∈ {64 bits (8 byte), 96 bits (12 bytes), 112 bits (14 bytes)}, andfor TWINE-80, ℓN ∈ {32 bits (4 byte), 48 bits (6 bytes)}.
– Tag length τ : For AES-128, τ ∈ {32 bits (4 bytes), 64 bits (8 bytes), 96 bits (12 bytes), 128 bits (16bytes)}, and for TWINE-80, τ ∈ {32 bits (4 bytes), 48 bits (6 bytes), 64 bits (8 bytes)}.
TWINE is a 64-bit blockcipher proposed by Suzaki, Minematsu, Morioka, and Kobayashi at SAC 2012 [39].
The speciﬁcation of TWINE is described in Appendix A.
The choice of the parameter determines the value of param ∈ B which is concatenated to the nonce
N in HASH. The deﬁnition of param is given in Table 1.
We note that CLOC is a blockcipher mode of operation and hence any reasonable blockcipher can beused. In order to meet a possible option, in Appendix D, we present how param for Simon and Speck [8]is speciﬁed when used with CLOC.
3

A[1] param N

A[2] · · · A[a − 1] A[a] param N

A[1]

ozp

ozp
fix0

f1 /f2

EK

EK

V

i/h

ozp

EK

f1 /f2

···

fix0

EK

ozp

EK

V

i/h

if |A[a]| = n, then f1 , else f2

if |A[1]| = n, then f1 , else f2

if msb1 (A[1]) = 1, then h, else iif msb1 (ozp(A[1])) = 1, then h, else i

Fig. 3. V ← HASHK (N, A) for 0 ≤ |A| ≤ n (left) and |A| ≥ n + 1 (right) for CLOC

V M [1]M [2]· · · M [m − 1]

M [m]C[2] · · · C[m − 1] C[m]V C[1]

···

EK

···

fix1

fix1

fix1

EK

EK

EK

EK

fix1

fix1

fix1

EK

EK

EK
msb

msb

C[1]

C[2]

···

C[m − 1]

M [1]

C[m]

M [2] · · · M [m − 1]M [m]Fig. 4. C ← ENCK (V, M ) for |M | ≥ 1 (left), and DECK (V, C) for |C| ≥ 1 (right) for CLOC

V

V

C[1] · · · C[m − 1] C[m]

g1

g2

ozp

if |C[m]| = n, then f1 , else f2

···
EK

EK

EK

f1 /f2

EK

EK
msb

msb

T

T
Fig. 5. T ← PRFK (V, C) for |C| = 0 (left) and |C| ≥ 1 (right) for CLOC

4

A[1]

param N

ozp

ozp
EK

fix0

f1 /f2i/h

if |A[1]| = n, then f1 , else f2

if msb1 (ozp(A[1])) = 1, then h, else i
A[1]

···

A[2]

V

A[a] param N

A[a − 1]

ozp
EK

fix0

EK

i/h

···

EK

ozp
EK

f1 /f2

V

if |A[a]| = n, then f1 , else f2

if msb1 (A[1]) = 1, then h, else i

Fig. 6. V ← HASHK (N, A) for 0 ≤ |A| ≤ n (top) and |A| ≥ n + 1 (bottom) for CLOC

M [1]
EK

V

M [2]
EK

fix1

···

C[1]

C[2]

C[1]

EK

fix1
M [1]

fix1

EK

M [m]

fix1

EK

msb

C[m − 1]C[m]C[m − 1]

···

···
M [2]

M [m − 1]

···

C[2]

EK

V

···

C[m]

fix1

EK

···

M [m − 1]

fix1

EK

msb
M [m]

Fig. 7. C ← ENCK (V, M ) for |M | ≥ 1 (top), and DECK (V, C) for |C| ≥ 1 (bottom) for CLOC

V

g1

EK

T

msb
C[1]

···

C[m − 1] C[m]
ozp

V

g2

EK

EK

···

EK

if |C[m]| = n, then f1 , else f2
f1 /f2EK

msb

T

Fig. 8. T ← PRFK (V, C) for |C| = 0 (top) and |C| ≥ 1 (bottom) for CLOC

5

Table 1. Deﬁnition of param for CLOC. ℓN and τ are written in bytes, and param is in hex. The asterisk indicatesthe recommended parameter.
EℓN τ param* AES-128 12 8 0xc0
AES-128 12 12 0xc1
AES-128 12 16 0xc2
AES-128 12 4 0xc3
AES-128 8 8 0xd0
AES-128 8 12 0xd1
AES-128 8 16 0xd2
AES-128 8 4 0xd3
AES-128 14 8 0xe0
AES-128 14 12 0xe1
AES-128 14 16 0xe2
AES-128 14 4 0xe3

EℓN τ param* TWINE-80 6 4 0xcc
TWINE-80 6 6 0xcd
TWINE-80 6 8 0xce
TWINE-80 4 4 0xdc
TWINE-80 4 6 0xdd
TWINE-80 4 8 0xde

Algorithm SILC-EK (N, A, M )Algorithm SILC-DK (N, A, C, T )1. V ← HASHK (N, A)
2. C ← ENCK (V, M )3. T ← PRFK (V, C)
4. return (C, T )1. V ← HASHK (N, A)
2. T ∗ ← PRFK (V, C)
3. if T ̸= T ∗ then return ⊥4. M ← DECK (V, C)
5. return M

Fig. 9. Pseudocode of the encryption and the decryption algorithms of SILC

4

Specification of SILC

In this section, we present the speciﬁcation of Π = SILC.
4.1

Algorithm of SILC

SILC-E and SILC-D are deﬁned in Fig. 9, which are the same as CLOC. In these algorithms, we use four
subroutines, HASH, PRF, ENC, and DEC. They have the following syntax.

HASH : KSILC × NSILC × ASILC → {0, 1}nPRF : Kn
SILC × {0, 1} × CSILC → TSILC
ENC : KSILC × {0, 1}n × MSILC → CSILC
DEC : KSILC × {0, 1}n × CSILC → MSILC
These subroutines are deﬁned in Fig. 10, and illustrated in Fig. 11, Fig. 12, and Fig. 13. Equivalent ﬁgures
are in Fig. 14, Fig. 15, and Fig. 16. We note that ENC and DEC are the same as those in CLOC. In HASH,the nonce N is padded with param ∈ B which is an 8-bit constant that depends on the parameters, E,ℓN , and τ . See Sect. 4.2 and Sect. 5 for the concrete values of param.
In the subroutines, we use the zero prepending function zpp : B∗ → B∗ , the zero appending function
zap : B∗ → B∗ , the bit-ﬁxing function fix1 : B∗ → B∗ , the tweak function g : {0, 1}n → {0, 1}n , and thelength encoding function Len : B∗ → {0, 1}n .
Both the zero prepending and appending functions are used to adjust the length of an input string
so that the total length becomes a non-negative multiple of n bits (the output is the empty string if andonly if the input is the empty string). For X ∈ B∗ , zpp(X) is deﬁned as{X
if |X| = ℓn for some ℓ ≥ 0,zpp(X) =0n−(|X| mod n) ∥ X otherwise,6

Algorithm HASHK (N, A)

Algorithm PRFK (V, C)

1. SH [0] ← EK (zpp(param ∥ N ))1. SP [0] ← EK (g(V ))2. if |A| = 0 then
2. if |C| = 0 then3.
V ← g(SH [0] ⊕ Len(A)) // Len(A) = 0n 3.
U ← g(SP [0] ⊕ Len(C)) // Len(C) = 0n4.
return V4.
T ← msbτ (EK (U ))n
5. (A[1], . . . , A[a]) ← A
5.
return T
n
6. for i ← 1 to a − 1 do
6. (C[1], . . . , C[m]) ← C
7.
SH [i] ← EK (SH [i − 1] ⊕ A[i])7. for i ← 1 to m − 1 do
8. SH [a] ← EK (SH [a − 1] ⊕ zap(A[a]))8.
SP [i] ← EK (SP [i − 1] ⊕ C[i])9. V ← g(SH [a] ⊕ Len(A))
9. SP [m] ← EK (SP [m − 1] ⊕ zap(C[m]))10. return V
10. U ← g(SP [m] ⊕ Len(C))
11. T ← msbτ (EK (U ))12. return T
Algorithm ENCK (V, M )Algorithm DECK (V, C)
1. if |M | = 0 then
2.
C←ε
3.
return Cn
4. (M [1], . . . , M [m]) ← M
5. SE [1] ← EK (V )6. for i ← 1 to m − 1 do
7.
C[i] ← SE [i] ⊕ M [i]8.
SE [i + 1] ← EK (fix1(C[i]))9. C[m] ← msb|M [m]| (SE [m]) ⊕ M [m]
10. C ← (C[1], . . . , C[m])11. return C

1. if |C| = 0 then
2.
M ←ε
3.
return M
n4. (C[1], . . . , C[m]) ← C
5. SD [1] ← EK (V )6. for i ← 1 to m − 1 do
7.
M [i] ← SD [i] ⊕ C[i]8.
SD [i + 1] ← EK (fix1(C[i]))9. M [m] ← msb|C[m]| (SD [m]) ⊕ C[m]10. M ← (M [1], . . . , M [m])11. return M

Fig. 10. Subroutines used in the encryption and decryption algorithms of SILC

and zap(X) is deﬁned aszap(X) ={X
X ∥ 0n−(|X| mod n)

if |X| = ℓn for some ℓ ≥ 0,otherwise.

In general, they are not invertible functions.
The bit-ﬁxing function fix1 is the same as the one in CLOC, and is used to ﬁx the most signiﬁcant
bit of an input string to one. For X ∈ B∗ , fix1(X) is deﬁned as fix1(X) = X ∨ 10|X|−1 , where ∨ denotes
the bit-wise OR operation.
The length encoding function Len : B∗ → {0, 1}n is used to encode the input length (in bytes) in HASHand PRF. For X ∈ B∗ , it is deﬁned as Len(X) = strn (|X|8 ), where strn (|X|8 ) is the standard encoding of|X|8 (the byte length of X) into an n-bit string. For example, when X = ε, we have Len(X) = 0n , andwhen |X|8 = 5, we have Len(X) = 0n−4 ∥ 0101. As the maximum lengths of A, M , and C are all 2n/2 − 1
bytes, the most signiﬁcant n/2 bits of Len(X) in HASH and PRF are ﬁxed to 0n/2 .
The tweak function g : {0, 1}n → {0, 1}n is used in HASH and PRF.
– For n = 128 and X ∈ {0, 1}n , g(X) is deﬁned asg(X) = (X[2], X[3], . . . , X[16], X[1, 2]),n/16

where (X[1], X[2], . . . , X[16]) ← X and X[a, b] stands for X[a] ⊕ X[b].
n/12– For n = 96, we let (X[1], X[2], . . . , X[12]) ← X and deﬁne g(X) as
g(X) = (X[2], X[3], . . . , X[12], X[1, 2]).
n/8

– Similarly, if n = 64, we let (X[1], X[2], . . . , X[8]) ← X and deﬁne g(X) as
g(X) = (X[2], X[3], . . . , X[8], X[1, 2]).
g can be interpreted as one byte left shift with the rightmost output byte being the xor of the leftmost
two input bytes.
7

param N Len(A)zppparam N A[1] · · · A[a − 1] A[a]Len(A)

zap

zpp
···
g

EK

EK

EK

EK

g

EK

V

V

Fig. 11. V ← HASHK (N, A) for |A| = 0 (left) and |A| ≥ 1 (right) for SILCV M [1]

M [2]

M [m]

· · · M [m − 1]C[2] · · · C[m − 1] C[m]V C[1]

···

···

EK

fix1

fix1

fix1

EK

EK

EK

EK

fix1

fix1

fix1

EK

EK

EK

msb

C[1]

C[2]

···

C[m − 1]

msb

M [1]

C[m]

M [2] · · · M [m − 1]M [m]Fig. 12. C ← ENCK (V, M ) for |M | ≥ 1 (left), and DECK (V, C) for |C| ≥ 1 (right) for SILC

V

Len(C)

V

C[1] · · · C[m − 1] C[m]Len(C)

zap
···
g

g

g

EK

EK

EK

EK

EK

EK

g
EK

msb

msb

T

T

Fig. 13. T ← PRFK (V, C) for |C| = 0 (left) and |C| ≥ 1 (right) for SILC

8

param N Len(A)zppparam N A[1]

···

EK

g

V

A[a − 1]A[a]Len(A)

zap

zpp
EK

EK

EK

···

EK

V

g

Fig. 14. V ← HASHK (N, A) for |A| = 0 (top) and |A| ≥ 1 (bottom) for SILC

M [1]

M [2]

EK

V

fix1

EK

···

C[1]

EK

M [m − 1]

fix1

EK

C[2]

C[1]

V

···

fix1
M [1]

EK
M [2]

msb
C[m]

C[m − 1]

···

···

EK

fix1
C[m − 1]

···

C[2]

M [m]

C[m]

fix1

EK

···

M [m − 1]

EK

fix1

msb
M [m]

Fig. 15. C ← ENCK (V, M ) for |M | ≥ 1 (top), and DECK (V, C) for |C| ≥ 1 (bottom) for SILC

Len(C)

V

g

EK

C[1]

···

C[m − 1] C[m]

EK

g

T

msb

Len(C)

zap
V

g

EK

EK

···

EK

EK

g

EK

msb

T

Fig. 16. T ← PRFK (V, C) for |C| = 0 (top) and |C| ≥ 1 (bottom) for SILC

9

Table 2. Deﬁnition of param for SILC. ℓN and τ are written in bytes, and param is in hex. The asterisk indicatesthe recommended parameter.
EℓN τ param* AES-128 12 8 0xc0
AES-128 12 12 0xc1
AES-128 12 16 0xc2
AES-128 12 4 0xc3
AES-128 8 8 0xd0
AES-128 8 12 0xd1
AES-128 8 16 0xd2
AES-128 8 4 0xd3
AES-128 14 8 0xe0
AES-128 14 12 0xe1
AES-128 14 16 0xe2
AES-128 14 4 0xe3

4.2

EℓN τ param* present-80 6 4 0xc4
present-80 6 6 0xc5
present-80 6 8 0xc6
present-80 4 4 0xd4
present-80 4 6 0xd5
present-80 4 8 0xd6
* LED-80
6 4 0xc8
LED-806 6 0xc9
LED-80
6 8 0xca
LED-804 4 0xd8
LED-80
4 6 0xd9
LED-80
4 8 0xda

Parameter Spaces

As the CAESAR submission we specify the parameter spaces of SILC as follows.
– Blockcipher E: AES-128 (AES with 128-bit key), or present-80 (present with 80-bit key), or LED-80(LED with 80-bit key).
– Nonce length ℓN : For AES-128, ℓN ∈ {64 bits (8 byte), 96 bits (12 bytes), 112 bits (14 bytes)}, andfor present-80 and LED-80, ℓN ∈ {32 bits (4 byte), 48 bits (6 bytes)}.
– Tag length τ : For AES-128, τ ∈ {32 bits (4 bytes), 64 bits (8 bytes), 96 bits (12 bytes), 128 bits (16bytes)}, and for present-80 and LED-80, τ ∈ {32 bits (4 bytes), 48 bits (6 bytes), 64 bits (8 bytes)}.
present is a 64-bit blockcipher proposed by Bogdanov et al. at CHES 2007 [12], and LED is a 64-bit
blockcipher proposed by Guo et al. at CHES 2011 [18]. The speciﬁcation of present is described inAppendix B, and that of LED is described in Appendix C.
The choice of the parameter determines the value of param ∈ B which is concatenated to the nonce
N in HASH. The deﬁnition of param is given in Table 2.
As with CLOC, SILC can be used with any reasonable blockcipher, and in Appendix D, we present
how param for Simon and Speck [8] is speciﬁed when used with SILC.

5

Recommended Parameter Sets and Use Cases

We specify the recommended parameter sets as follows.
– Parameter set 1, aes128n12t8clocv3: E = AES-128, ℓN = 96 (12-byte nonce), τ = 64 (8-byte tag)
– Parameter set 2, aes128n12t8silcv3: E = AES-128, ℓN = 96 (12-byte nonce), τ = 64 (8-byte tag)
– Parameter set 3, twine80n6t4clocv3: E = TWINE-80, ℓN = 48 (6-byte nonce), τ = 32 (4-byte tag)
– Parameter set 4, present80n6t4silcv3: E = present-80, ℓN = 48 (6-byte nonce), τ = 32 (4-bytetag)– Parameter set 5, led80n6t4silcv3: E = LED-80, ℓN = 48 (6-byte nonce), τ = 32 (4-byte tag)
These are marked with the asterisk in Table 1 and Table 2.
Following the CAESAR requirement, we identify prioritized targeted use cases as follows.
– Parameter set 1, aes128n12t8clocv3: Use Case 1: Lightweight applications– Parameter set 2, aes128n12t8silcv3: Use Case 1: Lightweight applications– Parameter set 3, twine80n6t4clocv3: Use Case 1: Lightweight applications– Parameter set 4, present80n6t4silcv3: Use Case 1: Lightweight applications– Parameter set 5, led80n6t4silcv3: Use Case 1: Lightweight applications
We note that although CLOC and SILC have some of the features listed in Use Case 3: Defense indepth, they are designed for lightweight applications.
10

Table 3. Security goal of CLOC for conﬁdentiality (privacy)
Parameter set aes128n12t8clocv3 twine80n6t4clocv3
Data
64
32
Time
128
80
Table 4. Security goal of CLOC for integrity (authenticity)
Parameter set aes128n12t8clocv3 twine80n6t4clocv3
Data
64
32
Verify
64
32
128
80
Time

6

Security Goals

The security goal of CLOC and SILC is to provide the provable security in terms of conﬁdentiality (orprivacy) of plaintexts under nonce-respecting adversaries, and integrity (or authenticity) of plaintext,
associated data, and nonce (public message number) under nonce-reusing adversaries. That is, to keep
both conﬁdentiality and integrity, the nonce of CLOC and SILC must be unique for all encryptions, andeven if this condition is violated for some reason, say by a software error, CLOC and SILC retain theauthenticity of sent messages, except for replays (which can be protected by some outer mechanism).
Note that CLOC and SILC have no secret message number. CLOC and SILC have provable security
guarantees both for conﬁdentiality and integrity, up to the standard birthday bound of the block length of
the underlying blockcipher, based on the assumption that the blockcipher is a pseudorandom permutation(PRP). That is, for the block length of n bits, the security is guaranteed provided that the attacker obtains
σ ≪ 2n/2 blocks of data. A detailed explanation on the attack models and the provable security bounds
are given in Sect. 7.
Attack Workload. We provide security bounds of CLOC and SILC in Sect. 7 based on the pseudorandomness of the underlying blockcipher. We obtain Tables 3, 4, 5, and 6 from these bounds. The variablesin the tables denote the required workload of an adversary to break the cipher, in logarithm base 2. If
one of the variables reaches the suggested number, then there is no security guarantee anymore, and thecipher can be broken. In Table 3 and Table 5, Data denotes σpriv of our privacy theorems (Theorem 1
and Theorem 2), and this roughly suggests the number of data blocks that the adversary obtains. In
Table 4 and Table 6, Data denotes σauth and Verify denotes q ′ of our authenticity theorems (Theorem 3
and Theorem 4), where σauth roughly suggests the number of data blocks that the adversary obtains, andq ′ denotes the number of decryption queries. In these tables, Time denotes the time complexity, which
we assume to be equal to the bit length of the key of the underlying blockcipher. We note that small
2
constant factors are neglected in these tables. For instance the privacy bound in Theorem 1 is 5σpriv
/2n ,
n
1/2
n/2
and it becomes void if σpriv ≈ (2 /5) , which is slightly less than 2 .
We have already mentioned that the nonce cannot be repeated to maintain the privacy. As an additional security goal, we claim that the privacy of CLOC and SILC hold as long as the uniqueness of(A, N ), a pair of associated data and a nonce, is maintained. That is, even if the nonce is reused, if theuniqueness is maintained as the pair, then the privacy bound still holds. We note that the authenticity
holds in this setting as well, since it is maintained even if the nonce is reused.
On the Use of 64-Bit Blockcipher. We emphasize that the use of 64-bit blockciphers, TWINE, present,
and LED, is not for general purpose applications. The birthday bound for the block length of 64 bits
is usually unacceptable for conventional data transmission. As demonstrated by McGrew [30], it leaks
information when the total data blocks reach about 32 Gbytes, if the key is not renewed. Moreover
Bhargavan and Leurent [11] showed how TLS is attacked if 64-bit blockciphers are used and collisions
are practical. However, the parameter sets with 64-bit blockciphers do not focus on commodity channels,e.g., the Internet, but they focus on networks where the data rate is signiﬁcantly low, with short packet
data, and sparse data transmission from edge devices. Many protocols for wireless sensor devices have a
low-data rate to suppress the power consumption. For example, IEEE 802.15.4 has 20/40/250 Kbps [4],which is used as physical and data-link layers of popular sensor protocols, Zigbee and 6LoWPAN. Another11

Table 5. Security goal of SILC for conﬁdentiality (privacy)
Parameter set aes128n12t8silcv3 present80n6t4silcv3 led80n6t4silcv3
Data
64
32
32
Time
128
80
80
Table 6. Security goal of SILC for integrity (authenticity)
Parameter set aes128n12t8silcv3 present80n6t4silcv3 led80n6t4silcv3
Data
64
32
32
Verify
64
32
32
Time
128
80
80

example is Z-Wave, which has 9.6 or 40 Kbps [5]. If edge devices are powered by a small battery, sending
32 Gbytes for one battery is unlikely to be possible in the ﬁrst place, and rekeying should occur withbattery replacement. This naturally implies that the total data blocks sent from one device for its life
time is small, hence it may keep the acceptable security even with a 64-bit blockcipher. For example,
when the edge device sends data of 512 bytes for every thirty minutes for 10 years (which is exceptionallylong for battery-powered sensor devices), the total data amount sent from the device for its life time isabout 90 Mbytes. With a standard birthday bound with the block length of 64 bits, the security boundis still below 2−17 , which can be acceptable for such constrained devices. Note that this setting assumes
only one key, and if the device can renew the key, say, for each year, the bound can be reduced to 2−23 .
Of course if the target network has a high-data rate with stable power source, we recommend to use
the parameter sets with a 128-bit blockcipher.

7

Security Analysis

In this section, we deﬁne the security notions of a blockcipher and Π ∈ {CLOC, SILC}, and present our
security theorems. The following descriptions are taken from [19], and they hold for all recommended
parameter sets.
PRP Notion. We assume that the blockcipher E : KE ×{0, 1}n → {0, 1}n is a pseudorandom permutation,$
or a PRP [27]. We say that P is a random permutation if P ← Perm(n), and deﬁne
[
]
[
]
def
EK (·)P (·)
Advprp
(A)
=
Pr
A
⇒
1
−
Pr
A
⇒
1
,
E
where the ﬁrst probability is taken over K ← KE and the randomness of A, and the last is over$P ← Perm(n) and A. We write Π[Perm(n), ℓN , τ ] for Π ∈ {CLOC, SILC} that uses P as EK , andthe encryption and decryption algorithms are written as Π-EP and Π-DP .
$Privacy Notion. We deﬁne the privacy notion for Π[E, ℓN , τ ] = (Π-E, Π-D). This notion captures theindistinguishably of a nonce-respecting adversary in a chosen plaintext attack setting. We consider anadversary A that has access to the encryption oracle Π-E, or a random-bits oracle. The encryption oracle
takes (N, A, M ) ∈ NΠ × AΠ × MΠ as input and returns (C, T ) ← Π-EK (N, A, M ). The random-bits$
oracle, $-oracle, takes (N, A, M ) ∈ NΠ × AΠ × MΠ as input and returns a random string (C, T ) ←{0, 1}|M |+τ . We deﬁne the privacy advantage as
[
]
[
]
def
Π-EK (·,·,·)
Advpriv⇒ 1 − Pr A$(·,·,·) ⇒ 1 ,Π[E,ℓN ,τ ] (A) = Pr A
where the ﬁrst probability is taken over K ← KΠ and the randomness of A, and the last is over the
random-bits oracle and A. We assume that A in the privacy game is nonce-respecting, that is, A does
not make two queries with the same nonce.
$

12

Privacy Theorem. Let A be an adversary that makes q queries, and suppose that the queries are(N1 , A1 , M1 ), . . . , (Nq , Aq , Mq ). Then we deﬁne the total associated data length as a1 + · · · + aq , and thenntotal plaintext length as m1 + · · · + mq , where (Ai [1], . . . , Ai [ai ]) ← Ai and (Mi [1], . . . , Mi [mi ]) ← Mi .
We have the following information theoretic result for CLOC.
Theorem 1. Let Perm(n), ℓN , and τ be the parameters of CLOC. Let A be an adversary that makes atmost q queries, where the total associated data length is at most σA , and the total plaintext length is at2nmost σM . Then we have Advpriv
CLOC[Perm(n),ℓN ,τ ] (A) ≤ 5σpriv /2 , where σpriv = q + σA + 2σM .
A complete proof is presented in [20, Appendix A]. If we use a blockcipher E, which is secure in the senseof the PRP notion, instead of Perm(n), then the corresponding complexity theoretic result can be shownby a standard argument. See e.g. [9].
We note that, in general, the privacy of CLOC is broken if the nonce is reused. However, as longas (Ni , Ai ) ̸= (Nj , Aj ) holds for all 1 ≤ i < j ≤ q, the bound in Theorem 1 holds. This is because, inthe proof in [20, Appendix A], the transition from CLOC to CLOC5 works without the nonce-respecting
assumption, and HASH5 and PRF5 used in CLOC5 generate random and independent output values if(Ni , Ai ) ̸= (Nj , Aj ) holds for all 1 ≤ i < j ≤ q.
For SILC, we have the following information theoretic result.
Theorem 2. Let Perm(n), ℓN , and τ be the parameters of SILC. Let A be an adversary that makes atmost q queries, where the total associated data length is at most σA , and the total plaintext length is atn2
most σM . Then we have Advpriv
SILC[Perm(n),ℓN ,τ ] (A) ≤ 5σpriv /2 , where σpriv = 3q + σA + 2σM .
A complete proof is presented in [24, Appendix C]. If we use a blockcipher E, which is secure in thesense of the PRP notion, then we obtain the corresponding complexity theoretic result. As in CLOC,
the privacy of SILC is broken if the nonce is reused, but it remains secure if the uniqueness of (A, N ) is
maintained.
Authenticity Notion. We next deﬁne the authenticity notion for Π[E, ℓN , τ ] = (Π-E, Π-D), which captures the unforgeability of an adversary in a chosen ciphertext attack setting. We consider a strong
adversary that can repeat the same nonce multiple times. Let A be an adversary that has access to theencryption oracle Π-E and the decryption oracle Π-D. The encryption oracle is deﬁned as above. The
decryption oracle takes (N, A, C, T ) ∈ NΠ × AΠ × CΠ × TΠ as input and returns M ← Π-DK (N, A, C, T )or ⊥ ← Π-DK (N, A, C, T ). The authenticity advantage is deﬁned as[]def
Π-EK (·,·,·),Π-DK (·,·,·,·)
Advauthforges ,Π[E,ℓN ,τ ] (A) = Pr A
where the probability is taken over K ← KΠ and the randomness of A, and the adversary forges if thedecryption oracle returns a bit string (other than ⊥) for a query (N, A, C, T ), but (C, T ) was not previously
returned to A from the encryption oracle for a query (N, A, M ). The adversary A in the authenticity gameis not necessarily nonce-respecting, and A can make two or more queries with the same nonce. Speciﬁcally,
A can repeat using the same nonce for encryption queries, a nonce used for encryption queries can beused for decryption queries and vice-versa, and the same nonce can be repeated for decryption queries.
Without loss of generality, we assume that A does not make trivial queries, i.e., if the encryption oracle
returns (C, T ) for a query (N, A, M ), then A does not make a query (N, A, C, T ) to the decryption oracle,
and A does not repeat a query.
$

Authenticity Theorem. Let A be an adversary that makes q encryption queries and q ′ decryption queries.
Let (N1 , A1 , M1 ), . . . , (Nq , Aq , Mq ) be the encryption queries, and (N1′ , A′1 , C1′ , T1′ ), . . . , (Nq′ ′ , A′q′ , Cq′ ′ , Tq′′ )be the decryption queries. Then we deﬁne the total associated data length in encryption queries as
a1 + · · · + aq , the total plaintext length as m1 + · · · + mq , the total associated data length in decryptionnqueries as a′1 + · · · + a′q′ , and the total ciphertext length as m′1 + · · · + m′q′ , where (Ai [1], . . . , Ai [ai ]) ← Ai ,nnn
(Mi [1], . . . , Mi [mi ]) ← Mi , (A′i [1], . . . , A′i [a′i ]) ← A′i , and (Ci′ [1], . . . , Ci′ [m′i ]) ← Ci′ . We have the following
information theoretic result for CLOC.
Theorem 3. Let Perm(n), ℓN , and τ be the parameters of CLOC. Let A be an adversary that makes
at most q encryption queries and at most q ′ decryption queries, where the total associated data length13

in encryption queries is at most σA , the total plaintext length is at most σM , the total associated data
length in decryption queries is at most σA′ , and the total ciphertext length is at most σC ′ . Then we have
2
n
′
τ
′
Advauth
CLOC[Perm(n),ℓN ,τ ] (A) ≤ 5σauth /2 + q /2 , where σauth = q + σA + 2σM + q + σA′ + σC ′ .
A complete proof is presented in [20, Appendix A]. As in the privacy case, if we use a blockcipher E
secure in the sense of the PRP notion, then we obtain the corresponding complexity theoretic result bya standard argument.
For SILC, we have the following information theoretic result.
Theorem 4. Let Perm(n), ℓN , and τ be the parameters of SILC. Let A be an adversary that makes
at most q encryption queries and at most q ′ decryption queries, where the total associated data length
in encryption queries is at most σA , the total plaintext length is at most σM , the total associated data
length in decryption queries is at most σA′ , and the total ciphertext length is at most σC ′ . Then we have
2
n
′
τ
′
AdvauthSILC[Perm(n),ℓN ,τ ] (A) ≤ 5σauth /2 + q /2 , where σauth = 3q + σA + 2σM + 3q + σA′ + σC ′ .
A proof is in [24, Appendix C]. It is standard to obtain the corresponding complexity theoretic result.

8

FeaturesFeatures of CLOC. CLOC has the following features.
1. It uses only the encryption of the blockcipher both for encryption and decryption, and does not use
bit-wise operations, such as a constant multiplication over GF(2n ).
2. CLOC makes ⌈|N |/n⌉ + ⌈|A|/n⌉ + 2⌈|M |/n⌉ blockcipher calls for a nonce N , associated data A, and aplaintext M , when |A| ≥ 1. No precomputation other than the blockcipher key scheduling is needed.
We note that in CLOC, 1 ≤ |N | ≤ n−1 holds (hence we always have ⌈|N |/n⌉ = 1), and when |A| = 0,
it needs ⌈|N |/n⌉ + 1 + 2⌈|M |/n⌉ blockcipher calls.
3. It works with two state blocks (i.e. 2n bits).
4. Both encryption and decryption can be processed in an online manner.⋆ ⋆ ⋆5. Static associated data can be processed eﬃciently if the corresponding intermediate state value isstored.
6. For security, the privacy and authenticity are proved based on the PRP assumption of the blockcipher, assuming standard nonce-respecting adversaries. Moreover, the authenticity is proved with evenstronger, nonce-reusing adversaries.
The second feature implies that a number of blockcipher calls required for processing short input data,say 16 or 32 bytes, is small. In particular, CLOC works without any precomputation of the blockcipher,say, computation of EK (0n ). The precomputation of CLOC is essentially the blockcipher key schedule,
hence it can eﬃciently handle short input data even without precomputation. This feature is particularly
desirable for low-power sensor networks, where messages are typically quite short and the devices have
limited computational power. CLOC is designed to be used in embedded processors, but this feature may
also be useful for powerful processors, for example when the key is frequently changed or when a large
number of keys need to be processed. For example, when the input data consists of 1-block nonce, 1-blockassociated data, and 1-block plaintext, CLOC needs 4 blockcipher calls, while we need 5 or 6 calls in
CCM [15], 7 calls (where 3 out of 7 can be precomputed) in EAX [10], and 5 calls (where 1 out of 5 canbe precomputed) in EAX-prime [7], where the last one is insecure [32].
The ﬁrst and the third features imply that CLOC works with small memory and its eﬃciency forprocessors with small words (say 8 or 16 bits). With these features CLOC is particularly suitable for
embedded processors with severe ROM/RAM constraints. The last feature implies that CLOC provides
standard security as a nonce-based AEAD, and in addition a level of security (i.e. authenticity only) evenwhen the nonce is reused, unlike many previous nonce-based AEADs.
⋆⋆⋆

The onlineness in decryption here merely means that the blockcipher can be called as soon as a block of data
is received, and this does not mean that the veriﬁcation step can be skipped.

14

Features of SILC. SILC has the following features.
1. It uses only the encryption of the blockcipher both for encryption and decryption.
2. It carefully avoids hardware-unfriendly operations as much as possible, e.g., conditional operation
branching, which requires multiplexers in hardware, and dynamic change of data shift amount.
3. It makes ⌈|N |/n⌉ + ⌈|A|/n⌉ + 2⌈|M |/n⌉ + 2 blockcipher calls for a nonce N , associated data A, anda plaintext M . No precomputation other than the blockcipher key scheduling is needed. As a result,no extra hardware register for storing the precomputed result is necessary. We note that in SILC,
1 ≤ |N | ≤ n − 1 holds (hence we always have ⌈|N |/n⌉ = 1).
4. The memory cost other than the blockcipher is low. It works with two state blocks (i.e. 2n bits) tostore chaining blocks for encryption and authentication, plus a counter for storing the message length.
5. Both encryption and decryption can be processed in an online manner. †6. For security, the privacy and authenticity are proved based on the PRP assumption of the blockcipher, assuming standard nonce-respecting adversaries. Moreover, the authenticity is proved with evenstronger, nonce-reusing adversaries.
The ﬁrst, second, and fourth features imply SILC’s suitability for small hardware. SILC essentiallyconsists a blockcipher encryption function EK and other functions, zpp, zap, fix1, Len, and g. These
functions are chosen by taking the hardware eﬃciency into account. For instance the 10∗ padding function
is commonly used in many blockcipher modes, but due to the operation branch depending on the input
length, it imposes non-negligible increase in circuit gates compared with zpp or zap. At the cost of one
additional blockcipher call for Len, the padding is signiﬁcantly simpliﬁed. The last feature says that SILC
has the same security property as CLOC.
Advantages over AES-GCM. Compared with AES-GCM [31], CLOC works eﬃciently for short input
data on embedded processors, and the implementation of CLOC with AES can be smaller, as we do
not use a full Galois-Field (GF) multiplier. In particular, AES-GCM is generally ineﬃcient on embedded
processors, since the GF multiplier is not fast (e.g. see [17]), while CLOC with AES can be eﬃciently
implemented. For CLOC with TWINE, we expect even smaller implementation, at the cost of reduced
security, which will be useful for ultimately tiny processors.
SILC also avoids using a GF multiplier, and the hardware implementation with AES can be smaller.
In hardware, AES-GCM is generally fast, however, a fast GF multiplier requires a rather large numberof gates, in addition to those needed for the AES encryption function. While SILC with AES can beeﬃciently implemented, it is also fast if AES is fast. For SILC with present or LED, we expect even smaller
implementations with reduced power consumption, at the cost of reduced security which is reasonable
for constrained hardware. The parameter set with present or LED would be beneﬁcial to tiny devices,such as RFID or CPLD.
With respect to the security, the provable security bound of CLOC and SILC for authentication isbetter, since the bound of GCM has a term q ′ (ℓA + 1)/2τ , which grows linearly with the block length ℓAof the associated data [25], while the corresponding term in CLOC is q ′ /2τ . This may have impact when
τ is small. Furthermore, in GCM, the existence of weak keys was pointed out [35], while weak keys are
not known in CLOC. Also, CLOC and SILC provide some level of security even if the nonce is reused.
Justifications of Parameter Sets. For the 128-bit blockcipher, we select AES for its excellent performanceand extensively studied security. For the 64-bit blockcipher, we select TWINE for CLOC for its suitability
for embedded processors (comparable speed to AES, smaller code size), and good performance even for
high-end platforms with SIMD operations [39]. Notably, TWINE allows eﬃcient processing of two blocks
in parallel for a wide range of platforms, which is desirable for CLOC, since in CLOC, the encryption
process and tag generation can be done in parallel. We select present and LED for SILC. Both ciphers
can be implemented with small gate size, and in particular, present is selected for its high throughput,and LED is selected for its high security margin against various cryptanalysis.
For aes128n12t8clocv3 and aes128n12t8silcv3, we select ℓN = 96 from the current trend on thelength of the nonce, and this is suitable, for instance, if a part of the nonce is randomly chosen and theother part consists of a counter. For twine80n6t4clocv3, present80n6t4silcv3, and led80n6t4silcv3,
we select ℓN = 48 by taking the half of 96 in aes128n12t8clocv3 and aes128n12t8silcv3. For all cases,
the tag length was chosen by taking the balance between the security and the data overhead.
†

The same note as CLOC applies.

15

Limitations. We also list several limitations of CLOC and SILC. For long input data, CLOC and SILC
are not eﬃcient as they need two blockcipher calls per one plaintext block. The nonce length is ﬁxed,
which may be problematic in some applications, and the associated data is always processed before theplaintext blocks. The four functions used in CLOC and SILC, HASH, ENC, DEC, and HASH, are all
sequential. However, the blockcipher calls in ENC and PRF can be done in parallel. We also note that theparallelization is always possible for multiple messages [14,13].
Due to the existence of ﬁve tweak functions in CLOC, the hardware implementation of CLOC does
not show the smallest size compared to existing schemes, since the implementation of tweak functions
requires many selectors.
SILC is designed to reduce the hardware gates of CLOC as much as possible, while maintaining theprovable security based on the pseudorandomness of the underlying blockcipher, at the cost of constantincrease in the number of blockcipher calls. It does not handle static associated data eﬃciently, as we ﬁrst
process a nonce and then associated data. We chose this order as the small hardware is the main target
of SILC, and hence it is unlikely that we keep the intermediate state block to improve the eﬃciency.

9

Design Rationale

The designers have not hidden any weaknesses in this cipher.
Design Rationale of CLOC. The design rationale of CLOC is detailed in [19], and we repeat a part of it
for completeness.
Our goal for CLOC is to provide an AEAD particularly eﬃcient for processing short input data, while
minimizing the memory consumption and precomputation outside the blockcipher. We mainly focus on
constrained sensor networks, where each data packet is short. For example, Zigbee [6] limits the maximum
packet length to 127 bytes, Bluetooth low energy limits to 47 bytes [1], and many previous proposals
on sensor network security protocols, e.g., TinySec [26], deﬁned similar limits, around 30 to 128 bytes.
Another example is EPC tag, which is a replacement of bar-code using RFID and has typically 96 bits [2].
We here describe the design rationale of CLOC for achieving our goal.
At abstract level CLOC is a straightforward combination of CFB and CBC MAC, where CBC MAC
is called twice for processing associated data and a ciphertext, and CFB is called once to generate aciphertext. However, when we want to achieve low-overhead computation and small memory consumption,
we found that any other combination of a basic encryption mode and a MAC mode did not work. For
instance, we could not use CTR or OFB, as they require one state block in processing a plaintext to holda counter value or a blockcipher output. We then realized that combining CFB and CBC MAC was notan easy task. Since we avoid using two keys or using blockcipher pre-calls, such as L = EK (0n ) used in
EAX, we could not computationally separate CFB and CBC MAC via input masking, such as Galois-ﬁeld
doubling (2i L for the i-th block, where 2L denotes the multiplication of 2 and L in GF(2n )) [10,37]. Thisimplies that CFB leaks input and output pairs of the blockcipher calls, which can be freely used to guessor fake the internal chaining value of CBC MAC, leading to a break of the scheme. Lucks [28] proposed
an AEAD scheme based on CFB, called CCFB. However, the problem is not relevant to CCFB due to thediﬀerence in the global structure. To overcome this obstacle in composition, we introduced the bit-ﬁxing
functions. Their role is to absolutely separate the input blocks of CFB and the first input block of CBC
MAC. This imposes the most signiﬁcant one bit of the input of CBC MAC being ﬁxed to 0, implying
one-bit input loss. The set of ﬁve tweak functions is used to compensate for this information loss. It also
works to compensate the information loss caused by padding functions applied to the last input blockto CBC MAC. A similar technique can be found in literature [34,41], however, the previous works only
considered MACs and the tweak functions required bit operations.
See [19] for further details about the choice of the tweak functions.
Design Rationale of SILC. Our goal is to provide an AEAD particularly eﬃcient for hardware, requiringa small number of gates other than the blockcipher implementation, that is, a small implementation
overhead. For achieving hardware eﬃciency, we set our design strategy as follows.
– Construct data ﬂow with minimized kinds/amount of functions, minimized ﬂow branching and merging, which implies extra multiplexers and registers, and the use of same ordering of functions in
diﬀerent steps, which makes hardware sharing easy.
16

– Avoid functions not suitable to hardware, such as dynamic data shifting, which requires a barrel
shifter, and integer operations etc.
– Avoid to use many pre-computed values, which consumes extra registers.
SILC is built upon CLOC, and inherits the overall structure. SILC is a combination of CFB and CBC
MAC, where we use fix1 and zpp functions to logically separate CFB and CBC MAC. Here, instead ofzpp, any function that forces the ﬁrst input bit to CBC MAC to zero would work, however, we choose
zpp for its simplicity in hardware. This loses the capability of eﬃcient handling of static associated data,
but we think this is the right treading-oﬀ between the size and simplicity, considering our target (e.g. it
is unlikely for small hardware to have a memory block and a control logic for caching static associateddata).
For the tweak function, as in CLOC, we avoid using GF doubling, and instead, we have adopted the gfunction to reduce the hardware logic size. When implemented as combinational circuits, the g function ismuch simpler than the GF doubling because it consists of a static amount of shifting, which consumes nohardware resources, and a minimum amount of xors. The role of the g function is to tweak an input valueof the blockcipher, and a similar technique can be found in the context of MAC [34,41]. There is only
one tweak function in SILC, which is diﬀerent from CLOC that has ﬁve tweak functions. This means the
hardware implementation of SILC does not need many selectors. The tweak function is selected so thatit satisﬁes the following conditions, which is needed for provable security. First, it is linear with respect
to xor (i.e. g(X ⊕ X ′ ) = g(X) ⊕ g(X ′ ) holds for all X, X ′ ∈ {0, 1}n ). Next, it is invertible over {0, 1}n .
Finally, let K ∈ {0, 1}n be uniform over {0, 1}n . Then, we require that the following functions are (closeto) uniform over {0, 1}n .


g(K)





g(K) ⊕ K
g(g(K))g(g(K)) ⊕ Kg(g(K)) ⊕ g(K)It can be easily conﬁrmed that our g function fulﬁlls these conditions for n = 64, 96, 128 by computing
the corresponding matrix ranks over GF(2) as was done in [19].
At the end of HASH and PRF, we use a simple padding function with additional length encoding.
Though this always requires one additional blockcipher call compared to popular 10∗ padding used bymany blockcipher modes, the former is much more eﬃcient in terms of the gate size. We remark that our
padding scheme here is similar to the one used in GCM.
Selection of Blockciphers. For n = 128, we choose AES as the underlying blockcipher for both CLOC and
SILC, because the security of AES has been extensively studied. For n = 64, we choose TWINE for CLOC
as the underlying blockcipher, because of its low-resource implementation for embedded processors shownin [39]. The use of 64-bit blockciphers is particularly useful if input length is short, say a few bytes, whichis in fact possible for ultimately constrained, single-purpose sensors such as energy harvester devices
like [3], gas or water metering, etc. In such cases, a 128-bit blockcipher can be ineﬃcient, since it islikely that we have more redundant output bits from the blockcipher that has to be discarded. For SILC,
we choose present and LED as the underlying blockciphers. Both ciphers were chosen for their small
hardware size, and we think present is useful when the application requires high throughput, and LED
is useful when long-term security is required, where LED’s high security margin will help.

10Intellectual Property

We claim no intellectual property (IP) rights associated to CLOC nor SILC, and are unaware of any
relevant IPs to CLOC or SILC held by others. The statement does not cover the internal blockcipher,and NEC Corporation (NEC) has pending patent applications related to TWINE blockcipher in CLOC:
WO2011052585 and WO2011052587. In case that CLOC with TWINE blockcipher is included into theﬁnal portfolio, NEC is willing to provide to implementors, solely for the purpose of implementing CLOC,
a royalty-free, non-exclusive license under the patents issuing on such patent applications, to the extent
17such patents are essential to implement CLOC as set forth in the ﬁnal portfolio, provided said that
implementor extends a reciprocal royalty-free license. Nanyang Technological University has a patent
related to LED blockcipher in SILC: WO2012154129 A1.
If any of this information changes, the submitter will promptly (and within at most one month)
announce these changes on the crypto-competitions mailing list.

11

Consent

The submitters hereby consent to all decisions of the CAESAR selection committee regarding the selection or non-selection of this submission as a second-round candidate, a third-round candidate, a ﬁnalist,a member of the ﬁnal portfolio, or any other designation provided by the committee. The submittersunderstand that the committee will not comment on the algorithms, except that for each selected algorithm the committee will simply cite the previously published analyses that led to the selection of thealgorithm. The submitters understand that the selection of some algorithms is not a negative comment
regarding other algorithms, and that an excellent algorithm might fail to be selected simply because notenough analysis was available at the time of the committee decision. The submitters acknowledge thatthe committee decisions reﬂect the collective expert judgments of the committee members and are notsubject to appeal. The submitters understand that if they disagree with published analyses then they
are expected to promptly and publicly respond to those analyses, not to wait for subsequent committee
decisions. The submitters understand that this statement is required as a condition of consideration ofthis submission by the CAESAR selection committee.
Acknowledgments. The work by Tetsu Iwata was carried out in part while visiting Nanyang Technological University, Singapore, and was supported in part by JSPS KAKENHI, Grant-in-Aid for ScientiﬁcResearch (B), Grant Number 26280045. The work by Jian Guo was partially supported by the Singapore
National Research Foundation Fellowship 2012 (NRF-NRFF2012-06).

References
1. Bluetooth low energy, http://www.bluetooth.com/Pages/Low-Energy.aspx/
2. Electronic Product Code (EPC) Tag Data Standard (TDS), http://www.epcglobalinc.org/standards/tds/
3. EnOcean, http://www.enocean.com/
4. IEEE 802.15.4, http://en.wikipedia.org/wiki/IEEE 802.15.4/
5. Z-Wave Alliance, http://www.z-wavealliance.org/
6. ZigBee Alliance, http://www.zigbee.org/
7. American National Standard Protocol Speciﬁcation For Interfacing to Data Communication Networks. ANSI
C12.22-2008. (2008)
8. Beaulieu, R., Shors, D., Smith, J., Treatman-Clark, S., Weeks, B., Wingers, L.: The SIMON and SPECK
Families of Lightweight Block Ciphers. Cryptology ePrint Archive, Report 2013/404 (2013), http://eprint.
iacr.org/2013/404
9. Bellare, M., Kilian, J., Rogaway, P.: The Security of the Cipher Block Chaining Message Authentication Code.
J. Comput. Syst. Sci. 61(3), 362–399 (2000)
10. Bellare, M., Rogaway, P., Wagner, D.: The EAX Mode of Operation. In: Roy, B.K., Meier, W. (eds.) FSE
2004. LNCS, vol. 3017, pp. 389–407. Springer (2004)
11. Bhargavan, K., Leurent, G.: On the Practical (In-)Security of 64-bit Block Ciphers: Collision Attacks on
HTTP over TLS and OpenVPN. In: ACM Conference on Computer and Communications Security. ACM(2016)
12. Bogdanov, A., Knudsen, L.R., Leander, G., Paar, C., Poschmann, A., Robshaw, M.J.B., Seurin, Y., Vikkelsoe,
C.: PRESENT: An Ultra-Lightweight Block Cipher. In: Paillier, P., Verbauwhede, I. (eds.) CHES 2007. LNCS,
vol. 4727, pp. 450–466. Springer (2007)
13. Bogdanov, A., Lauridsen, M.M., Tischhauser, E.: Comb to Pipeline: Fast Software Encryption Revisited. In:
Leander, G. (ed.) FSE 2015. LNCS, vol. 9054, pp. 150–171. Springer (2015)14. Bogdanov, A., Mendel, F., Regazzoni, F., Rijmen, V., Tischhauser, E.: ALE: AES-Based Lightweight Authenticated Encryption. In: Moriai, S. (ed.) FSE 2013. LNCS, vol. 8424, pp. 447–466. Springer (2013)
15. Dworkin, M.: Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication
and Conﬁdentiality. NIST Special Publication 800-38C (2004)

18

16. Eichlseder, M.: Remark on variable tag lengths and OMD. A comment on the CAESAR mailing list (2014),
https://groups.google.com/forum/#!forum/crypto-competitions
17. Gouvêa, C.P.L., López, J.: High Speed Implementation of Authenticated Encryption for the MSP430X Microcontroller. In: Hevia, A., Neven, G. (eds.) LATINCRYPT 2012. LNCS, vol. 7533, pp. 288–304. Springer(2012)
18. Guo, J., Peyrin, T., Poschmann, A., Robshaw, M.: The LED Block Cipher. In: Preneel, B., Takagi, T.
(eds.) CHES 2011. LNCS, vol. 6917, pp. 326–341. Springer (2011), An updated version is available at http://eprint.iacr.org/2012/600
19. Iwata, T., Minematsu, K., Guo, J., Morioka, S.: CLOC: Authenticated Encryption for Short Input. In: Cid,
C., Rechberger, C. (eds.) FSE 2014. LNCS, vol. 8540, pp. 149–167. Springer (2014)
20. Iwata, T., Minematsu, K., Guo, J., Morioka, S.: CLOC: Authenticated Encryption for Short Input. Cryptology
ePrint Archive, Report 2014/157 (2014), Full version of FSE 2014 paper, http://eprint.iacr.org/2014/157
21. Iwata, T., Minematsu, K., Guo, J., Morioka, S.: CLOC: Compact Low-Overhead CFB. Submission to the
CAESAR competition (2014), CLOC v1. March 15, 2014
22. Iwata, T., Minematsu, K., Guo, J., Morioka, S.: CLOC: Compact Low-Overhead CFB. Submission to the
CAESAR competition (2015), CLOC v2. August 29, 2015
23. Iwata, T., Minematsu, K., Guo, J., Morioka, S., Kobayashi, E.: SILC: SImple Lightweight CFB. Submission
to the CAESAR competition (2014), SILC v1. March 15, 2014
24. Iwata, T., Minematsu, K., Guo, J., Morioka, S., Kobayashi, E.: SILC: SImple Lightweight CFB. Submission
to the CAESAR competition (2014), SILC v2. August 29, 2015
25. Iwata, T., Ohashi, K., Minematsu, K.: Breaking and Repairing GCM Security Proofs. In: Safavi-Naini, R.,
Canetti, R. (eds.) CRYPTO 2012. LNCS, vol. 7417, pp. 31–49. Springer (2012)
26. Karlof, C., Sastry, N., Wagner, D.: TinySec: a link layer security architecture for wireless sensor networks. In:
Stankovic, J.A., Arora, A., Govindan, R. (eds.) SenSys 2004. pp. 162–175. ACM (2004)
27. Luby, M., Rackoﬀ, C.: How to Construct Pseudorandom Permutations from Pseudorandom Functions. SIAM
J. Comput. 17(2), 373–386 (1988)
28. Lucks, S.: Two-Pass Authenticated Encryption Faster Than Generic Composition. In: Gilbert, H., Handschuh,H. (eds.) FSE 2005. LNCS, vol. 3557, pp. 284–298. Springer (2005)
29. Manger, J.H.: [Cfrg] Attacker changing tag length in OCB. A discussion thread on Cfrg (2013), http://www.
ietf.org/mail-archive/web/cfrg/current/msg03433.html
30. McGrew, D.: Impossible Plaintext Cryptanalysis and Probable-Plaintext Collision Attacks of 64-bit Block
Cipher Modes. Pre-proceedig of FSE 2013 (2013)
31. McGrew, D.A., Viega, J.: The Security and Performance of the Galois/Counter Mode (GCM) of Operation.
In: Canteaut, A., Viswanathan, K. (eds.) INDOCRYPT 2004. LNCS, vol. 3348, pp. 343–355. Springer (2004)
32. Minematsu, K., Lucks, S., Morita, H., Iwata, T.: Attacks and Security Proofs of EAX-Prime. In: Moriai, S.
(ed.) FSE 2013. LNCS, vol. 8424, pp. 327–347. Springer (2013)
33. Moise, A., Beroset, E., Phinney, T., Burns, M.: EAX’ Cipher Mode (May 2011). NIST Submission (2011), http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/eax-prime/
eax-prime-spec.pdf
34. Nandi, M.: Fast and Secure CBC-Type MAC Algorithms. In: Dunkelman, O. (ed.) FSE 2009. LNCS, vol.
5665, pp. 375–393. Springer (2009)35. Procter, G., Cid, C.: On Weak Keys and Forgery Attacks Against Polynomial-Based MAC Schemes. J.
Cryptology 28(4), 769–795 (2015)
36. Rogaway, P., Wagner, D.: A Critique of CCM. Cryptology ePrint Archive, Report 2003/070 (2003), http://eprint.iacr.org/2003/070
37. Rogaway, P.: Eﬃcient Instantiations of Tweakable Blockciphers and Reﬁnements to Modes OCB and PMAC.
In: Lee, P.J. (ed.) ASIACRYPT 2004. LNCS, vol. 3329, pp. 16–31. Springer (2004)
38. Suzaki, T., Minematsu, K.: Improving the Generalized Feistel. In: Hong, S., Iwata, T. (eds.) FSE 2010. LNCS,
vol. 6147, pp. 19–39. Springer (2010)
39. Suzaki, T., Minematsu, K., Morioka, S., Kobayashi, E.: TWINE : A Lightweight Block Cipher for Multiple
Platforms. In: Knudsen, L.R., Wu, H. (eds.) SAC 2012. LNCS, vol. 7707, pp. 339–354. Springer (2012)
40. Whiting, D., Housley, R., Ferguson, N.: Counter with CBC-MAC (CCM). IETF RFC 3610 (2003)
41. Zhang, L., Wu, W., Zhang, L., Wang, P.: CBCR: CBC MAC with rotating transformations. SCIENCE CHINA
Information Sciences 54(11), 2247–2255 (2011)

A

TWINE Blockcipher [39]We describe TWINE blockcipher by reusing materials from [39].
19Data Processing Part. TWINE is a 64-bit blockcipher with 80 or 128-bit keys. We write TWINE-80 or
TWINE-128 to denote the key length. We here focus on TWINE-80, which is used in CLOC. The global
structure of TWINE is a variant of Type-2 generalized Feistel structure (GFS) with 16 nibbles (i.e. 4-bit
sub-blocks). A round function of TWINE consists of a nonlinear layer using 4-bit S-boxes and a diﬀusion
layer, which is a permutation on 16 nibbles. The diﬀusion layer of TWINE is not a cyclic shift and ischosen to provide a better diﬀusion property than the cyclic shift, according to the result of Suzaki and
Minematsu [38]. This round function is iterated for 36 times for both key lengths, where the diﬀusion
layer of the last round is omitted. For i = 1, . . . , 36, the i-th round uses a 32-bit round key, RKi , which
is derived from the 80-bit secret key, K, using the key schedule.
The data processing part essentially consists of a 4-bit S-box, denoted by S, and a permutation πover the indexes of 4-bit nibbles. That is, we have π : {0, . . . , 15} → {0, . . . , 15}, where the j-th subblock is mapped to the π[j]-th sub-block. Fig. 17 shows the encryption procedure, TWINE.Enc, and thedecryption procedure, TWINE.Dec, using the derived round keys. Fig. 17 also shows S-box S, and the
permutation π and its inverse. In all ﬁgures of this section, a variable X may have a subscript (i) toexpress its length, i.e., X may be written as X(|X|) , for clearness. The round function is also illustrated
in Fig. 19.
Key Schedule Part. The key schedule produces RK(32×36) from the 80-bit secret key K. It is also avariant of GFS with nibbles using the same S-box as data processing part. The key schedule uses 6-bit
round constants, CONi(6) = CONiH(3) ∥CONiL(3) for i = 1 to 35. Fig. 18 shows the pseudocode of the keyschedule, and Fig. 20 illustrates the key schedule for one round. In Fig. 18 Roti(x) means i-bit left cyclic
shift of x. We remark that CONi corresponds to 2i in GF(26 ) with primitive polynomial z 6 + z + 1. The
values of CONi are also listed at Fig. 18.
We provide a test vector in Table 7.

Algorithm TWINE.Enc(P(64) , RK(32×36) , C(64) )Algorithm TWINE.Dec(C(64) , RK(32×36) , P(64) )1
1
1
1. X0(4)∥X1(4)∥ . . . ∥X15(4)←P
136
2. RK(32) ∥ . . . ∥RK(32) ← RK(32×36)
3. for i = 1 to 35 do
4.
RKi0(4) ∥RKi1(4) ∥ . . . ∥RKi7(4) ← RKi(32)5.
for j = 0 to 7 do
i
i
i
6.
X2j+1
← S(X2j⊕ RKij ) ⊕ X2j+1
7.
for h = 0 to 15 do
i+1
← Xhi
8.
Xπ[h]
9. for j = 0 to 7 do
36
36
36
10.
X2j+1
← S(X2j⊕ RK36j ) ⊕ X2j+1
36
36
36
11. C ← X0 ∥X1 ∥ . . . ∥X15

36
36
36
1. X0(4)∥X1(4)∥ . . . ∥X15(4)←C
136
2. RK(32) ∥ . . . ∥RK(32) ← RK(32×36)
3. for i = 36 to 2 do
4.
RKi0(4) ∥RKi1(4) ∥ . . . ∥RKi7(4) ← RKi(32)5.
for j = 0 to 7 do
i
i
i
6.
X2j+1
← S(X2j⊕ RKij ) ⊕ X2j+1
7.
for h = 0 to 15 do
i
8.
Xπi−1
−1 [h] ← Xh
9. for j = 0 to 7 do
1
1
1
10.
X2j+1
← S(X2j⊕ RK1j ) ⊕ X2j+1
1
1
1
11. P ← X0 ∥X1 ∥ . . . ∥X15

x 0 1 2 3 4 5 6 7 8 9 A B C D E F
S(x) C 0 F A 2 B 9 5 8 3 D 7 1 E 6 4h
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
π[h] 5 0 1 4 7 12 3 8 13 6 9 2 15 10 11 14
π −1 [h] 1 2 11 6 3 0 9 4 7 10 13 14 5 8 15 12Fig. 17. Data processing part of TWINE (top) with S-box S (middle) and permutation π (bottom)

Table 7. A test vector of TWINE-80 in hexadecimal notation
key (80 bits) 00112233 44556677 8899
plaintext
01234567 89ABCDEF
ciphertext
7C1F0F80 B1DF9C28

20

Algorithm TWINE.KeySchedule-80(K(80) , RK(32×36) )1. WK0(4) ∥WK1(4) ∥ . . . ∥WK19(4) ← K
2. for r = 1 to 35 do
3.
RKr(32) ← WK1 ∥WK3 ∥WK4 ∥WK6 ∥WK13 ∥WK14 ∥WK15 ∥WK16
4.
WK1 ← WK1 ⊕ S(WK0 )5.
WK4 ← WK4 ⊕ S(WK16 )6.
WK7 ← WK7 ⊕ 0∥CONrH
7.
WK19 ← WK19 ⊕ 0∥CONrL8.
WK0 ∥ . . . ∥WK3 ← Rot4(WK0 ∥ . . . ∥WK3 )9.
WK0 ∥ . . . ∥WK19 ← Rot16(WK0 ∥ . . . ∥WK19 )10. RK36(32) ← WK1 ∥WK3 ∥WK4 ∥WK6 ∥WK13 ∥WK14 ∥WK15 ∥WK16
11. RK ← RK1 ∥RK2 ∥ . . . ∥RK36i
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
CONi 01 02 04 08 10 20 03 06 0C 18 30 23 05 0A 14 28 13 26
i
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
CONi 0F 1E 3C 3B 35 29 11 22 07 0E 1C 38 33 25 09 12 24
Fig. 18. Key schedule of TWINE-80. S-box S is the same as Fig. 17.

Fig. 19. Round function of TWINE
16

RK 0i

RK1i
RK 2i
RK 3i
RK 4i
RK 5i
RK 6i

4

4

16
4

4

4

4

16
4

4

16
4

4

16
4

4

4

8

0 CON Hi

4

0 CON Li

S
S

RK 7i

16

16

16

16

16

Fig. 20. 80-bit key scheduleB

present [12]present is a blockcipher with 80-bit or 128-bit keys, and employs the SP-network. We describe the 80-bit
key version, which we write present-80, using the materials in [12].
It consists of 31 rounds, and each of the 31 rounds consists of an xor operation of a round key Ki
for 1 ≤ i ≤ 32, where K32 is used for post-whitening, a linear bitwise permutation, and a non-linear
substitution layer. The non-linear layer uses a single 4-bit S-box S which is applied 16 times in parallelin each round. The cipher is described in the following pseudocode.
1. generateRoundKeys()
2. for i ← 1 to 31 do
21

3.
addRoundKey(state, Ki )4.
sBoxLayer(state)
5.
pLayer(state)
6. end for7. addRoundKey(state, K32 )Throughout this section, we number bits from zero with bit zero on the right of a block or word. Eachstage is speciﬁed below.
addRoundKey. Given round key Ki = κi63 . . . κi0 for 1 ≤ i ≤ 32 and current state b63 . . . b0 , addRoundKey consists of the operation for 0 ≤ j ≤ 63,
bj → bj ⊕ κij .
sBoxlayer. The S-box used in present is a 4-bit to 4-bit S-box S : {0, 1}4 → {0, 1}4 . The following
table shows the input and output of the S-box in hexadecimal notation.
x 0123456789ABCDEF
S[x] C 5 6 B 9 0 A D 3 E F 8 4 7 1 2For sBoxLayer the current state b63 . . . b0 is considered as sixteen 4-bit words w15 . . . w0 where wi =b4∗i+3 ∥ b4∗i+2 ∥ b4∗i+1 ∥ b4∗i for 0 ≤ i ≤ 15 and the output nibble S[wi ] provides the update state values
in the obvious way.
pLayer. The bit permutation used in present is given by the following table. Bit i of state is moved
to bit position P (i).
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
The key schedule. present can take keys of either 80 or 128 bits. In the 80-bit key version, theuser-supplied key is stored in a key register K and represented as k79 k78 . . . k0 . At round i the 64-bit
round key Ki = κ63 κ62 . . . κ0 consists of the 64 leftmost bits of the current contents of register K. Thusat round i we have that:
Ki = κ63 κ62 . . . κ0 = k79 k78 . . . k16 .
After extracting the round key Ki , the key register K = k79 k78 . . . k0 is updated as follows.
1. [k79 k78 . . . k1 k0 ] = [k18 k17 . . . k20 k19 ]2. [k79 k78 k77 k76 ] = S[k79 k78 k77 k76 ]3. [k19 k18 k17 k16 k15 ] = [k19 k18 k17 k16 k15 ] ⊕ round counter
Thus, the key register is rotated by 61 bit positions to the left, the left-most four bits are passed throughthe present S-box, and the round counter value i is xor’ed with bits k19 k18 k17 k16 k15 of K with theleast signiﬁcant bit of round counter on the right.
22

C

LED [18]

LED [18] is a 64-bit lightweight blockcipher family designed by Guo et al. in 2011, consists of mainly twovariants of 64-bit and 128-bit key, denoted as LED-64 and LED-128, respectively. The 64-bit plaintext m
is split into 16 4-bit nibbles m0 ∥m1 ∥ . . . ∥m15 , and can be represented in a square array as:
m0 m1 m2 m3
 m4 m5 m6 m7 
 m8 m9 m10 m11 
m12 m13 m14 m15
LED is AES like, and every round function consists of 4 operations: SubByte, ShiftRow, MixColumn,
and AddConstant.
SubByte applies the present S-box, as already described in Appendix B, to every nibble, i.e., mi =S(mi ) for i = 0, . . . , 15.
ShiftRow shifts the i-th row to the left by i positions for i = 0, . . . , 3, and the resulted matrix becomes
m0 m1 m2 m3
m0 m1 m2 m3
 m4 m5 m6 m7  m5 m6 m7 m4  m8 m9 m10 m11  ←  m10 m11 m8 m9 
m12 m13 m14 m15m15 m12 m13 m14
MixColumn applies Galois-Field multiplication, with irreducible polynomial f (x) = x4 + x + 1, of MDS
matrix to each column. The MDS matrix is deﬁned as


4 

0100
4122
0 0 1 0 = 8 6 5 6.
M = (A)4 = 0 0 0 1
B E A 9
4122
22FB
Then for i = 0, 1, 2, 3,






mi+0
mi+0
 mi+4  mi+4  mi+8  = M ×  mi+8  .
mi+12
mi+12

AddConstant adds a round-dependent value rc and key-size dependent value ks (ks is an 8-bit representation of the master key size) to the state. The constant format is as follows.


0 ⊕ (ks7 ∥ks6 ∥ks5 ∥ks4 ) 1 ⊕ (ks7 ∥ks6 ∥ks5 ∥ks4 ) 2 ⊕ (ks3 ∥ks2 ∥ks1 ∥ks0 )3 ⊕ (ks3 ∥ks2 ∥ks1 ∥ks0 )(rc5 ∥rc4 ∥rc3 )(rc2 ∥rc1 ∥rc0 )(rc5 ∥rc4 ∥rc3 )(rc2 ∥rc1 ∥rc0 )

0
0
0
0


0
0

0
0

The values of (rc5 , rc4 , rc3 , rc2 , rc1 , rc0 ) for rounds r = 1, . . . , 48 are shown below:
RoundsConstants

1–24
25–48

01,03,07,0F,1F,3E,3D,3B,37,2F,1E,3C,39,33,27,0E,1D,3A,35,2B,16,2C,18,30
21,02,05,0B,17,2E,1C,38,31,23,06,0D,1B,36,2D,1A,34,29,12,24,08,11,22,04

Every 4 rounds are then grouped together to form a Step, and the key material is added in every
step. In this proposal, we make use of LED-80, which follows LED-128. The 80-bit key is padded with‘0’s and then split into two 64-bit subkeys K1 and K2 (note K1 and K2 can be encoded in the same
way as for plaintext), which are then added into the state alternatively in every one of the 12 steps,
as shown in Fig. 21.
23

.K1
.

.K2
.4 rounds.P.K1.4 rounds.K2.4 rounds.K2.K1.4 rounds.C.one step

Fig. 21. Encryption of LED-80

Table 8. Values of param for CLOC and SILC with Simon-n/k (left) and Speck-n/k (right). τ is written in bits
and param is in hex.
Simon-n/k
τ 64/96 64/128 96/96 128/128 128/256
32 0xa0 0xa1 0xa2 0xa3
0xa4
48 0xa5 0xa6 0xa7 0xa8
0xa9
64 0xaa 0xab 0xac 0xad
0xae

DSpeck-n/k
τ 64/96 64/128 96/96 128/128 128/256
32 0xb0 0xb1 0xb2 0xb3
0xb4
48 0xb5 0xb6 0xb7 0xb8
0xb9
64 0xba 0xbb 0xbc 0xbd
0xbe

Using Other Blockciphers

CLOC and SILC are blockcipher modes of operation and any blockcipher can be used. In this appendix,
we describe how other blockciphers can be used by taking examples of Simon and Speck in [8] as possible
options (and hence the speciﬁcations of Simon and Speck are not included in this document. See [8]).
They are lightweight blockciphers, and Simon is a family of 10 blockciphers depending on the blockand key lengths. Speck also consists of 10 blockciphers, and Simon-n/k refers to Simon with block lengthn bits and key length k bits. Speck-n/k is analogously deﬁned. We consider Simon-n/k and Speck-n/kfor (n, k) = (64, 96), (64, 128), (96, 96), (128, 128), (128, 256).
When we use Simon-n/k or Speck-n/k in CLOC or SILC, we let the nonce length be96 if n = 128,
ℓN = 72 if n = 96,
48 if n = 64
in bits, τ ∈ {32, 48, 64} in bits, and the values of param are as speciﬁed in Table 8.

E

Changes

E.1

Changes from CLOC v1 to CLOC v2

The speciﬁcation of CLOC v2 uses param so that the encryption and decryption algorithms depend on the
choice of the parameters, which are E, ℓN , and τ . This type of dependency was previously highlighted,
e.g., in [16,29,36]. There are three things to note:– The introduction of param does not mean that CLOC v2 handles variable length nonces nor variable
length tags. All the parameters, E, ℓN , and τ , have to be ﬁxed during the lifetime of the secret key.
– The introduction of param does not aﬀect the provable security result of CLOC, since we may consider
param ∥ N as a nonce, and then the provable security results in [19] still hold.
– We also note that param does not remove the dependency to other blockcipher modes of operation.
For instance the concurrent use (with the same secret key) of CLOC and ECB mode results in theloss of security. Similarly, CLOC and SILC cannot be used concurrently.
See [22, Appendix B] for the details of the speciﬁc part of the document that was updated.
24

E.2

Changes from SILC v1 to SILC v2

The introduction of param is the change from SILC v1 to SILC v2, and the same notes as CLOC v2
above apply to SILC v2. See [24, Appendix H] for the details of the speciﬁc part of the document thatwas updated.
E.3

Changes from CLOC v2 and SILC v2 to CLOC and SILC v3– CLOC v2 and SILC v2 are integrated into a single submission document as “CLOC and SILC v3”
following the request by CAESAR. Overall texts were revised for the integration.
– Two recommended parameter sets, aes128n8t8clocv2 and aes128n8t8silcv2, were removed tonarrow down the size of the recommended parameter space.
– We speciﬁed the order of the ﬁve recommended parameter sets.
– n = 96 is listed as a possible choice of the block length of the underlying blockcipher.
– We added Simon and Speck as possible options in Appendix D.
– There is no algorithmic change in the speciﬁcations of CLOC and SILC.

25