Beetle Family of Lightweight and Secure

Authenticated Encryption Ciphers

Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan Yasuda1
1
NTT Secure Platform Laboratories, Japan, {lastname.firstname}@lab.ntt.co.jp
2
Indian Institute of Technology, Kharagpur, [email protected]
3
Indian Statistical Institute, Kolkata, [email protected]

Abstract

This paper presents a lightweight, sponge-based authenticated encryption (AE)

family called Beetle. When instantiated with the PHOTON permutation from CRYPTO
2011, Beetle achieves the smallest footprint - consuming only a few more than 600
LUTs on FPGA while maintaining 64-bit security. This figure is significantly smaller
than all known lightweight AE candidates which consume more than 1,000 LUTs,
including the latest COFB-AES from CHES 2017. In order to realize such small
hardware implementation, we equip Beetle with an “extremely tight” bound of security.
The trick is to use combined feedback to create a difference between the cipher text
block and the rate part of the next feedback (in traditional sponge these two
values are the same). Then we are able to show that Beetle is provably secure
up {to−min c log}r, b/2, r bits, where b is the permutation size and r and c are
parameters called rate and capacity, respectively. The tight security bound allows
us to select the smallest security parameters, which in turn result in the smallest
footprint.
Keywords: Beetle, sponge, PHOTON, authenticated encryption, lightweight, permuta-
tion.

1 Introduction
Due to the recent rise in communication networks operated on small devices, authenticated
encryption (AE) is expected to play a key role in securing these networks, providing
both confidentiality and authenticity via symmetric-key cryptographic primitives. In
light of CAESAR competition [3] for AE and NIST’s lightweight cryptography project [27],
people recognize the apparent lack of AE standards suitable for the whole spectrum of
lightweight applications. As a result, several lightweight AE proposals have emerged.
These include: ASCON [19], CLOC/SILC [22, 23], Gibbon/Hanuman [6], JAMBU [32] and
Ketje [15]from the CAESAR competition, as well as the recently developed COFB [17,
18].

1.1 Block-Cipher-Based vs. Sponge-Based Constructions

We can classify the above AE proposals into two groups based on their designs. The first
group: CLOC/SILC, JAMBU and COFB, follow a rather classical style of iterating a
block cipher. The second group: ASCON, Gibbon/Hanuman and Ketje, are based on the
sponge construction introduced by Bertoni et al. in 2007 [9].
The sponge construction, now standardized as the SHA-3 hash function, consists of
a sequential application of a permutation f on a state of b bits. This state is partitioned
into an r-bit rate (or outer part) and a c-bit capacity (or inner part), where b = r + c. In
the absorption phase, message blocks of size r bits are absorbed by the outer part and
the
2 Beetle Family of Lightweight and Secure Authenticated Encryption

state is transformed using f , while in the squeezing phase, digests are extracted from the
outer part r bits at a time.
One of the advantages of the sponge-based design is that they can build lightweight
hash functions. Indeed, since the introduction of the design, a number of lightweight hash
algorithms have been proposed, including SPONGENT [16], QUARK [7] and PHOTON [20].
Mainly due to the smaller size of the total state values, the footprint of these algorithms
is generally smaller than classical Merkle-Damgård hash functions, which iterate a com-
pression function (rather than a permutation), and these compression functions essentially
employ the design of block ciphers.
Alongside being used as a “simple" hash function (such as SHA-3 standard Keccak
[29, 12]), the keyed variants of sponge mode have become very popular modes of operation
for a permutation to build a wide spectrum of symmetric-key primitives like message
authentication codes [13], pseudorandom functions, Extendable-Output Functions (“XOFs”)
[29] and authenticated encryption (AE) modes [10, 11]. The keyed Sponge principle also
got adopted in Spritz, a new RC4-like stream cipher [31], and in 10 out of 57
submissions to the currently running CAESAR [3] competition on authenticated
encryption.
Of these AE proposals, unexpectedly, one of the smallest is the COFB, which is
block- cipher-based. This does not seem to be consistent with what we have learned
from the designs of hash functions; we should be able to build more lightweight
schemes with the sponge construction than with block ciphers. Where is this gap
coming from? This work answers this question by demonstrating that actually, also for
AE, one can build smaller schemes with the sponge construction.

1.2 Existing Security Bounds of Sponge-based AE

Encryption via the Sponge is typically done via the Duplex construction [11], a stateful
construction consisting of an initialization interface and a duplexing interface. The
initialization interface can be called to initialize an all-zero state; the duplexing interface
absorbs a message of size < r bits and squeezes ≤ r bits of the outer part. The security of
the Duplex traces back to the indifferentiability of the classical Sponge, yielding a
O(2c/2) security bound. Bertoni et al. [11] showed that the Duplex, in turn, allows for
authenticated encryption in the form of SpongeWrap. This mode is, de facto, the basis of
the majority of Sponge-based submissions to the CAESAR competition. Jovanovic et al.
[24] claimed that Sponge-based constructions for authenticated encryption can achieve
the significantly
higher bound of min{2b/2, 2c, 2k} asymptotically, with b > c the permutation size.

1.2.1 Limitations of Jovanovic et al’s Result

In the above mentioned result, for the integrity security the authors have assumed that
the number of forgery blocks is limited. To be more specific, total number of forgery
attempted blocks σv is restricted to satisfy the following:

qp + σe + σv ≤ 2c/σv,

where σe is the total number of encryption query blocks and qp is the number of permutation
queries. The above equation clearly suggest that the number of decryption blocks
should be at most 2c/2.
But, in the real life applications, it is more likely that the adversary would make a
large number of decryption queries to mount the integrity (or forging) attack, and
hence the overall bound should be given in terms decryption queries along with the total
number of encryption and permutation queries. Considering the decryption queries,
their result
achieves min{2c/2, 2k} integrity security.
 Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 3

1.3 Our Contributions

In this paper, we present an efficient sponge based authenticated encryption mode called
Beetle that provides min{ c −log r, b/2, r }bits of security without any restrictions on
decryption queries.

1. Combining a Feedback Function with Sponge. In traditional sponge based

modes, the plain text is XORed with the rate part of the permutation output to get
the cipher text, and the same value is used as the rate part of the next feedback
(i.e. input to the subsequent permutation). However, in Beetle construction, a
Combined Feedback is used to create a difference between the cipher text block
and the rate part of the next feedback (in traditional sponge these two values are the
same). With this simple tweak, we have shown that the mode achieves improved
security without any additional storage.

2. PHOTON Instantiation and Hardware Implementation. We present our hard-

ware implementation results for our recommended instantiations, mainly targeting
two environments: one for the lightweight applications, other to achieve high security.
Our implementation results depicts that (i) the lightweight version has excellent
performance and it achieves the smallest footprint among all known lightweight
candidates, (ii) the highly-secure version provides good security and most lightweight
among other existing constructions achieving about 121 bits of security.

1.4 Design Rationale behind Our Construction

1.4.1 Sponge-Based
Design of sponge based AE schemes have drawn lots of attention in the recent years.
They adopt the design rational of sponge functions more precisely duplex sponge
functions. SpongeWrap [11] is a primitive of this type. Several constructions following
this type exist in the literature. In this work, we take the approach of designing a sponge
based AE scheme that achieves the above security level with a minimized hardware area.
We observed that, if we adopt a simple combined feedback (described in [18]) during
data absorption and release phase, we can achieve the desired security bound without any
additional overhead as compared to the traditional duplex sponge mode. Moreover, this
result is significant as we can minimize the hardware area by adopting a low state
permutation but with a standard security bound of 64-bit (this is a standard bound in
lightweight crypto). However, if we adopt a permutation with a larger state size, still we
can get a better hardware area than the existing schemes (with comparable security bound)
as the design has a negligible overhead from the traditional sponge design.

1.4.2 Combined Feedback

Chakraborti et. al. in [18] used combined feedback to design a lightweight block cipher
based AE scheme COFB. However, this design needs to maintain an additional secret state
for masking. We have observed that, we can remove this extra state by adopting a
sponge mode where the full state is not exposed through the ciphertext and the message
block (only the rate part is exposed). Moreover, this combined feedback helps us to
avoid any other additional operations but only to follow the traditional sponge mode.

1.4.3 Choosing PHOTON

Finally, we show that if we use a very lightweight permutation like PHOTON [20, 21]
then to the best of our knowledge, we can achieve an AE scheme with the lowest
hardware footprint. The benchmark in Sect 5 proves our statement. The benchmark also
shows that
 4 Beetle Family of Lightweight and Secure Authenticated Encryption

even if we adopt a larger state permutation, still we have better hardware area with a
high security bound than the existing schemes.

1.5 Beetle in the Light of NIST Lightweight Cryptography Project

Here we provide a brief discussuion on the significance of our design Beetle in the light
of NIST Lightweight Cryptography Project. In addition to the standard functionalities,
NIST has set the following minimum requirements from AE submissions, when the key
size is restricted to 128 bits:
112
• Time Complexity: any cryptanalytic attack should need at least T = 2 compu-
tations (includes the total time required to process the offline evaluations of the
underlying permutation) in a single key setting.

