2008 Annual Computer Security Applications Conference
Instruction Set Extensions for Enhancing the Performance of Symmetric-Key
Cryptography
Sean O’Melia ∗, Member, IEEE, and AJ Elbirt †, Member, IEEE
Abstract
Instruction set extensions for a RISC processor are pre-
sented to improve the software performance of the Data En-
cryption Standard (DES), Triple-DES, the International Data
Encryption Algorithm (IDEA), and the Advanced Encryption
Standard (AES) algorithms. The most computationally in-
tensive operations of each algorithm are off-loaded to a set
of newly defined instructions. The additional hardware re-
quired to support these instructions is integrated into the
processor’s datapath. For each of the targeted algorithms,
comparisons are presented between traditional software im-
plementations and new implementations that take advantage
of the extended instruction set architecture. Results show that
utilization of the proposed instructions significantly reduces
program code size and improves encryption and decryption
throughput. Moreover, the additional hardware resources re-
quired to support the instruction set extensions increases the
total area of the processor by less than 65%.
Keywords: symmetric-key, cryptography, software, FPGA
1 Introduction
With more than 188 million Americans connected to the
Internet [12], information security has become a top priority.
Many applications — electronic mail, electronic banking,
medical databases, and electronic commerce — require the
exchange of private information. For example, when engag-
ing in electronic commerce, customers provide credit card
numbers when purchasing products. If the connection is not
secure, an attacker can easily obtain this sensitive data. In or-
der to implement a comprehensive security plan for a given
network to guarantee the security of a connection, Confiden-
tiality, Data Integrity, Authentication, and Non-Repudiation
must be provided [37].
Cryptographic algorithms used to ensure confidentiality
fall within one of two categories: private-key (also known as
symmetric-key) and public-key. Symmetric-key algorithms
use the same key for both encryption and decryption. Con-
versely, public-key algorithms use a public key for encryp-
tion and a private key for decryption. In a typical session,
a public-key algorithm will be used for the exchange of a
∗ Sean O’Melia is a Associate Member of Technical Staff at MIT Lincoln
Laboratory. Email: sean.omelia@gmail.com
† AJ Elbirt is a Senior Member of Technical Staff at The Charles Stark
Draper Laboratory. Email: aelbirt@draper.com
1063-9527/08 $25.00 © 2008 IEEE
DOI 10.1109/ACSAC.2008.10
session key and to provide authenticity through digital sig-
natures. The session key is then used in conjunction with
a symmetric-key algorithm. Symmetric-key algorithms tend
to be significantly faster than public-key algorithms and as
a result are typically used in bulk data encryption [37]. The
two types of symmetric-key algorithms are block ciphers and
stream ciphers. Block ciphers operate on a block of data
while stream ciphers encrypt individual bits or bytes. Block
ciphers are typically used when performing bulk data encryp-
tion and the data transfer rate of the connection directly fol-
lows the throughput of the implemented algorithm.
High throughput encryption and decryption are becoming
increasingly important in the area of high-speed networking.
Many applications demand the creation of networks that are
both private and secure while using public data transmission
links. These systems, known as Virtual Private Networks
(VPNs), can demand encryption throughputs at speeds ex-
ceeding Asynchronous Transfer Mode (ATM) rates of 622
million bits per second (Mbps). Increasingly, security stan-
dards and applications are defined to be algorithm indepen-
dent. Although context switching between algorithms can
be easily realized via software implementations, the task is
significantly more difficult when using hardware implemen-
tations. The advantages of a software implementation in-
clude ease of use, ease of upgrade, ease of design, porta-
bility, and flexibility. However, a software implementation
offers only limited physical security, especially with respect
to key storage [37]. Conversely, cryptographic algorithms
that are implemented in hardware are by nature more physi-
cally secure as they cannot easily be read or modified by an
outside attacker when the key is stored in special memory in-
ternal to the device. As a result, the attacker does not have
easy access to the key storage area and cannot discover or
alter its value in a straightforward manner [37]. Although
traditional hardware implementations lack flexibility, config-
urable hardware devices offer a promising alternative for the
implementation of processors via the use of IP cores in Ap-
plication Specific Integrated Circuit (ASIC) and Field Pro-
grammable Gate Array (FPGA) technology. To illustrate,
Altera Corporation offers IP core implementations of the In-
tel 8051 microcontroller and the Motorola 68000 processor
in addition to their own Nios R
-II embedded processor. Sim-
ilarly, Xilinx Inc. offers IP core implementations of the Pow-
erPC processor in addition to their own MicroBlazeT M and
PicoBlazeT M embedded processors. ASIC and FPGA tech-
465
nologies provide the opportunity to augment the existing dat-
apath of a processor implemented via an IP core to add ac-
celeration modules supported through newly defined instruc-
tion set extensions targeting performance-critical functions
[13], [19], [39]. Instruction set extensions result in signifi-
cant performance improvements versus traditional software
implementations with considerably reduced logic resource
requirements versus hardware-only solutions [4], [23], [24],
[32], [33].
What follows is an overview on the various methods of
speeding up symmetric-key algorithms in software. It will
be shown that advances in technology have fueled trends to-
wards increased reconfigurability in embedded systems, re-
sulting in instruction set extensions becoming an attractive
option for performance-critical applications. A discussion of
the target processor, the LEON2 RISC processor, will be fol-
lowed by an analysis of the performance bottlenecks com-
monly encountered in software implementations of the tar-
geted cryptographic algorithms. The proposed instructions
will then be presented, followed by a description of the mod-
ifications to the LEON2 processor and its associated devel-
opment tools. Finally, data on the logic utilization of the
additional hardware as well as throughput data for the target
algorithms achieved using the instruction set extensions will
be presented to demonstrate the effectiveness of this acceler-
ation method.
2 Previous Work
Most traditional methods for improving the throughput of
pure software implementations of symmetric-key algorithms
fall into one of two categories. One option is to construct
memory-based look-up tables where results of some of the
basic operations of the algorithm have been pre-computed
and stored. The substitution boxes, or S-Boxes, of the DES
and AES algorithms are commonly stored in look-up tables
in software implementations. Look-up tables may also be
used to combine operations used in the DES and AES al-
gorithms. AES requires several complicated mathematical
operations that are time-consuming on general-purpose pro-
cessors. Therefore in some implementations, large look-up
tables, called T-tables, are employed that combine several
of these complex operations into a single table access [34].
Look-up table based implementations are viable for systems
with large memory spaces and low access times. However,
area-constrained systems suffer large performance penalties
using this methodology and are typically not implemented in
this manner [33], [34].
Another method for speeding up software implementa-
tions of cryptographic algorithms involves taking advantage
of mathematical or structural properties of the particular al-
gorithm. The Initial and Final Permutations of the DES algo-
rithm have regular structures that make it possible to execute
a series of matrix transformations and XOR operations as
demonstrated in [29]. This translates into a sequence of in-
structions that is much smaller than the traditional sequence
required to perform the Initial and Final Permutations. In
466
previous work on improving the performance of the AES
algorithm on 32-bit systems, it has been shown that trans-
forming a block of plaintext from a column-oriented matrix
to a row-oriented matrix reduces the number of instructions
required to complete the cipher due to more efficient imple-
mentation of the Galois Field matrix multiplication opera-
tions [1].
In order to extend the cryptographic capabilities of an
embedded system without modifying the main processor, a
co-processor solution can be adapted. When there is data
that must be encrypted or decrypted through the chosen
symmetric-key algorithm, the main processor sends the data
and key material to the co-processor, and the co-processor
performs the algorithm, sending the processed data back over
the interface to the main processor. Most co-processor so-
lutions have tended to combine a number of different al-
gorithms to provide a multi-faceted security solution. Co-
processors have achieved high throughput values compared
to traditional software implementations and therefore are
much more capable of meeting demands for speed-critical
network communications. However, this type of solution re-
quires considerable overhead in terms of hardware area, data
transfer latency, and processor interfaces [4], [5], [11], [15],
[16], [21], [28], [35], [36], [40].
Previous work on instruction set extensions for general-
ized permutations are useful for improving the performance
of permutations used in the DES algorithm. Two new instruc-
tions for general and dynamically specified permutations are
presented in [38]. The input and a string of configuration bits
are specified in the source operands and the result is stored
in the destination register. Permutations of n bits required
log2 (n) issues of the custom instructions as well as several
loads of configuration bits into registers. The MOSES plat-
form, based on the Xtensa T1040, is a RISC-like processor
designed to be easily extended with additional hardware and
supporting instructions. Throughput improvement factors of
31.0 for DES, 33.9 for Triple-DES, and 17.4 for AES were
reported for this architecture [31]. Similarly, instruction set
extensions that perform the mathematical operations in the
AES rounds using custom functional units integrated into
the targeted processor’s datapath were investigated in [33].
These extensions minimize the number of memory accesses,
usually by combining the SubBytes and MixColumns trans-
formations into one T-table look-up operation to speed up al-
gorithm execution. While T-table performance is dependent
upon available cache size, these extensions have yielded per-
formance improvements of up to a factor of 3.68 versus AES
implementations without the use of the instruction set exten-
sions [16], [18], [31], [36].
Several software implementations of the IDEA algorithm
take advantage of advanced processor architectures that em-
ploy instruction parallelism or functional units for multime-
dia support. A four-way parallel implementation on a 166
MHz Pentium MMX processor [25] achieved a throughput
of approximately 72 Mbps. Throughput values ranging from
421 Mbps to 550 Mbps have been achieved on the Itanium
platform running at 733 MHz [14]. The performance evalu-
ations reported in [10] include a comparison of IDEA soft-
ware implementations on processors with various word sizes,
clock frequencies, and cache sizes. Execution times for
IDEA encryption ranged from 2,555 µs on the 8-bit 4 MHz
Atmega 103 to 9 µs on the 64-bit 440 MHz UltraSparc2 R
with instruction and data cache sizes of 16 Kbytes. Fast mul-
tiplication capability was shown to be a major factor in the
performance of the IDEA algorithm.
Implementations of IDEA on reconfigurable computing
platforms and systems with co-processors have shown im-
proved performance. An implementation on an SRC-6E
platform [27] achieved throughputs of approximately 590
Mbps for end-to-end software time for bulk data process-
ing. Comparisons have been made between the performance
of IDEA on Digital Signal Processors (DSPs), cryptographic
co-processors, and hardware implementations on FPGAs in
a hardware-software co-design system that makes use of en-
cryption in a mobile device. Reported performance figures
ranged from 32 Mbps on the DEC SA-110 and 53.1 Mbps
on the TI TMX320C6x DSP chips, to 180 Mbps using the
VINCI cryptographic co-processor, to 528 Mbps with an
FPGA-based implementation [26].
3 The LEON2 Processor
The LEON2 processor is a RISC CPU produced by
Gaisler Research that is implemented in VHDL and is fully
synthesizable. The model is highly configurable and the
source code is freely available under the GNU General Public
License which enables modifications and enhancements to
the architecture. The LEON2 processor is based on the Scal-
able Processor Architecture (SPARC R
) and features a fully
synchronous design with a single clock, use of multiplexers
for loading of pipeline registers, separate combinational and
sequential processes, and record types for interconnection of
component I/O signals.
All SPARC R
V8 instructions are implemented in the
LEON2 processor architecture. Instructions are grouped ac-
cording to the values of the various fields in the instruction
opcode. Most of the available features of the LEON2 pro-
cessor can be enabled, disabled, or adjusted. This research
employed a basic configuration with no FPU, PCI, Ethernet,
co-processor interface, or hardware multiplier or divider. To
extend the LEON2 architecture beyond the scope of the stan-
dard model, additional VHDL code is required. The specific
files that must be modified depend on the functionality to be
added, but if the instruction set is to be extended, the mod-
ule containing the SPARC R
V8 opcode constants must be
updated.
The LEON2 implementation can be targeted to any type
of FPGA or ASIC technology. Pre-made packages enable
use of technology-specific cells to directly instantiate or au-
tomatically infer the register files, caches, PCI FIFOs, and
I/O pads. Functional verification and performance evalua-
tion of programs built for the LEON2 architecture can be
performed with the provided generic test bench. The VHDL
source for the test bench is located in the /tbench/ sub-folder
467
of the LEON2 directory structure. Software code is placed in
the /tsource/ sub-folder in a format readable by the test bench
VHDL code. The software can then be read and executed by
the test bench. In order to facilitate the development of pro-
grams targeting the LEON2 processor, Gaisler Research has
provided a series of compilers and simulators that may be
chosen depending on the software environment. For stand-
alone applications, the Bare C Compiler, based on the GNU
Compiler Collection and GNU binutils, is recommended.
4 Evaluation of the Target Algorithms
Software implementations of DES tend to be significantly
slower than hardware implementations. Bit-level manipula-
tions such as those contained in the permutation, expansion,
permuted choice, and Cyclic Left/Right Shift units do not
map well to general-purpose processors. General-purpose
processor instruction sets operate on multiple bits at a time
based on the processor word size. Moreover, the DES S-
Boxes do not use memory in an efficient manner. Soft-
ware look-up tables would appear to be the obvious imple-
mentation choice for the DES S-Boxes. However, the DES
S-Boxes have 6-bit addresses and 4-bit output bits while
most memories associated with general-purpose processors
use byte addressing with either 8-bit or 32-bit output data.
As a result, many software implementations of DES exhibit
throughputs that are at least a full order of magnitude slower
than hardware implementations.
Even the best software implementations are only capable
of throughputs in the range of 100–200 Mbps. Most of these
implementations recommend storing the 32-bit left and right
halves of the data stream as a 48-bit padded word within a
64-bit processor word and implementing the permutations
and S-Boxes as precomputed look-up tables. Additionally,
look-up table implementation for the S-Boxes is most effec-
tive when the size of the look-up tables is minimized, guar-
anteeing that the data will fit entirely in on-chip cache. Size
minimization of the S-Box look-up tables is achieved by im-
plementing each S-Box in its own look-up table. Finally, one
key software optimization is the unrolling of software loops
to increase performance. Even when software loops are too
cumbersome to unroll, using loop counters that decrement to
zero in place of loop counters that increment to a terminal
count are shown to greatly increase the performance of soft-
ware implementations of the DES algorithm. However, the
unrolling of software loops must be done with great care such
that the total data storage space does not exceed the size of
the on-chip cache to avoid extreme performance degradation
[3], [17], [30].
In terms of the core operations of IDEA, bit-wise XOR
and addition are easily implemented with one instruction
each in software. For reduction modulo 216 , a processor such
as the LEON2 that only performs arithmetic on 32-bit regis-
ter operands requires an additional logic instruction to mask
out the bits that may overflow into the sixteen most signifi-
cant bits of the destination register. However, the major per-
formance bottleneck for a software implementation of IDEA
is multiplication modulo 216 + 1. Multiplication may require
several clock cycles to complete (especially those without
hardware multipliers), and the modular reduction, commonly
implemented using the Low-High Lemma [22], requires ad-
ditional execution time.
AES software performance bottlenecks typically occur in
the SubBytes and MixColumns transformations, one or both
of which are usually implemented via 8-bit to 8-bit look-
up tables. Often most of the AES round transformations
— SubBytes, ShiftRows, and MixColumns — are combined
into large look-up tables termed T-tables. Such implemen-
tations require up to three T-tables whose size may be ei-
ther 1 Kbytes or 4 Kbytes where the smaller tables require
performing an additional rotation operation. The goal of the
T-tables is to avoid performing the MixColumns and InvMix-
Columns transformations as these operations perform Galois
Field fixed field constant multiplication, an operation which
maps poorly to general-purpose processors. However, the
use of T-tables has a number of disadvantages. T-tables sig-
nificantly increase code size, their performance is dependent
on the memory system architecture as well as cache size, and
their use causes key expansion for AES decryption to be-
come significantly more complex. As an alternative to the
use of T-tables, it is also feasible to have the processor per-
form all of the AES round transformations. Row-based im-
plementations have been demonstrated to allow for greater
efficiency in the implementation of the MixColumns and In-
vMixColumns transformations versus column-based imple-
mentations. However the SubBytes transformation still re-
mains as a bottleneck, requiring separate 256-byte look-up
tables for encryption and decryption [1], [6], [33], [34].
5 Proposed Instruction Set Extensions
All of the proposed instruction set extensions comply with
the SPARC R
V8 instruction model using the Format 3 struc-
ture. All instructions that write to a register execute in one
clock cycle except for the mmul16 instruction which re-
quires two clock cycles. For those instructions that store data
directly into registers contained in the hardware added to the
datapath, the data is available at the start of the next cycle,
after instruction execution has completed. Building the set
of development tools from the source files is necessary when
extending the instruction set of the LEON2 processor. The
source code archive for BCC v1.0.29c includes specific mod-
ifications made to two different versions of GNU binutils to
support the LEON2 processor. This research employs the
v2.16.1 binutil. The file /opcodes/sparc-opc.c was edited to
include op3 values for the instruction set extensions.
All added hardware modules are coded in VHDL and all
inputs and outputs are read from and written to the LEON2
pipelined integer unit (IU) register file. None of the added
logic circuits rely on external memory for their functional-
ity. A new module was included with the VHDL source for
the LEON2 processor architecture to provide an easy way to
select specific extensions to be included in the architecture.
For the AES S-Box extensions, the available options are no
468
S-Boxes, one S-Box, and four S-Boxes. For all other types
of extensions, setting the configuration variables to true in-
cludes extensions into the architecture while a value of false
excludes them from the architecture. All of the added func-
tional units that support the proposed instruction set exten-
sions have been included in the IU. Component declarations
were added for each of the added hardware units and instan-
tiated as part of the arithmetic logic unit. The decode stage
of the IU pipeline sets flags for the instruction set extensions
and generates source register and immediate data. On the
next clock cycle, the execute stage passes the input operands
to the appropriate functional unit based on the instruction flag
set. The result is then read from the functional unit when the
instruction specifies a destination register to receive an out-
put.
The SPARC R
assembly instruction opcodes are defined
in the /leon/sparcv8.vhd module. The code added to this
module include the values for the op3 field of the new in-
structions. Provided in the LEON2 base package is a generic
test bench with disassembly support. During functional sim-
ulation, assembly instructions are printed out to the simula-
tion software’s console window as they are executed. The
module /leon/debug.vhd contains the functions that handle
display of the instruction strings, and disassembly support
for the new instructions was added. When the op and op3
instructions match those of one of the instruction set exten-
sions, the instruction name is printed followed by any appli-
cable source/destination registers or immediate data for that
instruction.
5.1 DES and Triple-DES
The desipl and desipr instructions produce the left and
right halves of the Initial Permutation, respectively. Simi-
larly, the desfpl and desfpr instructions produce the left and
right halves of the Final Permutation, respectively. The left
half of the input block must be located in the rs1 register and
the right half must be located in the rs2 register. Inclusion of
these instructions allows the Initial and Final Permutations to
be completed in two instructions each. Traditional software
implementations require a series of bit mask setup, shift, log-
ical AND, and logical OR operations for each bit for a total
of 256 instructions [38]. Even the improved permutation al-
gorithm used in [20] requires 44 instructions to complete on
a SPARC R
V8 processor such as the LEON2.
The desdir instruction sets up the Key Generator to out-
put round keys in either encryption or decryption order. This
instruction also resets the round counter of the Key Genera-
tor according to the chosen direction to ensure that output of
the round keys may be immediately carried out in the proper
order. It is not necessary to re-load the master key after this
instruction is executed. The desdir instruction is used in con-
junction with the deskey and desf instructions. The deskey
instruction loads the 64-bit master key. The left half of the
master key must be contained in the rs1 register, and the right
half in the rs2 register. The desf instruction takes the right
half of a round output block stored in the rs1 register and
stores the output of the f -function into the rd register. The
round key is not specified here since the round key output
of the Key Generator is hard-wired to the f -Function unit’s
round key input. After completion of this instruction, the Key
Generator is signaled to generate the key for the next round.
Due to the logic of the Key Generator, the desf instruction
may not be followed by another desf instruction. However,
this is not expected to cause a performance bottleneck due to
the additional instruction required for swapping the values of
the left and right halves of the round input block. Implemen-
tation of the desdir, deskey, and desf instructions removes
the need for storage of the sixteen round keys and S-Boxes
in memory. All round keys are generated on-the-fly in the
hardware added to the datapath. An implementation of the
DES algorithm using these instructions requires two instruc-
tions for key scheduling and four instructions for each of the
sixteen rounds — one desf, one bit-wise XOR, and two reg-
ister data transfers for swapping the left and right halves of
the round function output.
The Permutation Unit implements the Initial Permutation
and Final Permutation. The inputs are loaded from the source
registers specified in the permutation instruction. The inputs
are passed through two stages of 2-to-1 multiplexers. The
first stage selects the rearranged bits of either the Initial Per-
mutation or the Final Permutation output. The output of the
selected permutation is represented by the pair of 32-bit vec-
tors. The second stage of multiplexers sets the final output
to either the left half or the right half of the output. The Key
Generator unit was designed to work in conjunction with the
f -Function unit. All registers are sensitive to the rising edge
of the clock. The 64 key bits, which are loaded from the
source registers specified in the deskey instruction, are rear-
ranged according to the PC-1 mapping. A 64-bit master key
is loaded by issuing the deskey instruction. When this in-
struction is in the execute stage, the key bits are loaded into
the C0 and D0 registers. When performing encryption, the
C and D registers are loaded with the values of C0 and D0
rotated left by 1 bit since the first values of Ci and Di used
in the encryption key schedule are C1 and D1 . When per-
forming decryption, the C and D registers are loaded with
the exact values of C0 and D0 because the final Ci and Di
values used in the encryption key schedule are the first values
used in the decryption key schedule. The f -Function unit’s
32-bit input port for Ri−1 is loaded from the source register
operand specified in the desf instruction. The 48-bit input
port for the current round key is generated by the Key Gen-
erator unit. Expansion and permutation blocks are imple-
mented by rerouting the inputs and the S-Boxes are defined
as logic-based mappings. The output of the f -Function unit
is stored in the destination register specified in the rd field of
the desf instruction.
5.2 IDEA
The mmul16 instruction computes rs1 · rs2 mod 216 + 1
and stores the product in the rd register. Both source
operands must be in the lower sixteen bits of their respective
469
registers. The 16-bit product is stored in the lower sixteen
bits of the rd register. The Modulo 216 + 1 Multiplication
unit is designed based on the adder-based modular multiplier
in [2]. The Modulo 216 + 1 Multiplication unit first gener-
ates partial products reduced modulo 216 + 1 as described
in Zimmerman’s investigation of efficient architectures for
arithmetic modulo 2n ± 1 [41]. Each partial product is de-
termined by the formula:
P Pi = xi · y15−i · · · y0 ȳ15 · · · ȳ16−i + x̄i · 0 · · · 01 · · · 1 (1)
where the vector 0 · · · 01 · · · 1 contains 16 − i zeros and i
ones. In order to handle cases where x = 0 or y = 0, a
correction term k is defined:
⎧
⎪
⎪ 2 if x = 0 and y = 0,
⎨
x̄ + 3 if x = 0 and y = 0,
k= (2)
⎪
⎪ ȳ + 3 if x = 0 and y = 0,
⎩
1 if x = 0 and y = 0.
15
An intermediate sum s = k + i=0 P Pi is then computed.
The final step is a reduction of s modulo 216 + 1. Defining
sL to be the sixteen least significant bits and sH to be the
remaining high-order bits of s, the result of the multiplication
is s mod (216 + 1) = sL + 216 sH . This result may be
reduced such that s mod (216 + 1) ≡ sL + s¯H + 2.
Using the Low-High Lemma for reduction modulo 216 + 1
assuming that t = sL + s¯H + 1 [22]:

