Abstract
Lightweight cryptography is at the heart of today’s security needs for embedded systems. The standardised cryptographic algorithms, such as the Advanced Encryption Standard (AES), hardly fits the resource restrictions of those small and pervasive devices. From this observation a plethora of Lightweight Block Ciphers have been proposed. Every algorithm has its own advantages in terms of security, complexity, latency, performances. This paper presents first a classification of some popular SubstitutionPermutationNetworks (SPN) class of lightweight ciphers according to their architecture and features which share many common operators. From this last point, we studied a roundbased generic hardware architecture that allows a security architect to dynamically change the lightweight cryptographic algorithms to be executed. The results of the ASIC implementation show that the configuration part of the proposed flexible architecture adds significant complexity. If compared with the parallel implementation of several algorithms, the complexity ratio becomes interesting when the number of algorithms (or the level of agility) increases. For instance, if we consider 6 SPN ciphers, the configurable architecture provides a complexity reduction of 62.5%, whereas there is no reduction with 4 algorithms.
You have full access to this open access chapter, Download conference paper PDF
Similar content being viewed by others
Keywords
1 Introduction
With the intense development of small and pervasive computing devices, as IoTs and their ability to communicate through insecure networks, it becomes essential to add security features. Indeed, from connected homes to connected vehicles or medical devices, security is at the heart of tomorrow’s issues as it will affect our private lives as much as our health. Hence, all these devices need to be protected using sound cryptography in order to get a good level of confidentiality, integrity and privacy. Such devices are constrained by a low complexity with restricted chip area, memory and energy, while still needing communication channels. The security of these devices and the sensitive data they process have to be addressed by a new generation of Lightweight Cryptography algorithms which provide a good compromise between security and complexity in terms of area, latency and energy.
The most common standard symmetrickey cryptographic algorithm used to secure digital information is the Advanced Encryption Standard (AES) [22]. However, AES does not fit the strong restrictions of small embedded systems. This observation led to the development of Lightweight Block Ciphers. Plethora of such ciphers are available in the literature [7]. The NIST has started a project [19] to develop a strategy for the standardisation of lightweight cryptographic algorithms. Some of these algorithms are based on the same basic computation steps as AES since they use a Substitution Permutation Network (SPN) structure [17], some others use Feistel networks as DES [24]. Out of these numerous algorithms, none have emerged as a clear favorite in terms of becoming a NIST standard. PRESENT [8] has been accepted as an ISO standard [15], but the impact of standardisation was not as significant as AES. Actually, this means first, that the security of these algorithms is not officially recognised by an authority. Second, that some industrial may use modified versions of those algorithms, loosing interoperability and eventually weakening the algorithm. Third, since the demand for such algorithms is increasing and the maturity of some of them is becoming evident, the NIST might eventually standardise one of them rendering obsolete actual devices or protocol implementations. From these three last points, it appears that the possibility to use a flexible architecture allowing the user to change afterwords the cryptographic algorithm is an interesting feature. Moreover, this “agility” characteristic increases the security level as the attacker is thwarted by the unsteady nature of the cryptographic computing. The point is to know if such flexible architecture is feasible in terms of complexity and other physical constraints.
We could think this objective could be made possible thanks to the common operators of SPN algorithms. But the cryptographic algorithms were developed focussing on different features and the SPN operators have thus been implemented in different manners Most algorithms focus on area, others such as PRINCE [9] and MANTIS [6] focus on latency thanks to a specific structure, inspired by SPN, called \(\alpha reflection\). The objective of low energy consumption is tackled by MIDORI [3] and PICCOLO [23]. It arises the question of how similar those algorithms are, and if these similarities can be used to design a unique hardware to implement them. This would permit the deployment of those block ciphers, while being ready to switch as soon as a standard emerges. This Generic Architecture would also have the advantage of allowing algorithms to be slightly modified or tweaked if necessary. The basic idea to develop such an architecture is that the SPN structured algorithms share similar functions. Those functions can be grouped within steps which have the same function but do not work in the same way. These steps are further detailed in Sect. 2.
An original finegrain FPGA [20] has already been proposed. It is based on the utilization of Fulladder configurable cells. Other flexible cryptographic architectures have been proposed [12, 25] or [18] which focuses on an agile permutation layer but none of these targeted specifically lightweight cryptography. We propose in this paper to study a coarsegrain approach by taking into account the common operators found in the Lightweight algorithms. However, even if some operators are very close, the Feistel class of algorithms are too far from the SPN in terms of scheduling. Therefore, the study targets the SPN class only.
Our Contributions. In this paper, we first propose a classification of lightweight cryptographic algorithms according to their internal scheduling and functions. From this classification and a detailed study of the differences between the selected SPN algorithms, a generic roundbased hardware architecture has been proposed. It can be configured for different levels of agility in order to handle some or all families of ciphers. The permutation layer (Player) which is quite specific to each algorithm has been deeply investigated. A third contribution is the evaluation of the generic architecture and the comparison with implementations of independent lightweight cryptographic ciphers.
The paper is organised as follows. Section 2 presents the classification of the different families of SPN lightweight algorithms. It focuses on the different functions which require specific hardware modules. Section 3 describes the design of the generic architecture. The overall architecture alongside the design of each step. Section 4 justifies the different design choices of the PLayer, as the architectural optimisations in the PLayer are strongly related to the requirements of each family of algorithms. Section 5 discusses the results of the architectural implementations. The hardware resources usage for different levels of agility are presented and compared to direct implementation of the algorithms. Finally, Sect. 6 concludes the paper.
2 Classification of the Algorithms
There are multiple ways to classify symmetric cryptographic algorithms, the main category used is the structure of the algorithm. An algorithm has either a Feistel structure (SIMON and SPECK [5]), an SPN structure (AES) or a structure derived from SPN (PRINCE [9], PICCOLO [23]).
Our study focuses on implementing SPN and SPNlike algorithms, as their functions are similar enough to be handled by the same hardware, and a large proportion of lightweight cryptographic algorithms use this structure. The SPN algorithms are composed of three steps:

The Sbox: S, which corresponds to the confusion

The PLayer: P, which corresponds to the diffusion

The AddKey: K, which corresponds to the addition of the secret
SPN Algorithms can differ by the order in which they execute those steps. This allow to classify them into three families based on the relative order of these steps. The first type is the SKPtype (SKINNY [6]), for which S is followed by K, itself followed by the Player. The second type is the SPKtype (MIDORI [3], GIFT [4], PRESENT [8]), for which S is followed by the Player, itself followed by K. On the one hand, each family can be implemented without changing the order, simply by changing the first step of the algorithm. On the other hand, the two families are not coherent and require extra modules to be handled by the same architecture. Note that it is also possible to handle both these families by adding computation to the key since the P and K are both linear layers. The last family is that of the \(\alpha reflective\) algorithms (PRINCE [9], MANTIS [6]) which change the order of the steps during the encryption.
Table 1 presents a classification proposal.
The Player P has two main types of permutations, either at the bitlevel (PRESENT [8], GIFT [4]) or at the nibblelevel (SKINNY [6], PRINCE [9]). These two different approaches require more or less complex permutation modules and implementing one but not the other has an influence over the cost of the permutation. An additional matrix multiplication can be used. It can be a \(4\times {}4\) multiplication of the nibbles (SKINNY [6], MANTIS [6]) or a \(64\times {}64\) multiplication on the whole word (PRINCE [9]). PRESENT [8], GIFT [4] do not use matrix multiplication. Each type represents different levels of complexity, especially if we consider the resources to store the matrix values. Finally, though most algorithms only use one Sbox, \(\alpha reflective\) algorithms (PRINCE [9], MANTIS [6]) use two Sboxes: the Sbox and its inverse.
The Key Scheduling block is in charge of generating the round keys. Key Scheduling is done in very different ways from one algorithm to the other. Despite basic operations such as rotation or the use of round constants, the Key scheduling uses different functions applied to different parts of the key. Indeed, the subkey generation is rather complex to unify as extracting different groups of bits of variety of size is hard to achieve in hardware without great increase in the design size. For example, GIFT [4] divides the entire key in 16bit words and extracts two of them (A type), PRESENT [8] extracts two nibbles (B type) and use the Sbox. In other algorithms such as PRINCE [9] and MANTIS [6] the key is divided into two parts (C type) used separately. For these reasons, and because making the key scheduling generic in hardware would be complex and costly, we have decided to use a buffer that will contain precomputed round keys. The round keys will be generated by software in the configuration phase.
Table 2 presents a selection of Lightweight Block Cipher and their implementations results from the literature.
3 Generic Architecture
In order to handle multiple algorithms with the same hardware, the architecture is designed to be configurable.
The overall architecture is divided between the key scheduling and the configurable SPN structure. Each cipher computes the three steps of the SPN structure in a specific order, and can skip some of them (completely or at a specific round). In our design, this is achieved through the use of four 3way multiplexers (see Fig. 1) which are controlled using configuration bits. These configuration bits need also to be different from one round to another.
For the desired functionality, there are only 15 different possible options to order the three steps, therefore all the multiplexers can be configured with only 4 bits per round. Thus, the number of necessary configuration bits is \(4\times \) the maximum number of rounds that the implemented ciphers need. This can be further reduced if we store a unique configuration for all the rounds that use the same configuration.
3.1 Key Scheduling
Initially, as with the rest of the architecture, the key scheduling of each algorithm was studied in order to identify similarities between each of them. The issue is that unlike the algorithm itself, which uses a set SPN structure and is broadly similar to the standardised AES, key scheduling is achieved through a plethora of methods. Each of these methods applies calculation specific to the algorithm. An example would be isolating parts of the key, a few bits long, apply a certain processing such as an LFSR or the algorithm’s Sbox to them, then each part is reordered and the result is shifted. Not only does this general description not fit most of the key scheduling but even if it were, being able to isolate different amounts of differentsized sample represents a real challenge and requires an important amount of hardware no matter the solution.
Once it had been made obvious that the variety of key scheduling does not allow a unified implementation at a reasonable cost, a different path had to be considered in order to obtain the used round keys. Using a configurable architecture means this architecture would most likely not work independently and thereby require to be included within a processor system. Computing the round keys could be done by software, prior to or in parallel with the configuration phase and the unrolled key could be stored in a specific buffer. Obviously this processor system, used for security applications, would have to ensure a secure way to store and handle the unrolled key. Moreover, as the key is generally not changed at each encryption, handling the Key Scheduling through software is not an issue.
3.2 The Sbox: S
The S module is rather straight forward, for each of the 16 possible nibble inputs there is an output defined through information stored within a RAM bloc. This module is therefore similar to a LUT. The substitution of each of the 16 nibbles is done in parallel and therefore requires 16 actual Sboxes. Most algorithms use the same Sbox throughout the entire encryption process but some of them require two different Sboxes. This is the case with \(\alpha reflective\) algorithms which use both an Sbox and its inverse, such as PRINCE [9] and Mantis [6]. Including a second Sbox means having to store twice as much information and add a mechanism to switch from one Sbox to the other.
3.3 The Key Addition: K
Each algorithm uses a different key for each round, called a round key, which is computed during the key scheduling. The round key considered here is not necessarily what algorithms call their round key, it also encompasses the round constant if any. Thereby, the K step is simply composed of 64 Xor gates in parallel to add the state to the software precomputed round key. The main security issue is that the round keys need to be stored in a secure environment, which is coherent with the natural use of encryption where the key needs to be stored securely. This mechanism also echoes the fact that the K needs to access this secure memory once per round, therefore once per cycle. Memory does not usually have this feature but this can be handled by using a bypass between this section of the memory and the K module. That part was not implemented and is a theoretical solution.
3.4 The PLayer: P
The permutation bloc P for an SPN structured algorithm can include two different parts. The first part, equivalent to the MixColumn function of AES, is a matrix multiplication.
This matrix multiplication (see Fig. 2) uses the same four bits of the input with four different bit sets of the matrix to compute four bits of the output. This means that the matrix multiplication uses four times 64 bits values or a unique 256 bits value. This seems like a lot but it is still smaller then a full \(64\times 64\) matrix.
The second part of the P bloc is equivalent to the Shift Row function of the AES cipher. This part required a lot of attention for multiple reasons. First, in a classic Lightweight Bloc Cipher, this part generally implemented as a simple reordering of wires and uses no specific hardware. Second, the algorithms which do not use a matrix multiplication require permutation at a bit level rather than the at the nibble level as with AES’s Shift Row. Third, designing a configurable permutation meant being able to route a signal through a crossbarlike module, but crossbars are expensive in terms of both area and configuration memory. It was therefore essential to find a lighter solution. The most efficient solution to optimise those crossbars was using Banyan switches [13].
The chosen solution (see Fig. 3) was based on a thorough study of each algorithms’ requirements in terms of permutation flexibility and the crossbarlike modules were optimised to better fit the situation (these optimised crossbarlike modules will be referred to as Banyan switches for the rest of the paper). More details on P will be given in Sect. 4.
3.5 The Configuration
The generic architecture uses configuration parameters to select an algorithm. These parameters are set during the configuration phase, before the encryption begins. This allows the algorithm used to be changed dynamically.
The configuration memory bits are distributed throughout the architecture. A shift register mechanism is used (see Fig. 4) to limit the complexity of the external configuration interface. Once the shift register’s content is valid, the configuration data is written by bloc in a configuration register chosen by a selection signal.
4 Detailed Analysis of the PLayer
Each module of the Generic Architecture has been designed to allow several levels of agility depending on the acceptable area overhead. This was achieved by identifying the common characteristics of different algorithms and designing the architecture accordingly. The most key part in unifying the architecture to each algorithm was P.
4.1 Unifying the Matrix Multiplication
The matrices used for the matrix multiplication are of two types. The first type is considering a \(4\times {}4\) matrix composed of nibbles whose value is either F or 0 (SKINNY [6]). They are represented as \(4\times {}4\) matrix but the multiplication actually applies to each bit of the state’s \(4\times {}4\) matrix of nibbles, they can therefore be considered as \(4\times {}4\) matrix of nibbles. The second type is a \(64\times {}64\) bit matrix which is mostly filled with 0s but has 4 \(16\times {}16\) submatrices composed of 1s and 0s (Prince [9]). The latter matrix are themselves composed of 16 \(4\times {}4\) diagonal matrices, therefore the \(16\times {}16\) matrix can only have 1s placed along the \(4\times {}4\) matrix’s diagonals (see Fig. 5a).
This property makes it possible to reduce the \(64\times {}64\) matrix to the information on the \(4\times {}4\) matrix’s diagonal which compose the \(16\times {}16\) submatrix. There are 16 \(4\times {}4\) matrix in each of the 4 \(16\times {}16\) submatrices, each of which have 4 bits on their diagonal, which amount to a total of \(4\times 16\times 4 = 256 bits\) of useful information. The first type only consists of a \(4\times {}4\) matrix of nibbles with a single bit either at 1 or 0. In this type of matrix, the value of a bit is the same as the other bits of the same nibble, in other word the \(4\times 4\times 4 = 64bits\) of the matrix can be summed up as \(4\times 4 = 16bits\) of useful information.
This meant that either some algorithms were discarded in order to maintain a lower amount of required information, or they had to be harmonised. Doing so meant turning 16 bits of information into 256 bits without changing the result of the multiplication. This was achieved by changing every nibble of the \(4\times {}4\) matrix into a \(4\times {}4\) matrix, either filled with 0s if the nibble was a 0 or the \(4\times {}4\) identity matrix if the nibble was a 1 (see Fig. 5b). The result is a \(16\times {}16\) matrix with \(4\times 4\times 16=64bits\) of useful information, which is the same as one of the \(16\times {}16\) sub matrix of the \(64\times {}64\) matrix. The \(16\times {}16\) matrix thereby obtained was then duplicated four times in order to have the 256 bits of useful information as with the \(64\times {}64\) matrix. This choice is still costly as 256 bits is meaningful but is much less than the \(64\times 64=2048bits\) of the entire matrix. The question remains nonetheless on whether adding the second type of matrix is worth the cost, this will be discussed later.
4.2 Minimizing the Cost of the Permutation
Permutation was a key issue as it is usually achieved by just reordering the wires. The overhead of making this bloc configurable could thus be significant. The simplest way to go is to consider a \(64\times {}64\) crossbar which would allow any permutation but would be incredibly costly both in terms of area and in terms of the size of configuration memory. It was therefore essential to identify similarities between the different permutations in order to limit the area of this module.
The result was two levels of permutations, as explained beforehand, the bitlevel permutation and the nibblelevel permutation. The bitlevel permutation (PRESENT [8], GIFT [4]) allows any layerinput bit to end up as any layeroutput bit within the same 16bit word, the restriction being that two bits from the same input nibble may not end up in the same output nibble. This restriction is coherent with the diffusion properties of a cipher as a bit level permutation needs to spread the information as much as possible in order to ensure the security. It requires four sets of Banyan switches each using the same parameters, which apply to each of the four 16bit words of the 64bits state.
It is composed of two layers (see Fig. 6a). Between these layers, the connection wires are fixed and cannot be configured. They link each bit of a nibble to a different nibble. The first layer defines which bit of each nibble will be connected to which nibble of the second layer, through the use of a \(4\times {}4\) Banyan switch for each nibble. The second layer reorders the bits within each nibble with a \(4\times {}4\) Banyan switch for each nibble.
Nibblelevel permutation (see Fig. 6b) works similarly and therefore, once again, any layerinput nibble may end up as any layeroutput nibble and the restriction is that two nibbles of the same 16bit input may not end in the same 16bit word output. There is an exception to this rule in the case of an actual Shift Register where each nibble is reordered but every nibble stays within the same 16bit word. It also requires two layers of Banyan switches separated with transition wires, which can be configured. There is a set of multiplexers which allows either to connect the four nibbles of a 16bit word to four different 16bit words or to keep each nibble within the same 16bit word, which is needed for the Shift Row function. The first layer defines which nibble goes to which 16bit word, and the second layer reorders each 16bit word. They each use four 4bit \(4\times {}4\) Banyan switches.
Finally, the Banyan Switches are composed of a set of five switches (see Fig. 7). Each switch allows the reordering of two inputs and is controlled by a single configuration bit. The \(4\times 4\) Banyan Switch can thus be configured to reorder its 4 inputs to get any permutation at the output. The \(4\times 3\times 2 = 24\) permutations can be controlled with only 5 configuration bits. This structure allows to reduce the area in terms of logic and configuration memory.
5 Implementation Results
The architecture was implemented targeting the Cadence Free45PDK standard cells library. Post synthesis results are used to evaluate the area and complexity of our design.
First the generic architecture complexity is evaluated for different levels of agility. Second the generic architecture is compared to the cost of implementation of classic Lightweight Block Ciphers to identify the gain of using such an architecture.
The Generic architecture can be divided in multiple subparts which have been presented in detail in chapter 3. The results of Table 3 show the cost of each of these parts. Making the architecture agile has important overcosts. For instance, Permutation is usually free in terms of area but making it configurable will obviously make it costly. It is also true for S which requires a configurable table and could not be optimised through the use of specific logic functions. The other two main parts are also new to such an architecture as they do not exist in a nonagile implementation of cryptographic algorithms. The Route_Mux allows to order each step at each round and therefore uses an important amount of multiplexers in order to select the path for the entire state. Finally, the most costly subpart is the configuration which gathers all the parameters used to select which algorithm is implemented within the architecture. This last subpart is divided between the different aspects which need configuration. It appears that the Multiplication requires the most important part of the parameters. Indeed, configuration of the Matrix multiplication has a cost of 256 bits (see Sect. 4.1) which is a lot more that the 64 bits required for S or the 176 bits used to define the algorithm’s route at each round. The overhead of the generic architecture is therefore important but most of it is due to the very nature of the architecture whose agility has a minimal cost which cannot be canceled. It would therefore seem that this architecture is not efficient when compared to a single algorithm but, the more algorithms it implements, the more interesting it becomes.
The next step was thereby comparing different levels of agility in order to identify how much adding new algorithms costs. This will then lead to a comparison between the cost of the generic architecture and the cost of implementing multiple algorithms.
Each level of agility, I, II, III and IV from Table 4 allows the implementation of a certain set of algorithms. Each of these levels is compared to the cost of each of the algorithms it can handle in Table 5.
Figure 8 illustrates the complexity reduction provided by the generic architecture when the level of agility increases. It shows that balance is achieved around an agility of four algorithms and that once this limit is exceeded, the generic architecture offers a real gain.
6 Conclusion
An implementation of a roundbased generic architecture of SPN lightweight ciphers has been presented. The results showed it was possible to compound multiple algorithms within the same architecture to provide agility features. The proposed architecture has the advantage of allowing to easily change the configuration at a round level and thus implementing the majority of SPN Lightweight algorithms.
However, the proposed architecture has a significant complexity cost, mainly due to the configuration logic. Compared to the complexity of a parallel implementation of different algorithms, we observe a complexity reduction if more than 4 ciphers are considered. The reduction can reach 62.5% if 6 different algorithms are considered. These results are promising if agility requirement is more important than complexity.
Apart from optimizing the design complexity by finding more optimal implementations for each sub bloc, a prospect is to search for ways to implement countermeasures against physical attacks. Indeed, specific countermeasures have to be implemented as they have to take into account the flexibility of our architecture without significantly increasing the global complexity.
References
Cryptographic technology guideline  lightweight cryptography (cryptrecgl00012016). Technical report, CRYPTREC Cryptographic Technology Guideline (2017)
Badel, S., et al.: ARMADILLO: a multipurpose cryptographic primitive dedicated to hardware. In: Mangard, S., Standaert, F.X. (eds.) CHES 2010. LNCS, vol. 6225, pp. 398–412. Springer, Heidelberg (2010). https://doi.org/10.1007/9783642150319_27
Banik, S., et al.: Midori: a block cipher for low energy. In: Iwata, T., Cheon, J.H. (eds.) ASIACRYPT 2015. LNCS, vol. 9453, pp. 411–436. Springer, Heidelberg (2015). https://doi.org/10.1007/9783662488003_17
Banik, S., Pandey, S.K., Peyrin, T., Sasaki, Y., Sim, S.M., Todo, Y.: GIFT: a small present. In: Fischer, W., Homma, N. (eds.) CHES 2017. LNCS, vol. 10529, pp. 321–345. Springer, Cham (2017). https://doi.org/10.1007/9783319667874_16
Beaulieu, R., TreatmanClark, S., Shors, D., Weeks, B., Smith, J., Wingers, L.: The SIMON and SPECK lightweight block ciphers. In: 2015 52nd ACM/EDAC/IEEE Design Automation Conference (DAC), pp. 1–6. IEEE (2015)
Beierle, C., et al.: The SKINNY family of block ciphers and its lowlatency variant MANTIS. In: Robshaw, M., Katz, J. (eds.) CRYPTO 2016. LNCS, vol. 9815, pp. 123–153. Springer, Heidelberg (2016). https://doi.org/10.1007/9783662530085_5
Biryukov, A., Perrin, L.P.: State of the art in lightweight symmetric cryptography (2017)
Bogdanov, A., et al.: PRESENT: an ultralightweight block cipher. In: Paillier, P., Verbauwhede, I. (eds.) CHES 2007. LNCS, vol. 4727, pp. 450–466. Springer, Heidelberg (2007). https://doi.org/10.1007/9783540747352_31
Borghoff, J., et al.: Princea lowlatency block cipher for pervasive computing applications. Cryptology ePrint Archive, Report 2012/529 (2012). https://eprint.iacr.org/2012/529.pdf
Borghoff, J., et al.: PRINCE – a lowlatency block cipher for pervasive computing applications. In: Wang, X., Sako, K. (eds.) ASIACRYPT 2012. LNCS, vol. 7658, pp. 208–225. Springer, Heidelberg (2012). https://doi.org/10.1007/9783642349614_14
Daemen, J., Peeters, M., Van Assche, G., Rijmen, V.: Nessie proposal: NOEKEON. In: First Open NESSIE Workshop, pp. 213–230 (2000)
Elbirt, A.J., Paar, C.: An instructionlevel distributed processor for symmetrickey cryptography. IEEE Trans. Parallel Distrib. Syst. 16(5), 468–480 (2005)
Goke, L.R., Lipovski, G.J.: Banyan networks for partitioning multiprocessor systems. In: ACM SIGARCH Computer Architecture News, vol. 2, pp. 21–28. ACM (1973)
Guo, J., Peyrin, T., Poschmann, A., Robshaw, M.: The LED block cipher. In: Preneel, B., Takagi, T. (eds.) CHES 2011. LNCS, vol. 6917, pp. 326–341. Springer, Heidelberg (2011). https://doi.org/10.1007/9783642239519_22
Hanley, N., ONeill, M.: Hardware comparison of the ISO/IEC 29192–2 block ciphers. In: 2012 IEEE Computer Society Annual Symposium on VLSI (ISVLSI), pp. 57–62. IEEE (2012)
Jean, J., Nikolić, I., Peyrin, T.: Tweaks and keys for block ciphers: The TWEAKEY framework. In: Sarkar, P., Iwata, T. (eds.) ASIACRYPT 2014. LNCS, vol. 8874, pp. 274–288. Springer, Heidelberg (2014). https://doi.org/10.1007/9783662456088_15
Kam, J.B., Davida, G.I.: Structured design of substitutionpermutation encryption networks. IEEE Trans. Comput. 10, 747–753 (1979)
Lee, R.B., Shi, Z., Yang, X.: Efficient permutation instructions for fast software cryptography. IEEE Micro. 21(6), 56–69 (2001)
McKay, K.A., Bassham, L.E.: Meltem Sonmez Turan Report on lightweight cryptography (nist interagency/internal report (nistir)  8114). Technical report, NIST Interagency/Internal Report (NISTIR) (2017)
Mentens, N., Charbon, E., Regazzoni, F.: Rethinking secure FPGAs: towards a cryptographyfriendly configurable cell architecture and its automated design flow. In: 2018 IEEE 26th Annual International Symposium on FieldProgrammable Custom Computing Machines (FCCM), pp. 215–215. IEEE (2018)
AES NIST: Advanced encryption standard. FIPS Publication, 197 (2001)
Rijmen, V., Daemen, J.: The Design of Rijndael: AES. The Advanced Encryption Standard. Springer, Heidelberg (2002). https://doi.org/10.1007/9783662047224
Shibutani, K., Isobe, T., Hiwatari, H., Mitsuda, A., Akishita, T., Shirai, T.: Piccolo: an ultralightweight blockcipher. In: Preneel, B., Takagi, T. (eds.) CHES 2011. LNCS, vol. 6917, pp. 342–357. Springer, Heidelberg (2011). https://doi.org/10.1007/9783642239519_23
Data Encryption Standard: Federal information processing standards publication 46. National Bureau of Standards, US Department of Commerce, 23 (1977)
Taylor, R.R., Goldstein, S.C.: A highperformance flexible architecture for cryptography. In: Koç, Ç.K., Paar, C. (eds.) CHES 1999. LNCS, vol. 1717, pp. 231–245. Springer, Heidelberg (1999). https://doi.org/10.1007/3540480595_20
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2019 IFIP International Federation for Information Processing
About this paper
Cite this paper
Tehrani, E., Danger, JL., Graba, T. (2019). Generic Architecture for Lightweight Block Ciphers: A First Step Towards Agile Implementation of Multiple Ciphers. In: Blazy, O., Yeun, C. (eds) Information Security Theory and Practice. WISTP 2018. Lecture Notes in Computer Science(), vol 11469. Springer, Cham. https://doi.org/10.1007/9783030200749_4
Download citation
DOI: https://doi.org/10.1007/9783030200749_4
Published:
Publisher Name: Springer, Cham
Print ISBN: 9783030200732
Online ISBN: 9783030200749
eBook Packages: Computer ScienceComputer Science (R0)