On the Impossibility of Tight Cryptographic Reduc:ons Christoph - - PowerPoint PPT Presentation

▶
on the impossibility of tight cryptographic reduc ons
SMART_READER_LITE
LIVE PREVIEW

On the Impossibility of Tight Cryptographic Reduc:ons Christoph - - PowerPoint PPT Presentation

Oct 27, 2022 350 likes •838 views

On the Impossibility of Tight Cryptographic Reduc:ons Christoph Bader, Tibor Jager, Yong Li, Sven Schge Ruhr-University Bochum EUROCRYPT 2016 1 Tight Cryptographic Reduc:ons 1. Define a security model 2. Prove: efficient a/acker A

slide-1
SLIDE 1

On the Impossibility of Tight Cryptographic Reduc:ons

Christoph Bader, Tibor Jager, Yong Li, Sven Schäge

Ruhr-University Bochum EUROCRYPT 2016

1

slide-2
SLIDE 2

“Tight” Cryptographic Reduc:ons

2

  • 1. Define a security model
  • 2. Prove: efficient a/acker A implies efficient

algorithm R that solves a “hard” problem P

pk (m*,s*) Adversary A si mi Q :mes

slide-3
SLIDE 3

“Tight” Cryptographic Reduc:ons

3

  • 1. Define a security model
  • 2. Prove: efficient adversary A implies efficient

algorithm R that solves a “hard” problem P

Instance of P Solu:on pk (m*,s*) Adversary A Reduc:on R si mi Q :mes

slide-4
SLIDE 4

“Tight” Cryptographic Reduc:ons

4

  • 1. Define a security model
  • 2. Prove: efficient adversary A implies efficient

algorithm R that solves a “hard” problem P Reduc:on R is :ght, if tR ≈ tA and succR ≈ succA

Instance of P Solu:on pk (m*,s*) Adversary A Reduc:on R si mi Q :mes

slide-5
SLIDE 5

Why is :ght security interes:ng?

  • Do schemes with :ght security exist?

– Inherent :ghtness lower bounds?

  • Tightness has impact on theore:cally-

sound selec:on of parameters

– “Non-:ght“ reduc:on => large parameters – Tight reduc:on => smaller parameters

5

slide-6
SLIDE 6

Why is :ght security interes:ng?

  • Do schemes with :ght security exist?

– Inherent :ghtness lower bounds?

  • Relevant for theore:cally-sound

selec:on of parameters

– “Non-:ght“ reduc:on large parameters – Tight reduc:on smaller parameters

6

slide-7
SLIDE 7

Many Tightly-Secure Cryptosystems

7

Digital Signatures

  • Katz-Wang (CCS 2003)
  • Schäge (Eurocrypt 2011)
  • ...

Public-Key Encryp:on

  • Bellare, Boldyreva, Micali (Eurocrypt 2000)
  • Hoeeinz, Jager (Crypto 2012)
  • Gay, Hoeeinz, Kiltz, Wee (Eurocrypt 2016)

(best paper)

  • ...

Pseudorandom Func:ons

  • Naor-Reingold (FOCS 1997)
  • Lewko-Waters (CCS 2009)
  • Jager (ePrint 2016)
  • ...

Iden:ty-based Encryp:on

  • Chen, Wee (Crypto 2013)
  • Blazy, Kiltz, Pan (Eurocrypt 2014)
  • ...

Key Exchange

  • Bader, Hoeeinz, Jager, Kiltz, Li (TCC 2015)
slide-8
SLIDE 8

Many Tightly-Secure Cryptosystems

8

Digital Signatures

  • Katz-Wang (CCS 2003)
  • Schäge (Eurocrypt 2011)
  • ...

Public-Key Encryp:on

  • Bellare, Boldyreva, Micali (Eurocrypt 2000)
  • Hoeeinz, Jager (Crypto 2012)
  • Gay, Hoeeinz, Kiltz, Wee (Eurocrypt 2016)

(best paper)

  • ...

Pseudorandom Func:ons

  • Naor-Reingold (FOCS 1997)
  • Lewko-Waters (CCS 2009)
  • Jager (ePrint 2016)
  • ...

Iden:ty-based Encryp:on

  • Chen, Wee (Crypto 2013)
  • Blazy, Kiltz, Pan (Eurocrypt 2014)
  • ...

Key Exchange

  • Bader, Hoeeinz, Jager, Kiltz, Li (TCC 2015)

Which proper:es must a cryptosystem (not) have to allow for a :ght security proof?

slide-9
SLIDE 9

Coron‘s Result* (1/2)

(Eurocrypt 2002)

9

pk (m*,s*) si mi

Q :mes

