Energy Consumption and Computational Analysis of Rijndael-AES

M. Razvi Doomun* Computer Science and Engineering

Department University of Mauritius

Reduit, Mauritius (230) 781 8923

r.doomun@uom.ac.mu*

KM Sunjiv Soyjaudah Faculty of Engineering, University of Mauritius

Reduit, Mauritius (230) 454 1041

ssoyjaudah@uom.ac.mu

Devesh Bundhoo Computer Science and Engineering

Department University of Mauritius

Reduit, Mauritius (230) 7861794

bundhood4@mx.uom.ac.mu

Abstract— Encryption, which is the backbone of security protocols, is computationally intensive and consumes energy and computational resources that are limited in wireless devices. This paper focuses on evaluating the performance of Rijndael-Advanced Encryption Standard (AES) encryption scheme in terms of energy consumed and execution time, and modeling the computational operations involved. The objective is to provide simulation results to help in the design and optimization of efficient cryptographic techniques. The computational model as a function of primitive operations shows a good estimate of encryption complexity, hence the energy consumption for encryption.

Keywords- AES encryption, computational analysis, energy consumption, complexity model.

I. INTRODUCTION

Security of wireless networks has come under heavy scrutiny and designing energy efficient and low overhead cryptographic techniques is a non-trivial task due to the limited computing and communication resources. Encryption algorithms are an indispensable part of the security architecture of resource-constrained wireless networks, such as wireless sensor network (WSN). However, wireless sensors devices are highly resource constrained in terms of memory, power and processing capability. Unfortunately, there are currently no off –the-shelf cryptographic library that readily satisfies the needs of resource constrained wireless network security. Hence, investigating and designing efficient cryptographic algorithms are necessary to maximize the battery life time of wireless nodes.

To design energy efficient secure protocols for wireless devices there is a need to understand how encryption affects the consumption of battery power with and without data transmission. It is thus vital to know the performance of the encryption schemes in terms of energy consumption for various options like changing key sizes, modifying the number of rounds, layers of security, amount of data processed per packet, and algorithms that can be used on the wireless devices before designing a secure wireless communication protocol. Knowledge of the tradeoffs would also help in designing systems that can adapt the security of the communication link

based on the device being used and the battery power left on it. The harsh wireless environment further complicates the trade-off. There has not been any research that studies the tradeoffs between security of wireless devices and the battery consumption of the algorithms. Contrary to performance and speed, the energy efficiency of Advanced Encryption Standard (AES) has not been widely investigated in the past.

The aim is to aid the design of energy efficient secure communication schemes for the wireless environment in the future. The research work has been divided into following tasks to achieve this goal: Gain knowledge and understanding of AES security; Study and model the computational performance and energy consumption of AES; and Perform simulations for analytical comparison of the effect of varying cipher parameters for AES.

II. RELATED WORK

Using the most efficient and robust encryption algorithm is thus an active research area and ‘efficient encryption algorithm’ refers to one which requires little storage, makes optimal use of hardware resources and consumes less energy. The amount of computational energy consumed by cryptographic algorithms on a given microprocessor is proportional to the number of clocks needed by the processor to compute the cryptographic algorithm. There have been some studies [2][3][4] about the energy efficiency of encryption algorithms for wireless devices.

AES-Counter mode with Cipher block code Message authentication code Protocol (CCMP) provides the encryption and data integrity and comes with three message integrity code (MIC) bit options: 32, 64 and 128 bits. AES-CCMP provides adequate security in terms of confidentiality and integrity. However the main issue is its performance on typical sensor networks. Yang Xiao et al. [7] analyzed the security overhead of AES-CCMP in IEEE 802.15.4 specification. The authors observed that processing cycles per block increases as the key length increases, the payload increases or Millions of Instructions Per Second (MIPS) decreases. Decryption has much larger processing cycles than encryption does. They also observed that the increase of processing cycles over the key length and the payload size appears to be linear.

Optimising AES block cipher implementations towards low energy consumption is of paramount importance for wireless battery-powered devices. In Potlapally et al. [4], the result for 128-bit AES encryption claimed is 151 nJ/bit for encryption energy usage. Execution time and energy consumption of key set up and encryption can differ in a factor of 1000. Hodjat et al. state in [8] that the AES encryption itself takes only 11 cycles, but the complete program with loading the data and key, AES encryption, and returning the result back to the software routine takes a total of 704 cycles. AES-Rijndael decryption was found to consume approximately up to 20-30% more energy than encryption [8]. Nevertheless, its performance is very good and seems likely to remain so on many 8-bit or 32-bit processors since it uses only efficient and commonly available instructions.

III. AES-CRITICAL OPERATIONS

In this section, we analyze AES transformations on arithmetic level to distinguish between time-critical and non-critical operations. Specifically, the types of arithmetic operations and the number of clock cycles needed to execute these operations are determined.

