Comparing Performance of Software CLEFIA to Established Block Ciphers on 8-bit Devices

Transcription

1 Comparing Performance of Software CLEFIA to Established Block Ciphers on 8-bit Devices Rembrand van Lakwijk University of Twente P.O. Box 217, 7500AE Enschede The Netherlands ABSTRACT In this document, the performance of the 128-bit version of the block cipher CLEFIA is evaluated on an ATMega type 8-bit processor. It is compared to the performance of another block cipher: IDEA. Optimisations for these algorithms are analyzed and the results are compared to previous performance analyses of the block ciphers TEA and AES on an ATMega type processor. By doing this we decide whether, when looking at performance only, CLE- FIA is an interesting candidate for low-power, low-cost encryption and decryption on 8-bit platforms. We conclude that 128-bit CLEFIA is very slow in comparison to the alternatives. We recommend choosing IDEA when an 128-bit block cipher is needed on an 8-bit system. Keywords CLEFIA, IDEA, lightweight, crypto, performance, 8-bit, ATMega 1. INTRODUCTION Data encryption on embedded devices is becoming ever more important as these devices have started handling sensitive data such as credit representing actual money in applications like Radio Frequency Identification (RFID) passes for public transport [6]. Not enough emphasis has been laid on secure communications on this kind of devices, as painfully demonstrated by the cracking of Crypto1 bydekoninggansetal.[3], whichisusedbythemifare Classic system in use in public transport in the United Kingdom and the Netherlands. This is why it is important to have encryption algorithms that have been proven to be secure available for these kinds of devices. There are several encryption algorithms available, most of which can be implemented on 8-bit devices. However, they differ wildly in performance. Choosing an efficient encryption algorithm is especially important for 8-bit lowpower devices because performance is directly related to power consumption, and power is often in short supply on these devices. For example nodes in a sensor network, which mostly also use an 8-bit processor, have to work for long periods of time without human intervention like replacing batteries. RFID tags even have to run on power Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 15 th Twente Student Conference on IT June 20 th, 2011, Enschede, The Netherlands. Copyright 2011, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science. generated from an RF signal. This is why, in addition to security, it is also important to evaluate the performance of new, promising ciphers on these devices. 1.1 Block ciphers versus stream ciphers A common choice for encryption on low-power devices is to use stream ciphers because in general these are faster than block ciphers [10, p. 44]. However, stream ciphers have a few limitations that block ciphers do not suffer from [10, p ]: Most notably a stream cipher does not diffuse bits in the plaintext over multiple bits in the ciphertext - one bit (or byte) in the plaintext always corresponds to the same bit (or byte) in the ciphertext. This makes stream ciphers vulnerable to bit flipping attacks where a third party, although not aware of the key or precise contents of the message, can flip certain bits in the ciphertext to modify the plaintext in a known way. Block ciphers do not suffer from this vulnerability because flipping one bit in the plaintext results in an unknown change of all bits in the ciphertext. Furthermore, block ciphers can start in the same state each time communication is initiated without necessarily compromising security, in contrast to stream ciphers. This means round keys can be stored in read-only memory (ROM) and no initialisation or key negotiation phase is necessary before communication can start. This gives block ciphers an advantage over stream ciphers; those can never reuse the same start state because that almost certainly compromises its security completely. This is why we will only consider block ciphers in this work. 2. RELATED WORK We found two papers that perform side-by-side performance evaluations of several block ciphers on an 8-bit platform (specifically the Atmel ATMega family of processors); Çakiroǧlu [2] and Eisenbarth et al. [4]. Çakiroǧlu evaluated the Advanced Encryption Standard (AES), Camellia, CAST5, Mars and Serpent. They found AES achieved the best performance by far; the algorithm that ranked second in their comparison was CAST5, at less than half the encryption performance of AES. AES achieved an encryption throughput in their comparison of slightly under 90 Kb/s on a 16 MHz ATMega processor. Eisenbarth et al. included AES, Data Encryption Standard (DES), DES-XL, Hight, International Data Encryption Algorithm (IDEA), Present, Scalable Encryption Algorithm (SEA) and Tiny Encryption Algorithm (TEA) in their research. The algorithms they found achieved the best throughput were IDEA, Hight and AES (in that order), where IDEA was 23% faster than AES. They found

