Introduction to symmetric crypto D. J. Bernstein How HTTPS protects - - PDF document

introduction to symmetric crypto d j bernstein how https
SMART_READER_LITE
LIVE PREVIEW

Introduction to symmetric crypto D. J. Bernstein How HTTPS protects - - PDF document

1 Introduction to symmetric crypto D. J. Bernstein How HTTPS protects connection: Public-key encryption system encrypts one secret message: a random 256-bit session key. Public-key signature system stops NSAITM attacks. Fast


slide-1
SLIDE 1

1

Introduction to symmetric crypto

  • D. J. Bernstein

How HTTPS protects connection:

  • Public-key encryption system

encrypts one secret message: a random 256-bit session key.

  • Public-key signature system

stops NSAITM attacks.

  • Fast authenticated cipher

uses the 256-bit session key to protect further messages.

slide-2
SLIDE 2

2

Some cipher history 1973, and again in 1974: U.S. National Bureau of Standards solicits proposals for a Data Encryption Standard.

slide-3
SLIDE 3

2

Some cipher history 1973, and again in 1974: U.S. National Bureau of Standards solicits proposals for a Data Encryption Standard. 1975: NBS publishes IBM DES

  • proposal. 64-bit block, 56-bit key.
slide-4
SLIDE 4

2

Some cipher history 1973, and again in 1974: U.S. National Bureau of Standards solicits proposals for a Data Encryption Standard. 1975: NBS publishes IBM DES

  • proposal. 64-bit block, 56-bit key.

1976: NSA meets Diffie and Hellman to discuss criticism. Claims “somewhere over $400,000,000” to break a DES key; “I don’t think you can tell any Congressman what’s going to be secure 25 years from now.”

slide-5
SLIDE 5

3

1977: DES is standardized. 1977: Diffie and Hellman publish detailed design of $20,000,000 machine to break hundreds of DES keys per year.

slide-6
SLIDE 6

3

1977: DES is standardized. 1977: Diffie and Hellman publish detailed design of $20,000,000 machine to break hundreds of DES keys per year. 1978: Congressional investigation into NSA influence concludes “NSA convinced IBM that a reduced key size was sufficient”.

slide-7
SLIDE 7

3

1977: DES is standardized. 1977: Diffie and Hellman publish detailed design of $20,000,000 machine to break hundreds of DES keys per year. 1978: Congressional investigation into NSA influence concludes “NSA convinced IBM that a reduced key size was sufficient”. 1983, 1988, 1993: Government reaffirms DES standard.

slide-8
SLIDE 8

3

1977: DES is standardized. 1977: Diffie and Hellman publish detailed design of $20,000,000 machine to break hundreds of DES keys per year. 1978: Congressional investigation into NSA influence concludes “NSA convinced IBM that a reduced key size was sufficient”. 1983, 1988, 1993: Government reaffirms DES standard. Researchers publish new cipher proposals and security analysis.

slide-9
SLIDE 9

4

1997: U.S. National Institute

  • f Standards and Technology

(NIST, formerly NBS) calls for proposals for Advanced Encryption Standard. 128-bit block, 128/192/256-bit key.

slide-10
SLIDE 10

4

1997: U.S. National Institute

  • f Standards and Technology

(NIST, formerly NBS) calls for proposals for Advanced Encryption Standard. 128-bit block, 128/192/256-bit key. 1998: 15 AES proposals.

slide-11
SLIDE 11

4

1997: U.S. National Institute

  • f Standards and Technology

(NIST, formerly NBS) calls for proposals for Advanced Encryption Standard. 128-bit block, 128/192/256-bit key. 1998: 15 AES proposals. 1998: EFF builds “Deep Crack” for under $250000 to break hundreds of DES keys per year.

slide-12
SLIDE 12

4

1997: U.S. National Institute

  • f Standards and Technology

