Hash Functions: Part 2 Macs & Authenticated Ciphers Required Reading

Home , CRYPTREC, NESSIE, Skein (hash function), UMAC

ECE 646 Lecture 11

Hash functions: Part 2 MACs & Authenticated Ciphers Required Reading

W. Stallings, "Cryptography and Network-Security,”

Chapter 11 Cryptographic Hash Functions

Recommended Reading

SHA-3 Project https://csrc.nist.gov/projects/hash-functions/sha-3-project Hash functions Applications (1) 1. Digital Signatures

Advantages 1. Shorter signature 2. Much faster computations 3. Larger resistance to manipulation (one block instead of several blocks of signature) 4. Resistance to the multiplicative attacks

5. Avoids problems with different sizes of the sender and the receiver moduli Hash functions Applications (2)

2. Fingerprint of a program or a document (e.g., to detect a modification by a virus or an intruder)

program

hash safe place ? fingerprint = original_fingerprint Hash functions Applications (3) 3. Storing passwords

Instead of: password ID, password

hash System stores:

ID, hash(password) hash(password) UNIX password scheme “00000000” password DES salt

ID, salt, password DES salt hash(password, salt) . . . . salt modifies the password DES salt expansion function E of DES hash(password, salt) Hash functions Applications (4) 4. Fast encryption

PRNG

mi ci

k0 = hash(KAB || IV ) k0 = hash(KAB || IV) k1 = hash(KAB || k0) or k1 = hash(KAB || c0) ......

kn = hash(KAB || kn-1) kn = hash(KAB || cn-1) General scheme for constructing a secure hash function Message m

Padding, appending bit length, M

M1 M2 . . . Mt

h(m) H0 H1 H2 Ht IV f f . . . g

compression output function transformation Merkle-Damgard Construction Parameters of the Merkle-Damgard Scheme

Compression Mi function r In SHA-1 n=160 n n r=512 Hi-1 f Hi In SHA-256 n=256 Entire hash r=512

H0 = IV In SHA-512 H = f(H , M ) n=512 i i-1 i r=1024 h(m) = g(Ht) Hash padding – SHA-1 & SHA-256 64-bits

message 100000000000 length

length of the entire message in bits

All zero padding: Correct padding: X X X 0 0 0 0 0 X X X 0 0 1 0 0 X X X 0 0 0 0 0 X X X 1 0 0 0 0 Hash padding – SHA-3 Candidates

BLAKE256D 1000 . . . 0001 len64 Grøstl D 1000 . . . 0000 #blocks JH42D 1000 . . . 0001 len128 Keccak D 1000 . . . 0001 Skein D 0000 . . . 0000 SHA−2 (256) D 1000 . . . 0000 len64 Minimum D Data M Padding P Padding C Counter SHA-512 N 1024 bits 128 bits L bits

Message 1000000 . . . 0 L

1024 bits 1024 bits 1024 bits M1 M2 MN

F F F

+ + +

IV = H0 H1 H2 HN hash code 512 bits 512 bits 512 bits

+ = word-by-word addition mod 264

Figure 11.9 Message Digest Generation Using SHA-512

Mi Hi–1

message schedule 64 a b c d e f g h W K 0 Round 0 0

a b c d e f g h W K t Round t t SHA-512

a b c d e f g h W K 79 Round 79 79

+ + + + + + + +

Figure 11.10 SHA-512 Processing of a Single 1024-Bit Block

SHA-512 Round

a b c d e f g h

Maj Ch +

+ + Wt

+ + Kt +

a b c d e f g h

512 bits

Figure 11.11 Elementary SHA-512 Operation (single round)

SHA-512 Message Scheduling

1024 bits W0 W1 W9 W14 Wt–16 Wt–15 Wt–7 Wt–2 W63 W65 W71 W76

0 1 0 1 0 1

+ + +

W0 W1 W15 W16 Wt W79

64 bits

Figure 11.12 Creation of 80-word Input Sequence for SHA-512 Processing of Single Block

Sponge Construction b b rc rc 0r 0c rc r c P0 0 Z0

f f

c P1 0 Z1 Sponge f Scheme s (b) Squeezing phase c P2 0

