Future Challenges for Lightweight Cryptography F.-X. Standaert UCL Crypto Group Crypto for 2020, Tenerife, January 2013
Outline 1 1. Past results 2. Future challenges
1. Block ciphers 2 • TEA, NOEKEON, AES, SERPENT, ICEBERG, HIGHT, mCrypton, SEA, PRESENT, KATAN, MIBS, LED, Piccolo, Lblock, KLEIN, PRINCE, …
1. Block ciphers 2 • TEA, NOEKEON, AES, SERPENT, ICEBERG, HIGHT, mCrypton, SEA, PRESENT, KATAN, MIBS, LED, Piccolo, Lblock , KLEIN, PRINCE, … • Mostly developed independently (1994-2012)
1. Block ciphers 2 • TEA, NOEKEON, AES, SERPENT, ICEBERG, HIGHT, mCrypton, SEA, PRESENT, KATAN, MIBS, LED, Piccolo, Lblock, KLEIN, PRINCE, … • Mostly developed independently (1994-2012) • Existing implementations in different technologies • Few comparative studies • Lack of standardization / competition?
Comparison issue 3 • Evaluation criteria are usually relative … … and reflect algorithmic and implementation choices
Comparison issue 3 • Evaluation criteria are usually relative … … and reflect algorithmic and implementation choices • But some of them reflect the algorithms better
Comparison issue 4 • Evaluation criteria are usually relative … … and reflect algorithmic and implementation choices • But some of them reflect the algorithms better • More parameters fixed => easier interpretation • Comparisons also depend on the designer’s skills… => Next: various ECRYPT examples
1.1. Block ciphers in software 5 • e.g. lightweight platform: ATMEL AtTiny45 • 8-bit RISC • 4kB flash memory, 256 bytes RAM • Direct and indirect addressing • 120 instructions (no multiplier) • 2-stage pipeline • Typically 1 cycle per instruction
1.1. Block ciphers in software 5 • e.g. lightweight platform: ATMEL AtTiny45 • 8-bit RISC • 4kB flash memory, 256 bytes RAM • Direct and indirect addressing • 120 instructions (no multiplier) • 2-stage pipeline • Typically 1 cycle per instruction • Assembly language • Easy to read • Minimize code size and RAM ( up to some extent! ) • Encryption & decryption, on-the-fly key scheduling • Common interface for all designers
Code size 6
Code size 6 HW-oriented ciphers are bigger
Code size 6 As well as “standard” ones (but not that much)
Cycle count 7
Cycle count 7 Iteration of many simple functions is slower
RAM 8
RAM 8 Precomputed key-scheduling
RAM 8 Mostly reflects state size
Combined metric 9
Combined metric 9 No huge differences for most ciphers (factor<5)
Combined metric 9 AES behaves pretty good!
Lessons learned 10 • Software comparisons relatively easy to interpret • Because hardware is fixed • (limited code size vs. cycle count tradeoff)
Lessons learned 10 • Software comparisons relatively easy to interpret • Because hardware is fixed • (limited code size vs. cycle count tradeoff) • Lightweight ciphers vs. AES • Gain in code size is possible • At the cost of higher cycle counts • RAM use essentially reflects state/key size
Lessons learned 10 • Software comparisons relatively easy to interpret • Because hardware is fixed • (limited code size vs. cycle count tradeoff) • Lightweight ciphers vs. AES • Gain in code size is possible • At the cost of higher cycle counts • RAM use essentially reflects state/key size • BTW, all codes are open source: http://perso.uclouvain.be/fstandae/source_codes/lightweight_ciphers/
1.2. Block ciphers in hardware 11 • Hardware (instructions) not fixed • Criteria more reflective of HW design choices
1.2. Block ciphers in hardware 11 • Hardware (instructions) not fixed • Criteria more reflective of HW design choices • Yet, their relevance to algorithm may differ
Case study: min. energy architectures 12 • Low-power 65nm CMOS • Two target frequencies: f max and f 100 • Metrics: area, delay, power, energy, throughput
Case study: min. energy architectures 12 • Low-power 65nm CMOS • Two target frequencies: f max and f 100 • Metrics: area, delay, power, energy, throughput • Flexible architecture • 3 core options (Enc, Dec, Enc/Dec) • Unrolling parameter Nr rounds per cycle
13 ?
13 ? 12
14 ? 12
14 ? 12
15 ? 12
15 ? 12
16 ? 12
16 ? 12
17 ? 12
Lessons learned 18 • Normalized metrics more illustrative • Energy (integrated over time) • Throughput/area
Lessons learned 18 • Normalized metrics more illustrative • Energy (integrated over time) • Throughput/area • Most significant differences between algorithms depend on the key scheduling and E/D combination
Lessons learned 18 • Normalized metrics more illustrative • Energy (integrated over time) • Throughput/area • Most significant differences between algorithms depend on the key scheduling and E/D combination • When using the same gate count / delay per cycle, all algorithms end up with similar cycle count • Suggests « complexity limit » for secure ciphers
Lessons learned 18 • Normalized metrics more illustrative • Energy (integrated over time) • Throughput/area • Most significant differences between algorithms depend on the key scheduling and E/D combination • When using the same gate count / delay per cycle, all algorithms end up with similar cycle count • Suggests « complexity limit » for secure ciphers • AES again behaves pretty good
1.3. Technology scaling 19 • Between and within technologies (freq vs. Vdd)
65nm case study 20 • How relevant are algorithmic changes?
Conclusion 21 • For most applications, AES is probably good enough
Conclusion 21 • For most applications, AES is probably good enough • If a lightweight cipher is needed (for gate count, area), existing candidates are probably good enough
Conclusion 21 • For most applications, AES is probably good enough • If a lightweight cipher is needed (for gate count, area), existing candidates are probably good enough • Changing algorithms is expensive and its impact on performances may be limited (yet, non negligible) compared to the one of technology scaling
Conclusion 21 • For most applications, AES is probably good enough • If a lightweight cipher is needed (for gate count, area), existing candidates are probably good enough • Changing algorithms is expensive and its impact on performances may br limited (yet, non negligible) compared to the one of technology scaling • Does not mean we de not need new ciphers • Rather that new ciphers should bring new perspectives (design techniques, properties, …)
Outline 22 1. Past results 2. Future challenges
Q1. Hash functions in software? 23 • Similar case study as for block ciphers • Atmel AVR AtTiny45 benchmarking • Again open source: • http://perso.uclouvain.be/fstandae/source_codes/hash_atmel/
RAM 24 * * * * * * * * *
Cycle count 25
Combined metric 26
Open problem 27 • Much larger differences than for block ciphers • More differences in state sizes • e.g. Keccak has a 1600-bit state • More tradeoffs available (e.g. for sponges) • More versatility in designs • Larger security margins?
Open problem 27 • Much larger differences than for block ciphers • More differences in state sizes • e.g. Keccak has a 1600-bit state • More tradeoffs available (e.g. for sponges) • More versatility in designs • Larger security margins? • What is the best approach for lightweight hash functions?
Q2. Hash functions in hardware 28 • Reference point: AES in hardware ( cfr. Stefan Mangard’s talk at the AES day in Bruges ) • Extremely clear tradeoffs • For 8-bit, 32-bit, 64-bit and 128-bit designs • Most likely well optimized
Q2. Hash functions in hardware 28 • Reference point: AES in hardware ( cfr. Stefan Mangard’s talk at the AES day in Bruges ) • Extremely clear tradeoffs • For 8-bit, 32-bit, 64-bit and 128-bit designs • Most likely well optimized • Implementations of SHA3 candidates (and Keccak) • More results on high-speed than low-cost
Q2. Hash functions in hardware 28 • Reference point: AES in hardware ( cfr. Stefan Mangard’s talk at the AES day in Bruges ) • Extremely clear tradeoffs • For 8-bit, 32-bit, 64-bit and 128-bit designs • Most likely well optimized • Implementations of SHA3 candidates (and Keccak) • More results on high-speed than low-cost More research needed in this direction • compact Keccak implementations seem non trivial • e.g. Kerckhof et al., Kaps et al. ( CARDIS, INDOCRYPT 2012 )
Q3. Block cipher design 29
Q3. Block cipher design 29 • How to design a key scheduling? • Sometimes as complex as rounds • KHAZAD, ICEBERG, SEA • Sometimes as simple as XORing the master key • NOEKEON, LED • Relations with recent works on Even-Mansour • Bogdanov et al., Dunkelman et al. ( EUROCRYPT 2012 )
Recommend
More recommend