(NIST, formerly NBS) calls for proposals for Advanced Encryption Standard. 128-bit block, 128/192/256-bit key. 1998: 15 AES proposals. 1998: EFF builds “Deep Crack” for under $250000 to break hundreds of DES keys per year. 1999: NIST selects five AES finalists: MARS, RC6, Rijndael, Serpent, Twofish.

slide-13
SLIDE 13

5

2000: NIST, advised by NSA, selects Rijndael as AES. “Security was the most important factor in the evaluation”—Really?

slide-14
SLIDE 14

5

2000: NIST, advised by NSA, selects Rijndael as AES. “Security was the most important factor in the evaluation”—Really? “Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.”

slide-15
SLIDE 15

5

2000: NIST, advised by NSA, selects Rijndael as AES. “Security was the most important factor in the evaluation”—Really? “Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” 2004–2008: eSTREAM competition for stream ciphers.

slide-16
SLIDE 16

5

2000: NIST, advised by NSA, selects Rijndael as AES. “Security was the most important factor in the evaluation”—Really? “Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” 2004–2008: eSTREAM competition for stream ciphers. 2007–2012: SHA-3 competition.

slide-17
SLIDE 17

5

2000: NIST, advised by NSA, selects Rijndael as AES. “Security was the most important factor in the evaluation”—Really? “Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” 2004–2008: eSTREAM competition for stream ciphers. 2007–2012: SHA-3 competition. 2013–2019: CAESAR competition.

slide-18
SLIDE 18

5

2000: NIST, advised by NSA, selects Rijndael as AES. “Security was the most important factor in the evaluation”—Really? “Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” 2004–2008: eSTREAM competition for stream ciphers. 2007–2012: SHA-3 competition. 2013–2019: CAESAR competition. 2019–now: NISTLWC competition.

slide-19
SLIDE 19

6

Main operations in AES: add round key to block; apply substitution box x → x254 in F256 to each byte in block; linearly mix bits across block.

slide-20
SLIDE 20

6

Main operations in AES: add round key to block; apply substitution box x → x254 in F256 to each byte in block; linearly mix bits across block. Extensive security analysis. Even in a post-quantum world, no serious threats to AES-256 in a strong security model, “multi-target SPRP security”.

slide-21
SLIDE 21

6

Main operations in AES: add round key to block; apply substitution box x → x254 in F256 to each byte in block; linearly mix bits across block. Extensive security analysis. Even in a post-quantum world, no serious threats to AES-256 in a strong security model, “multi-target SPRP security”. So why isn’t AES-256 the end

  • f the symmetric-crypto story?
slide-22
SLIDE 22

7

slide-23
SLIDE 23

8

slide-24
SLIDE 24

9

slide-25
SLIDE 25

10

slide-26
SLIDE 26

11

slide-27
SLIDE 27

12

. . .

slide-28
SLIDE 28

13

AES performance seems limited in both hardware and software by small 128-bit block size, heavy S-box design strategy.

slide-29
SLIDE 29

13

AES performance seems limited in both hardware and software by small 128-bit block size, heavy S-box design strategy. AES software ecosystem is complicated and dangerous. Fast software implementations

  • f AES S-box often leak

secrets through timing.

slide-30
SLIDE 30

13

AES performance seems limited in both hardware and software by small 128-bit block size, heavy S-box design strategy. AES software ecosystem is complicated and dangerous. Fast software implementations

  • f AES S-box often leak

secrets through timing. Picture is worse for high-security authenticated ciphers. 128-bit block size limits “PRF” security. Workarounds are hard to audit.

slide-31
SLIDE 31

14

ChaCha creates safe systems with much less work than AES.

slide-32
SLIDE 32

14

ChaCha creates safe systems with much less work than AES. More examples of how symmetric primitives have been improving speed, simplicity, security: PRESENT is better than DES. Skinny is better than Simon and Speck. Keccak, BLAKE2, Ascon are better than MD5, SHA-0, SHA-1, SHA-256, SHA-512.