c Pk–1 0

(a) Absorbing phase

Figure 11.15 Sponge Construction

theta step

rho step rot(x, y)

Round 0 chi step

iota step RC[0]

SHA-3

theta step

rho step rot(x, y)

Round 23 chi step

iota step RC[23]

Figure 11.17 SHA-3 Iteration Function f

Parameters of new hash functions Features affecting security and functionality

SHA-1 SHA-256 SHA-384 SHA-512

Size of hash 160 256 384 512 value Complexity of 280 2128 2192 2256 the birthday attack Equivalently secure Skipjack AES-128 AES-192 AES-256 secret-key cipher Message size < 264 < 264 < 2128 < 2128 Parameters of new hash functions Features affecting implementation speed

SHA-1 SHA-256 SHA-384 SHA-512

Message block 512 512 1024 1024 size Number of 80 64 80 80 digest rounds Hardware implementations Conceptual comparison Speed

SHA-512, SHA-384

SHA-256

SHA-1 Area Results of the prototype FPGA implementation GMU, 2002 Speed in hardware [Mbit/s] 700 616 600 462 500 400 300 200 100 0 SHA-1 SHA-512 Complexity of the best attack 280 2256 the same as Skipjack AES-256 Hash functions 20 years ago Present U.S. Government standards: U.S. Government standards:

SHA-1 SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 Other popular hash functions: SHA-3

MD5, RIPEMD Other popular hash functions:

Security status: Whirlpool – winner of NESSIE

MD4 broken (1995) Security status: SHA-1 replaced SHA-0 (1995) MD5 partially broken MD5 broken (1 hr on PC) (collisions in compression SHA-0 broken function, 1996) RIPEMD broken (without a need for computer) SHA-1 practically broken, best attack – 263 operations – only 128 x more than breaking DES Hash functions Timeline

U.S. Government standards: II. 2003 SHA-1 FIPS 180 FIPS 180-2 SHA-256, 384, 512 FIPS 180-2 SHA-224 FIPS 180-2 II. 2004 Contests: I. 2000 XII. 2002 SHA-256, SHA-384, SHA-512, NESSIE Whirlpool

VIII. 2004 Attacks: broken: MD5 – collisions VIII. 1998 MD4, MD5, SHA-0, for compression SHA-0 – attack RIPEMD with 261 operations function, II-VIII. 2005 10 hrs on PC attack on SHA-1 269®263 operations

1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 Authentication Alice Bob Message MAC Message MAC

K KAB Secret key AB Secret key algorithm algorithm Secret key Secret key of Alice and Bob of Alice and Bob MAC’

yes no MAC MAC - Message Autentication Codes (keyed hash functions)

arbitrary length m message secret key K MAC function

MAC

fixed length MAC functions Basic requirements

1. Public description, SECRET key parameter

2. Compression arbitrary length input ® fixed length output

3. Ease of computation MAC functions Security requirements

Given zero or more pairs

mi, MACK(mi) i = 1..k it is computationally impossible to find any new pair

m’, MACK(m’) Such that

m’ ¹ mi i = 1..k MAC functions Security requirements

Resistance against

1. Known-text attack

2. Chosen-text attack

3. Adaptive chosen-text attack CBC-MAC (1)

m1 m2 mt H 0 t-1 . . . .

E E E

Ht K K K H1 H2 MAC FIPS-113 K’ D

K E MAC CBC-MAC (1)

H0 = IV = 0 Hi = DESK(mi Å Hi-1) i = 1..t

MAC(m) = Ht[1..32] or -1 MAC(m) = EK(EK’ (Ht))[1..32] MAC functions

Based on Based on Based block hash Dedicated on stream ciphers functions ciphers

CBC-MAC HMAC MAA CRC-MAC CFB-MAC MD5-MAC RIPE-MAC CMAC CMAC

. . . .

. . . . RIPE-MAC

H0 = IV = 0

Hi = DESK(mi Å Hi-1) Å mi i = 1..t -1 MAC(m) = EK(EK’ (Ht))[0..31] K’ = K Å 0xf0f0…f0 HMAC Bellare, Canetti, Krawczyk, 1996

Used in SSL and IPSec