Rijndael-Advance Encryption Standard (AES) [1] takes 128 bits plaintext input and outputs 128-bit cipher text. AES operates on a 4×4 array of bytes, termed the state (versions of Rijndael with a larger block size have additional columns in the state). For encryption, each round (called the round function)of AES (except the last round) consists of four stages: 1. AddRoundKey — each byte of the state is combined with

the round key; each round key is derived from the cipher key using a key schedule.

2. SubBytes — a non-linear substitution step where each byte is replaced with another according to a lookup table.

3. ShiftRows — a transposition step where each row of the state is shifted cyclically a certain number of steps.

4. MixColumns — a mixing operation which operates on the columns of the state, combining the four bytes in each column using a linear transformation.

The final round replaces the MixColumns stage with another instance of AddRoundKey.

Motivated by the work in [5][6][7], the approach used to evaluate a block cipher computational complexity and energy-consumption performance is based on the number of basic operations required in the execution of the algorithm. All involved algorithmic transformations can be condensed to a set of logical operations: bytewise-AND, bytewise-OR, and shifts of bytes. For a simple bitwise-XOR it is considered as the sum of 2 bitwise-ANDs and 1 bitwise-OR. Likewise, a circular shift (rotate) operation of an 8-bit word by n positions is taken as a bytewise-OR and 8 shifts.

In the AddRoundKey, first transformation of the AES process, a 16-bytes round key is added to the state. There is no dependency between the state’s bytes and the AddRoundKey can be performed using 16 simple bytewise-XOR operations.

Considering only the effect of this transformation, with R rounds for whole encryption process, 16R bytewise-XOR operations are required. In general, this is implemented with 8Nb bytewise-ANDs and 4Nb bytewise-ORs, where Nb = block length/32.This will cost a limited amount of clock cycles and the AddRoundKey software implementation is not a critical transformation.

In SubByte and Inverse SubByte transformations, the 16 bytes of the state are substituted using the lookup table S-box or inverse S-box. The SubByte transformation can be realized using 16 look-up tables with 8bit-input / 8bit-output. In this case, no computational power is required, but will have an impact on memory cost with the fetching of data out of the memory. But the S-box can also be implemented by mathematical calculations, then each SubByte operation incurs 3Nb bytewise-ANDs and 2Nb bytewise-ORs. However, these transformations will consume limited amount of clock cycles. The ShiftRow and InvShiftRow transformations manipulate the order of bytes.

The MixColumn and InvMixColumns transformation are based on matrix multiplication which consists of two arithmetic operations: multiplication and addition. Since with these transformations 4x4 matrices are involved, it involves 88 multiplications and 48 additions. MixColumns transformation costs for every element 4 bytewise-XORs, 6-bitwise-XORs, 2 byteswise-ORs and 16 shifts, i.e. it can be implemented for each round operation with 19Nb bytewise-XORs, 8Nb bytewise-ORs and 64Nb shifts; or 38Nb bytewise-ANDs, 27Nb bytewise-ORs and 64Nb shifts. The effect of these transformations incurs significant processing for each data block. Hence, MixColumns and InvMixColumns are critical operations and require optimised implementation.

IV. AES COMPLEXITY MODEL

The number of operations required to execute one round (i.e. SubBytes (negligible), ShiftRows, MixColumns and AddRoundKey) are 46Nb bytewise-ANDs, 31Nb + 12 bytewise-ORs and 64Nb + 96 binary shifts.

Neglecting SubBytes in complexity model, the computational effort required for AES encryption of one block of data is a function of the block size, the key size, and the number of processing cycles required for performing basic operations bytewise-AND (Ta), bytewise-OR (To), and bytewise shift (Ts) and expressed in general terms as: TAES-ENCRYPT = (46Nb R – 30Nb)Ta + [31Nb R + 12(R – 1) – 20Nb ]To + [64Nb Nr + 96(R – 1) – 61 Nb]Ts. A critical limitation of AES is related to its decryption because the cipher and its inverse make use of partially different code. The decryption code has InvMixColumns operation, which uses a different polynomial transformation. This leads to an additional complexity for decryption as multiplication by bigger coefficients costs much more. Overall, InvMixColumns transformation needs 134 Nb bytewise-ANDs, 99 Nb bytewise-ORs and 32 Nb shifts of bytes to be implemented. Hence, the difference in computation between one InvMixColumn and