slide-33
SLIDE 33

15

Authentication details Standardize a prime p = 1000003. Assume sender knows independent uniform random secrets r1 ∈ {0; 1; : : : ; 999999}, r2 ∈ {0; 1; : : : ; 999999}, . . . r5 ∈ {0; 1; : : : ; 999999}, s1 ∈ {0; 1; : : : ; 999999}, . . . s100 ∈ {0; 1; : : : ; 999999}.

slide-34
SLIDE 34

16

Assume receiver knows the same secrets r1; r2; : : : ; r5; s1; : : : ; s100.

slide-35
SLIDE 35

16

Assume receiver knows the same secrets r1; r2; : : : ; r5; s1; : : : ; s100. Later: Sender wants to send 100 messages m1; : : : ; m100, each mn having 5 components mn;1; mn;2; mn;3; mn;4; mn;5 with mn;i ∈ {0; 1; : : : ; 999999}.

slide-36
SLIDE 36

16

Assume receiver knows the same secrets r1; r2; : : : ; r5; s1; : : : ; s100. Later: Sender wants to send 100 messages m1; : : : ; m100, each mn having 5 components mn;1; mn;2; mn;3; mn;4; mn;5 with mn;i ∈ {0; 1; : : : ; 999999}. Sender transmits 30-digit mn;1; mn;2; mn;3; mn;4; mn;5 together with an authenticator (mn;1r1 + · · · + mn;5r5 mod p) + sn mod 1000000 and the message number n.

slide-37
SLIDE 37

17

e.g. r1 = 314159, r2 = 265358, r3 = 979323, r4 = 846264, r5 = 338327, s10 = 950288, m10 = ✵✵✵✵✵✻ ✵✵✵✵✵✼ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✵✵✵✵✵✵:

slide-38
SLIDE 38

17

e.g. r1 = 314159, r2 = 265358, r3 = 979323, r4 = 846264, r5 = 338327, s10 = 950288, m10 = ✵✵✵✵✵✻ ✵✵✵✵✵✼ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✵✵✵✵✵✵: Sender computes authenticator (6r1 + 7r2 mod p) + s10 mod 1000000 = (6 · 314159 + 7 · 265358 mod 1000003) + 950288 mod 1000000 = 742451 + 950288 mod 1000000 = 692739.

slide-39
SLIDE 39

17

e.g. r1 = 314159, r2 = 265358, r3 = 979323, r4 = 846264, r5 = 338327, s10 = 950288, m10 = ✵✵✵✵✵✻ ✵✵✵✵✵✼ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✵✵✵✵✵✵: Sender computes authenticator (6r1 + 7r2 mod p) + s10 mod 1000000 = (6 · 314159 + 7 · 265358 mod 1000003) + 950288 mod 1000000 = 742451 + 950288 mod 1000000 = 692739. Sender transmits ✶✵ ✵✵✵✵✵✻ ✵✵✵✵✵✼ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✻✾✷✼✸✾.

slide-40
SLIDE 40

18

A MAC using fewer secrets Instead of choosing independent r1; r2; : : : ; r5; s1; : : : ; s100, choose r; s1; s2; : : : ; s100.

slide-41
SLIDE 41

18

A MAC using fewer secrets Instead of choosing independent r1; r2; : : : ; r5; s1; : : : ; s100, choose r; s1; s2; : : : ; s100. Sender transmits 30-digit mn;1; mn;2; mn;3; mn;4; mn;5 together with an authenticator (mn;1r + · · · + mn;5r5 mod p) + sn mod 1000000 and the message number n. i.e.: take ri = ri in previous (mn;1r1 + · · · + mn;5r5 mod p) + sn mod 1000000.

slide-42
SLIDE 42

19

e.g. r = 314159, s10 = 265358, m10 = ✵✵✵✵✵✻ ✵✵✵✵✵✼ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✵✵✵✵✵✵:

slide-43
SLIDE 43

19

e.g. r = 314159, s10 = 265358, m10 = ✵✵✵✵✵✻ ✵✵✵✵✵✼ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✵✵✵✵✵✵: Sender computes authenticator (6r + 7r2 mod p) + s10 mod 1000000 = (6 · 314159 + 7 · 3141592 mod 1000003) + 265358 mod 1000000 = 953311 + 265358 mod 1000000 = 218669.

slide-44
SLIDE 44

19

e.g. r = 314159, s10 = 265358, m10 = ✵✵✵✵✵✻ ✵✵✵✵✵✼ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✵✵✵✵✵✵: Sender computes authenticator (6r + 7r2 mod p) + s10 mod 1000000 = (6 · 314159 + 7 · 3141592 mod 1000003) + 265358 mod 1000000 = 953311 + 265358 mod 1000000 = 218669. Sender transmits authenticated message ✶✵ ✵✵✵✵✵✻ ✵✵✵✵✵✼ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✵✵✵✵✵✵ ✷✶✽✻✻✾.

slide-45
SLIDE 45

20

Security analysis Attacker’s goal: Find n′; m′; a′ such that m′ = mn′ but a′ = (m′(r) mod p) + sn′ mod 1000000. Here m′(x) = P

i m′[i]xi.

slide-46
SLIDE 46

20

Security analysis Attacker’s goal: Find n′; m′; a′ such that m′ = mn′ but a′ = (m′(r) mod p) + sn′ mod 1000000. Here m′(x) = P

i m′[i]xi.

Obvious attack: Choose any m′ = m1. Choose uniform random a′. Success chance 1=1000000.

slide-47
SLIDE 47

20

Security analysis Attacker’s goal: Find n′; m′; a′ such that m′ = mn′ but a′ = (m′(r) mod p) + sn′ mod 1000000. Here m′(x) = P

i m′[i]xi.

Obvious attack: Choose any m′ = m1. Choose uniform random a′. Success chance 1=1000000. Can repeat attack. Each forgery has chance 1=1000000 of being accepted.

slide-48
SLIDE 48

21

More subtle attack: Choose m′ = m1 so that the polynomial m′(x) − m1(x) has 5 distinct roots x ∈ {0; 1; : : : ; 999999} modulo p. Choose a′ = a.

slide-49
SLIDE 49

21

More subtle attack: Choose m′ = m1 so that the polynomial m′(x) − m1(x) has 5 distinct roots x ∈ {0; 1; : : : ; 999999} modulo p. Choose a′ = a. e.g. m1 = (100; 0; 0; 0; 0), m′ = (125; 1; 0; 0; 1): m′(x) − m1(x) = x5 + x2 + 25x which has five roots mod p: 0; 299012; 334447; 631403; 735144.

slide-50
SLIDE 50

21

More subtle attack: Choose m′ = m1 so that the polynomial m′(x) − m1(x) has 5 distinct roots x ∈ {0; 1; : : : ; 999999} modulo p. Choose a′ = a. e.g. m1 = (100; 0; 0; 0; 0), m′ = (125; 1; 0; 0; 1): m′(x) − m1(x) = x5 + x2 + 25x which has five roots mod p: 0; 299012; 334447; 631403; 735144. Success chance 5=1000000.

slide-51
SLIDE 51

22

Actually, success chance can be above 5=1000000.

slide-52
SLIDE 52

22

Actually, success chance can be above 5=1000000. Example: If m1(334885) mod p ∈ {1000000; 1000001; 1000002} then a forgery (1; m′; a1) with m′(x) = m1(x) + x5 + x2 + 25x also succeeds for r = 334885; success chance 6=1000000. Reason: 334885 is a root of m′(x) − m1(x) + 1000000.

slide-53
SLIDE 53

22