HMAC(m) = h(K Å ipad || h(K Å opad || m)) ipad, opad - constant padding strings of the length of the message block size in the hash function h

ipad = repetitions of 0x36 = 00110110 opad = repetitions of 0x5A = 01011010 HMAC KEY Å opad = KEY’ message m

KEY Å h • American standard ipad FIPS 198 = KEY” • Arbitrary hash function and key size

h HMAC Message Authentication Codes - MACs 20 years ago Present U.S. Government standards: U.S. Government standards:

MAC (DAC) based on DES HMAC – based on hash functions (since 1985) used in SSL and IPSec

CMAC – block cipher mode (AES, Triple DES, Skipjack)

Other MACs in use: Other MACs in use:

RIPE-MAC3, CRC-MAC, MAA UMAC, TTMAC, EMAC – winners of the NESSIE contest NESSIE: Winners of the contest: 2002 Message Authentication Codes, MACs

Security level Key size Output width high ³ 256 32×k normal ³ 128 32×k

Name Origin 1. UMAC UC Davis 2. TTMAC K.U. Leuven 3. EMAC U. of Toronto 4. HMAC NIST & NSA Message Authentication Codes Timeline

U.S. standards: MAC (DAC) FIPS 113 (based on DES) withdrawn in 2008 HMAC FIPS 198 (based on hash functions) CMAC SP 800-38C III. 2002 V. 2005

Contests: Contest winners: NESSIE UMAC, TTMAC, EMAC

2002 RMAC – practical attack Attacks: against MAC proposed by NIST and based on Triple DES

1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 Confidentiality & Authentication Authenticated Ciphers

Bob Alice N Message N Ciphertext Tag

K KAB Authenticated AB Authenticated Cipher Cipher Encryption Decryption

N Ciphertext Tag invalid or Message

KAB - Secret key of Alice and Bob N – Nonce or Initialization Vector Confidentiality & Authentication Authenticated Ciphers

Enc Npub Nsec AD Message NpubNsec AD Ciphertext Tag

KKeyAB KKeyAB Encryption Decryption

or Enc NpubNsec AD Ciphertext Tag Invalid Nsec AD Message

Npub - Public Message Number Nsec - Secret Message Number Enc Nsec - Encrypted Secret Message Number AD - Associated Data

KAB - Secret key of Alice and Bob CAESAR Contest 2013-2017 Cryptographic Standard Contests

IX.1997 X.2000 AES 15 block ciphers ® 1 winner

NESSIE I.2000 XII.2002 CRYPTREC XI.2004 IV.2008 34 stream 4 HW winners eSTREAM ciphers ® + 4 SW winners X.2007 X.2012 51 hash functions ® 1 winner SHA-3 I.2013 TBD 57 authenticated ciphers ® multiple winners CAESAR

97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 time Evaluation of Candidates in Cryptographic Contests

Completed 51 hash functions ® 1 winner X.2007 X.2012 In progress SHA-3 I.2013 TBD 57 authenticated ciphers CAESAR ® multiple winners VIII.2018 TBD 56 Lightweight authenticated ciphers & hash functions Lightweight Cryptography

Deadline for submitting candidates: February 25, 2019!

07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 Year Evaluation Criteria

Security

Software Efficiency Hardware Efficiency

μProcessors μControllers FPGAs ASICs

Flexibility Simplicity Licensing

46 CAESAR Contest: 2015-2018

Round 1 Round 2 Round 3 Round 4 57 Final 15 7 6 candidates 29 Portfolio Jul. 2015 Aug. 2016 Mar. 2018 Feb. 2019 Mar. 2014 Hardware benchmarking

Security Analysis & Software Benchmarking

47 CAESAR Major Challenges

Fairness Number of Candidates

48 CAESAR Hardware API

1. Minimum Compliance Criteria 3. Communication Protocol • Encryption, decryption, key scheduling • Padding • Maximum size of message & AD • Permitted data port widths, etc.

2. Interface 4. Timing Characteristics

Proposed by GMU in Feb. 2016, approved by the CAESAR Committee in May 2016 49 CAESAR Development Package

Universal Testbench (VHDL)

Code Common for All Candidates (VHDL)