(sL + s¯H + 2) mod 216 if t < 216 ,
s mod (216 + 1) = (sL + s¯H + 1) mod 216 if t ≥ 216 .
(3)
Additions are implemented in the Modulo 216 + 1 Mul-
tiplication unit with a carry-propagate adder tree. A generic
model is specified in a VHDL source file separate from the
multiplier source file. The generic component design allows
for adjustable width of the inputs.
5.3 AES
The aessb, aessbs, aessb4, and aessb4s instructions per-
form the SubBytes and InvSubBytes operations on either
one or four of the bytes in the rs1 register. The instruction
operands determine if the SubBytes operation or the InvSub-
Bytes operation is to be performed. In the case of the single
S-Box instructions, the operand also specifies which of the
four bytes in the rs1 register is to be operated upon. The
aessbs instruction provides the additional functionality of al-
lowing the user to specify the destination byte in the rd reg-
ister while the aessb4s instruction allows the user to spec-
ify the number of bytes to left-shift the 4-byte result prior to
storage in the destination register. The gfmkld instruction is
used to load one of the sixteen constants into the 4 × 4 con-
stant matrix of the Galois Field fixed field constant matrix
multiplier. The constants are loaded row by row, beginning
with row zero and proceeding in order to row three. Each
row is loaded beginning with the constant from column zero
and proceeding in order to the constant in column three. Due
to the logic that has been added to the multiplier for inclusion
into the LEON2 processor datapath, instances of the gfmkld
instruction may not be issued consecutively. The gfmmul in-
struction performs the Galois Field fixed field constant ma-
trix multiplication on the input in the rs1 register and stores
the result in the rd register.
The SubBytes and InvSubBytes S-Boxes are implemented
as logic-based mappings in hardware. The dir signal se-
lects the S-Box output. The Galois Field Fixed Field Con-
stant Multiplier unit performs the MixColumns or InvMix-
Columns operation. The architecture of this multiplier is de-
scribed in [9], [8]. The MixColumns and InvMixColumns
operations are a matrix multiplication over the Galois Field
GF(28 ) on each column of the state by a 4 × 4 fixed field
constant matrix. This means that a total of sixteen multi-
plications in the Galois Field GF(28 ) must be performed to
complete the entire operation. Each product must then be re-
duced modulo m(x) = x8 + x4 + x3 + x + 1, the irreducible
polynomial specified for AES. To accomplish the multipli-
cation and modular reduction simultaneously, the operation
can be represented as an 8 × 8 matrix multiplication over
the Galois Field GF(2). The constants in the inner matrix
are determined by the constant factor in the multiplication
and the polynomial m(x). Consider the representative Ga-
lois Field GF(28 ), used by AES in the MixColumns and In-
vMixColumns transformations. Note that [A3 : A0 ] are the
input bytes and [B3 : B0 ] are the output bytes [7]:
⎡ ⎤ ⎡ ⎤⎡ ⎤
B0 K00 K01 K02 K03 A0
⎢ B1 ⎥ ⎢ K10 K11 K12 K13 ⎥ ⎢ A1 ⎥ tion keys. The key schedule for decryption sees a slight de-
⎢ ⎥ ⎢ ⎥⎢ ⎥
⎣ B2 ⎦ = ⎣ K20 K21 K22 K23 ⎦ ⎣ A2 ⎦ (4)
B3 K30 K31 K32 K33 A3
The core operation in this fixed field multiplication is an
8-bit inner product that must be performed sixteen times,
four per row. The four inner products of each row are then
combined via a bit-wise XOR operation to form the final
output word. For a known primitive polynomial p(x), k(x)
(representing the 8-bit constant), and a generic input a(x),
the resultant polynomial equation takes the form b(x) =
a(x) × k(x) mod p(x) where each coefficient of b(x) is
a function of a(x). This results in an 8-bit × 8-bit matrix
representing the coefficients of b(x) in terms of a(x) [7]. An
8-bit × 8-bit matrix must be generated for each Kxy , result-
ing in a total of sixteen matrices. Note that this analysis holds
true for Galois Fields other than GF(28 ) with corresponding
adjustments to the mapping matrix.
6 Analysis of Results
Functional verification was performed using twelve test
vectors for each algorithm. Performance testing measured
the execution cycles required to perform one iteration of
the target algorithm. Each algorithm was tested in both
non-feedback (Electronic Code Book) and feedback (Cipher
Block Chaining) modes of operation for both encryption and
470
decryption. The LEON2 processor implementation was syn-
thesized targeting the Xilinx Virtex-4 XC4VLX25 FPGA us-
ing the Xilinx ISE 8.1i tools.
6.1 Code Size
The following tables present executable code sizes for im-
plementations of the target algorithms with different combi-
nations of instruction set extensions. For the DES and Triple-
DES algorithms, the permutation instructions decrease the
total code size by up to a factor of 1.3 but have no effect on
the key schedule as permutations are not used in the compu-
tation of the round keys. Instructions supporting the round
key generation and round function have a much more pro-
nounced impact on code size. When these instructions are
used, all of the lengthy permutation routines and memory-
based S-Boxes are no longer needed. Encryption and decryp-
tion code size is reduced by up to a factor of 4.0 in the case
of DES and a factor of 3.5 in the case of Triple-DES with the
use of these instructions alone. Key scheduling is handled
via two instructions, making the respective code size a small
percentage of the remaining program code needed to imple-
ment encryption and decryption. When all of the instruction
set extensions are implemented, DES code size is reduced by
factors of up to 31.2 in non-feedback mode and 21.1 in feed-
back mode and Triple-DES code size is reduced by factors of
up to 15.9 in non-feedback mode and 13.0 in feedback mode.
Note that the decryption key schedule code size data for
IDEA includes that of the encryption key schedule. This is
because the decryption keys are determined from the encryp-
crease in code size with the use of the mmul16 instruction
because of the need to compute multiplicative inverses mod-
ulo 216 . The addition of the mmul16 instruction significantly
decreases the code size of encryption and decryption by fac-
tors of up to 2.8 in non-feedback mode and 2.4 in feedback
mode. Note that due to the absence of a hardware multiplier
in the LEON2 integer unit, the multiplication is performed
by a library function.
The AES instruction set extensions aessbs and aessb4s
yielded either equivalent or reduced code size for both
column-oriented and row-oriented implementations versus
the aessb and aessb4 instruction set extensions. Using one
S-Box led to the largest reduction in code size for column-
oriented implementations by up to a factor of 1.8 for encryp-
tion and 1.6 for decryption. In the case of the row-oriented
implementations, the use of four S-Boxes led to the largest
reduction in code size by up to a factor of 2.6 for encryp-
tion and 2.2 for decryption. However, the use of one S-Box
results in significantly reduced key scheduling code size for
row-oriented implementations.
When only the gfmmul instruction is incorporated, code
size decreases by up to a factor of 1.3 for encryption and
1.8 for decryption in the column-oriented implementations.
The original code used to implement the InvMixColumns op-
eration for decryption requires many more operations than
the MixColumns operation used by encryption. Only four
instances of the gfmmul instruction are needed to perform encryption is unaffected, the use of the mmul16 instruction
both operations – one for each column of the AES state. results in a decryption key scheduling speedup by a factor of
The use of the gfmmul instruction results in up to a factor 7.8. Similarly, the use of the mmul16 instruction results in
of 1.1 increase in code size for encryption and 1.1 decrease speedups of IDEA by up to a factor of 7.7 in non-feedback
in code size for decryption in the row-oriented implemen- mode and 7.1 in feedback mode.
tations. This occurs because the MixColumns and InvMix- The AES instruction set extensions aessbs and aessb4s
Columns operations operate on the columns of the AES state, yielded either equivalent or reduced execution cycles for both
requiring additional instructions to rearrange the bytes prior column-oriented and row-oriented implementations versus
to being processed by the gfmmul instruction in the row- the aessb and aessb4 instruction set extensions. Using one
oriented implementations. The effect of the byte rearrange- S-Box led to the largest speedup for column-oriented imple-
ment is that column-oriented implementations require signif- mentations by up to a factor of 1.4 for encryption and 1.2 for
icantly smaller code space than the row-oriented implemen- decryption. Using four S-Boxes led to the largest speedup
tations when all of the instruction set extensions are imple- for row-oriented implementations by up to a factor of 1.9 for
mented. For column-oriented implementations, code size is encryption and 1.6 for decryption. However, the use of one
reduced by up to a factor of 3.6 for encryption and 4.8 for S-Box reduced the key scheduling execution cycles for row-
decryption using one S-Box while for row-oriented imple- oriented implementations.
mentations, code size is reduced by up to a factor of 2.1 for Incorporating only the gfmmul instruction yields
encryption and 2.3 for decryption using four S-Boxes. speedups of up to a factor of 1.8 for encryption and 3.0
for decryption in the column-oriented implementations.
Key and
Base Permute f-Function All The original code used to implement the InvMixColumns
Operation Code ISEs ISEs ISEs
DES Key Sched 1524 1524 8 8 operation for decryption requires many more operations,
DES Enc ECB 1996 1572 500 68 and thus cycles, versus the MixColumns operation used by
DES Enc CBC 2028 1604 532 100
DES Dec ECB 1996 1572 496 64 encryption. The use of the gfmmul instruction results in
DES Dec CBC 2028 1604 528 96
Triple-DES Key Sched 1524 1524 24 24 up to a factor of 1.1 decrease in performance for encryp-
Triple-DES Enc ECB 2096 1656 588 132
Triple-DES Enc CBC 2128 1688 620 164 tion and 1.04 speedup for decryption in the row-oriented
Triple-DES Dec ECB 2096 1656 588 132 implementations. This occurs because the MixColumns and
Triple-DES Dec CBC 2128 1688 620 164
InvMixColumns operations operate on the columns of the
Table 1. DES and Triple-DES code size (bytes) AES state, requiring additional cycles to rearrange the bytes
prior to being processed by the gfmmul instruction in the
Modulo 216 + 1 row-oriented implementations. The effects of the byte rear-
Base Multiplication rangement is such that the speedups of the column-oriented
Operation Code ISE
Enc Key Sched 436 436 implementations are significantly larger than the speedups of
Dec Key Sched 844 760
Enc ECB 596 212 the row-oriented implementations when all of the instruction
Enc CBC 660 276 set extensions are implemented and row-oriented imple-
Dec ECB 596 212
Dec CBC 660 276 mentations perform better when the gfmmul instruction is
Table 2. IDEA code size (bytes) combined with one S-Box instead of four S-Boxes. Column-
oriented implementations yield speedups by a factor of 4.0
for encryption and 6.6 for decryption using one S-Box while
6.2 Execution Cycles row-oriented implementations yield speedups by a factor of
1.4 for encryption and 1.7 for decryption.
The following tables present the number of clock cycles
Key and
required to complete a full iteration of each algorithm. For Base Permute f-Function All
Operation Code ISEs ISEs ISEs
the DES and Triple-DES algorithms, the permutation in- DES Key Sched 2917 2917 9 9
structions alone have virtually no impact on the execution DES Enc ECB
DES Enc CBC
4330
4342
4215
4227
252
263
133
144
cycles for both DES and Triple-DES. However, the instruc- DES Dec ECB
DES Dec CBC
4330
4343
4215
4228
250
263
132
144
tions supporting round key generation and the round func- Triple-DES Key Sched 8750 8750 24 24
tion have a significant impact on execution cycles, yielding Triple-DES Enc ECB 12993 12648 752 396
Triple-DES Enc CBC 13004 12659 764 407
speedups for DES by a factor of up to 17.3 in non-feedback Triple-DES Dec ECB 12993 12648 751 395
Triple-DES Dec CBC 13004 12659 764 407
mode and 16.5 in feedback mode and speedups for Triple-
DES by a factor of up to 17.3 in non-feedback mode and Table 4. DES and Triple-DES execution cycles
17.0 in feedback mode. Implementation of all of the instruc-
tion set extensions yields speedups for DES by a factor of Table 7 details execution cycle counts for some combi-
up to 32.6 in non-feedback mode and 30.2 in feedback mode nations of extensions are compared with results published
and speedups for Triple-DES by a factor of up to 32.8 in non- by the ISEC project [33]. Their work includes the use of
feedback mode and 32.0 in feedback mode. logic-based mappings as a choice of hardware implementa-
The use of the mmul16 instruction significantly decreases tion for the S-Boxes. The sbox and sbox4 instructions from
the IDEA execution cycle count. While key scheduling for the ISEC project are equivalent to the aessbs and aessb4 in-