• Data Complexity: the total number of message bytes (among all messages and
associated data) processed through the underlying permutation under a single key
should be at least D = 250 − 1.
2
Now, the best known bound for the original sponge mode SpongeAE is O( D +D.T ), while
2 2 c
Beetle provides a security bound of O( D +DT + r.(D+T ) ). This clearly depicts that if
SpongeAE 2b 2c
mode is instantiated with a 256-bit permutation, then the capacity must be
at least 112 + 48 = 160 bits. However, only 120-bit capacity is sufficient for Beetle. This
essentially ensures lesser number of permutation invocations in case of Beetle, which makes
it more energy efficient. In fact, in case of short messages of length 16 bytes, Beetle
leads to 33.3% savings in the energy consumption, which is quite significant for the
lightweight applications.

2 Preliminaries
In this section we build up all the notations and recall basic security definitions for
authenticated encryption. We also recall some important basic results on the security of
authenticated encryption.

2.1 Notation
Fix three positive integer b, r and c to represent state size, rate and capacity of a sponge
construction. By definition, b = r + c. We denote a block by an element of {0, 1}r (i.e,
∗ ∗
a block is an r-bit string). For any X ∈ {0, 1} , where {0, 1} is the set of all finite bit
strings (including λ, the empty string), we denote the number of bits of X by |X|. Note
that |λ| = 0. For two bit strings X and Y , XǁY denotes the concatenation of X and Y . A
bit string X is called a complete (or incomplete) block if |X| = r (or |X| < r
respectively). We write the set of all complete (or incomplete) blocks as B (or B<
≤ ≤
respectively). Let B = B< ∪ B denote the set of all blocks. For B ∈ B , we define B using
∗ ∗
10 padding with B, to make it complete. Given Z ∈ {0, 1} , we define the parsing of Z
into r-bit blocks as
(Z[1], Z[2], . . . , Z[𝑥]) ← Z, where 𝑥 = [|Z|/r[, |Z[i]| = r for all i < 𝑥 and 1 ≤ |Z[𝑥]| ≤ r
r

such that Z = (Z[1] ǁ Z[2] ǁ · · · ǁ Z[𝑥]). If Z = λ, we let 𝑥 = 1 and Z[1] = λ. We write

||Z|| = 𝑥 (number of blocks present in Z). We similarly write (Z[1], Z[2], . . . , Z[𝑥]) ← Z
r

to denote the parsing of the bit string Z into r bit strings Z[1], Z[2], . . . , Z[𝑥 − 1] and
1 ≤ |Z[𝑥]| ≤ r. Given any sequence Z = (Z[1], . . . , Z[s]) and 1 ≤a ≤b ≤ s, we represent
the sub sequence (Z[a], . . . , Z[b]) by Z[a..b]. Similarly, for integers ≤a b, we write [a..b]
{ a, a + 1, . . . , b . We use the notation trunc(Z, r) to denote the most significant r
for the set
} binary string Z. Let γ = (γ[1], . . . , γ[s]) be a tuple of equal-length strings. We
bits of the
define mcoll(γ) = m if there exist distinct i1 , . . . , im ∈ [1..s] such that γ[i1 ] = · · · =
γ[im ]
 Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 5

and m is the maximum of such integer. We call{ i1, . . . , im }to be an m-multi-collision set
for γ.

2.2 Security Model

In this section we provide the security definitions for authenticated encryption in ideal
permutation model.

An authenticated encryption (AE) is an integrated scheme that provides both privacy

∗ ∗
of a plaintext M ∈0,{ 1 } and authenticity of M as well as associate data A ∈ {0, 1 } .
Taking a nonce N (which is a value never repeats at encryption) together with associated
date A and plaintext M , the encryption function of AE,E K , produces a tagged-ciphertext
(C, T ) where| C| = |M |and T| = | t. Typically, t is a fixed length. The corresponding
decryption function, DK , takes (N, A, C, T ) and returns a decrypted plaintext M when
the verification on (N, A, C, T ) is successful, otherwise returns the atomic error symbol
denoted by ⊥.
Unified Security Notion for AE in Random Permutation Model. Let f be the
underlying idealized permutation of an AE scheme E. We define the advantage of an
adversary A in breaking the AE-security of E under ideal permutation model as follows:
,EK,Dk ,$,⊥
± ±
AdvEAE(A) := | Pr[Af = 1] − Pr[Af = 1]|,

where the probabilities are taken over the random choices of f , $, K, and the random
choices of A, if any. The fact that the adversary has access to both the forward and inverse
permutations in f is denoted by f ±. We assume that adversaryA is nonce-respecting,
which means that it never makes two queries toEKor $ with the same nonce. By
AdvAE (q , q , q , σ , σ ) we denote the maximum advantage taken over all adversaries
SP e p v e v
that makes at most qe encryption queries with a total length of at most σe, at most qp
queries to f ± and at most qv decryption queries with a total length of at most σv.

2.3 Coefficients-H Technique

In this section we give a quick high-level outline of coefficients H technique due to
Patarin [30]. We will use this technique (without giving a proof) to prove our main
theorem. Consider two oraclesO 0 (the ideal oracle) andO 1 (the real oracle). Let𝘧 denote
the set of all possible transcripts an adversary can obtain. For any view τ ∈ 𝘧 , we will
denote the probability to realize the view as ipreal(τ ) (or ipideal(τ )) when it is interacting
with the real (or ideal respectively) oracle. We call these interpolation probabilities.
w.o.l.g., we assume that adversary is deterministic. Hence, the interpolation
probabilities are the properties of the oracles only. As we deal with stateless oracles,
these probabilities are independent of the order of query responses in the view.
Theorem 1. Suppose for a set 𝘧 good ⊆𝘧 of views (called the good views) the
following hold:
1. For any adversary A playing against O0 (the ideal), the probability of getting a view
in 𝘧good is at least 1 − ϵ1. We may denote the set 𝘧 \ 𝘧good by 𝘧bad. Hence, the the
probability of getting a view in 𝘧bad is at most ϵbad.

2. For any view τ ∈ 𝘧good, we have

ipreal(τ ) ≥ (1 − ϵratio) · ipideal(τ )

For an oracle O1 satisfying (1) and (2) above, for any adversary A, we have AdvOprf
1
(A) ≤
ϵbad + ϵratio.
 6 Beetle Family of Lightweight and Secure Authenticated Encryption

3 Specification of Beetle
In this section, we provide a formal specification of Beetle family, a variant of
traditional duplex sponge. Similar to the original construction, we use a b-bit
permutation f with rate−r and capacity c = b r. First we specify all the basic building
blocks and parameters used in our construction, and then provide the formal algorithm
along with a pictorial description.

3.1 External Parameters and Recommended Parameter Sets

The rate r and capacity c is taken as the external parameter. Recall that, these two
explicitly determine the state size i.e. b = r + c. Depending on the application, we suggest
the following recommended parameter sets:
Beetle[Light+] (for lightweight applications): This instantiation mainly focuses on
lightweight applications. Here, we recommend to use the permutation P144 with the
parameter set (r = 64, c = 80).
Beetle[Secure+] (for highly secure applications): This is a highly secure instantiation
of Beetle. Here, we recommend to use the permutation P256 (described in [20, 21]) with
the parameter set (r = 128, c = 128).

3.2 Mathematical Components

3.2.1 Feedback Function ρ
←
r/2
Let W ∈ {0, 1}r and (W [1], W [2]) W , where W [i] ∈ {0, 1}r/2 . We define shuffle : B → B
as shuffle(W ) = (W [2], W [2]⊕ W [1]). For1 I∈ B and I2 ∈ B , we define the
function ρ : B × B → B × B as follows:
feedback
ρ(I1, I2) = (O1, O2), where O1 := ρ1(I1, I2) = shuffle(I1) ⊕ I2, O2 := ρ2(I1, I2) = I1 ⊕ I2.

The corresponding inverse feedback function ρ' : B × B → B × B is defined as

'
ρ' (I1 , O2 ) = (O1 , I2 ), where O1 := ρ1 (I1 , O2 ) = shuffle(I1 ) ⊕ I1 ⊕ O2 , I2 := ρ2 (I1 , O2 ) = I1 ⊕ O2 .

Note that, here we need the following requirements on the function shuffle:

• The mapping I → shuffle(I) is bijective.

• The mapping I → shuffle(I) ⊕ I is also bijective.

It is easy to see that our choice of shuffle satisfies both the requirements.

3.2.2 PHOTON Permutation

PHOTON is a permutation on b bits where b can be written as b = d2.s. The internal state
of PHOTON is represented as a (d×d) matrix whose each cell element is of s bits long.
The permutation is composed of 12 rounds, each round containing four layers:

• AddConstants (AC). This function applies round-dependent constants to each cell of

the first column.

• SBox (SBox). This function applies the s-bit Sbox to every cell of the internal state.
For s = 4, Present SBox and s = 8, AES SBox are used.

• ShiftRows (SR): This function simply rotates each cell located at row i by i
positions to the left.
 Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 7

A[1] A[3]

N ⊕ K1
ρ ρ
Y [1]X[1] · · · Y [3]X[3]
K2 f f f
⊕ Z[3]
Z[1]
ConstA

M [1] C[1]
M [4] C[4] T

ρ ρ
X[3]ǁZ[3] Y [4]X[4] ··· Y [7]X[7]
f f f f
⊕ Z[7]
Z[4]

ConstM

Figure 1: Beetle Construction with a = 3 associated data blocks and m = 4 message

blocks. The value ConstA and ConstM is used to denote whether last associated data
block and message block is complete or not.

• MixColumns (MC): This function updates linearly all columns independently using
a light non MDS matrix M serially (d times) such that M d is an MDS matrix.
This provides maximal diffusion and also makes the circuit efficient for hardware
implementation.
Complete details of PHOTON can be found in [21, 20]. In this work, we use two
versions of PHOTON permutations on 144 bits and 256 bits which are denoted as P144
and P256 respectively. The parameters for these two versions are (s = 4, d = 6) and (s = 4,
d = 8) respectively.

3.3 Formal Specification of Beetle

Formal specification of Beetle is presented in Fig. 2. The algorithm takes an r-bit nonce
N and a master key b-bit K. The master key is K = Kǁ 1 K2, where | K| 1 = r and| K2 =
c. N and K are first loaded into the initial state ⊕ |asǁ (N K1) K2. The state is then
processed using f and next the encryption algorithm takes non-empty A and non-
empty M , and
outputs C and T such that |C| = |M | and |T | = r. The decryption algorithm takes
(N, A, C, T ) with |A|, |C| = 0 and outputs M or ⊥.
The hash module is a variant of traditional sponge mode with an API suitable for
using it in an authenticated encryption mode. It takes IV to initialize the state and data
D. The other input parameters such as l is used to initialize the counter for the internal
state variables, const is used for domain separation for the associated data process and the
message process, release is an indicator to output ciphertext/ message blocks along
with the state value from hash and enc is used to denote whether we are invoking hash
inside the encryption or decryption module. For associated data processing, we set
release = 0 to denote that it is not releasing any output block, it only updates the
state.

3.4 Security of Beetle

Here we state the main security theorem for Beetle:
 8 Beetle Family of Lightweight and Secure Authenticated Encryption

D[d]) ←r D Beetle-EK(N, A, M ) 1. (A[1], . . . , A[a]) ←r A

Module hash(IV, D, l, const, release, enc) 1. (D[1], . . . , Algorithm
X[l]ǁZ[l] ← IV 2. (M [1], . . . , M [m]) ←r M
for i = 1 to d
4.Y [l+i]ǁZ[l+i+1] ← f (X[l+i−1]ǁZ[l+i−1])
If enc = 1 Then: (
3. const = 1 if |A[a]| < r
(X[l + i], O[i]) ← ρ(Y, D[i]) A 2 otherwise.
Else:
(X[l + i], O[i]) ← ρ'(Y, D[i]) (
4. const = 3 if |M [m]| < r
Z[l + d] ← Z[l + d] ⊕ const M 4 otherwise.
If release = 0 Then: Return X[l + d]ǁZ[l + d]
Else: 5. X[a]ǁZ[a] ← Proc-A( N ⊕ K 12
ǁ
K , A, 0, Const A)
Return ((O[1], . . . , O[d]), X[l + d]ǁZ[l + d]) (C, X[a + m]ǁZ[a + m]) ← Proc-M(X[a]ǁZ[a], M , a, ConstM )
Module Proc-A(IV, A, l, const) T ← trunc(f (X[a + m]ǁZ[a + m]), r)
XǁZ ← hash(IV, A, l, const, 0, 1)
Return C[1..|M |], T
Return XǁZ
Algorithm Beetle-DK(N, A, C, T )
Module Proc-M(IV, M, l, const)
(O, XǁZ) ← hash(IV, M, l, const, 1, 1)
Return (O, XǁZ) 1. (A[1], . . . , A[a ]) ←
r
A
Module Proc-C(IV, C, l, const) 2. (C[1], . . . , C[c]) ←r C
(O, XǁZ) ← hash(IV, C, l, const, 1, 0)
( 1
Return (O, XǁZ) 3. const = if |A [a ]| < r
A 2 otherwise.
( 3
4. constM = if |M [m]| < r
4 otherwise.

5. X[a]ǁZ[a] ← Proc-A( N ⊕ K1ǁ K2, A, 0, ConstA )

6. (M, X[a + c]ǁZ[a + c ]) ← Proc-C(X [a] ǁ Z[a ], C, a, ConstM )

T ' ← trunc(f (X[a + c]ǁZ[a + c]), r)
If T ' = T Then: Return M [1..|C|]
Else:
Return ⊥

Figure 2: The encryption and decryption algorithms of Beetle. Here ∀i, |X[i]| = |Y [i]| =
|O[i]| = r and |Z[i]| = c.

-
 Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 9

2
2(σe + σv )(σe + qp) qp r qp r rσv qv
AE
(q e, qp , qv , σe , σv , t) ≤
AdvBeetle + r−1 + + + .
2 b 2 2r+c−1 2c 2r
Based on the above theorem, Beetle[Light+] achieves 64-bit AE security and Bee-
tle[Secure+] achieves 121-bit AE security. The proof of the above theorem is detailed in
Sect. 4.

3.5 Features
The sponge based mode described above aims to achieve high security bound. This in
turn makes the mode lightweight by minimizing the state size. We follow the approach
of boosting the security by using a combined feedback technique over the traditional
duplex sponge. The AE security level increases from c/2 − to c log r. This in turns helps us to
construct a scheme with the same security level but with a reduced state size. For example,
Beetle[Secure+] achieves almost 128-bit security (121-bit security) with only a 256-bit state
and c = 128. Beetle is a lightweight design (with small overheads from the tradition duplex
sponge) that boosts the security without any restriction. Here we present a comparative
study on the state size and security trade-off in Table 1.
Beetle also enjoys flexibility. It is easy to fit any permutation into this structure. This
depicts that, when used with lighter permutations, it consumes lower hardware footprints.
We can also play with r and c to make a proper trade off between the data absorption
and the security level.

Table 1: Comparative Study on the State size and Security Trade-off: for all the con-
structions, we have assumed that n/2 bits message is processed per primitive call. Here
SpongeAE refers to the AE mode using traditional duplex sponge mode.

Design State size Security

Beetle n n/2−log n/4
COFB (1.5n + k)/2 n/4 − log n/2
SpongeAE n n/4

We would like to point out that, we have concentrated only on the round-based
implementation with n-bit data path and that essentially ensures that the state size to
be
n. However, we agree that a real serialized implementation could make it area efficient,
but state size would grow up close to 1.5n (b + r in general). In addition, as far we know,
in principle we need n bits for state and n/2 bits for message buffer. However if we
process message in one clock cycle we don’t need to store the message buffer to an
internal state. Note that this argument holds for duplex sponge, not imposed by the
addition of feedback.

4 Formal Security Proof

In this section, we present the security analysis of Beetle, mainly we prove Theorem 2:
2

AE
AdvBeetle e p v e v
2(σe + 2σbv)(σe + qp) qp
2r−1 r qp
2b−1 r r(qp2+
c σv ) qrv
(q , q , q , σ , σ , t) ≤ + + + +2 .

4.1 Notations and Set-up

Fix a deterministic non-repeating query making distinguisher adv that interacts with either
(1) the real oracle (Beetlef , f ) or (2) the ideal oracle ($, f ) making at most
1. qe encryption queries (Ni, Ai, Mi)i=1..qe with an aggregate of total σe many blocks,
 10 Beetle Family of Lightweight and Secure Authenticated Encryption

2. qf offline or direct forward queries (Q+ )i=1..q to f ,

i f
− −1
3. qb direct backward queries (Q )i=1..q to f and
i b

4. attempts to forge with qv many queries (N ∗ , A∗ , C ∗ , T ∗ )i=1..q having a total of σv

i i i i
many blocks. v

We assume qp = qf + qb to be the total no of offline or direct queries. Also assume that,

i, Mi and Ai have mi and ai blocks respectively and C∗ and A∗ have c∗ and a∗ blocks
∀
respectively. We use the notation X ∗ , Z ∗ , Y ∗ and Z '∗ to denote
i the
i intermediate
i variables
corresponding to the forging queries. i

4.2 Overview of the Attack Transcript

We begin with a description of the ideal oracle which consists of two phases. In the on line
phase, for any encryption queries (Ni , Ai = (Ai [1], . . . , Ai [ai ]), Mi = (Mi [1], . . . ,
Mi [mi ])), the oracle samples the cipher text blocks Ci = (Ci [1], . ←. . , {Ci [m}i ]) $ 0, 1
r.mi r
and
∈ { the} tag T 0, 1 uniformly at random and returns
Ai it to . For any direct forward
query Q+ i
to f , the oracle returns (L ǁR ) := f (Q ) uniformly at random. Here L+ and R+ denot e
+ + +
i i i i i
the rate (most significant r bits) and capacity (least significant c bits) of the value f (Qi+).
−
Similarly for any direct backward query Q−i to f , the oracle returns L−i ǁRi := f
−1 ∗ ∗ ∗
(Q−i ) uniformly at random. For any forging query (Ni , A∗i , Ci , Ti ), the oracle
returns ⊥.

OFFLINE CHAIN. We call that there exists a chain of sequence (Li1 , Li2 , . . . , Liµ+1 ), denoted
by Chain(Li1 , Li2 , . . . , Liµ+1 ) if there exists Ri1 , . . . , Riµ+1 such that the following chain
is obtained via offline queries:

f (Li1 ǁRi1 ) = L'i2 ǁRi2

' '
, f (ρ'1 (Li 2 , Li2 )ǁRi2 ) = Li 3
ǁRi3 , .
.
'
f (ρ 1 (L iµ−1 , Liµ−1 )ǁRiµ−1 ) = Li µ ǁRiµ ,
' '

f (ρ'1 (L'iµ , Liµ )ǁ(Riµ ⊕ const)) = Liµ+1

ǁRiµ+1 ,

We use the notation mChain(Li1 , Li2 , . . . , Liµ+1 ) to denote number of (Ri1 , Ri2 , . . . , Riµ+1 )
for which the event Chain(Li1 , Li2 , . . . , Liµ+1 ) occurs. We use the notation Init(Li1 , Li2 , . . . , Liµ+1
) to denote the set of Ri1 values for which Chain(Li1 , Li2 , . . . , Liµ+1 ) occurs.
Next, in the offline phase (i.e. after A makes all the queries responses), it sets all the
Xi [ai + k], Yi [ai + k] values: Yi [ai + k] := Mi [k] ⊕ Ci [k], Xi [ai + k] := shuffle(Mi [k]
Ci [k]) ⊕ Mi [k], for all k = 1, . . . , mi . Then it samples Xi [k], Yi [k], for all k = 1, . . .
, ai and the internal chaining values i.e. Zi [k], for all k = 1, . . . , ai + mi uniformly at
random { from} ≤ all
0, 1 c . For i k a∗ ,i the values Y ∗ [k], Z ∗ [k] are set to Yj [k],
Zj [k] respectively,
i
if ∃j, Ni ∗ = Nj , Ai∗ [1..k] = Aj [1..k]. Similarly, for all ai ∗ + 1 ≤ k ≤ a∗i + m∗i , the values
Yi∗ [k], Zi∗ [k] are set to Yj [k], Zj [k] respectively, if ∃j, Ni∗ = Nj , A∗ = Aj , C ∗ [1..k] = Cj [1..k].
The value ∗
i Xi [k] is defined as Yi [k]
∗
⊕ A∗ [k], for k ≤ ai∗ . The value Xi∗ [ai∗ + k] is defined
∗ ∗ ∗
as Y i [a + k]⊕M [k], for k ≤ m . All the remaining Y ∗ values are sampled uniformly at
∗

∗
random and corresponding
i
X variables are set accordingly.

If A interacts with real oracle, we always have (i) f (Ni ǁK) = Xi [0]ǁZi [0] and (ii)
f (Xi [j]ǁZi [j − 1]) = Yi [j]ǁZi [j], i = 1..qe , j = 1, .., ai + mi − 1 and f (Xi [ai + mi ]ǁZi [ai +
mi ]) = Yi [ai + mi ]ǁZi [ai + mi ] ⊕ ConstM , where X[i] and Y [i]s are computed via ρ.
Overall, the transcript of the adversary τ := (τe, τp, τv) be the list of queries and responses
of A that constitutes the query response transcript of A, where
 Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 1

• τe = (Ni, Ai, Mi, Ci, Zi, Ti)i=1..qe ,

• τp = (Q+
i , f (Qi ))i=1..q f ∪ (f
+ −1
(Q− −
i ), Qi )i=1..q band
∗ ∗ ∗
• τv = (Ni , A∗i , Ci , Ti , ⊥), i = 1..qv .
We denote ipideal and ipreal the probability distribution of transcript τ induced by the ideal
world and real world respectively.

4.3 Identifying and Bounding Bad Events

Now, we fix λ > 0, and define a set of events (initial bad events) for which the adversary
aborts.
• B1: initColl. This event denotes that the initial state collides with a direct forward
query or the response of a direct backward query, i.e.
∃i, j (Ni ⊕ K1 ǁ K2) ∈ {Qj +, Lk−ǁRk−}.

• B2: mColl(X) > λ. This event signifies that λ multi-collision occurs in the rate part
of the encryption queries. Formally, ∃w ≥ λ, i1, i2 . . . , iw such that
Xi1 [j1 ] = Xi2 [j2 ] = · · · = Xiw [jw ].

• B3: inpColl. This event denotes a state collision in the input of a permutation. This
can happen when: (i) two input states to the permutation collides during the
online (encryption) queries or (ii) an input state in the online (encryption) query
collides with a direct forward query or the response of a direct backward query.
Technically speaking, this event occurs when either
∃i, j, i' , j ' s (Xi [j]ǁZi [j]) = (Xi' [j ' ]ǁZi' [j ' ]) or ∃i, j, k (Xi [j]ǁZi [j]) ∈ {Qk+ , Lk− ǁRk− }.

• B4: outColl. This event denotes a state collision in the output of a permutation.
This can happen when: (i) two output states to the permutation collides during the
online (encryption) queries or (ii) an output state in the online (encryption) query
collides with a direct backward query i.e. either
∃i, j, i' , j ' s (Yi [j]ǁZi [j + 1]) = (Xi' [j ' ]ǁZi' [j ' + 1]) or
−
∃i, j, k (Yi [j]ǁZi [j + 1]) ∈ {Qk , Lk+ ǁRk+ }.

• B5: mColl(L ) > λ. This event signifies that λ multi-colllision occurs in the rate
+

part of the direct permutation queries. Technically seen, this event can be written
as: ∃w ≥ λ, i1, i2 . . . , iw such that
L+i1 = L+i2= · · · = Li+w .
−
• B6: mColl(L ) > λ. This event signifies that λ multi-colllision occurs in the rate
part of the direct inverse permutation queries. Technically seen, this event can be
written as: ∃w ≥ λ, i1, i2 . . . , iw such that
L−i1 = L−i2 = · · · = L−iw .
− −
• B7: mMitM(L+, R+, L , R ) > λ. This event signifies that λ Meet-in-the-Middle
type collision occurs via the direct permutation and inverse permutation queries.
More formally, the event is expressed as: ∃w > λ, i1, i2 . . . , iw such that
'
i1 j )1 = ρ 1 (L i2, L j2 ) = · · · = ρ1 (L
ρ'1 (L+ , L − ' + −
iλ
+
,L
λ
−
j ),
R+i1= R−j1, R+i2= R− j2, · · · , Ri+λ = Rj−λ .
 12 Beetle Family of Lightweight and Secure Authenticated Encryption