MixColumn operation is [96NbTa + 72NbTo – 32NbTs]. Therefore, the total number of processing cycles in computational effort required for AES decryption of one block of data is given: TAES-DECRYPT = TAES-ENCRYPT + {[96 NbTa + 72 NbTo – 32 NbTs] × (R – 1)}. If Sd is the size of an unencrypted user data packet in bits, i.e. plaintext, the number of operations required to do the encryption, OPAES(Sd): OPAES(Sd) = TAES-ENCRYPT × Sd / block size, where denotes ceil function. Assuming, a processor executes Cp Millions Instructions Per Second (MIPS), and TIME –AES (Sd, Cp) refer to time required by the processor for encrypting one user packet of length Sd bits with AES-Rijndael. Then, TIME-AES (Sd, Cp) = TAES-ENCRYPT × Sd / block size / Cp .

TABLE I. AES COMPUTATIONAL OPERATIONS

AES Encryption AES Decryption Key size / block

size OR AND Shift

(Bytes) OR AND Shift

(Bytes) 128/128 1268 1720 408 3860 5176 1272 128/192 1540 2088 496 4708 6312 1552 128/256 1812 2456 584 5556 7448 1832 192/128 2310 3132 744 7062 9468 2328 192/192 2310 3132 744 7062 9468 2328 192/256 2718 3684 876 8334 11172 2748 256/128 3624 4912 1168 11112 14896 3664 256/192 3624 4912 1168 11112 14896 3664 256/256 3624 4912 1168

11112 14896 3664

TABLE II. PERCENTAGE OF OPERATIONS WITH ENCRYPT ION COMPUTATION MODEL

AES 128/10 Encrypt ( )

Bytewise-AND

Bytewise-OR

Shift (bytes)

Overall Computational load

AddRoundKey 320Ta (17.7%)

160To (12.0%)

0 (0.0%)

9%

ShiftRows 0 (0.0%) 120To (9.0%)

120Ts (5.0%)

5%

SubBytes 120Ta (6.6%)

80To (6.0%)

0 (0.0%)

4%

MixColumns 1368Ta (75.7%)

972To (73.0)

2304Ts (95.0%)

82%

V. AES ENERGY CONSUMPTION

In simulation-based methods, energy consumed by software is estimated by calculating the energy consumption of various components in the target processor through simulations. Energy consumed by various cryptographic computations is the sum of energy consumed by individual operations and can be expressed as a function of various parameters and data sizes. Each encryption algorithm is generally divided into two parts:

setup functions that initialize the key elements to be used in encryption/decryption and core functions which repeatedly perform operations on the data block. The energy cost of a symmetric encryption algorithm, can be estimated by a simple equation, given by:

Energy cost = KeySetupCost + [EnergyPerByte x DataSize];

where KeySetupCost , is the energy cost of expanding the symmetric key for an algorithm, energy expended per byte for encryption/decryption using algorithm is given by EnergyPerByte, and DataSize is the total size of the data to be encrypted by algorithm.

Energy consumed by AES e can be expressed as a function of size of key and data block and number of rounds of encryption. Therefore,

TotalSecureDataCommEnergy = [DataSize × (EncryptionEnergy{keysize,BlockSize,EncryptionRounds})] +

MACEnergy{KeySize} + TransmissionEnergy + SessionOverheadsEnergy ;

Total energy consumed during secure data communication is computed as the sum of energy consumed by data confidentiality (encryption and decryption), energy consumed by data authentication, energy consumed by data transmission/reception and energy consumed by session overheads (session and key refreshes or handoffs).

VI. EXPERIMENTAL METHODOLOGY

In the simulation, the reference ANSI C source code of the AES algorithm was used. Every transformation is represented by a separate function and the code is more transparent. The simulation framework is shown in figure 1 and the battery and computational tradeoff of AES encryption schemes are considered under different scenarios of varying encryption parameters. The average battery life consumed per run and the execution time of each encryption stage are measured. The processing time will also be determined by including a timer in the source codes. Using instruction profiling tools such as Oprofile, the number of processor cycles used by each algorithm will be determined. It is well known in literature that number of processor cycles is linearly correlated to energy usage. We assume that an average amount of energy is consumed by normal operations and the extra energy consumed by encryption algorithm is determined. The percentage level of remaining battery is monitored over a large number of repeated encryption processes. The energy consumption is also related to the number of processor cycles which are used in the computation of basic operations. By averaging the amount of energy consumed by primitive cryptographic operations in each cycle, the number of computing cycles is converted into energy used.

Figure 1. Cipher simulation procedure

The framework to test the efficiency of encryption algorithm consist of measuring the parameters, execution time, number of instructions executed, energy usage by the encryption algorithm, memory usage of the algorithm, and number and type of operations involved in the algorithm (additions, rotations, etc). Parameters of the algorithm that are varied include key length, word size and number of rounds. The change in performance is determined using different key sizes, 128, 192 and 256 bit keys, and different encryption rounds, 10, 12, and 14.

VII. RESULTS AND DISCUSSIONS

The simulation results for the AES-128 bits and 10 rounds

encryption and decryption processes are depicted in Figure 2 and 3, giving the number of executed instructions for a certain transformation in terms of percentage. There are at least two times more instructions executed for MixColumn transformation than for others.

