Future Challenges for Lightweight Cryptography F.-X. Standaert UCL - - PowerPoint PPT Presentation

▶
future challenges for lightweight cryptography
SMART_READER_LITE
LIVE PREVIEW

Future Challenges for Lightweight Cryptography F.-X. Standaert UCL - - PowerPoint PPT Presentation

Jan 23, 2023 162 likes •851 views

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,

slide-1
SLIDE 1

Future Challenges for Lightweight Cryptography

F.-X. Standaert UCL Crypto Group Crypto for 2020, Tenerife, January 2013

slide-2
SLIDE 2

Outline 1

  • 1. Past results
  • 2. Future challenges
slide-3
SLIDE 3
  • 1. Block ciphers

2

  • TEA, NOEKEON, AES, SERPENT, ICEBERG,

HIGHT, mCrypton, SEA, PRESENT, KATAN, MIBS, LED, Piccolo, Lblock, KLEIN, PRINCE, …

slide-4
SLIDE 4
  • 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)
slide-5
SLIDE 5
  • 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?
slide-6
SLIDE 6

Comparison issue 3

  • Evaluation criteria are usually relative …

… and reflect algorithmic and implementation choices

slide-7
SLIDE 7

Comparison issue 3

  • Evaluation criteria are usually relative …

… and reflect algorithmic and implementation choices

  • But some of them reflect the algorithms better
slide-8
SLIDE 8

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

slide-9
SLIDE 9

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
slide-10
SLIDE 10

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
slide-11
SLIDE 11

Code size 6

slide-12
SLIDE 12

Code size 6

HW-oriented ciphers are bigger

slide-13
SLIDE 13

Code size 6

As well as “standard” ones (but not that much)

slide-14
SLIDE 14

Cycle count 7

slide-15
SLIDE 15

Cycle count 7

Iteration of many simple functions is slower

slide-16
SLIDE 16

RAM 8

slide-17
SLIDE 17

RAM 8

Precomputed key-scheduling

slide-18
SLIDE 18

RAM 8

Mostly reflects state size

slide-19
SLIDE 19

Combined metric 9

slide-20
SLIDE 20

Combined metric 9

No huge differences for most ciphers (factor<5)

slide-21
SLIDE 21

Combined metric 9

AES behaves pretty good!

slide-22
SLIDE 22

Lessons learned 10

  • Software comparisons relatively easy to interpret
  • Because hardware is fixed
  • (limited code size vs. cycle count tradeoff)
slide-23
SLIDE 23

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
slide-24
SLIDE 24

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/

slide-25
SLIDE 25

1.2. Block ciphers in hardware 11

  • Hardware (instructions) not fixed
  • Criteria more reflective of HW design choices
slide-26
SLIDE 26

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
slide-27
SLIDE 27

Case study: min. energy architectures 12

  • Low-power 65nm CMOS
  • Two target frequencies: fmax and f100
  • Metrics: area, delay, power, energy, throughput
slide-28
SLIDE 28

Case study: min. energy architectures 12

  • Low-power 65nm CMOS
  • Two target frequencies: fmax and f100
  • Metrics: area, delay, power, energy, throughput
  • Flexible architecture
  • 3 core options (Enc, Dec, Enc/Dec)
  • Unrolling parameter Nr rounds per cycle
slide-29
SLIDE 29

? 13

slide-30
SLIDE 30

? 12 13

slide-31
SLIDE 31

? 12 14

slide-32
SLIDE 32

? 12 14

slide-33
SLIDE 33

? 12 15

slide-34
SLIDE 34

? 12 15

slide-35
SLIDE 35

? 12 16

slide-36
SLIDE 36

? 12 16

slide-37
SLIDE 37

? 12 17

slide-38
SLIDE 38

Lessons learned 18

  • Normalized metrics more illustrative
  • Energy (integrated over time)
  • Throughput/area
slide-39
SLIDE 39

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

slide-40
SLIDE 40

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
slide-41
SLIDE 41

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
slide-42
SLIDE 42

1.3. Technology scaling

19

  • Between and within technologies (freq vs. Vdd)
slide-43
SLIDE 43

65nm case study 20

  • How relevant are algorithmic changes?
slide-44
SLIDE 44

Conclusion 21

  • For most applications, AES is probably good enough
slide-45
SLIDE 45

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

slide-46
SLIDE 46

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
  • n performances may be limited (yet, non negligible)

compared to the one of technology scaling

slide-47
SLIDE 47

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
  • n 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, …)

slide-48
SLIDE 48

Outline 22

  • 1. Past results
  • 2. Future challenges
slide-49
SLIDE 49
  • 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/
slide-50
SLIDE 50

RAM 24

* * * * * * * * *

slide-51
SLIDE 51

Cycle count 25

slide-52
SLIDE 52

Combined metric 26

slide-53
SLIDE 53

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?
slide-54
SLIDE 54

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?
slide-55
SLIDE 55
  • 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
slide-56
SLIDE 56
  • 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
slide-57
SLIDE 57
  • 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)
slide-58
SLIDE 58
  • Q3. Block cipher design

29

slide-59
SLIDE 59
  • 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)
slide-60
SLIDE 60
  • 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)
  • And how to combine encryption & decryption?
  • Useful for bus encryption (low latency)
  • PRINCE block cipher (ASIACRYPT 2012)
slide-61
SLIDE 61
  • Q4. New features for block ciphers

30

  • Authenticated encryption
  • DIAC workshop (Stockholm, 2012)
  • Competition?
slide-62
SLIDE 62
  • Q4. New features for block ciphers

30

  • Authenticated encryption
  • DIAC workshop (Stockholm, 2012)
  • Competition?
  • Side-channel resistance
  • e.g. PICARO block cipher (ACNS 2012)
  • May give rise to “asymptotic”performance gains
  • (since implementation complexity increases with

physical security, e.g. at least quadratically for masking)

slide-63
SLIDE 63
  • Q4. New features for block ciphers

30

  • Authenticated encryption
  • DIAC workshop (Stockholm, 2012)
  • Competition?
  • Side-channel resistance
  • e.g. PICARO block cipher (ACNS 2012)
  • May give rise to “asymptotic”performance gains
  • (since implementation complexity increases with

physical security, e.g. at least quadratically for masking)

  • Others…
slide-64
SLIDE 64

By 2020 31

?

slide-65
SLIDE 65

THANKS

http://perso.uclouvain.be/fstandae/

slide-66
SLIDE 66

?

slide-67
SLIDE 67

?

Observation: Excepted for extremely simple rounds

slide-68
SLIDE 68

Code size ?