• B8: Forge. This event signifies that for some forging query, none of the states are
fresh and the final tag also matches. Technically, ∃ i such that
∗ ∗
– ∀j ≤ (a∗i + m∗i ), Xi [j]ǁZi [j] is not fresh, and
∗ ∗ ∗ ∗ ∗
– f (Xi [a∗i + m∗i ]ǁZi [ai + mi ]) = Ti ǁ * .

The following lemma bounds the probability of bad transcripts in ideal oracle:

Lemma 1. Let ϵbad denotes the probability of the event (B1 ∨ B2 · · · ∨ B8). Then,
(σeqp + σ2 + σeσv + qpσv)
e λqp q2λ λσv
qλ p p
ϵbad ≤ + c + r(λ−1) + r(λ−1)+cλ + c .
2b 2 2 2 2
Proof. Here we provide the upper bounds for the bad events (in ideal oracle) one by one,
as follows:
Bounding Pr[B1]. As the key K1 and K2 is chosen uniformly at random, for any fix i
and j, we have −
Pr[(Ni ⊕ K1 )ǁK2 ∈ {Q+ , L− ǁR− }] = 21 b .
j j j

Now, varying over all choices of i and j, we have

qe.qp
Pr[B1] ≤ .
2b−1
Bounding Pr[B2]. Fix i1, . . . iλ. As, all the X values are (i) either sampled uniformly at
random, or (ii) defined from C values which are sampled uniformly at random. Hence,
−r(λ−1)
Pr[Xi1 [j1 ] = Xi2 [j2 ] = · · · = Xiλ [jλ ]] ≤ 2 .