471
 1 S-Box and 4 S-Boxes and
Base 1 S-Box 4 S-Boxes GF Mult GF Mult GF Mult
Operation Code ISEs ISEs ISEs ISEs ISEs
Col Oriented Key Sched 588 176 164 588 176 164
Col Oriented Enc ECB 1404 764 908 1052 392 520
Col Oriented Enc CBC 1468 828 972 1116 456 584
Col Oriented Dec ECB 1872 1200 1408 1048 392 528
Col Oriented Dec CBC 1936 1264 1472 1112 456 592
Row Oriented Key Sched 564 256 564 564 256 564
Row Oriented Enc ECB 1220 620 476 1328 540 584
Row Oriented Enc CBC 1284 684 540 1392 604 648
Row Oriented Dec ECB 1328 692 592 1296 668 568
Row Oriented Dec CBC 1392 756 656 1360 732 632

Table 3. AES code size (bytes)

1 S-Box and 4 S-Boxes and

Base 1 S-Box 4 S-Boxes GF Mult GF Mult GF Mult
Operation Code ISEs ISEs ISEs ISEs ISEs
Col Oriented Key Sched 519 376 346 519 376 346
Col Oriented Enc ECB 1742 1250 1423 962 435 549
Col Oriented Enc CBC 1768 1276 1449 989 462 576
Col Oriented Dec ECB 2872 2360 2638 963 435 561
Col Oriented Dec CBC 2899 2387 2665 990 462 588
Row Oriented Key Sched 669 606 669 669 606 669
Row Oriented Enc ECB 1335 926 717 1573 751 971
Row Oriented Enc CBC 1361 952 743 1600 778 998
Row Oriented Dec ECB 1622 1193 1026 1557 1132 964
Row Oriented Dec CBC 1649 1220 1053 1584 1159 991