* see also Kakvi and Kiltz, Eurocrypt 2012 ** generalized to re-randomizable signatures by Hoeeinz et al., PKC 2012

  • Digital signatures

– single-user selng – unique signatures**

slide-10
SLIDE 10

Coron‘s Result* (1/2)

(Eurocrypt 2002)

10

  • Digital signatures

– single-user selng – unique signatures**

pk (m*,s*) si mi

Q :mes

Result: If a signature scheme has unique signatures, then any security reduc:on “loses” a factor of at least 1/Q.

* see also Kakvi and Kiltz, Eurocrypt 2012 ** generalized to re-randomizable signatures by Hoeeinz et al., PKC 2012

slide-11
SLIDE 11

Coron‘s Result (2/2)

(Eurocrypt 2002)

11

Instance of P Solu:on Reduc:on R pk (m*,s*) si mi Q :mes

slide-12
SLIDE 12

Coron‘s Result (2/2)

(Eurocrypt 2002)

12

Instance of P Solu:on Reduc:on R Meta-Reduc:on M Instance of P Solu:on pk (m*,s*) si mi Q :mes Simula:on of Adversary A

slide-13
SLIDE 13

Coron‘s Result (2/2)

(Eurocrypt 2002)

13

Coron shows: If a signature scheme has unique signatures, then any reduc:on R implies an algorithm M that solves P

  • In :me tM ≈ tR
  • With

✏M ≥ ✏R − 1 Q · ✓ 1 − Q |MsgSpace| ◆−1

Instance of P Solu:on Reduc:on R Meta-Reduc:on M Instance of P Solu:on pk (m*,s*) si mi Q :mes Simula:on of Adversary A

slide-14
SLIDE 14

Coron‘s Result (2/2)

(Eurocrypt 2002)

14

Coron shows: If a signature scheme has unique signatures, then any reduc:on R implies an algorithm M that solves P

  • In :me tM ≈ tR
  • With

✏M ≥ ✏R − 1 Q · ✓ 1 − Q |MsgSpace| ◆−1

Instance of P Solu:on Reduc:on R Meta-Reduc:on M Instance of P Solu:on pk (m*,s*) si mi Q :mes Simula:on of Adversary A “Annoying term”

slide-15
SLIDE 15

Limita:ons of Coron‘s Technique

  • Restricted but reasonable class of reduc:ons:

– Treat adversary A as a black-box – Few advanced capabili:es (e.g. seq. rewinding)

  • Rela:vely complex analysis

15

slide-16
SLIDE 16

Limita:ons of Coron‘s Technique

  • Restricted but reasonable class of reduc:ons:

– Treat adversary A as a black-box – Few advanced capabili:es (e.g. seq. rewinding)

  • Rela:vely complex analysis

16

  • Only useful in selngs where Q << |MsgSpace|