Now, varying over all possible choices of i1, . . . , iλ,

σe
Pr[B2] ≤ λ
.
2r(λ−1)
Bounding Pr[B3]. This probability stands for the (i) input state collisions between two
online queries or (ii) between one online query and one offline query. As all the
Ci [j] (and hence Xi [j]), Zi [j] values are sampled uniformly at random, for any fixed i, j,
i' , j ' ,
−
we have Pr[(Xi [j]ǁZi [j]) = (X−i' [j '−]ǁZi' [j ' ])]
1−b
= 2 b . On the other hand, for any fixed
i, j, k, Pr[Xi [j]ǁZi [j] ∈ {Qk , Lk ǁR k }] = 2
+
(if the offline query is made earlier) and
+
−
Pr[Xi [j] ǁZi [j] ∈ Q k ] = 2 c (as adversary can choose the offline query keeping the rate
part as Xi [j]). For the last case, given B2, the number of choices for (i, j) can be at most
λ. Now, combining all the cases and varying over all possible choices, we obtain
σe
Pr[B3 |B2] ≤ 2 σe.qp λ.qp
+ + .
2b−1 2b−1 2c
Bounding Pr[B4]. This probability stands for the output state collisions between two
online queries or between one online query and one offline query. Again, with a similar
logic as used in the previous case, one can show
σe
Pr[B4 |B2] ≤ 2 σe.qp λ.qp
+ + .
2b−1 2b−1 2c
Bounding Pr[B5]. Fix i1, . . . iλ. As, all the L+ values are sampled uniformly at random,

−r(λ−1)
Pr[Li+1 = L+i2= · · · = Li+λ ] ≤ 2 .
 Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 1

Now, varying over all possible choices of i1, . . . , iλ,

qp
Pr[B5] ≤ λ
.
2r(λ−1)
Bounding Pr[B6]. Fix i1, . . . iλ. As, all the L− values are sampled uniformly at random,

Pr[L−i1 = − − −
−
= · · · = Li ] ≤ 2 r(λ 1) .
L i2
λ

Now, varying over all possible choices of i1, . . . , iλ,