Table 6. AES execution cycles

Modulo 216 + 1 and combinational logic used to compute the matrix product,
Base Multiplication
Operation Code ISE the Galois Field matrix multiplier is the largest of the added
Enc Key Sched 894 894
Dec Key Sched 43005 5510 hardware units. The implementation with all of the proposed
Enc ECB 2580 337 instruction set extensions leads to a total area increase over
Enc CBC 2602 365
Dec ECB 2577 337 the baseline configuration by approximately 63%. The mod-
Dec CBC 2602 365
ulo 216 + 1 multiplier for IDEA was the single largest
Table 5. IDEA execution cycles contributor to decreases in the implementation’s maximum
operating frequency. A purely combinational design of the
multiplier had large path delays due to the carry-propagate
structions presented in this research. The mixcol4 instruc- adder structure, yielding a maximum operating frequency of
tion uses an entire 32-bit word as input into an AES-specific only 72 MHz. The multiplier was modified to create a two
MixColumns/InvMixColumns functional unit. In order to cycle instruction implementation to decrease the effect on
address the ShiftRows operation, the instructions sbox4s the processor clock frequency. With all extensions imple-
and mixcol4s combine an implicit ShiftRows operation with mented, the LEON2 processor implementation resulted in a
SubBytes and MixColumns respectively. This functionality clock frequency of approximately 117 MHz, a 10% decrease
is similar but not identical to the combination of the aessb4s compared to the baseline implementation.
and gfmmul instructions. CLB Freq
Slices F/Fs (MHz)
Enc Enc Dec Dec Baseline LEON2 Implementation 4563 1803 129.929
Implementation Cyc SU Cyc SU DES
No Extensions (ISEC) 1637 1.0 1955 1.0 Permutation 5200 2372 128.083
No Extensions (UML) 1335 1.0 1622 1.0 Keygen/f-Function 5498 2477 122.786
4 S-Boxes sbox4 (ISEC) 1020 1.6 1435 1.4 All Units 5543 2488 123.880
4 S-Boxes aessb4 (UML) 837 1.6 1117 1.5 IDEA mod (216 + 1) Multiplier 5411 2398 118.162
GF Mult mixcol4 (ISEC) 939 1.7 970 2.0 AES
GF Mult gfmmul (UML) 962 1.4 963 1.7 1 S-Box 5367 2368 128.996
sbox and mixcol4 (ISEC) 458 3.6 458 4.3 1 S-Box (S) 5281 2336 128.594
aessbs and gfmmul (UML) 435 3.1 435 3.7 4 S-Boxes 5657 2380 127.369
4 S-Boxes (S) 6633 2910 125.639
sbox4s and mixcol4s (ISEC) 458 3.6 459 4.3 GF Multiplier 5681 3415 120.766
aessb4s and gfmmul (UML) 549 2.4 561 2.9 1 S-Box and GF Multiplier 5862 3399 126.787
1 S-Box (S) and GF Multiplier 5920 3416 123.896
4 S-Boxes and GF Multiplier 6174 3414 121.422
Table 7. AES execution cycles comparison 4 S-Boxes (S) and GF Multiplier 6420 3543 122.134
LEON2 with All Extensions 7447 3766 116.828