Figure 2. Percentage of executed instruction for encryption

Figure 3. Percentage of executed instructions for decryption

Comparing the simulation values in, Figure 2 & 3 and computation model values, in Table I and II reveal that cyclic shift (rotation) operations are more costly than bytewise-AND or bytewise-OR, hence adding extra computational load on microprocessor. Results in Figure 5 shows and confirms that decryption has more computational overhead than encryption, approximately 20-35% more clock cycles, because of the additional complexity of the matrix multiplication in InvMixColumns of decryption. The InvMixColumns needs to perform four multiplications while MixColumns performs only two multiplications per each byte of the State. This complies with the mathematical model analysis where the difference in computation between one InvMixColumn and MixColumn operation is [96NbTa + 72NbTo – 32NbTs].

Figure 4. AES Computational Composition Performance

In Figure 4, as the key size and number of rounds is increased, this has a considerable impact of the number of bytewise-OR and bytewise-AND operations to be performed for encryption, while the number of bytewise-shift computations increases by a smaller amount for both encryption and decryption. However the difference increase in computation for decryption is approximately three time that for encryption.

Figure 5. AES computational performance for different parameters

Increasing the block size normally results in a marginally higher number of encryption computations if the key size and number of rounds are the same. As expected from AES complexity model equations, increasing AES operational rounds has a more significant impact than increasing the key size. The number of rounds affects the performance of AES block cipher due to the recursive encryption process which magnifies the computation.

Figure 6. Energy Consumption of AES for different rounds and packet size.

The execution time and the battery energy consumed are proportional to the complexity of operations per round and the number of data moves required making it difficult to state how much effect each type of operation has in the performance of the schemes. This is because data moves are difficult to analyze with different register allocations that can be done by the compiler and state of the operation system. The size of AES cipher key is impacts on the security strength, but desired key size will depend on the safety lifetime of encrypted data as well as computation capacity of devices.

VIII. CONCLUSION

This work investigates the computational load and energy consumption characteristics of Rijndael-AES. Simple computation complexity models are derived for the various stages in AES to design and evaluate energy-efficient cryptographic technique. Energy consumption simulation results validate the relationship of computational models of encryption algorithms with different key size, block size and number of rounds parameters. The simulation results presented quantify the computational complexity overhead and energy cost of AES-Rijndael with varying operational parameters. When dealing with crytosystems, the added issues of security affect the execution speed, memory size, data throughput, power consumption and robustness. The results’ evaluations bring the possibility of verifying the viability of the AES-Rijndael algorithm application in resource-limited device. A future research is to explore different optimization techniques for AES process to benefit from low resource consumption for wireless security services. Code optimization techniques for critical encryption stages can be used to minimize the computational clock cycles. Modularisation and reusability of modules can conserve valuable clock cycles.

REFERENCES [1] Andrea Vitaletti, Gianni Palombizio: Rijndael for Sensor Networks: Is

Speed the Main Issue? Electr. Notes Theor. Comput. Sci. 171(1): 71-81 (2007)

[2] P. Ganesan, R. Venugopalan, and P. Peddabachagari, “Analyzing and modelling encryption overhead for sensor network nodes” ACM in Proceedings of WSNA’03, September 2003.

[3] J. Grobschadl , S. Tillich, C. Rechberger, M. Hofmann, and Marcel Medwed, “Energy Evaluation of Software Implementations of Block Ciphers under Memory Constraints” In Proceedings of the 10th Conference on Design, Automation and Test in Europe, 2007.

[4] N. R. Potlapally, S. Ravi, A. Raghunathin, and N. K. Jha, “Analyzing the Energy Consumption of Security Protocols”, In Proceedings. 2003 International Symposium on Low Power Electronics and Design, pp. 25-27, Aug. 2003.

[5] F. Granelli, G. Boato, “A novel methodology for analysis of the computational complexity of block ciphers: Rijndael, Camellia and

Shacal-2 compared”, In Third Conference on Security and Network Architectures (SAR’04), June 2004.

[6] C. Xenakis, N. Laoutaris Merakos, and I. Stavrakakis, “A generic characterization of the overheads imposed by IPsec and associated cryptographic algorithms” Elsevier journal of computer networks, 2006.

[7] Y. Xiao, H. Chen, B. Sun, R. Wang and S. Sethi. “MAC Security and Security Overhead Analysis in IEEE 802.15.4 Wireless Sensor Networks” EURASIP Journal on Wireless Communication and Networking, pp.1-12. Volume 2006.

[8] A. Hodjat and I. Verbauwhede. “Interfacing a high speed crypto accelerator to an embedded CPU”, In Proceedings of the 38th Asilomar Conference on Signals, Systems, and Computers, IEEE Press,vol. 1, pp. 488–492, 2004.