– Acceptable for [C`02, KK`12, HJK`12] – Makes applica:on to other sePngs difficult

✏M ≥ ✏R − 1 Q · ✓ 1 − Q |MsgSpace| ◆−1

“Annoying term”

slide-17
SLIDE 17

Mul:-User Security of Signatures

17

  • A receives N public keys
  • Q signature queries
  • Corrupt N-1 users
  • Goal: :ght security in

– Number of signatures Q – Number of public keys N

pk1, ..., pkN (m*,s*)

slide-18
SLIDE 18

Mul:-User Security of Signatures

18

  • A receives N public keys
  • Q signature queries
  • Corrupt N-1 users
  • Goal: :ght security in

– Number of signatures Q – Number of public keys N

pk1, ..., pkN (m*,s*) si (mi, j)

slide-19
SLIDE 19

Mul:-User Security of Signatures

19

  • A receives N public keys
  • Q signature queries
  • Corrupt N-1 users
  • Goal: :ght security in

– Number of signatures Q – Number of public keys N

pk1, ..., pkN (m*,s*) si (mi, j) skj j

slide-20
SLIDE 20

Mul:-User Security of Signatures

20

  • A receives N public keys
  • Q signature queries
  • Corrupt N-1 users
  • Desired: :ght security in

– Number of signatures Q – Number of public keys N

pk1, ..., pkN (m*,s*) si (mi, j) skj j

slide-21
SLIDE 21

Mul:-User Security of Signatures

21

  • A receives N public keys
  • Q signature queries
  • Corrupt N-1 users
  • Desired: :ght security in

– Number of signatures Q – Number of public keys N

pk1, ..., pkN (m*,s*) si (mi, j) skj j

Single-user security mul:-user security But the reduc:on is not :ght, loses a factor 1/N

slide-22
SLIDE 22

Applying Coron’s technique to the mul:-user selng

22

  • To show that this loss is impossible to avoid:
  • Applying [Coron 2002], we get

✏M ≥ ✏R − 1 N

slide-23
SLIDE 23

Applying Coron’s technique to the mul:-user selng

23

  • To show that this loss is impossible to avoid:
  • Applying [Coron 2002], we get

✏M ≥ ✏R − 1 N · ✓ 1 − N − 1 N ◆−1 ✏M ≥ ✏R − 1 N

slide-24
SLIDE 24

Applying Coron’s technique to the mul:-user selng

24

  • To show that this loss is impossible to avoid:
  • Applying [Coron 2002], we get

✏M ≥ ✏R − 1 N · ✓ 1 − N − 1 N ◆−1

Equal to N

Trivial bound, because of the “annoying term”

✏M ≥ ✏R − 1 N

slide-25
SLIDE 25

Our approach

Goal: Prove that 1/N-loss is impossible to avoid

  • 1. Define a weaker security defini:on

– Counterintui:ve: Should be more difficult to prove impossibility of :ght reduc:ons!

  • 2. New meta-reduc:on technique

– No “annoying term” – Weakness of security defini:ons enables simple and clean analysis

  • 3. Generalize this technique to other primi:ves

25

slide-26
SLIDE 26

Our approach

Goal: Prove that 1/N-loss is impossible to avoid

  • 1. Define a weaker security defini:on

– Counterintui:ve: Should be more difficult to prove impossibility of :ght reduc:ons!

  • 2. New meta-reduc:on technique

– No “annoying term” – Weakness of security defini:ons enables simple and clean analysis

  • 3. Generalize this technique to other primi:ves

26

slide-27
SLIDE 27

Weak Mul:-User Security

27

pk1, ..., pkN skj j ski for i≠j

  • A receives N public keys
  • Corrupt users
  • Signature queries
  • A has to compute skj
slide-28
SLIDE 28

Weak Mul:-User Security

28

pk1, ..., pkN skj j ski for i≠j

No :ght security proof for “weak” security

  • No :ght security proof for any “stronger” no:on
  • A receives N public keys
  • Corrupt users
  • Signature queries
  • A has to compute skj
slide-29
SLIDE 29

Weak Mul:-User Security

29

pk1, ..., pkN skj j ski for i≠j

No :ght security proof for “weak” security

  • No :ght security proof for any “stronger” no:on
  • A receives N public keys
  • Corrupt users
  • Signature queries
  • A has to compute skj

Makes sense for any public-key scheme!

slide-30
SLIDE 30

Our approach

Goal: Prove that 1/N-loss is impossible to avoid

  • 1. Define a weaker security defini:on

– Counterintui:ve: Should be more difficult to prove impossibility of :ght reduc:ons!

  • 2. New meta-reduc:on technique

– No “annoying term” – Weakness of security defini:ons enables simple and clean analysis

  • 3. Generalize this technique to other primi:ves

30

slide-31
SLIDE 31

Our result

  • Restricted but reasonable class of reduc:ons:

– Use adversary A as a black-box – Few advanced capabili:es (e.g. seq. rewinding)

  • Rela:vely simple analysis

31

✏M ≥ ✏R − 1 N · ✓ 1 − N − 1 N ◆−1

slide-32
SLIDE 32

Tightness Bound: Intui:on

32

pk1, ..., pkN skj j ski for i≠j

Reduc:on R Instance of P Solu:on

slide-33
SLIDE 33

Tightness Bound: Intui:on

33

pk1, ..., pkN skj j ski for i≠j

Reduc:on R

  • 1. Only one index j such that R can output ski for all i≠j

R not :ght!

  • 2. More than one j P not “hard”!

Instance of P Solu:on

slide-34
SLIDE 34

Tightness Bound: Intui:on

34

pk1, ..., pkN skj j ski for i≠j

Reduc:on R

  • 1. Only one index j such that R can output ski for all i≠j

R not :ght!

  • 2. More than one j P not “hard”!

Instance of P Solu:on

slide-35
SLIDE 35

Tightness Bound: Proof Sketch (1/2)

35

  • 1. Run R un:l right a[er it outputs pk1, ..., pkN,

save the state of R

  • 2. Run R star:ng from this state for all j from 1 to N,

un:l R outputs the secret keys ski for all i≠j

pk1, ..., pkN

Reduc:on R Instance of P Instance of P Meta-Reduc:on M

slide-36
SLIDE 36

Tightness Bound: Proof Sketch (1/2)

36

  • 1. Run R un:l right a[er it outputs pk1, ..., pkN,

save the state of R

  • 2. Run R star:ng from this state for all j from 1 to N,

un:l R outputs the secret keys ski for all i≠j

pk1, ..., pkN j ski for i≠j

Reduc:on R Instance of P Instance of P Meta-Reduc:on M

slide-37
SLIDE 37

Tightness Bound: Proof Sketch (1/2)

37

  • 1. Run R un:l right a[er it outputs pk1, ..., pkN,

save the state of R

  • 2. Run R star:ng from this state for all j from 1 to N,

un:l R outputs the secret keys ski for all i≠j

pk1, ..., pkN j ski for i≠j

Reduc:on R Instance of P Instance of P Meta-Reduc:on M

M learns all secret keys

slide-38
SLIDE 38

Tightness Bound: Proof Sketch (2/2)

38

pk1, ..., pkN skj j ski for i≠j

Reduc:on R Instance of P Instance of P Meta-Reduc:on M Simula:on of Adversary A

  • 1. Execute R once again, star:ng from
  • 2. Simulate A that chooses j uniformly random
  • 3. Output skj
slide-39
SLIDE 39

Tightness Bound: Proof Sketch (2/2)

39

pk1, ..., pkN skj j ski for i≠j

Reduc:on R Instance of P Solu:on Instance of P Solu:on Meta-Reduc:on M Simula:on of Adversary A

  • 1. Execute R once again, star:ng from
  • 2. Simulate A that chooses j uniformly random
  • 3. Output skj

Perfect simula:on of a successful adversary

slide-40
SLIDE 40

Requirements on the public-key scheme

  • For each pk there is only one unique sk (*)
  • One can efficiently verify that a given sk

belongs to a given pk

  • Holds for many known construc:ons

40

(* In the paper: generalized to re-randomizable keys)

slide-41
SLIDE 41

Requirements on the public-key scheme

  • For each pk there is only one unique sk (*)
  • One can efficiently verify that a given sk

belongs to a given pk

  • Holds for many known construc:ons

41

Result: A public-key scheme that sa:sfies the above condi:ons cannot have a :ght security proof in the mul:-user selng with corrup:ons.

(* In the paper: generalized to re-randomizable keys)

slide-42
SLIDE 42

Our approach

Goal: Prove that 1/N-loss is impossible to avoid

  • 1. Define a weaker security defini:on

– Counterintui:ve: Should be more difficult to prove impossibility of :ght reduc:ons!

  • 2. New meta-reduc:on technique

– No “annoying term” – Weakness of security defini:ons enables simple and clean analysis

  • 3. Generalize this technique to other primi:ves

42

slide-43
SLIDE 43

Goal: easy applicability

43

Generalized experiment

Strengthened versions of [C02, KK12, HJK12] Mul:-user security with corrup:ons Security of non-interac:ve key exchange

“Master theorem” Special cases

slide-44
SLIDE 44

Generaliza:on to Abstract Rela:ons

44

x1, ..., xN wj j wi for i≠j S = {(x1, w1), (x2, w2), ... , (xN, wN)}

Requirements on S:

  • Efficient verifiability
  • For each statement x, the

witness w is unique (or re-randomizable)

slide-45
SLIDE 45

Generaliza:on to Abstract Rela:ons

45

x1, ..., xN wj j wi for i≠j S = {(x1, w1), (x2, w2), ... , (xN, wN)}

For example:

  • Public key crypto in the mul:-user selng:

S = {(pk1, sk1), (pk2, sk2), ... , (pkN, skN)}

  • Unique signatures in the single-user selng:

S = {(m1, s1), (m2, s2), ... , (mN, sN)}

Requirements on S:

  • Efficient verifiability
  • For each statement x, the

witness w is unique (or re-randomizable)

slide-46
SLIDE 46

Generaliza:on to Abstract Rela:ons

46

x1, ..., xN wj j wi for i≠j S = {(x1, w1), (x2, w2), ... , (xN, wN)}

For example:

  • Public key crypto in the mul:-user selng:

S = {(pk1, sk1), (pk2, sk2), ... , (pkN, skN)}

  • Signatures in the single-user selng:

S = {(m1, s1), (m2, s2), ... , (mN, sN)}

Requirements on S:

  • Efficient verifiability
  • For each statement x, the

witness w is unique (or re-randomizable)

slide-47
SLIDE 47

Summary

New techniques to prove inexistence of :ght reduc:ons

  • Stronger results but simpler proof
  • More applica:ons
  • Easy to check whether a construc:on can

have a :ght security proof

  • Easy to adapt to other applica:ons via generic

“master theorem”

47

slide-48
SLIDE 48

Summary

New techniques to prove inexistence of :ght reduc:ons

  • Stronger results but simpler proof
  • More applica:ons
  • Easy to check whether a construc:on can

have a :ght security proof

  • Easy to adapt to other applica:ons via generic

“master theorem”

48

Thank you!