The lightweight block ciphers zoo

The Lightweight Block Ciphers Zoo
Nathan Keller
Bar Ilan University
Lightweight Crypto Day, Haifa University, 2.2.2014
Talk outline
• Block ciphers in general – definition and some
history
• DES (and Feistel constructions in general)
• AES (and SP networks in general)
• Attacks on AES (related-key, side channel)
• Lightweight crypto in general
•
•
•
•
The target applications (RFID tags, WSNs)
Why block ciphers and not stream ciphers?
Design criteria
Hardware vs. Software efficiency
Talk outline (cont.)
• The lightweight block ciphers (LBC) zoo
• The ciphers (divided to groups)
• Specific examples (Present, Piccolo, Ktantan)
• Special features in LBC design
• Key schedule (simplicity, on-the-fly computation)
• Decryption (is possible or not, involution structures)
• Simple operations
Talk outline (cont.)
• Theoretical foundations
• Generalized Even-Mansour constructions
• Different security models ?!
• Cryptanalysis
• Are the attacks on lightweight block ciphers different?
History
• See auxiliary presentation.
Lightweight Crypto in General
• What are the target platforms?
• Radio-frequency identification (RFID) is the wireless
non-contact use of radio-frequency electromagnetic
fields to transfer data, for the purposes of
automatically identifying and tracking tags attached to
objects.
• A wireless sensor network (WSN) of spatially
distributed autonomous sensors to monitor physical or
environmental conditions, such as temperature,
sound, pressure, etc. and to cooperatively pass their
data through the network to a main location.
• Various other platforms.
Why block ciphers?
• Security – it is believed that our understanding
in block cipher design is better than in stream
cipher design.
• Various modes of operations possible (e.g., can
act as a stream cipher in the CBC mode).
• Other reasons.
Design criteria
• Speed (a.k.a throughput, or cycle count)
• A single block or many blocks?
• Memory consumption (SW)
• ROM use (usually between 300 to 2000 bytes).
• RAM use (a few dozens of bytes).
• Area consumption (HW)
• Measured in Gate Equivalents, between 500-3000.
• Energy consumption
Hardware/Software efficiency
• Some of the ciphers are especially optimized for
hardware/software, while others try to achieve
good performance on both platforms.
• Comparative studies show that they are quite
inherent tradeoffs between software and
hardware efficiency.
• So, should we try to optimize both in the same
primitive, or different primitives for hardware
and software are better?
The lightweight block ciphers Zoo
• SP networks:
• AES (various lightweight implementations).
• mCrypton [Lim05] (lightweight version of Crypton).
• Present [Bogdanov+07] (the most well-known one,
accepted as an ISO standard).
• PrintCipher [Knudsen+10] (Uses the ability to “print”
the circuit on the RFID tag, 3*3 S-boxes).
• Klein [Gong+11] (similar to Present, more effective).
• LED [Guo+11] (Hardware oriented, no key schedule).
• Prince [Borghoff+12] (involution structure, no claims
against related-key attacks, similar to Present).
• Zorro [Gerard+13] (designed to resist side-channel
attacks, similar to LED but less S-boxes).
The lightweight block ciphers Zoo
• Feistel (or generalized Feistel) constructions:
• TEA, XTEA [Needham+94] (Very simple code, no Sboxes, the same key used each round. TEA was
vulnerable to related-key attacks, fixed in XTEA).
• DESL,DESXL [Poschmann06] (A variant of DES, using
the same S-box in all places. In DESXL, independent
keys are XORed before and after encryption).
• SEA [Standaert+05] (variable block/key size).
• Hight [Hong+06] (8-branch Feistel-II).
• MIBS [Izadi+09] (Similar to Camellia).
• Piccolo [Shibutani+11] (4-branch Feistel-II, with a byte
transformation after each round).
The lightweight block ciphers Zoo
• Feistel (or generalized Feistel) constructions:
• LBlock [Wu+11] (4-bit S-boxes and wiring).
• Twine [Suzaki+12] (16-branch Feistel-II, similar to
LBlock).
• Stream-cipher like constructions:
• KATAN, KTANTAN [deCanniere+09] (Based on two
NLFSRs that influence each other. The full state after
many steps is the ciphertext. In KTANTAN, the key is
burnt into the device).
Specific examples
• SP network
• Present
• Feistel construction
• Piccolo (see auxiliary presentation)
• Stream-cipher like construction
• KTANTAN
Special features in LBC design
• Simple operations and small S-boxes
• In many of the target devices, only simple operations
are supported (e.g., not multiplication).
• As a result, most of the designs are based on modular
additions, rotations and xors (except for S-boxes).
• The S-boxes are small (4*4 or even 3*3).
• Very simple key schedule
• Allows on-the-fly computation, including the
decryption direction (as opposed to IDEA).
• The key schedule is mostly linear, and in some of the
ciphers (LED, Zorro, CGEN, PrintCipher, Prince) is
absent at all!
Special features in LBC design
• Decryption
• Some of the ciphers (e.g., Present) prefer to not allow
decryption, in order to save space on the device.
• If decryption is allowed, there is a try to make it as
similar to encryption as possible:
• Feistel constructions
• Involutional elements (ranging from S-boxes to the entire
cipher, like in Iceberg, SEA, Prince).
• Re-using of components
• In order to save space, there is a try to re-use
components:
• The same S-box is used for all purposes.
• Key generation uses the same procedure as encryption.
Theoretical foundations
• Due to the simplicity of the key schedule, some
of the lightweight block ciphers can be viewed as
a special case of the Generalized Even-Mansour
construction.
• This allows to achieve security bounds (under
some assumptions, of course  ).
• Very extensive research in the last three years.
Theoretical foundations
• Attack model issues
• Several of the lightweight designs base their
security claims on the anticipated threats in
lightweight environment:
• The amount of available data is limited.
• Related-key attacks are not considered a threat.
• Is this a good practice?
Cryptanalysis
• Are the attacks on LBC similar to the attacks on
classical block ciphers?
• In general, yes. In particular, almost no proposal
was broken. But there are a few differences:
• In LBC, the complexities are lower (e.g., 80-bit keys), so
we are closer to being practical.
• The simple key schedules lead to new kinds of attacks,
which weren’t relevant in classical ciphers.
Thanks for your attention
• This was just the appetizer, all the real stuff will
be in the next talks (and was in Roberto’s talk, of
course  )