qp
Pr[B6] ≤ λ
.
2r(λ−1)
Bounding Pr[B7]. Fix i1, . . . iλ. As, all the L+, L− values are sampled uniformly at
random,
1
Pr[ρ'1(L+ , L− ) = · · · = ρ'1(L+ , L− ); R+ = R− , · · · , R+ = R− ] ≤ .
i1 j1 iλ jλ i1 j1 iλ jλ 2 .2cλ
r(λ−1)

Now, varying over all possible choices of i1, j1, . . . , iλ, jλ,
qp
Pr[B7] ≤ 2λ
.
r(λ−1).2cλ 2

Bounding Pr[B8]. Recall that the event B7 occurs if there exists a forging query
∗ ∗ ∗ ∗ ∗ ∗
(Ni , A∗i , Ci , Ti ) such that ∀j ≤ (a∗i + m + 1), Xi [j]ǁZi [j] is not fresh, and f (Xi [a∗i +
∗ ∗ ∗
m∗i ]ǁZi [a∗i + mi ]) = Ti ǁ*. Now we consider the following cases:
CASE A. ∀j, N ∗ /= Nj . The probability that the initial state (N ⊕ K1 K2 ) matches with
+q
any encryption orǁdirect
i query state, can be bounded by probability2bσe p .
∗
CASE B. Ni = Nj , A∗i /= Aj . Let p be the common prefix block index of A∗i and
∗
Aj i.e. A∗i [1..p] = Aj [1..p], Ai [p + 1] /= Aj [p + 1]. The probability that the state
∗
X ∗ [ai + p + 1]ǁZ ∗ [p + 1] matches with any encryption or direct query state, can be bounded
+q
by probability σe2b p .
∗ ∗
CASE C. (Ni , Ai ) = (Nj , Aj ). Let p be the common prefix of the corresponding
∗ ∗ ∗
ciphertexts i.e Ci [1..p] = Cj [1..p], Ci [p+1] Cj [p+1]. It is easy to see that Xi [a∗i +p+1] =
∗
ρ'1 (Cj [p + 1] ⊕ Mj [p + 1], Ci [p + 1]). Now, for B8 to hold, we need
∗≥ ∈
(i) mChain(Xi∗ [a∗i + p + 1], Ci ∗ [p + 2], . . . , iC ∗ [m ∗ ∗ ∗ ∗
i ], T ) 1 and Zi [a i + p + 1] Init[X [p +
∗ ∗ ∗ ∗
1], Ci [p + 2],i . . . , Ci [m i ], T ], or
∗ ∗ ∗ ∗
(ii) ∃ j, k; Xi [ai + p + 1] = Xj [k] and Zi [ai + p + 1] =
Zj [k] Now we make the following claim:
Claim. mChain(X i∗ [a∗i + p + 1], C ∗i [p + 2], . . . , Ci∗ [mi∗ ], T ∗ ) ≤ (m∗ + 1)λ, given that
B5, B6 and B7 have noti occured. 1

Proof. Suppose the claim is not true. Now by simple application of Pigeon-hole principle,
the above offine chain of length at most m∗i necessarily gives rise to one of three events:

• There exist at least λ many offine chain with f queries only: this essentially forces a
λ-multicollision in L+ values (and the value is T ∗), which is nothing but the event
B5.
∗
1 Note that, in the original sponge construction SpongeAE, the above claim doesn’t hold as (m + 1)λ
i
many collisions in an offine chain doesn’t necessarily converges to λ-multicollisions there.
 14 Beetle Family of Lightweight and Secure Authenticated Encryption

−
• There exist at least λ many offine chain with f 1 queries only: this forces a λ-
− ∗ ∗
multicollision in L values (and the value is Xi [a i + p + 1]), which is nothing
but the event B6.
−
• There exists at least λ many offine chain with f and f 1 that meets in the ith state:
th
this forces a λ-multicollision of type MitM at the i state, which is is nothing
but event B7.
∗ ∗ ∗
Given the above claim holds, the probability that 𝗁
Zi [a∗i + p +∈1] Init(Xi [ai + p + 1],
∗ ∗ ∗ ∗ (mi +1)λ
Ci [p + 2],
i
. .
i
. , C [m ], T ) is bounded by . This is due to the uniform random
2c
sampling
of the B2 hasn’t occur, the probability that
∗ ∗ Z values. On the other hand, given λ that
Z [a + p + 1] = Z [k] can be bounded by . Hence,
i i j 2c
qv
Σ σe + qp (m∗i + 2)λ
Pr[B8|B2 ∧ B5 ∧ ∧ B7] ≤
B6 i=1 2b + 2c
(σe + qp).qv
≤ + σvλ.
2b 2c
The lemma follows as we sum all the probabilities.

4.4 Analysis of Good Transcripts

Having defined and bounded the probability of realizing bad transcript in ideal world, it
only remains to lower bound the ratio of real and ideal interpolation probability for a
good transcript. Fix a good attainable transcript τ := (τe, τp, ⊥all) where ⊥all is used to
represent that all the verification queries output is ⊥. It is easy to see that,

ipideal = Prideal[τ ] = Prideal[τe, τp, ⊥all]

= Prideal[τe].Prideal[τp].Prideal[ ⊥all]
1
=
b σ
(2 ) e+qe+qp
.
Now, we consider the probability of the transcript in real oracle. By definition,

ipreal = Prreal[τ ] = Prreal[τe, τp, ⊥all]

Σ
≥ Prreal [τe , τp ] − Prreal [τe , τp , 𝖳i ]
i
Σ
= Prreal [τe , τp ] − Prreal [τe , τp ] Pr[𝖳i |τe , τp ]
i
= Prreal[τe, τp](1 − ϵratio)
=
P(2b ( 1
.(1 − ϵratio)
+ ))
, σe + qe qp
≥ ipideal.(1 − ϵratio),
Σ
where ϵratio = i ϵi , with ϵi = Pr[𝖳i |τe , τp ].
Calculation of ϵratio . Now we calculate ϵratio by bounding ϵi . Since τ is a good transcript,
and hence the event B8 doesn’t hold, either (i) ∃ j ∗ : (X ∗ [j ∗ ]ǁiZ ∗ [j ∗ ]) is fresh or (ii) the
event 𝖳 i holds with probability 0. For case (ii), we trivially i have ϵi = 0. So, we
consider case (i). Now we have the following observations:
∗ ∗
• If (Xi [j ∗ ]ǁZi [j ∗ ]) is fresh, then permutation f and the ρ function ensures
∗ ∗ ∗ ∗ (σe +σp )
that
i (X [j + i1]ǁZ [j + 1]) would be non-fresh with probability at most2b .
This
 Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 1

is due to the fact that usage of the ρ function restricts the adversary to have any
∗ ∗
control over Xi [j ∗ + 1] if the value Yi [j ∗ ] is random. This is in contrast to
the original sponge construction SpongeAE, where the adversary can always control
∗ ∗ ∗
the Xi [j ∗ + 1] using Ci [j ∗ + 1] irrespective of the value of Yi [j ∗ ].

• Extending this argument, we claim that the sequence of states any one of the
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗
following states (Xi [jiǁ] Zi [ji ]), (Xi [ji ǁ + 1] Zi [ji + 1]), . . ǁ. , (Xi [m∗i ]
∗ 𝗁
mi (σe+σp)
Zi [m∗i ]) will be non-fresh with probability
2b at most .
∗ ∗
• It is easy to see that, if (Xi [m∗i ]ǁZi [m∗i ]) is fresh, then
1
Pr[f (X ∗ [m∗ ]ǁZ ∗ [m∗ ]) = T ǁ*] = .
i i i i i
2r
Putting everything together,
1 m∗i (σe +
ϵi ≤ qp )
2r
+ .
Hence, we bound ϵratio as: 2b
qv qv
ϵratio = Σ ϵi ≤ Σ 1 + m i(σ e + qp)
∗
qv σ v .( σ e + q p ) .
b ≤ r +
2r 2 2 2b
i=1 i=1

4.5 Combining Everything Together and Use Patarin’s H-Coeffcient

2
Applying (σeqp+σe +σeσv +qpσv )
1 (Patarin’s H-Coeffcient technique) with ϵbad = .(σ
rqp qpTheorem
r 2b
+ ( ) + ( q σv e+qp)
2 r) +
rσ (putting = ) and = + , the result of
q p
v λ r ϵ v

2c 2r−1 2(r−1)+c 2c ratio 2r 2b

Theorem 2 follows.

5 Hardware Implementation of Beetle

5.1 Overview
Beetle primarily aims to be implemented in small hardware devices. In several applications,
the hardware resource for implementation plays an important role and the implementation
memory dominates in the total hardware resource and parallelization of the internal
modules for scalability are not needed. For this purpose, a small state size and completely
serial implementation is more desirable.
From implementation perspective, Beetle has a simple structure since it consists of
a permutation and a few basic operations (such as bitwise XORs with simple combined
feedback computations). Beetle uses a small sized state (only the permutation state)
and the implementation area of Beetle is largely dominated by the underlying
permutation.
In this paper, we only describe hardware architecture of Beetle[Light+]. Hardware
architecture for Beetle[Secure+] is similar (only differences are the bit lengths of the
variables) and can be easily followed. We provide our hardware implementation results
on both Virtex 6 and Virtex 7 under Xilinx 13.4. We first provide a brief analysis on the
clock cycles required to process the input bytes. This is a conventional way to estimate
the speed. Beetle[Light+] gets an a-block associated data and an m-block message and
needs 13(a + m) + 12 cycles (13 for each of the data blocks and 12 for the first
permutation call for initialization). Note that, when the data (associated data or
message) is empty, the algorithm processes one 0r block and it takes 25 = 13 + 12 clock
cycles. Table 2 shows the number of average cycles per input message bytes, which we
call cycles per byte (cpb), assuming the associated data has the same length as message
(i.e, a = m) and rate is 64 bits or 8 bytes.
· That is, the cpb is (13 2m + 12)/8m = 3.25 +
1.5/m. Clearly, when m is large then cpb converges to 3.25.
16 Beetle Family of Lightweight and Secure Authenticated Encryption