Actually, success chance can be above 5=1000000. Example: If m1(334885) mod p ∈ {1000000; 1000001; 1000002} then a forgery (1; m′; a1) with m′(x) = m1(x) + x5 + x2 + 25x also succeeds for r = 334885; success chance 6=1000000. Reason: 334885 is a root of m′(x) − m1(x) + 1000000. Can have as many as 15 roots

  • f (m′(x) − m1(x)) ·

(m′(x) − m1(x) + 1000000) · (m′(x) − m1(x) − 1000000).

slide-54
SLIDE 54

23

Do better by varying a′?

slide-55
SLIDE 55

23

Do better by varying a′?

  • No. Easy to prove: Every choice
  • f (n′; m′; a′) with m′ = mn′

has chance ≤ 15=1000000

  • f being accepted by receiver.
slide-56
SLIDE 56

23

Do better by varying a′?

  • No. Easy to prove: Every choice
  • f (n′; m′; a′) with m′ = mn′

has chance ≤ 15=1000000

  • f being accepted by receiver.

Underlying fact: ≤ 15 roots

  • f (m′(x) − m1(x) − a′ + a1) ·

(m′(x) − m1(x) − a′ + a1 + 106) · (m′(x) − m1(x) − a′ + a1 − 106).

slide-57
SLIDE 57

23

Do better by varying a′?

  • No. Easy to prove: Every choice
  • f (n′; m′; a′) with m′ = mn′

has chance ≤ 15=1000000

  • f being accepted by receiver.

Underlying fact: ≤ 15 roots

  • f (m′(x) − m1(x) − a′ + a1) ·

(m′(x) − m1(x) − a′ + a1 + 106) · (m′(x) − m1(x) − a′ + a1 − 106). Warning: very easy to break the oversimplified authenticator (mn[1] + · · · + mn[5]r4 mod p) + sn mod 1000000: solve m′(x) − m1(x) = a′ − a1.

slide-58
SLIDE 58

24

Scaled up for serious security: Poly1305 uses 128-bit r’s, with 22 bits cleared for speed. Adds sn mod 2128.

slide-59
SLIDE 59

24

Scaled up for serious security: Poly1305 uses 128-bit r’s, with 22 bits cleared for speed. Adds sn mod 2128. Assuming ≤ L-byte messages: Each forgery succeeds for ≤ 8 ⌈L=16⌉ choices of r. Probability ≤ 8 ⌈L=16⌉ =2106.

slide-60
SLIDE 60

24

Scaled up for serious security: Poly1305 uses 128-bit r’s, with 22 bits cleared for speed. Adds sn mod 2128. Assuming ≤ L-byte messages: Each forgery succeeds for ≤ 8 ⌈L=16⌉ choices of r. Probability ≤ 8 ⌈L=16⌉ =2106. D forgeries are all rejected with probability ≥ 1 − 8D ⌈L=16⌉ =2106.

slide-61
SLIDE 61

24

Scaled up for serious security: Poly1305 uses 128-bit r’s, with 22 bits cleared for speed. Adds sn mod 2128. Assuming ≤ L-byte messages: Each forgery succeeds for ≤ 8 ⌈L=16⌉ choices of r. Probability ≤ 8 ⌈L=16⌉ =2106. D forgeries are all rejected with probability ≥ 1 − 8D ⌈L=16⌉ =2106. e.g. 264 forgeries, L = 1536: Pr[all rejected] ≥ 0:9999999998.

slide-62
SLIDE 62

25

Authenticator is still secure for variable-length messages, if different messages are different polynomials mod p.

slide-63
SLIDE 63

25

Authenticator is still secure for variable-length messages, if different messages are different polynomials mod p. Split string into 16-byte chunks, maybe with smaller final chunk; append 1 to each chunk; view as little-endian integers in ˘ 1; 2; 3; : : : ; 2129¯ . Multiply first chunk by r, add next chunk, multiply by r, etc., last chunk, multiply by r, mod 2130 − 5, add sn mod 2128.