Test Vector Generator (Python) 50 VHDL/Verilog Code Submitters

1. CCRG NTU (Nanyang Technological University) Singapore – ACORN, AEGIS, JAMBU, & MORUS 2. CLOC-SILC Team, Japan – CLOC & SILC 3. Ketje-Keyak Team – Ketje & Keyak 4. Lab Hubert Curien, St. Etienne, France – ELmD & TriviA-ck 5. Axel Y. Poschmann and Marc Stöttinger – Deoxys & Joltik 6. NEC Japan – AES-OTR 7. IAIK TU Graz, Austria – Ascon 8. DS Radboud University Nijmegen, Netherlands – HS1-SIV 9. IIS ETH Zurich, Switzerland – NORX 10.Pi-Cipher Team – Pi-Cipher 11.EmSec RUB, Germany – POET 12.CG UCL, INRIA – SCREAM 13.Shanghai Jiao Tong University, China – SHELL 13 Design Groups, 19 CAESAR Round 2 Candidates 51 VHDL/Verilog Code Submitters

“Ice” Homsirikamol Will Diehl AES-GCM, AEZ, Minalpher Ascon, Deoxys, OMD HS1-SIV, ICEPOLE, POET Joltik, NORX, OCB, SCREAM PAEQ, Pi-Cipher, STRIBOB

Ahmed Farnoud Mike X. Ferozpuri Farahmand Lyons PRIMATEs- AES-COPA TriviA-ck GIBBON & CLOC HANUMAN, PAEQ GMU alone, 19 Candidate Families + AES-GCM 52 CAESAR Contest: Impact 75 unique open-source designs Covering the majority of primary variants of 28 out of 29 Round 2 Candidate Families (all except Tiaoxin) High-speed implementation of AES-GCM (baseline)

The biggest and the earliest hardware benchmarking effort in the history of cryptographic competitions

53 Percentage of Candidates in Hardware

Initial number Implemented Percentage of candidates in hardware

AES 15 5 33.3% eSTREAM 34 8 23.5%

SHA-3 51 14 27.5%

CAESAR 57 28 49.1%

54 CAESAR Contest: Results for Round 2

Relative (w.r.t. AES-GCM) Throughput in Virtex 6

14-16x better than the E – Throughput for Encryption D – Throughput for Decryption current standard A – Throughput for Authentication Only Default: Throughput the same for all 3 operations Why the slowest?

Red – algorithms qualified to Round 3

Throughput of AES-GCM = 3239 Mbit/s 55 CAESAR Contest: Results for Round 2

Relative (w.r.t. AES-GCM) Throughput/Area in Virtex 6

E – Throughput/Area for Encryption Team D – Throughput/Area for Decryption Keccak A – Throughput/Area for Authentication Only Default: Throughput/Area the same for all 3 operations

Red – algorithms qualified to Round 3

Throughput/Area of AES-GCM = 1.020 (Mbit/s)/LUTs 56 Side-Channel Analysis Resistance

Use Case: Lightweight applications (resource constrained environments) • critical: fits into small hardware area and/or small code for 8-bit CPUs • desirable: ability to protect against side-channel attacks (e.g., power attacks)

Will Diehl (co-advised with Jens-Peter Kaps) t-test using low-cost FOBOS environment developed by CERG

57 Side-Channel Analysis – Preliminary Results Unprotected Lightweight Implementations

Best: Fast & Small Best: ACORN JAMBU-SIMON

Worst: CLOC-AES Worst: Slow SILC-AES & Big

x 58 Side-Channel Analysis – Preliminary Results Protected Lightweight Implementations On Average: Area: x2.7 Thr: x1.8 Thr/Area: x5.4 Best: ACORN JAMBU-SIMON

Worst: CLOC-TWINE CLOC-AES

59 Presentation of Prof. D. Bernstein at the Rump Session of the Fast Software Encryption conference, March 2018 Final Portfolio

The final CAESAR portfolio is organized into three use cases:

1: Lightweight applications (resource constrained environments) 2: High-performance applications 3: Defense in depth Final Portfolio Lightweight Cryptography Authenticated Ciphers

Bob Alice