Table 2: Clock cycles per message byte for Beetle[Light+] with r = 64.

Message length (Bytes)

8 16 24 32 64 128 256 512 1024 2048 16384
cpb 3.4375 3.3437 3.3125 3.2969 3.2734 3.2617 3.2559 3.2529 3.2514 3.2507 ≈ 3.2500

T C

Init 64 64
64
N
144 Tr isFinal, isComplete
⊕ isAD
64 State 144
K1

144
80
K2 144 ρcomp 144 Con⊕ 144
frnd
144
64
D

Release, Round12
Round12

Figure 3: Hardware circuit diagram for Beetle[Light+]

5.2 Hardware Architecture

We implement both instantiations and report the results. They are base implementations
without any pipe lining. We mainly focus on the encryption only as the combined
encryption-decryption circuit has very small overhead in hardware area. This is mainly
due to the fact that the decryption algorithm does not need inverse permutation routine.
We use the same hardware for both the associated data and message processing phase
as they have similar computations. Only a single bit switch for the two types of input
data is required to distinguish. The main modules of the architecture are described below.
We also describe the finite state machine (FSM) that controls the circuit flow by setting
up and updating internal signals and sending them to the internal modules. The FSM
has a simple flow structure. The overall hardware architecture for the lighter version is
described in Fig. 3. The description of the architecture is based on Beetle[Light+] only.

1. State Register. The architecture for Beetle[Light+] contains only one state register
State. This register is used to store intermediate variables after each iteration. We
use an 144-bit state register for the permutation. We don’t need any register for
the key, as it is used only to initialize the state. The hardware circuit in Fig. 3
shows that State is updated after each round of f executed by frnd module.

2. Module frnd. frnd computes one round of f . It takes an 144-bit input from the
state register, computes one round of f and then either updates the state or send
the output to the ρ computation module ρcomp or releases the output as the tag.
The entire operation is serial and we need 12 clock cycles with 12 frnd executions to
execute f .

3. Module ρcomp. ρcomp module computes ρ on a 64-bit data block and a 144-bit
Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 1

intermediate state (output from the f computation). The output is a 144-bit feedback
value (passed to Con⊕ module to perform a constant addition in the capacity
part).

4. Module Con⊕ . This module executes a constant addition (addition of the constant
1/2/3/4) based on the signals it receives. The signals are described below.

5. Data Signals. The hardware circuit uses several internal data signals controlled by
the finite state machine (FSM). The circuit uses the following signals.

• Start: This signal indicates the start of the computations of the circuit. It
actually resets all the variables and sets the control to the reset state of the
circuit.
• Init: This signal indicates that the initialization is done and the circuit can
now process data blocks.
• isAD: This signal indicates whether the current block is an associated data
block or a message block. It actually controls the feedback computation module
as the associated data processing phase does not release any ciphertext block
and only computes the next feedback, where as the message processing
phase computes the next feedback as well as releases the ciphertext block. This
signal is also used with isFinal signal to decide which constant addition.
• isFinal: This signal indicates whether the current data block is the final block or
not. If it is the final block then the constant addition module becomes active.
It is used to control the Con⊕ module. It uses an internal demultiplexer that
decides whether to pass the data to the state register or add a constant to it.
This decision is taken using the isFinal signal.
• isComplete: This signal together with isAD decide which constant to add as
they differ by the completeness of the last block and type of the data block.
• Round12: This signal indicates whether frnd is executing its last round. If yes
then ρ computation module will start executing, otherwise the control
returns to the frnd module.
• Release: This signal indicates the release of the tag. After the tag release, the
circuit ends its functionalities.

These signals are actually generated and controlled by a controller module, which can
be viewed as a finite state machine (FSM). For the sake of simplicity, we intentionally
omit the description of FSM in Fig. 3. We describe the FSM separately in Fig. 4.
The description of the FSM is given below.

6. FSM. This module controls the whole circuit. It generates and sends signals to
different modules and divides the functionalities of the circuit into several states.
This is depicted in Fig. 4. The individual states are described below. Note that,
the signal isComplete is implicitly taken care by the controller and for the sake of
simplicity, it does not appear in Fig. 4.

• Reset: Starts the functionality of the circuit. It denotes everything is reset and
the circuit will begin to work now.
• Load: Initialize the permutation state where the secret key and the nonce are
loaded into the permutation state. The control next enters into invocation of f .
This is denoted by Init = 1.
• Invokef : Invocation of f . This state is further described by four states .
– Resetf : Resets the permutation state before the execution.
 18 Beetle Family of Lightweight and Secure Authenticated Encryption

Start Reset Load Invokef input control

FSM for
ProcAD isAD=1 isFinal = 0 Resetf
Invokef
Init=1
Release=0
isAD=1 isFinal=1
ProcADFinal Startf

Invokef Round12 = 0
isAD=0 isFinal=0

ProcM Release=1 Roundf

isAD=0
isFinal=1ReleaseTagRound12 = 1

ProcMFinal Endf

End
Invokef output control

Figure 4: Finite State Machine

– Startf : Start of the permutation execution. It actually loads the permuta-

tion state with the current internal value.
– Roundf : f round computations. The control remains in the same
state until the control reaches the last round. When Round12 becomes 1,
the control goes to the end of the permutation invocation.
– Endf : Indicates the end of the permutation execution and the control comes
out of the permutation module.
If Release = 1, control goes to the ReleaseTag state, else to the following four
stages.
• ProcAD: The circuit is now processing an associated data block but not the final
block. This information is passed to the circuit by isAD = 1 and isFinal = 0.
• ProcADFinal: The circuit is now processing the final associated data block. This
information is passed to the circuit by isAD = 1 and isFinal = 1.
• ProcM: The circuit is now processing a message block but not the final block.
This information is passed to the circuit by isAD = 0 and isFinal = 0.
• ProcMFinal: The circuit is now processing the final message block. This infor-
mation is passed to the circuit by isAD = 0 and isFinal = 1.
• ReleaseTag: The circuit releases the tag and the control enters into the End
state to signify the end of the computations.
• End: This state signifies the end of the computations by the circuit.

5.3 Basic Implementation

We describe a basic flow of our implementation of Beetle[Light+], which generally follows the
pseudo code of Fig. 2. During the initialization, State register is loaded with⊕ (N K1ǁ) K2.
Next, the initialization is started by processing the associated data blocks. After each of
the f invocations the output is processed with data blocks to compute the next feedback.
During the final associated data block processing, one constant is added to the capacity
part for domain separation. The message is processed in the same way as the associated
data, except the circuit releases one ciphertext block at each clock cycle and also
different constant is added when the final message block is processed. Finally, after the
message is processed the tag is released by truncating the output of the final f
execution.
 Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 1

Remark 1. (Combined Encryption and Decryption) As mentioned earlier, we have focus

on the encryption-only circuit. However, due to the similarity between the encryption and
the decryption modes, the combined hardware for encryption and decryption can be built
with a small increase in the area, with the same throughput. This can be done by adding
a control flow to a binary signal for mode selection.

Round12

+1
0 Round

M
StateACSBoxSRMC C

Start

Figure 5: Hardware circuit diagram for Round Based Implementation of f

5.4 Hardware Implementation of PHOTON

In this section, we briefly describe our own round based hardware implementation of
the P144 permutation [20, 21] (our choice of f ). The architecture described in Fig. 5 follows a
simple base implementation. The FSM for the architecture has been depicted in Fig. 4.
We intentionally remove the control unit from Fig. 5 for the sake of simplicity. The f
module receives 144-bit (18 bytes) plaintext data as input and processes it in 12 cycles
(one clock cycle for each of the 12 rounds ). Hence, cpb for f is 18/12 = 1.5. The circuit
maintains a 144-bit state register which is first loaded with the input and then gets updated
after each round. It also maintains a 4-bit register Round which stores the current round
number. It is initialized with 0 and is incremented by one after each round. After the
permutation executes all the rounds, the register is again reset to 0. As mentioned already,
the architecture computes one permutation round in one clock cycle and the round function
consists of 4 sequential submodules AC, SBox, SR and MC. AC is the first module of the
that adds a round dependent constant to the first column of the intermediate state. It
takes two inputs, the intermediate state and the current round number. Next, the SBox
module applies a non linear substitution to each of the nibbles (4-bit) of the state. The
SR module shifts each of the rows in the state and finally the MC module multiplies the
state with a serial matrix 6 times successively (multiplying once is denoted by MCS),
such that altogether it becomes multiplication by an MDS matrix. We implement this
version on Virtex 6 (target device xc6vlx760) and Virtex 7 (target device xc7vx415t). We
use the RTL approach and a basic iterative type architecture. We would like to
emphasize that our implementation is round based and it uses 144-bit data path.
We have also implemented P256 [20, 21] on the same platforms and and using the same
approach. The AC, SBox SR and MC operations are similar except they use larger state
(8 ×
8 matrix with 4-bit cells). The permutation consumes 256-bit (32 bytes) input and
processes it in 12 cycles (12 rounds in 12 clock cycles). Hence, cpb is 32/12 = 2.67. In
Sect. 5.5 below we report the overall hardware implementation results for Beetle[Light+]
and Beetle[Secure+].