2 IDEA to be capable of encrypting 94.8 Kb/s on a 4 MHz ATMega processor. 3. SUBJECT ALGORITHM As a block cipher to research we chose CLEFIA [9], since no existing performance research on it exists in terms of implementation on 8-bit devices. It is a promising cipher because in the 3 years since its introduction, despite several efforts, only minor steps were made towards breaking this cipher. The best results so far were presented by Tsunoo et al. [12] and Tezcan [11]. Tsunoo s method is the best break in terms of time complexity, but only works for a heavily reduced (12-)round version of CLEFIA and still has a time complexity of 2 119, which makes it impossible to apply in practice for at least the near future. The full-round version of CLEFIA has not been broken yet. Furthermore the cipher is scalable to larger keys to provide better security (128 up to 256 bits) and according to its designers it has been designed to be quick in software as well as in hardware implementations [9]. In this work we will only focus on the 128-bit version because this provides enough security for virtually all applications. 4. METHODOLOGY To be able to integrate our findings into existing performance research on symmetric block cipher algorithms on 8-bit devices, such as that of Eisenbarth et al. [4] and Çakiroǧlu[2] we will also need to implement another, similar symmetric block cipher and run performance tests with it. We can then compare our results to the performance achieved in existing research. That way, we can verify that our implementations are representative for the real performance potential of the tested algorithms. For this purpose we chose IDEA. It shares a number of elementary operations with CLEFIA (see Section 7), also uses 128-bit keys, is still considered secure (the full-round version has not yet been broken [1]) and turned out to be the fastest software-based encryption algorithm for implementation on an ATMega processor in Eisenbarth et al. [4]. Since CLEFIA uses more (18 versus 8.5) but simpler encryption rounds, it might be a good competitor. We will implement and analyze these algorithms on the Atmel ATMega processor. It is a very widely used 8-bit processor that was also used in previous research by Eisenbarth et al. and Çakiroǧlu. Using this processor will make it easy to compare our research to theirs. For our tests, we use an ATMega328 IC on an Arduino Duemilenova board, with the UNO bootloader. It has 32KB flash memory, 2KB SRAM and runs at 16MHz. The software to compile and run our code is Arduino It is based on the GNU Compiler Collection (GCC) C compiler. 5. SCOPE It is important to note that we only evaluate the sustained throughput of the algorithms on this processor when the round keys are precalculated. This means only the performance of the round functions is evaluated, not the round key generation functions. This also means our research results are only valid for systems which can hold the round keys in memory; for 128-bit CLEFIA the amount of memory needed to do this is 18 8 = 144 bytes, for IDEA it is = 116 bytes. These number double when both encryption and decryption are needed. Ofcourse these keys don t necessarily have to be held in RK F 0 RK F 1 RK F 0 RK F 1 RK F 0 RK F 1 Figure 1. Three rounds of CLEFIA s 4-branch Feistel network with two round functions, F0 and F1, each consisting of a round key (RK) addition step, a substitution (S) step and a diffusion (D) step. RAM; when the keys are static, they might just as well be stored in ROM. 6. NOTATIONS In this document, we will use the following notations for a few common operations: a b Addition in GF(2 n ) a b Multiplication in GF(2 8 ) a b Multiplication in GF( ) a b Bitwise exclusive OR a%b Modulo 7. ALGORITHM STRUCTURE 7.1 CLEFIA The CLEFIA algorithm consists of a generalized Feistel structure with four branches, as can be seen in Figure 1 [9]. Each branch handles a 32-bit word, making the total block size for CLEFIA 128 bits. The round functions, F0 and F1, treat the 32-bit input as four separate bytes, and are split up into two parts: a substitution step (S) and a diffusion step (D). The substitution step performs a simple S-box substitution, although two S-boxes are used; one for bytes 0 and 2, the other for bytes 1 and 3. The diffusion step performs a linear combination of the four substituted input bytes: y n = (a n,1 x 1) (a n,2 x 2) (a n,3 x 3) (a n,4 x 4) where a n,k {1,2,4,6,8,10}. The specified number of rounds for a 128-bit key is 18. Even though reduced-round versions of CLEFIA might be considered secure, it is only fair to compare algorithms as they were originally designed and evaluated. This is why we will abide by this specification. For 192-bit and 256-bit keys the number of roundswould be 22 and 26 respectively [9]. 7.2 IDEA IDEA was originally introduced as Improved PES (Proposed Encryption Standard) [8] as a slightly modified and more secure version of the original PES [7]. It is based on the mixing of algebraically incompatible operations, being exclusive-or, multiplication modulo and addition modulo 2 16 [7]. It operates on 64-bit blocks split into four 16-bit words and consists of 8 rounds and a final output transformation, which are described in detail in Figure 2.