6.3 Hardware Resource Requirements Table 8. Hardware Utilization — Xilinx

XC4VLX25 FPGA
Table 8 shows the component usage of the Xilinx Virtex-
4 XC4VLX25 FPGA by each added functional unit and the 6.4 Algorithm Throughput Comparisons
total utilizations of the LEON2 processor with combinations
of instruction set extensions for each targeted algorithm. Due Table 9 presents throughput data for baseline implementa-
to the number of storage bits needed for matrix configuration tions of the target algorithms versus implementations of the

472
target algorithms using the proposed instruction set exten-
sions when performing encryption in non-feedback mode.
The results are analyzed with respect to the hardware re-
sources required for each implementation to determine the
hardware cost associated with improving the execution time
of the targeted algorithms using the proposed instruction
set extensions. Throughput data is presented in terms of
Megabits per second (Mbps), hardware usage is presented
in terms of FPGA configurable logic block (CLB) slices, and
throughput/area (T/A) ratios are presented in bits per second
per slice.
The data shows that the instruction set extensions yielded
the best improvement for DES in terms of T/A ratio, with
the ratio increasing by a factor of 25.6. This increase is a re-
sult of nearly all of the DES functionality being off-loaded to
the added hardware. As expected, T/A ratios for Triple-DES
were approximately 13 of the corresponding values for DES
because both algorithms require the same hardware in order
to be implemented using the instruction set extensions. The
T/A ratio for Triple-DES increased by a factor of 25.8 when
instruction set extensions are used, matching the increase ev-
idenced by DES. In the case of IDEA, the instruction set
extensions had a significant impact upon performance at a
reasonable hardware cost, with the measured T/A ratio in-
creasing by a factor of 5.9. For AES, the instruction set ex-
tensions used in conjunction with the column-oriented im-
plementations yield larger increases in throughput versus the
instruction set extensions used in conjunction with the row-
oriented implementations. As a result, the column-oriented
implementations yielded a greater increase in T/A ratio and
are superior to the row-oriented implementations when using
the proposed instruction set extensions.
7 Conclusions
Instruction set extensions for improving software im-
plementations of symmetric-key algorithms have been pro-
posed. Existing literature on the subject of enhancing the per-
formance of symmetric-key algorithms was discussed, fol-
lowed by detailed descriptions of the targeted processor and
the targeted cryptographic algorithms. Descriptions of the
custom instructions were given along with the functional
units that implement the underlying logical and arithmetic
operations. The results show that the proposed instructions
have a significant positive effect on program code size for
all of the targeted algorithms, shrinking the number of code
bytes by up to a factor of 31.2. Execution time for all algo-
rithms was also improved, with demonstrated speedups by
factors of up to 32.8. The instruction set extensions required
only a 63% increase in the logic utilization of the LEON2
processor on the chosen FPGA device while decreasing the
maximum clock frequency by approximately 10%. All of
the targeted algorithms evidenced an increase in T/A ratio,
increasing by a factor of up to 25.8. Finally, it was demon-
strated that column-oriented implementations of AES are
superior to row-oriented implementations for all evaluation
metrics when using the proposed instruction set extensions.
473
8 Acknowledgement
We would like to thank Stefan Tillich and Johann
Großchädl from the Graz University of Technology for their
useful discussions regarding their instruction set extensions
targeting the LEON2 processor.
References
[1] G. Bertoni, L. Breveglieri, P. Fragneto, M. Macchetti, and
S. Marchesin. Efficient Software Implementation of AES on
32-Bit Platforms. In B. S. K. Jr., Ç. K. Koç, and C. Paar,
editors, Workshop on Cryptographic Hardware and Embed-
ded Systems — CHES 2002, volume LNCS 2523, pages 159–
171, Redwood Shores, California, USA, August 13–15 2002.
Springer-Verlag.
[2] J. Beuchat. Modular Multiplication for FPGA Implemen-
tation of the IDEA Block Cipher. In Proceedings of the
Fourteenth IEEE International Conference on Application-
Specific Systems, Architectures and Processors — ASAP
2003, pages 412–422, The Hague, The Netherlands, June 24–
26 2003.
[3] E. Biham. A Fast New DES Implementation in Software.
In E. Biham, editor, Fourth International Workshop on Fast
Software Encryption, volume LNCS 1267, pages 260–272,
Haifa, Israel, January 20–22 1997. Springer-Verlag.
[4] J. Burke, J. McDonald, and T. M. Austin. Architectural Sup-
port for Fast Symmetric-Key Cryptography. In Proceedings
of the Ninth International Conference on Architectural Sup-
port for Programming Languages and Operating Systems —
AS-PLOS 2000, pages 178–189, Cambridge, Massachusetts,
USA, November 12–15 2000.
[5] F. Crowe, A. Daly, T. Kerins, and W. Marnane. Single-Chip
FPGA Implementation of a Cryptographic Co-processor. In
O. Diessel and J. Williams, editors, Proceedings of the
2004 IEEE International Conference on Field-Programmable
Technology — FPT 2004, pages 279–285, Brisbane, Aus-
tralia, December 6–8 2004.
[6] J. Daemen and V. Rijmen. The Design of Rijndael. Springer,
New York, New York, USA, 2002.
[7] A. J. Elbirt. Reconfigurable Computing for Symmetric-Key
Algorithms. PhD thesis, Worcester Polytechnic Institute,
Worcester, Massachusetts, USA, April 2002. Available at
http://faculty.uml.edu/aelbirt/thesis.pdf.
[8] A. J. Elbirt. Efficient Implementation of Galois Field Fixed
Field Constant Multiplication. In Proceedings of the Interna-
tional Conference on Information Technology: New Genera-
tion — ITNG ’06, pages 172–177, Las Vegas, Nevada, USA,
April 10–12 2006.
[9] A. J. Elbirt. Fast and Efficient Implementation of AES Via
Instruction Set Extensions. In Proceedings of the Third
IEEE International Symposium on Security in Networks and
Distributed Systems, pages 396–403, Niagara Falls, Canada,
May 21–23 2007.
[10] P. Ganesan, R. Venugopalan, P. Peddabachagari, A. Dean,
F. Mueller, and M. Sichitiu. Analyzing and Modeling Encryp-
tion Overhead for Sensor Network Nodes. In Proceedings of
the Second ACM International Conference on Wireless Sen-
sor Networks and Applications — WSNA ’03, pages 151–159,
San Diego, California, USA, September 19 2003.
[11] A. V. Garcia and J.-P. Seifert. On the Implementation of
the Advanced Encryption Standard on a Public-key Crypto-
Coprocessor. In Proceedings of the Fifth Smart Card Re-
search and Advanced Application Conference — CARDIS
’02, pages 135–146, San Jose, California, USA, Novem-
ber 21–22 2002.
[12] P. Gil. How Big is the Internet? World Wide Web
— http://netforbeginners.about.com/cs/technoglossary/f/
FAQ3.htm, 2005.
[13] M. Gschwind. Instruction Set Selection for ASIP Design.
In A. A. Jerraya, L. Lavagno, and F. Vahid, editors, Pro-
ceedings of the Seventh International Symposium on Hard-
ware/Software Codesign — CODES’99, pages 7–11, Rome,
Italy, March 1999.
 Base Code
