size. This results in a 128-bit digest, too small to be
considered secure against simple brute-force attacks.
In (Bos et al., 2011) several techniques to increase
this digest are proposed, some of them we are cur-
rently evaluating on the sensor node. Using an AES-
based hash would allow the usage of the existing AES
co-processor on the node, in this way hopefully mit-
igating the additional complexity required to extend
the digest size.
2.4 SHA-3
The 6-year long competition to find the new standard
hash algorithm SHA-3 is expected to be finished by
the end of 2012. Currently, there are five finalists left:
BLAKE (Jean-Philippe Aumasson and Luca Henzen
and Willi Meier Raphael C.-W. Phan, 2010), Grøstl
(Gauravaram,P. and Knudsen, L. R. and Matusiewicz,
K. and Mendel, F. and Rechberger, C. and Schlffer,
M. and and Thomsen, S. S., 2011), JH (Wu, H., 2011),
Keccak (Bertoni, G. and Daemen, J. and Peeters, M.
and Assche, G. v., 2011), and Skein (Ferguson, N. and
Lucks, S. and Whiting, B. S. D. and Bellare, M. and
Kohno, T. and Walker, J. C. J., 2008). All of these
functions have a digest size of at least 224 bits.
We chose Grøstl as an example candidate for a
first comparison, although an evaluation of the re-
maining 4 candidates is also planned. Grøstl operates
on a 64-byte input, producing a 256 or 512-bit mes-
sage digest. Internally, it’s structure is very similar to
AES, even using the same S-Box as defined for Rijn-
dael, and also using similar approaches operating on
a two-dimensional state. The individual round opera-
tions are repeated 10 or 14 times, for 256 or 512 bit
digest size, respectively.
3 IMPLEMENTATION AND
PRELIMINARY RESULTS
Tiger, SHA-1 and Grøstl-256 were implemented
on a Texas Instruments Zig-Bee compliant CC2530
Sensornode, featuring an 8051 microcontroller core
clocked at 32MHz. As compiler, the IAR C compiler
for 8051, version 8.10.1, was used.
As a first test, no assembler optimizations were
performed, the code was entirely written in C.
In the case of SHA-1, the reference implementa-
tion given in RFC3174 (Eastlake, D. and Jones, P.,
2001) was slightly modified, some functions were ex-
changed by macros for better speed.
Tiger was entirely ported to 32-bit datatypes that
are supported in IAR declaring them as long long.
All basic operation on the 64-bit values from the the
Tiger reference implementations were rewritten to op-
erations on 32-bit datatypes. We also performed an
additional split and tried to use 16-bit datataypes in-
stead, but due to the resulting increase in codesize, the
16-bit version ran slower then the 32-bit one.
For Grøstl we also used the reference implementa-
tion from the project homepage. Again, slight modifi-
cations were performed to adapt the code to the 8051
platform.
We then used the Tiger reference test vectors as
input to all three hash-functionsand timed the number
of cycles needed for processing a single block (that
is, 64 Bytes or 512 Bits, respectively, for all hash-
functions analyzed). Table 1 gives an overview of our
results, while Table 2 compares the code sizes for the
three implementations.
Our results show that, barring any optimizations
but the most obvious ones, even a hash-function de-
signed for 64-bit machines like Tiger can achieve
acceptable performance on an 8051 microcontroller.
The bad results for Grøstl are surprising yet will be
optimized during the next steps, at least on an AT-
mega163 Grøstl has already been shown to perform
very favorably. Again, our focus in this first round
was only on a comparison of unoptimized versions of
the algorithms, ported straightforward from the refer-
ence implementations.
Table 1: Number of cycles per 64-byte input block.
Hash cycles/block
Tiger 193,944
SHA-1 561,589
Grøstl-256 2,813,496
Table 2: Code size after compilation , optimized for speed.
Hash Code Size in kB
Tiger 85.332
SHA-1 58.936
Grøstl-256 89.880
4 OUTLOOK
We performed a preliminary performance analysis of
three hash functions from different domains (one de-
signed for 64-bit machines, the current standard, and
one SHA-3 finalist) on a TI CC2530 sensor node, us-
ing an 8051 microcontroller. Our main goal was to
answer the question whether a more or less arbitrarily
selected, secure cryptographic hash-function can be
implemented on a sensor node, heavily constrained
in terms of available memory and processing power,
HashAlgorithmsfor8051-basedSensornodes
67