3 Z1 n Z2 n Z3 n Z4 n Z5 n Z6 n Z1 9 Z2 9 Z3 9 Z4 9 one round 7 more rounds output transformation Figure 2. One round (the n th round) of IDEA and the output transformation. The semantics of the symbols are as specified in Section 6. Z n x specifies the x th round key for the n th round (based on [8]). Processing time (ms) CLEFIA IDEA Dataset size (bits) x10 3 Figure 3. Encryption/decryption performance of the reference implementations of CLEFIA-128 and IDEA at 16 MHz. This algorithm was tested as being the fastest decryption algorithm when implemented on an ATMega128 8-bit processor in Eisenbarth et al. [4], which is why we use it to compare CLEFIA with - this algorithm should at least be comparable in performance to be a good candidate for usage on 8-bit low-power devices. 8. REFERENCE IMPLEMENTATION PER- FORMANCE 8.1 Measurement method To evaluate the performance of the algorithms and verify linearity between data size and processing time we encrypt (or decrypt) data sets of 0 b up to 640 Kb in incremental steps of 32 Kb and measure the time each of these data sets take to be processed using the millis() method provided by the Arduino library. This duration is also what we derive the number of clock cycles it takes to process each block from. We assume millis() to provide accurate integer measurements of the number of milliseconds since the system booted, which means that at 16 MHz our maximum measurement error for the total data set is instructions. When processing 640 Kb this means a total maximum measurement error of 2 cycles/block for IDEA and 4 cycles/block for CLEFIA. 8.2 IDEA ThepaperpresentingIPES(whichisnowknownasIDEA) does not provide a reference implementation. However, the paper presenting the original PES algorithm does. This reference implementation of PES [7] was used and modified to implement IDEA according to the improvements specified in [8]. This change only consists of a different permutation of subblocks at the end of each round (except the last), making this change relatively simple and risk-free in terms of correctness Results As can be seen in Figure 3, the reference IDEA implementation averages about 265 Kb/s. This boils down to 3870 clock cycles per 64-bit block. The measured performance is encryption performance, but since encryption differs only from decryption in the round keys used, the numbers are exactly the same. 8.3 CLEFIA For CLEFIA, a reference implementation is provided by the authors. For these tests, version (August ) of clefia_ref.c was used, which was the latest available at the time of writing Results In Figure 3 it can be seen that the reference implementation of CLEFIA is significantly slower than that of IDEA; its encryption/decryption performance averages 55 Kb/s which is equivalent to cycles/block (do note however that CLEFIA s blocks are twice as large as those of IDEA). Encryption and decryption were measured to be equal in performance to within 35 cycles/block, decryption being marginally faster. This difference is unexplained because it is higher than the maximum measurement error, but also so small (< 0.1%) as to not provide any reason to waste any time researching the cause. 9. OPTIMISATIONS 9.1 IDEA Observations When we look at the research conducted by Eisenbarth et al. [4], it is clear that the reference implementation is suboptimal; the reference implementation uses 3870 cycles/block whereas Eisenbarth et al. achieve a performance of 2700 cycles/block. The reference implementation uses a 64-bit (long) multiplication for the multiplications modulo , which is very inefficient on an 8-bit processor; when we disassemble the produced binary, we can see that one such multiplication has an average case of around 53 instructions More efficient multiplication It is unclear why the reference implementation uses 64- bit longs for the multiplication. The algorithm used (as described in Elagooz et al. [5]) is called the High-Low algorithm and works by means of the equation depicted in Figure 4. This algorithm, which in itself is very efficient for what it does[5], worksjustaswellwith32-bitints, sincethehigh-