Algorithm Throughput CLB Slices
DES 1.92 4563
Triple-DES 0.64 4563
IDEA 3.23 4563
AES-Columns 9.55 4563
AES-Rows 12.47 4563
Table 9. Throughput to area ratios
[14] J.-O. Haenni. Architecture EPIC et Jeux d’Instructions Mul-
timédias Pour Applications Cryptographiques. PhD thesis,
Swiss Federal Institute of Technology, Lausanne, Switzer-
land, 2002.
[15] A. Hodjat, D. D. Hwang, B. Lai, K. Tiri, and I. Ver-
bauwhede. A 3.84 GBits/s AES Crypto Coprocessor with
Modes of Operation in a 0.18-µm CMOS Technology. In
Proceedings of the Fifteenth ACM Great Lakes symposium on
VLSI — GLSVLSI ’05, pages 60–63, Chicago, Illinois, USA,
April 17–19 2005.
[16] 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 Com-
puters, volume 1, pages 488–492, Los Angeles, California,
USA, November 7–10 2004.
[17] J. Hughes. Implementation of NBS/DES Encryption Algo-
rithm in Software. In Colloquium on Techniques and Impli-
cations of Digital Privacy and Authentication Systems, 1981.
[18] J. Irwin and D. Page. Using Media Processors for Low-
Memory AES Implementation. In Proceedings of the
Fourteenth IEEE International Conference on Application-
Specific Systems, Architectures and Processors — ASAP
2003, pages 144–154, The Hague, The Netherlands, June 24–
26 2003.
[19] K. Küçükçakar. An ASIP Design Methodology for Embed-
ded Systems. In A. A. Jerraya, L. Lavagno, and F. Vahid,
editors, Proceedings of the Seventh International Symposium
on Hardware/Software Codesign — CODES’99, pages 17–
21, Rome, Italy, March 1999.
[20] P. Karn. DES Software Implementation.
http://http://www.citi.umich.edu/projects/apv/.
[21] H. W. Kim and S. Lee. Design and Implementation of a Pri-
vate and Public Key Crypto Processor and its Application to a
Security System. IEEE Transactions on Consumer Electron-
ics, 50(1):214–224, February 2004.
[22] X. Lai and J. Massey. A Proposal for a New Block Encryp-
tion Standard. In I. B. Damgård, editor, Advances in Cryptol-
ogy — EUROCRYPT ’90, volume LNCS 473, pages 389–404,
Berlin, Germany, May 1990. Springer-Verlag.
[23] R. B. Lee. Accelerating Multimedia with Enhanced Micro-
processors. IEEE Micro, 15(2):22–32, April 1995.
[24] R. B. Lee, Z. Shi, and X. Yang. Efficient Permutation Instruc-
tions for Fast Software Crytography. IEEE Micro, 21(6):56–
69, November/December 2001.
[25] H. Lipmaa. IDEA: A Cipher for Multimedia Architectures?
In S. Tavares and H. Meijer, editors, Fifth Annual Workshop
on Selected Areas in Cryptography, volume LNCS 1556,
Kingston, Ontario, Canada, August 1998. Springer-Verlag.
[26] O. Mencer, M. Morf, and M. J. Flynn. Hardware Soft-
ware Tri-Design of Encryption for Mobile Communication
Units. In Proceedings of International Conference on Acous-
tics, Speech, and Signal Processing, volume 5, pages 3045–
3048, Seattle, Washington, USA, May 1998.
[27] A. Michalski, K. Gaj, and D. A. Buell. High-Throughput
Reconfigurable Computing: A Design Study of an IDEA En-
cryption Cryptosystem on the SRC-6E Reconfigurable Com-
puter. In T. Rissa, S. J. E. Wilton, and P. H. W. Leong, editors,
Proceedings of the International Conference on Field Pro-
grammable Logic and Applications — FPL ’05, pages 681–
686, Tampere, Finland, August 24–26 2005.
[28] D. Oliva, R. Buchty, and N. Heintze. AES and the Cryptonite
Crypto Processor. In J. H. Moreno, P. K. Murthy, T. M. Conte,
and P. Faraboschi, editors, Proceedings of the 2003 Interna-
tional Conference on Compilers, Architecture and Synthesis
for Embedded Systems — CASES 2003, pages 198–209, San
Jose, California, USA, October 30-November 1 2003.
With ISEs With ISEs
T/A Ratio Throughput CLB Slices T/A Ratio
420.78 59.61 5543 10754.10
140.26 20.07 5543 3620.78
707.87 22.44 5411 4147.11
2092.92 28.89 5920 4880.07
2732.85 16.45 5920 2778.72
[29] D. A. Osvik. Efficient Implementation of the Data Encryption
Standard. PhD thesis, Universitatis Bergensis, April 2003.
[30] A. Pfitzmann and R. Assman. More Efficient Software Im-
plementations of (Generalized) DES. Computers & Security,
12(5):477–500, 1993.
[31] S. Ravi, A. Raghunathan, N. Potlapally, and M. Sankaradass.
System Design Methodologies for a Wireless Security Pro-
cessing Platform. In Proceedings of the 2002 Design Automa-
tion Conference — DAC 2002, pages 777–782, New Orleans,
Louisiana, USA, June 10–14 2002.
[32] S. Tillich and J. Großchädl. Accelerating AES Using In-
struction Set Extensions for Elliptic Curve Cryptography. In
O. Gervasi, M. L. Gavrilova, V. Kumar, A. Laganà, H. P. Lee,
Y. Mun, D. Taniar, and C. J. K. Tan, editors, International
Conference on Computational Science and Its Applications
— ICCSA 2005, volume LNCS 3481, pages 665–675, Singa-
pore, May 9–12 2005. Springer-Verlag.
[33] S. Tillich and J. Großchädl. Instruction Set Extensions
for Efficient AES Implementation on 32-bit Processors. In
L. Goubin and M. Matsui, editors, Workshop on Crypto-
graphic Hardware and Embedded Systems — CHES 2006,
volume LNCS 4249, pages 270–284, Yokohama, Japan, Oc-
tober 10–13 2006. Springer-Verlag.
[34] S. Tillich and J. Großchädl and A. Szekely. An Instruction
Set Extension for Fast and Memory-Efficient AES Implemen-
tation. In J. Dittmann, S. Katzenbeisser, and A. Uhl, editors,
Proceedings of the Ninth International Conference on Com-
munications and Multimedia Security — CMS 2005, volume
LNCS 3677, pages 11–21, Salzburg, Austria, September 19–
21 2005. Springer-Verlag.
[35] G. A. Sathishkumar and C. Prasanna. A Novel VLSI Archi-
tecture for an Integrated Crypto Processor. In Proceedings
of the 2005 Annual IEEE INDICON Conference, pages 272–
275, Chennai, India, December 11–13 2005.
[36] P. Schaumont, K. Sakiyama, A. Hodjat, and I. Verbauwhede.
Embedded Software Integration for Coarse-Grain Reconfig-
urable Systems. In Proceedings of the Eighteenth Inter-
national Parallel and Distributed Processing Symposium —
IPDPS 2004, pages 137–142, Santa Fe, New Mexico, USA,
April 26–30 2004.
[37] B. Schneier. Applied Cryptography. John Wiley & Sons Inc.,
New York, New York, USA, 2nd edition, 1996.
[38] Z. Shi and R. B. Lee. Bit Permutation Instructions for
Accelerating Software Cryptography. In Proceedings of
the Eleventh IEEE International Conference on Application-
Specific Systems, Architectures and Processors — ASAP
2000, pages 138–148, 2000.
[39] A. Wang, E. Killian, D. E. Maydan, and C. Rowen. Hard-
ware/Software Instruction Set Configurability for System-
On-Chip Processors. In Proceedings of the 38th Design Au-
tomation Conference — DAC 2001, pages 184–188, Las Ve-
gas, Nevada, USA, June 18–22 2001.
[40] L. Wu, C. Weaver, and T. Austin. CryptoManiac: A Fast Flex-
ible Architecture for Secure Communication. In B. Werner,
editor, Proceedings of the 28th Annual International Sympo-
sium on Computer Architecture — ISCA-2001, pages 110–
119, Goteborg, Sweden, June 30–July 4 2001.
[41] R. Zimmermann. Efficient VLSI Implementation of Modulo
(2n ±1) Addition and Multiplication. Technical report, Swiss
Federal Institute of Technology (ETH), Zurich, Switzerland,
1999. http://www.stud.ee.ethz.ch/ zimmi/publications/ mod-
ulo arith.ps.gz.
474