Implementations of hash functions in Atmel AVR devices.
(see also our block ciphers project)
Please refer to the following companion paper whenever
you use the source codes:
Josep Balasch, Baris Ege, Thomas Eisenbarth, Benoit Gérard, Zheng Gong, Tim Güneysu,
Stefan Heyse, Stéphanie Kerckhof, François Koeune, Thomas Plos, Thomas Pöppelmann,
Francesco Regazzoni, François-Xavier Standaert, Gilles Van Assche, Ronny Van Keer,
Loïc van Oldeneel tot Oldenzeel, Ingo von Maurich,
Compact Implementation and Performance Evaluation of Hash Functions in ATtiny Devices,
to appear in the proceedings of CARDIS 2012, Lecture Notes in Computer Science,
vol xxxx, pp yyy-zzz, Graz, Austria, November 2012,
(pdf file).
Hash functions that are efficiently implemented in low cost embedded
devices are important components for securing new applications
in ubiquitous computing. This page reports on the performance
evaluation of standard and emerging hash functions, in the Atmel AVR
Attiny45 8-bit RISC microcontroller.
In order to increase the transparency
of the evaluation, we make all source codes used in the evaluations
available under an open source license. The performance indicators
chosen are: code size (rom and ram), and cycle count when hashing 8-byte, 50-byte,
100-byte and 500-byte messages.
All implementations are provided as a single file and contain three routines (init, update and final),
that can be used by the following common interface.
The performance evaluations of the different hash functions (i.e. init + update + final) are given below. Note that for certain
(e.g. sponge-based) functions, the data part of the RAM could be arbitrarily reduced by changing the interface
(in which case, this part of the memory is reported in grey).
Some additional results (for variants of the main versions investigated) are also given in the fourth part of the table.
Remark. For lightweight hash functions, different versions of the algorithms are provided (aiming for 256-bit and 160-bit hashes
with "flat security", i.e. n/2-bit preimage security, second preimage security and collision resistance).
Despite the similar names, these versions correspond to different specifications (hence I/O behavior). For example,
the lightweight versions of Keccak are not the same as the standard one.
In order to avoid confusion we refer to them as Keccak and (small) Keccak. The same comment holds for (small) Skein-256-256
which is given in the additional results table.
Standard hash functions and SHA3 candidates.
Hash function
Digest size [bits]
Code size [bytes]
RAM data [bytes]
RAM state and others [bytes]
RAM stack
Cycle count (8-byte message)
Cycle count (50-byte message)
Cycle count (100-byte message)
Cycle count (500-byte message)
SHA256
256
1090
64
73
6
33 600
33 600
66 815
266 105
BLAKE-256
256
1166
64
120
9
35 714
35 714
70 808
281 372
Groestl-256
256
1400
64
128
9
61 007
61 049
101 279
342 759
JH-256
256
1020
64
162
8
524 602
524 518
785 510
2 531 262
Keccak[r=1088,c=512]*
256
868
136
240
4
178 022
178 022
179 494
716 483
Skein-512-256
256
988
64
160
8
532 346
532 388
798 290
2 393 802
* benchmarked on the AtTiny85 because the read-only input buffer did not fit in the ATtiny45
and our interface did not allow that the message could be directly XORed into the state, hence resulting in an excessive RAM for the AtTiny45.