Exploring Lightweight Efficiency of ForkAES

Abstract

Recently the ForkAES construction was proposed by Andreeva et al. for efficiently performing authenticated encryption of very short messages on next generation IoT devices. The ForkAES tweakable block cipher uses around one and a half AES encryption calls to produce a pair of ciphertexts for any given plaintext. However the only downside of the construction is that it needs to store an extra state of 128 bits in addition with the storage elements required to perform AES encryption. Thus a hardware implementation of ForkAES would require additional circuit area to accommodate the extra state. In this paper, we first show that it is possible to implement ForkAES without any additional storage elements other than those required to implement AES, if the AES circuit can additionally perform decryption. Such an implementation naturally requires more clock cycles to perform ForkAES operations. We extend the recently proposed Atomic AES v2.0 architecture to realize ForkAES and compare the area-latency trade-offs incurred with and without an additional storage. The area of the most compact ForkAES design takes about 1.2 times that of AES. In the second part of the paper we look at another important parameter of lightweight efficiency, i.e. energy. It is well known that round based constructions for AES are the most energy efficient ones. We extend the so-called "S3K2" construction of Banik et al. (IEEE HOST 17) to realize ForkAES in an energy-preserving manner, and compare the effects of some design choices. The energy consumption of our best ForkAES design takes about 2 times that of AES. From lightweight design perspective, our results hence demonstrate that although ForkAES lives up to its promise (of being roughly 1.5 times that of AES) in terms of its area, the same does not hold for its energy consumption.

Multiple Impossible Differential Attacks for ForkAES

“…Using the sieve method based on rapid sorting, select 2 m+8 × (2 m+8 − 1)÷2 × 2 − 160 ≈ 2 2m− 145 pairs of (C 0 , y AK 8 ), where Δy SB 8,(0,1,2,3) ≠ 0 and ΔC SB 0,(0,1,2,3,4,5,6,7) ≠ 0, and the difference value of the other 20 bytes is zero; then, store the ordered texts (C 0, (8,9,10,11,12,13,14,15) , y SB 8,(0,1,2,3) ) in Table Ω 3 . For the second attack trail, attackers use the same 2 m known plaintexts, select 2 8 tweaks that take all possible values in T (2) , and fix the other 7 bytes to constant values.…”

“…Andreeva et al [1] also proposed a forkcipher named ForkAES. Balli and Banik [2] analysed the hardware performance of ForkAES. ey achieve a hardware implementation of ForkAES without any additional storage cost if the AES circuit can also perform decryption, thereby further optimizing the storage cost.…”

“…to obtain 3 × 2 n+79 subkeys k 10,(0,1,2,3,4,5,6,7) . Store the corresponding pairs (ySB 8,(4,5,6,7) , y ′ ) inTable U 2 , and index the pairs by subkey k 10,(0,1,2,3,4,5,6,7) , so 3 × 2 n+15 pairs remain on average.…”

Energy Analysis of Lightweight AEAD Circuits

“…In order to obtain higher number of round keys, the authors extend the 6-bit LFSR into a 7-bit one. Implementing ForkSkinny requires an additional 128-bit register to store the forking state, unless the block cipher supports combined encryption and decryption functionality [BB19]. Compared to generic unrolling, there is a caveat in unrolling ForkSkinny.…”