4 { (a b)%(2 16 ((a b)%2 16 ) (a b)/2 16 : ((a b)%2 16 ) >= (a b)/ ) = ((a b)%2 16 ) (a b)/ : ((a b)%2 16 ) < (a b)/2 16 Figure 4. The High-Low algorithm used in the implementation of IDEA to implement multiplication modulo as described in [5]. Round key calculation strategy As-needed Eisenbarth et al. [4] Precalculated Decryption Encryption Cycles per 64-bit block Figure 5. Encryption/decryption performance of two implementations of IDEA to analyze the implementation method used by Eisenbarth et al. [4] ; y[0] = ; z [0] ; ˆ ClefiaMul2(z [1]) ; ˆ ClefiaMul4(z [2]) ; ˆ ClefiaMul6(z [3]); ldd r24, Y+16 ldd r25, Y+17 add r24, r24 adc r25, r25 ldd r18, Y+16 ldd r19, Y+17 add r18, r18 mov r18, r19 adc r18, r18 sbc r19, r19 std Y+17, r19 std Y+16, r18 estoperandusedisa bandtheresultofthisoperationwill never be higher than (2 16 1) 2. Since (2 16 1) 2 < , the result of this operation always fits in a 32-bit operand. The correctness of this optimization has been verified using an exhaustive output comparison between the old and the new implementation of the multiplication function for all possible inputs when using ints as operands. Using ints reduced the average multiplication complexity from 53 to 19 instructions. When we tested the algorithm again with this optimisation, we achieved much better performance figures than Eisenbarth et al. [4]: 580 Kb/s (1766 cycles/block). This is nearly 1000 cycles per block less than the aforementioned research - a 34% increase in performance Comparison with Eisenbarth et al. The aforementioned result is suspicious since it is so much faster using an only slightly modified reference implementation. This leads us to believe that Eisenbarth et al. used an implementation that does not use precalculated round keys. In their research they do not mention whether or not they use precalculated round keys. We ran another test to see that if we include the round key calculation in the time measurement, we achieve results which are more similar to those of Eisenbarth et al. This was not the case; calculating the round keys as-needed decreased the performance dramatically to an average of 4886 cycles/block, which is about 80% more than Eisenbarth et al.. Encryption is even much worse at cycles/block (a 479% increase). A visual comparison of the performance of these three IDEA implementations can be seen in Figure 5. Since neither of these tests provide comparable results to the original research, we contacted Dr. Eisenbarth who confirmed the round keys were calculated for each block - meaning our implementation is somehow still inefficient. Especially decryption is very inefficient, but since this can only be caused by the round key calculation function (because the round functions themselves are the same as for encryption) and this is outside the scope of this research, we can disregard this rather disappointing result Conclusion Even though we could not reproduce the performance Eisenbarthet al.achieved, whattheseresultsdoprovideus with Figure 7. A snippet of the disassembled binary of CLEFIA with original source code as comment, with approximately one assembly implementation of ClefiaMul2. is a reference point; we already know how IDEA compares to other algorithms through existing research, thus knowing how CLEFIA performs relatively to IDEA provides us withanideaofhowitwouldrankagainstotheralgorithms. In this way it does not really matter that we were unable to match previous performance evaluations of IDEA. 9.2 CLEFIA Observations Firstly it should be noted that the reference implementation of CLEFIA states that it is in no way optimised for size or performance. When we look at the source however, we immediately notice that all operations are 8-bit operations, making it very efficient on 8-bit platforms. What we also notice is that each multiplication with 2, 4, 6, 8 or 10 modulo 2 8 has its own separate function that operates on bit-level, as can be seen in the listing in Figure 6. When we disassemble the binary this results in (Figure 7, showing the first part of the operation y 1 = (1 x 1) (2 x 2) (4 x 3) (6 x 4)), we see that GCC has unrolled and highly optimized the nested calls to ClefiaMul2 and has replaced all bitshifts which were present in the original source code with self-additions and self-substractions. The conditional jumps one would expect to see when if-statements are used are nearly not present at all due to smart code optimization and utilization of available registers. This results in an average of around 10 instructions per call to ClefiaMul2 in the line of C-code for which the assembly code is presented in the listing in Figure 7. It is very unlikely we can improve upon this by writing these functions in assembly ourselves Conclusion The observations as described above result in our conclusion that despite the comment at the top of the source code, at least some operations have been optimised for

5 / Multiplication of x with 2 in GF(256) / unsigned char ClefiaMul2( unsigned char x) { / multiplication over GF(2ˆ8) (p(x) = 11d ) / if (x & 0x80U){ x ˆ= 0x0eU; } return ((x << 1) (x >> 7)); } #define ClefiaMul4( x) (ClefiaMul2(ClefiaMul2 (( x )))) #define ClefiaMul6( x) (ClefiaMul2 (( x )) ˆ ClefiaMul4 (( x ))) #define ClefiaMul8( x) (ClefiaMul2(ClefiaMul4 (( x )))) #define ClefiaMulA( x) (ClefiaMul2 (( x )) ˆ ClefiaMul8 (( x ))) Figure 6. CLEFIA functions to multiply in GF(2 8 ) IDEA (ours) IDEA [4] AES TEA CLEFIA (ours) Decryption Encryption Kbps at 4MHz Figure 8. Encryption/decryption performance comparison between our implementations and the software-oriented algorithms tested by Eisenbarth et al. [4] speed. This also means there is no elementary operation we can optimize to significantly speed up the implementation as there was with IDEA, since the implementations of the other elementary operations used in CLEFIA (addition modulo2 8, exclusive-orandsubstitution)aretrivial. Furthermore, when we look at the assembly code produced by GCC we can see all short, common operations such as multiplication modulo 2 8 have been inlined and optimized well. It seems that the fact that CLEFIA is so slow in comparison to IDEA is purely due to the large number of rounds required. We can not reduce this number since that would make our implementation incompatible with other implementations of CLEFIA, however Tezcan s research [11] suggests reducing the number of rounds from 18 to 12 still provides fairly strong encryption. Doing this however, is outside the scope of this research. Having said this, we could find no way of optimizing the existing implementation. 10. PERFORMANCE COMPARISON The first thing we notice when we put the two existing papers by Eisenbarth et al. [4] and Çakiroǧlu [2] on block ciphers on 8-bit devices side by side, is that Çakiroǧlu s implementation is much slower than that of Eisenbarth et al; Çakiroǧluachieves around88 Kb/s with AES on a 16 MHz ATMega128 while Eisenbarth et al. achieve 77.1 Kb/s on a 4 MHz ATMega128. The difference is a factor 3.5. This is so much we decided not to use Çakiroǧlu s research to compare our own results with. Then, when we integrate Table 1. Our test results integrated in the software-oriented 128-bit block cipher test results from Eisenbarth et al. [4], ordered from highest to lowest encryption speed. IDEA (ours) IDEA [4] AES [4] TEA [4] CLEFIA (ours) b at 4 MHz Table 2. Our test results, corrected for implementation overhead, integrated in the softwareoriented 128-bit block cipher test results from Eisenbarth et al. [4], ordered from highest to lowest encryption speed. IDEA [4] AES [4] TEA [4] CLEFIA (ours c ) at 4 MHz c corrected by a factor of 1/1.8 based on Section 9.1.3, round function only our own research into the performance evaluations of 128- bit software-oriented block ciphers of Eisenbarth et al., we get the comparison in Table 1. A visualisation of this table can be seen in Figure Correcting results for implementation overhead There is a problem with the comparison table produced in Section 10 however; it has not been corrected for the fact that somehow our implementation method is not as efficientasthatofeisenbarthet al.; asshownin Section9.1.3, our implementation is 80% slower than that of Eisenbarth et al. when we look at encryption speed of IDEA (which, performance-wise, is much more trivial than decryption). To correct for this 80% slowdown we assume that when we apply a correction of 1/1.8 to our performance figure of CLEFIA, we get a fairer comparison. When we do this we get Table 2. We can see that this does not

6 Table 3. Our test results, corrected for implementation overhead, integrated in the softwareoriented 128-bit block cipher test results from Eisenbarth et al. [4], ordered from highest to lowest encryption speed. In contrast to Table 2, this table includes round key calculation for CLEFIA. IDEA [4] AES [4] TEA [4] CLEFIA (ours c ) at 4 MHz c corrected by a factor of 1/1.8 based on Section Table 4. Our test results integrated in the software-oriented 128-bit block cipher test results from Eisenbarth et al. [4], corrected to compensate for round key calculation and implementation overhead on our part, ordered from highest to lowest encryption speed. IDEA (ours) AES [4] c TEA [4] c CLEFIA (ours) at 4 MHz c corrected by 34% to compensate for round key calculation and implementation overhead on our part change anything in the performance ranking of the different algorithms. What we should also keep in mind when looking at this table is that the CLEFIA performance figure does not include round key calculation, whereas the performance figures of the other algorithms do; meaning CLEFIA s performance in comparison to the other algorithms is even worse CLEFIA round key calculation To get a rough idea of what kind of performance decrease including round key calculation would introduce, we ran a performance evaluation on the round key calculation function of CLEFIA using its reference implementation. CLEFIA s round key calculation function turned out to be almost equal in processing time to its round function, at cycles/block. When we add this figure to the results we get Table 3. Looking at this table one might notice that IDEA s decryption speed is almost as low as CLEFIA s. There are two important footnotes to this performance figure though: First of all, Eisenbarth et al. stated in their paper that they used a simple but slow algorithm to calculate the inverse multiplication needed for decryption - this could be optimized to use a better algorithm. Secondly, this part of the algorithm is completely irrelevant when looking at round functions only; it is part of the round key calculation function and should be disregarded in this paper as we attempt to evaluate round function performance only Eliminating round key calculation time To provide a better performance comparison we should try to eliminate the round key generation from the performance evaluation of Eisenbarth et al.. To do this, we looked at the performance difference between our fast im- IDEA AES TEA CLEFIA Decryption Encryption Kbps at 4MHz Figure 9. Encryption/decryption performance comparison between our implementations and the software-oriented algorithms AES and TEA tested by Eisenbarth et al. [4], both corrected by 34% to compensate for round key calculation and implementation overhead on our part. Visualisation of Table 4. plementation (without round key calculation) and that of Eisenbarth et al.. This is a 34% difference (see Section 9.1.2). When we apply this correction to the ciphers evaluated by Eisenbarth et al. we get Table 4. When we visualize this we get Figure 9. When we look at these performance test results it is clear that CLEFIA, when compared to all other algorithms and especially IDEA, does not even come close to being an algorithm that provides efficient encryption on this platform. In this sense it does not matter that we do not know exactly how Eisenbarth et al. have implemented the round key generation (as discussed in Section 9.1.3) - the round functions of CLEFIA by themselves are slower than the round functions of IDEA and their key generation functions combined, regardless of the key generation strategy in the case of encryption. 11. CONCLUSIONS In this paper, we compared the two block ciphers IDEA and CLEFIA to two other block ciphers evaluated by Eisenbarth et al, being AES and TEA. These results are presented visually in Figure 9. We conclude that CLEFIA, being more than ten times slower than IDEA when we disregard round key generation, is too slow to be a feasible candidate for usage on low-power 8-bit platforms. This is especially so because 128-bit CLEFIA does not provide any better security than IDEA, which also uses 128-bit keys (and neither cipher has been broken as of yet). CLE- FIA is also slower than all software-oriented block ciphers evaluated in Eisenbarth et al. [4], although only AES and IDEA are an order of magnitude faster. This means, when designing a new low-power 8-bit system for which 128-bit security is enough, we recommend using IDEA over CLEFIA. 12. FUTURE WORK The first priority for future work evaluating other encryption algorithms should be to achieve (at least) the same performance as Eisenbarth et al. did to gain more reliable results. The only reason this did not matter in our research is that the performance gap between IDEA and CLEFIA is so large. As discussed in Section we could find no way of optimizing the C reference implementation any further than wealreadydidinsection Thiscouldmeanthechoice

7 of compiler was not the optimal one; maybe tests could be re-run using for example Atmel s own AVR Studio compiler to achieve better performance. 13. ACKNOWLEDGEMENTS We would like to thank Dr. Eisenbarth for providing us with a clarification of the algorithm implementation method used in the paper this work is heavily based on [4]. 14. REFERENCES [1] E. Biham, O. Dunkelman, and N. Keller. New cryptanalytic results on idea. In X. Lai and K. Chen, editors, Advances in Cryptology - ASIACRYPT 2006, volume 4284 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [2] M. Çakiroǧlu. Software implementation and performance comparison of popular block ciphers on 8-bit low-cost microcontroller. International Journal of Physical Sciences, 5(9): , [3] G. de Koning Gans, J.-H. Hoepman, and F. Garcia. A practical attack on the mifare classic. In G. Grimaud and F.-X. Standaert, editors, Smart Card Research and Advanced Applications, volume 5189 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [4] T. Eisenbarth, S. Kumar, C. Paar, A. Poschmann, and L. Uhsadel. A survey of lightweight-cryptography implementations. IEEE Design and Test of Computers, 24: , [5] S. Elagooz, N. Hamdy, K. Shehata, and M. Helmy. Design and implementation of high and low modulo ( ) multiplier used in idea algorithm on fpga. In Radio Science Conference, NRSC Proceedings of the Twentieth National, pages C , march [6] A. Juels. Rfid security and privacy: a research survey. Selected Areas in Communications, IEEE Journal on, 24(2): , feb [7] X. Lai and J. Massey. A proposal for a new block encryption standard. In I. Damgård, editor, Advances in Cryptology - EUROCRYPT 90, volume 473 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [8] X. Lai, J. Massey, and S. Murphy. Markov ciphers and differential cryptanalysis. In D. Davies, editor, Advances in Cryptology - EUROCRYPT 91, volume 547 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [9] T. Shirai, K. Shibutani, T. Akishita, S. Moriai, and T. Iwata. The 128-bit blockcipher clefia (extended abstract). In A. Biryukov, editor, Fast Software Encryption, volume 4593 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [10] W. Stallings. Network security essentials. Pearson education, inc., third edition, [11] C. Tezcan. The improbable differential attack: Cryptanalysis of reduced round clefia. In G. Gong and K. Gupta, editors, Progress in Cryptology - INDOCRYPT 2010, volume 6498 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [12] Y. Tsunoo, E. Tsujihara, M. Shigeri, T. Saito, T. Suzaki, and H. Kubo. Impossible differential cryptanalysis of clefia. In K. Nyberg, editor, Fast Software Encryption, volume 5086 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, 2008.