Remark 2. We would like to point out that a possible way of optimization is to have serial
implementation with smaller data paths (e.g. 4 or 24 bits) as used in [4, 5]. It seems
 20 Beetle Family of Lightweight and Secure Authenticated Encryption

that such implementation could make the construction even more area efficient, though
the state size would increase by 64 and 128 bits for Beetle[Light+] and Beetle[Secure+]
respectively. This is due to the fact that we need to store the message buffer to an
internal state. This has nothing to do with the introduced feedback, and holds in
general for any duplex sponge mode.

5.5 Implementation Results

The hardware architecture of Beetle[Light+] is programmed in VHDL language and is
implemented on the same Virtex 6 (target device xc6vlx760) and Virtex 7 (target device
xc7vx415t) under Xilinx 13.4. We use the same RTL approach and a basic iterative type
architecture. The areas are listed in terms of the number of Slice Registers, Slice LUTs
and Occupied Slices. The number of slice registers, LUTs and slices are 185, 616 and 252
respectively on Virtex 6 and the same on Virtex 7 are 185, 608 and 312 respectively. The
frequencies reported are 381.592 MHZ on Virtex 6 and 425.595 MHZ on Virtex 7 where 13
(12 for f and one for ρ computation) cycles are required to process one 64 bit data block.
Thus, the throughputs for long messages on Virtex 6 and 7 are 1.879 and 2.211 Gbps
respectively. However we also calculate the area efficiency metric. The detailed hardware
results are presented in Table 3 below.

Table 3: Beetle[Light+] Implemented FPGA Results

# Slice Frequency Mbps/ Mbps/

Platform # LUTs # Slices Gbps
Registers (MHZ) LUT Slice
Vertex 6 185 616 252 381.592 1.879 3.050 7.369
Virtex 7 185 608 312 425.595 2.095 3.445 6.715

We also report the hardware implementation results for Beetle[Secure+] on the same
platform using the same approach. The detailed results are described in Table 4 below.

Table 4: Beetle[Secure+] Implemented FPGA Results

# Slice Frequency Mbps/ Mbps/

Platform # LUTs # Slices Gbps
Registers (MHZ) LUT Slice
Vertex 6 281 998 434 256.000 2.520 2.525 5.806
Vertex 7 305 1101 512 303.965 2.993 2.718 5.846

5.6 Component Wise Hardware Area Calculation for lightweight Bee-

tle[Light+]
The architecture of lightweight Beetle[Light+] consists of several modules. In this
section, we provide a brief description of the distribution of hardware area among the
modules. The main modules in this circuit are f , ρcomp and the control unit. The underlying
register State is used by f . The hardware area utilizations (in Virtex 6) by different modules
are presented in Fig. 6. It has been observed that, the majority of the hardware
footprint is used by the underlying f permutation and rest of the circuit uses a few
lightweight operations. The orange part denoted by "Others" consists of some additional
operations like key and nonce load, state updates, constant additions etc.

5.7 Benchmarking Beetle[Light+]

We benchmark hardware implementation results of Beetle[Light+] using a few of the Athena
listed implementations along with the implementation results in [2, 1] on both Virtex 6
 Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 2

ρ computation Others

Conrol Unit 13.64%

Control Unit 15.87%
02.27%
3.97% ρ Computation
Others 7.79%
7.14%

76.3%
73.02%

P144 Permutation
P144 permutation

Figure 6: Distribution of Components by #Slices (left) and #LUTs (right)

and 7. We would like to mention that this is a rough benchmark. Our implementation
ignores the overhead associated with the CAESAR API (an updated version of GMU
hardware API) and also this is an encryption only circuit while most of the others
support both encryption-decryption. We know that the GMU hardware API used in
the SHA-3 competition hardware benchmarking, can cause 25% overhead in terms of
the area compared to other interfaces they have provided [25, 26]. Nevertheless, our
current implementation results for Beetle[Light+] depict that it consumes lower hardware
footprints and provides highly competitive results than other constructions even if we
add the overhead for supporting GMU API and decryption circuit. We have chosen the
candidates for the benchmark by the following criteria

• CAESAR or non CAESAR lightweight Blockcipher based AE schemes and

1 1

• Sponge based AE schemes with smaller permutation size.

We observe that Beetle[Light+] occupies the lowest hardware area among the listed im-
plementations. it occupies much lower hardware footprint than the closest competitors:
COFB-AES, JAMBU-SIMON96 and Ketje-JR etc. and also achieves a better through-
put/area metric. These two benchmarks depicts that Beetle[Light+] is one of the best
candidates for lightweight applications. The benchmark is detailed in Table 5 and 6. The
hardware implementation results of COFB-AES have been taken from [18, 17] and that
of the other schemes have been taken from the ATHENA database [2, 1].

Table 5: Benchmarking Beetle[Light+] on Virtex 6. Sponge(b, r) denotes the scheme follows

sponge mode with rate r and uses a b-bit permutation. BC(n) denotes the scheme
follows a blockcipher based mode with an n-bit blockcipher.
Underlying Security Mbps/ Mbps/
Scheme # LUTs # Slices Gbps
Primitive (in Bits) LUT Slice
Beetle[Light+] Sponge(144, 64) 64 616 252 1.879 3.050 7.369
Ketje-JR [15] Sponge(200, 16) 96 1236 412 2.832 2.292 6.875
ASCON-128 [19] Sponge(320, 64) 128 1274 451 3.118 2.447 6.914
JAMBU-SIMON96 [32] BC(64) 48 1035 386 0.931 0.899 2.411
CLOC-TWINE80 [22] BC(80) 32 1689 532 0.343 0.203 0.645
SILC-LED80 [23] BC(80) 32 1684 579 0.245 0.145 0.422
SILC-PRESENT80 [23] BC(80) 32 1514 548 0.407 0.269 0.743
COFB-AES [17, 18] BC(128) 58 1075 442 2.850 2.240 6.450
 22 Beetle Family of Lightweight and Secure Authenticated Encryption

Table 6: Benchmarking Beetle[Light+] on Virtex 7.

Mbps/ Mbps/
Scheme # LUTs # Slices Gbps
LUT Slice
Beetle[Light+] 608 312 2.095 3.445 6.715
Ketje-JR 1567 518 4.080 2.604 7.876
ASCON-128 1557 432 4.059 2.607 9.396
JAMBU-SIMON96 1376 387 0.938 0.682 2.423
CLOC-TWINE80 1552 439 0.432 0.279 0.985
SILC-LED80 1682 524 0.267 0.159 0.510
SILC-PRESENT80 1514 484 0.479 0.316 0.990
COFB-AES 1456 55 2.820 2.220 5.080

5.8 Benchmarking Beetle[Secure+]

We also benchmark hardware implementation results of Beetle[Secure+] using a few of the
Athena listed implementations along with the implementation results in [2, 1] on both
Virtex 6 and 7. We have chosen the candidates for the benchmark by the following criteria
• Popular Sponge based CAESAR candidates with higher security level (available
in [2, 1]).
We observe that Beetle[Secure+] occupies the lowest hardware area among the listed
implementations. In fact, it occupies lower hardware footprint than the closest competitors:
ASCON-128, Hanuman and Ketje-JR. This benchmark is detailed in Table 7 and 8.

Table 7: Benchmarking Beetle[Secure+] on Virtex 6.

Underlying Mbps/ Mbps/
Scheme Security (in Bits) # LUTs # Slices Gbps
Primitive LUT Slice
Beetle[Secure+] Sponge(256, 128) 121 998 434 2.520 2.525 5.806
ASCON-128 [19] Sponge(320, 64) 128 1274 451 3.118 2.447 6.914
NORX [8] Sponge(1024, 768) 128 5495 1724 24.524 4.463 9.139
Ketje-SR [15] Sponge(400, 32) 128 1903 613 5.772 3.033 9.416
Riverkeyak [14] Sponge(800, 544) 128 6234 1751 7.417 1.190 4.236
Lakekeyak [14] Sponge(1600, 1344) 128 19860 7130 12.603 0.635 1.768
Gibbon [6] Sponge(280, 40) 120 1807 653 1.280 0.708 1.960
Hanuman [6] Sponge(280, 40) 120 1769 626 0.693 0.392 1.107
ICEPOLE128a [28] Sponge(1280, 1024) 128 5734 1995 44.464 7.754 22.288

Table 8: Benchmarking Beetle[Secure+] on Virtex 7. We use U to denote that the

corresponding results are unavailable.
Mbps/ Mbps/
Scheme # LUTs # Slices Gbps
LUT Slice
Beetle[Secure+] 1101 512 2.993 2.718 5.846
ASCON-128 1557 432 4.080 2.604 7.876
NORX 7877 2088 19.712 2.502 9.441
Ketje-SR 2592 724 6.752 2.605 9.326
Riverkeyak 8169 U 8.704 1.065 U
Lakekeyak 18581 4877 16.672 0.897 3.418
Gibbon 1894 600 1.169 0.617 1.948
Hanuman 1829 595 0.654 0.358 1.099
ICEPOLE128a 5733 1742 37.461 6.534 21.505

6 Conclusion
This paper presents Beetle, a sponge mode for AE focusing on the state size as well
as optimizing the security. It is instantiated with two versions, where the first version
Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 2