Nonce AD Message Nonce AD Ciphertext Tag

K valid KAB Authenticated AB Authenticated Cipher Cipher

Nonce AD Ciphertext Tag Message

KAB – Secret key of Alice and Bob N – Nonce (a.k.a., IV – Initialization Vector, Npub, – Public Message Number)

AD – Associated Data 64 Optional Hash Functionality

arbitrary length m message

hash h function

h(m) hash value

fixed length 65 Evaluation Criteria

Security

Software Efficiency Hardware Efficiency

μProcessors μControllers FPGAs ASICs

Flexibility Simplicity Licensing

66 NIST PQC Standardization Process

56 Round 1 Round 2 Round 3 candidates 32 ? ? Aug. 2019 Dec. 2020 2022 Feb. 2019 Hardware benchmarking

Security Analysis & Software Benchmarking

67 FPGA Benchmarking by GMU

September-October 2020

27 hardware design submissions representing 22 out of 32 candidates (69%)

Candidates with two submissions from two different groups: Ascon, COMET, Gimli, TinyJAMBU, and Xoodyak

68 Summary of Hardware Design Groups

• George Mason University Cryptographic Engineering Research Group (CERG), USA (6): Elephant, PHOTON-Beetle, Pyjamask, Saturnin, TinyJAMBU, and Xoodyak • Virginia Tech Signatures Analysis Lab, USA (5): Ascon, COMET, GIFT-COFB, SCHWAEMM & ESCH, and Spoc • CINVESTAV-IPN, Mexico (4) COMET, ESTATE, LOCUS-AEAD/LOTUS-AEAD, and Oribatida • Institute of Applied Information Processing and Communications, TU Graz, Austria (2) Ascon and ISAP • Submissions from the respective candidate teams (8): Gimli, KNOT, Romulus, Spook, Subterranean 2.0, WAGE, TinyJAMBU, Xoodyak • Submissions from other groups and independent researchers (2): Gimli, DryGASCON

69 Design Variants

Different variants corresponds to • different algorithms of the same family described in a single submission to the NIST LWC standardization process • different parameter sets, such as sizes of keys, nonces, tags, etc. • support for AEAD vs. AEAD+Hash • different hardware architectures, e.g., basic iterative, folded, unrolled, pipelined, etc.

72 variants Minimum: 1, Maximum: 12, Average: 2.7ion

70 Throughput vs. Area for Long Inputs Artix-7 FPGA: Auth Encryption, Plaintext only

71 Throughput vs. Area for Long Inputs Artix-7 FPGA: Auth Encryption, AD only

72 Throughput vs. Area for Long Inputs Artix-7 FPGA: Hashing

73 Design Space Exploration: KNOT Artix-7 FPGA: Auth Encryption, Plaintext only

Subterranean

2.0

KNOT (key length, state size, bit rate)

bit rate v2=(128, 384, 192) Hashing SCHWAEMM v3=(192, 384, 96) TinyJAMB U v4=(256, 512, 128) v1=(128, 256, 64)

state size

74 Tentative Conclusions Highest Throughput for #LUTs < 2500

Plaintext Only AD Only

1. Subterranean 2.0 ~6 Gbit/s 1. Subterranean 2.0 ~6 Gbit/s 2. Xoodyak 2. Xoodyak 3-4 Gbit/s 3. Ascon 2-3 Gbit/s 3. TinyJAMBU 4. Gimli 4. Ascon 2-3 Gbit/s 5. KNOT 5. Gimli 6. DryGASCON 1-2 Gbit/s 6. KNOT 7. Spook 7. Saturnin 8. Romulus 1-2 Gbit/s 9. DryGASCON 10. Elephant 11. Spook

75 Future Work in Round 2

Phase 3: Nov. 9, 2020: 3rd submission deadline Nov. 30, 2020: Final version of the report

• Hopefully 85%-100% of candidates! • Improved designs • More design space explorations • A new tool supporting the derivation of formulas for the execution times • Evaluation in terms of Power consumption and Energy per bit

76 Future Work in Round 3

• Evaluation of SCA-protected implementations!

• Practical experiments • Information leakage assessments • Actual attacks • SCA countermeasures 77