Beetle[Light+] aims to be lightweight and the second version Beetle[Secure+] aims to

be highly secure, yet lightweight (though much heavier than Beetle[Light+]). When
instantiated with a b-bit blockcipher, Beetle operates at a rate r (b = 144, r = 64 for
Beetle[Light+] and b = 256, r = 128 for Beetle[Secure+]) and requires state size of b bits,
and is provable secure up to min {c − log r, b/2, r} queries under the ideal permutation
model. To be precise, Beetle[Light+] has 64-bit security and Beetle[Secure+] has 121-bit
security. The key idea of Beetle is a feedback function combining both plaintext and
ciphertext blocks. We have also presented the hardware implementation results, which
demonstrate the effectiveness of our approach.

References
[1] ATHENa: Automated Tool for Hardware Evaluation. https://cryptography.gmu.
edu/athena/.
[2] Authenticated Encryption FPGA Ranking. https://cryptography.gmu.edu/
athenadb/fpga_auth_cipher/rankings_view.
[3] CAESAR: Competition for Authenticated Encryption: Security, Applicability, and
Robustness. http://competitions.cr.yp.to/caesar.html/.
[4] N. Nalla Anandakumar, Thomas Peyrin, and Axel Poschmann. A very compact
FPGA implementation of LED and PHOTON. IACR Cryptology ePrint Archive,
2014:738, 2014.

[5] N. Nalla Anandakumar, Thomas Peyrin, and Axel Poschmann. A very compact
FPGA implementation of LED and PHOTON. In Willi Meier and Debdeep
Mukhopadhyay, editors, Progress in Cryptology - INDOCRYPT 2014 - 15th
International Conference on Cryptology in India, New Delhi, India, December 14-17,
2014, Proceedings, volume 8885 of Lecture Notes in Computer Science, pages 304–
321. Springer, 2014.
[6] Elena Andreeva, Begül Bilgin, Andrey Bogdanov, Atul Luykx, Florian Mendel, Bart
Mennink, Nicky Mouha, Qingju Wang, and Kan Yasuda. PRIMATEs v1.02. Submis-
sion to CAESAR. 2016. https://competitions.cr.yp.to/round2/primatesv102.
pdf.
[7] Jean-Philippe Aumasson, Luca Henzen, Willi Meier, and María Naya-Plasencia. Quark:
A lightweight hash. In Stefan Mangard and François-Xavier Standaert, editors,
Cryptographic Hardware and Embedded Systems, CHES 2010, 12th International
Workshop, Santa Barbara, CA, USA, August 17-20, 2010. Proceedings, volume 6225
of Lecture Notes in Computer Science, pages 1–15. Springer, 2010.

[8] Jean-Philippe Aumasson, Philipp Jovanovic, and Samuel Neves. NORX v3.0. Submis-
sion to CAESAR. 2016. https://competitions.cr.yp.to/round3/norxv30.pdf.
[9]Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. On the
indifferentiability of the sponge construction. In Nigel P. Smart, editor, Advances
in Cryptology - EUROCRYPT 2008, 27th Annual International Conference on the
Theory and Applications of Cryptographic Techniques, Istanbul, Turkey, April 13-17,
2008. Proceedings, volume 4965 of Lecture Notes in Computer Science, pages 181–197.
Springer, 2008.

[10] Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. Duplexing the
sponge: single-pass authenticated encryption and other applications. IACR Cryptology
ePrint Archive, 2011:499, 2011.
24 Beetle Family of Lightweight and Secure Authenticated Encryption

[11] Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. Duplexing
the sponge: Single-pass authenticated encryption and other applications. In Ali Miri
and Serge Vaudenay, editors, Selected Areas in Cryptography - 18th International
Workshop, SAC 2011, Toronto, ON, Canada, August 11-12, 2011, Revised Selected
Papers, volume 7118 of Lecture Notes in Computer Science, pages 320–337. Springer,
2011.

[12] Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. Keccak. In
Thomas Johansson and Phong Q. Nguyen, editors, Advances in Cryptology - EURO-
CRYPT 2013, 32nd Annual International Conference on the Theory and Applications
of Cryptographic Techniques, Athens, Greece, May 26-30, 2013. Proceedings, volume
7881 of Lecture Notes in Computer Science, pages 313–314. Springer, 2013.

[13] Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. On the security
of the keyed sponge construction. In Symmetric Key Encryption Workshop, 2011.

[14] Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche, and Ronny Van
Keer. CAESAR submission: Keyak v2. Submission to CAESAR. 2016. https:
//competitions.cr.yp.to/round3/keyakv22.pdf.

[15] Guido Bertoni, Michaël Peeters Joan Daemen, Gilles Van Assche, and Ronny Van
Keer. Ketje v2. Submission to CAESAR. 2016. https://competitions.cr.yp.to/
round3/ketjev2.pdf.

[16] Andrey Bogdanov, Miroslav Knezevic, Gregor Leander, Deniz Toz, Kerem Varici,
and Ingrid Verbauwhede. spongent: A lightweight hash function. In Bart Preneel
and Tsuyoshi Takagi, editors, Cryptographic Hardware and Embedded Systems -
CHES 2011 - 13th International Workshop, Nara, Japan, September 28 - October 1, 2011.
Proceedings, volume 6917 of LNCS, pages 312–325. Springer, 2011.

[17] Avik Chakraborti, Tetsu Iwata, Kazuhiko Minematsu, and Mridul Nandi. Blockcipher-
based authenticated encryption: How small can we go? IACR Cryptology ePrint
Archive, 2017:649, 2017.

[18] Avik Chakraborti, Tetsu Iwata, Kazuhiko Minematsu, and Mridul Nandi. Blockcipher-
based authenticated encryption: How small can we go? In Wieland Fischer and
Naofumi Homma, editors, Cryptographic Hardware and Embedded Systems - CHES
2017 - 19th International Conference, Taipei, Taiwan, September 25-28, 2017, Pro-
ceedings, volume 10529 of Lecture Notes in Computer Science, pages 277–298.
Springer, 2017.

[19] Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer. Ascon
v1.2. Submission to CAESAR. 2016. https://competitions.cr.yp.to/round3/
asconv12.pdf.
[20]Jian Guo, Thomas Peyrin, and Axel Poschmann. The PHOTON family of
lightweight hash functions. In Phillip Rogaway, editor, Advances in Cryptology -
CRYPTO 2011 - 31st Annual Cryptology Conference, Santa Barbara, CA, USA,
August 14-18, 2011. Proceedings, volume 6841 of Lecture Notes in Computer Science,
pages 222–239. Springer, 2011.

[21] Jian Guo, Thomas Peyrin, and Axel Poschmann. The PHOTON family of
lightweight hash functions. IACR Cryptology ePrint Archive, 2011:609, 2011.

[22] Tetsu Iwata, Kazuhiko Minematsu, Jian Guo, Sumio Morioka, and Eita Kobayashi.
CAESAR Candidate CLOC. DIAC 2014.
Avik Chakraborti1, Nilanjan Datta2, Mridul Nandi3 and Kan 2

[23] Tetsu Iwata, Kazuhiko Minematsu, Jian Guo, Sumio Morioka, and Eita Kobayashi.
CAESAR Candidate SILC. DIAC 2014.
[24]Philipp Jovanovic, Atul Luykx, and Bart Mennink. Beyond 2 c/2 security in sponge-
based authenticated encryption modes. In Palash Sarkar and Tetsu Iwata, editors,
Advances in Cryptology - ASIACRYPT 2014 - 20th International Conference on the
Theory and Application of Cryptology and Information Security, Kaoshiung, Taiwan,
R.O.C., December 7-11, 2014. Proceedings, Part I, volume 8873 of Lecture Notes in
Computer Science, pages 85–104. Springer, 2014.
[25] B. Jungk and M. Stttinger. Hobbit: Smaller but faster than a dwarf: Revisiting
lightweight SHA-3 FPGA implementations. pages 1–7.
[26] Sachin Kumar, Jawad Haj-Yihia, Mustafa Khairallah, and Anupam Chattopadhyay.
A comprehensive performance analysis of hardware implementations of CAESAR
candidates. IACR Cryptology ePrint Archive, 2017:1261, 2017.
[27] Kerry A. McKay, Larry Bassham, Meltem Sönmez Turan, and Nicky Mouha. Report on
Lightweight Cryptography. 2017. http://nvlpubs.nist.gov/nistpubs/ir/2017/
NIST.IR.8114.pdf.
[28] PawełMorawiecki, Kris Gaj, Ekawat Homsirikamol, Krystian Matusiewicz, Josef
Pieprzyk, Marcin Rogawski, Marian Srebrny, and Marcin Wójcik. ICEPOLE v2. Sub-
mission to CAESAR. 2016. https://competitions.cr.yp.to/round2/icepolev2.
pdf.
[29] NIST. SHA-3 standard: Permutation-based hash and extendable-output functions.
FIPS PUB 202, 2015.
[30] J. Patarin. Etude des Générateurs de Permutations Basés sur le Schéma du D.E.S.
Phd Thèsis de Doctorat de l’Université de Paris 6, 1991.
[31] Ronald L. Rivest and Jacob C. N. Schuldt. Spritz - a spongy rc4-like stream cipher
and hash function. IACR Cryptology ePrint Archive, 2016:856, 2016.
[32] Hongjun Wu and Tao Huang. The JAMBU Lightweight Authentication Encryption
Mode (v2.1). Submission to CAESAR. 2016. https://competitions.cr.yp.to/
round3/jambuv21.pdf.