Introduction we consider the problem of complexity analysis for - - PowerPoint PPT Presentation

▶
introduction
SMART_READER_LITE
LIVE PREVIEW

Introduction we consider the problem of complexity analysis for - - PowerPoint PPT Presentation

Aug 19, 2022 308 likes •991 views

Implicit Computational Complexity of Subrecursive Functional Programs, with Applications to Cryptographic Proofs Patrick Baillot LIP, CNRS & ENS de Lyon joint work with Gilles Barthe and Ugo Dal Lago gdt Gomtrie du Calcul (GEOCAL)

slide-1
SLIDE 1

Implicit Computational Complexity of Subrecursive Functional Programs, with Applications to Cryptographic Proofs

Patrick Baillot

LIP, CNRS & ENS de Lyon

joint work with Gilles Barthe and Ugo Dal Lago

gdt Géométrie du Calcul (GEOCAL) & Logique, Algèbre, Calcul (LAC) journées 2016 du gdr IM

1

slide-2
SLIDE 2

Introduction

✤ we consider the problem of complexity analysis for higher-order

functional programs with references

✤ implicit computational complexity has designed restricted languages

with guaranteed complexity bounds, in particular polynomial time

✤ however here we aim at: ✤ an analysis covering a larger class of programs ✤ allowing to extract concrete complexity bounds ✤ our motivation is the analysis of complexity bounds on adversaries

built by cryptographic reductions

2

slide-3
SLIDE 3

Modular complexity analysis? S1

String String String

S2

3

slide-4
SLIDE 4

Modular complexity analysis? S1

String String String

S2

T(S1; S2) ≤ T(S1)+ T(S2)o|S1|

4

slide-5
SLIDE 5

String -> String String

S2

String

5

slide-6
SLIDE 6

S1

String -> String String

S2

String

6

slide-7
SLIDE 7

S1

String -> String String

S2

String

Which information from S1 and S2 is sufficient to bound T(S1;S2) ?

7

slide-8
SLIDE 8

S1

N ->N N

S2

N

8

slide-9
SLIDE 9

S1

F :N ->N N n :N return F(F(n));

9

slide-10
SLIDE 10

S1

F :N ->N N n :N return F(F(n));

T(S1; S2) ≤ T(S1)+ T(S1)o|S1|

10

slide-11
SLIDE 11

S1

F : N ->N N n : N r:=1; for i=0 to n {r:= F(r)}; return r;

11

slide-12
SLIDE 12

S1

F : N ->N N n : N r:=1; for i=0 to n {r:= F(r)}; return r; let F n = n+3;

12

slide-13
SLIDE 13

S1

F : N ->N N n : N r:=1; for i=0 to n {r:= F(r)}; return r; let F n = n+3;

... leads to linear output growth: 3n

13

slide-14
SLIDE 14

S1

F : N ->N N n : N r:=1; for i=0 to n {r:= F(r)}; return r; let F n = 3n;

... leads to exponential output growth: 3n

14

slide-15
SLIDE 15

S1

F : N ->N N n : N r:=1; for i=0 to n {r:= F(r)}; return r; let F n = 3n;

... leads to exponential output growth: 3n hence exponential time if the output is used to drive another for-loop

15

slide-16
SLIDE 16

S1

(N ->N)-> (N ->N) N

S2

N

16

slide-17
SLIDE 17

S1

(N ->N)-> (N ->N) N

S2

N

T(S1; S2) ??

17

slide-18
SLIDE 18

Motivation for modular complexity analysis

N ->N N

S2

N

Analysis with partial information, e.g. S1 coming from a library

18

slide-19
SLIDE 19

Motivation for modular complexity analysis

?

N ->N N

S2

N

Guide the choice/design of S1 in order to satisfy some global complexity property

19

slide-20
SLIDE 20

Motivation for cryptographic reductions

we consider security proofs of cryptographic primitives, in the computational model

20

slide-21
SLIDE 21

Motivation for cryptographic reductions

we consider security proofs of cryptographic primitives, in the computational model their correction can be verified formally with tools such as e.g. Cryptoverif or Easycrypt

21

slide-22
SLIDE 22

Motivation for cryptographic reductions

reduction proof

computational assumption security property

  • f a scheme

we consider security proofs of cryptographic primitives, in the computational model

22

slide-23
SLIDE 23

Motivation for cryptographic reductions

∃ feasible adversary A1 for security property

  • f the scheme

reduction proof

computational assumption security property

  • f a scheme

reduction proof

by contraposition:

∃ feasible adversary A2 for the computational assumption

we consider security proofs of cryptographic primitives, in the computational model

23

slide-24
SLIDE 24

Motivation for cryptographic reductions

A2

reduction program

A1

24

slide-25
SLIDE 25

Motivation for cryptographic reductions

A2

reduction program

A1 If A1 is PPT, is A2 also PPT ?

25

slide-26
SLIDE 26

Motivation for cryptographic reductions

A2

reduction program

A1 If A1 is PPT, is A2 also PPT ? If A1 is in DTIME(nk), is A2 is in DTIME(ng(k)), for some g?

26

slide-27
SLIDE 27

Ideas for complexity analysis

ideas steming from implicit complexity, for higher-order complexity analysis:

  • linearity discipline for functional variables
  • time bounds can be derived from the combination of:
  • a size analysis
  • structural recursion (for loops)
  • to analyse the size, use an enriched type systems: indexed types

27

slide-28
SLIDE 28

Towards indexed types S1

N ->N let F n = n+3;

28

slide-29
SLIDE 29

Towards indexed types S1

Na ->Na+3 let F n = n+3;

29

slide-30
SLIDE 30

Towards indexed types S1

Na ->N3a let F n = 3n;

30

slide-31
SLIDE 31

Towards indexed types S1

Na ->N3a let F n = 3n;

  • in which language write the type indexes? polynomials ?

31

slide-32
SLIDE 32

Towards indexed types S1

Na ->N3a let F n = 3n;

  • in which language write the type indexes? polynomials ?
  • however if we fix the language:
  • some programs will not be typable
  • some polynomial time programs may have exponential

subprocedures

32

slide-33
SLIDE 33

Towards indexed types S1

Na ->N3a let F n = 3n;

Therefore we choose an open index language: first-order language with as many function symbols as needed

33

slide-34
SLIDE 34

Source language : lT

✤ Terms

a higher order calculus with references

34

slide-35
SLIDE 35

Source language : lT

✤ Terms

a higher order calculus with references iteration

35

slide-36
SLIDE 36

Source language : lT

✤ Terms

a higher order calculus with references read and write operations

36

slide-37
SLIDE 37

Source language : lT

✤ Terms

a higher order calculus with references sufficient to embed a simple imperative for-language

37

slide-38
SLIDE 38

Source language : lT

✤ Terms

a higher order calculus with references sufficient to embed a simple imperative for-language but also functional combinators such as fold, map

38

slide-39
SLIDE 39

Source language : lT

✤ Terms ✤ Types

39

slide-40
SLIDE 40

Source language : lT

✤ Terms ✤ Types

type-and-effects effect: a = set {r1,..., rk}

  • f references read

40

slide-41
SLIDE 41

Source language : lT

✤ Terms ✤ Types

type-and-effects data-type of binary strings: L(B)

41

slide-42
SLIDE 42

Source language : lT

✤ Terms ✤ Terms ✤ Types ✤ Typing judgements

42

slide-43
SLIDE 43

T yping rules for lT programs (selection)

43

slide-44
SLIDE 44

T yping rules for lT programs (selection)

typability ensures linear use of functional variables and termination of execution

44

slide-45
SLIDE 45

Index terms

✤ An «open» language of indexes: first-order terms

I := a| f(I1, ..., Ik) for f in a set IF and a system of equations ε defining IF will contain such functions as 0, +, s ...

✤ example: εcontaining e(0) = 1

e(s(a))=2 e(a) defines exponentiation.

{

45

slide-46
SLIDE 46

dlT type system

✤ Indexed types: ✤ Effects: ✤ Judgements:

46

slide-47
SLIDE 47

dlT type system: typing rules (selection)

we omit subtyping conditions here...

47

slide-48
SLIDE 48

dlT type system: examples

48

slide-49
SLIDE 49

Weight of a derivation

✤ we associate to each derivation π an index term W(π), its weight,

defined by induction on π. example:

49

slide-50
SLIDE 50

Complexity soundness

Theorem (Complexity soundness): If π is derivation of then the execution of M on the abstract machine is done in time bounded by W(π).

50

slide-51
SLIDE 51

Example: hardcore predicate

✤ If f : {0,1}n -> {0,1}n is a one-way function, then gf : {0,1}2n -> {0,1} 2n

defined by gf (x,y)=(f(x),y) is also one-way.

✤ A hardcore predicate p for a one-way function f : {0,1}n -> {0,1}n is a

function which is efficiently computable from {0,1}n to {0,1} such that it is difficult to guess p(x), when one only knows f(x).

51

slide-52
SLIDE 52

A2 adversary for

reduction program

A1 adversary for

Example: hardcore predicate

. If A1 is PPT, is A2 also PPT ?

is a hardcore predicate for gf gf is a one-way function

52

slide-53
SLIDE 53

Example: reduction for hardcore predicate [KatzLindell]

53

slide-54
SLIDE 54

Example: reduction, written in lT

54

slide-55
SLIDE 55

Example: reduction for hardcore predicate [KatzLindell]

55

slide-56
SLIDE 56

Example: reduction for hardcore predicate [KatzLindell]

La (B)

56

slide-57
SLIDE 57

Example: reduction for hardcore predicate [KatzLindell]

La (B) Na

57

slide-58
SLIDE 58

Example: reduction for hardcore predicate [KatzLindell]

La (B) Nlog(r(a)) Na

58

slide-59
SLIDE 59

Example: reduction for hardcore predicate [KatzLindell]

Llog(r(a)) (B) La (B) Nlog(r(a)) Na

59

slide-60
SLIDE 60

Example: reduction for hardcore predicate [KatzLindell]

✤ in this example we obtain for the type derivation of the inverter A’

the weight W(π)=O(n2 fA(1+2n)), where fA is a function bounding the complexity of adversary A.

✤ the bound given by the soundness thm for the complexity of A’

corresponds with the one obtained by a complexity analysis by hand.

60

slide-61
SLIDE 61

T ype inference

Theorem (Inference): There is a type inference algorithm CTI, taking as input typed lT terms, such that:

✤ CTI is total, ✤ if CTI(M)=(π,ε) then π is a correct type derivation for M .

Theorem (Termination): If M is an lT term and CTI(M)=(π,ε) , then εis terminating. So, type inference never fails...

61

slide-62
SLIDE 62

T ype inference

Theorem (Inference): There is a type inference algorithm CTI, taking as input typed lT terms, such that:

✤ CTI is total, ✤ if CTI(M)=(π,ε) then π is a correct type derivation for M .

Theorem (Termination): If M is an lT term and CTI(M)=(π,ε) , then εis terminating. So, type inference never fails... But ... what do we know about the equational program ε ?

62

slide-63
SLIDE 63

T ype inference

Theorem (Inference): There is a type inference algorithm CTI, taking as input typed lT terms, such that:

✤ CTI is total, ✤ if CTI(M)=(π,ε) then π is a correct type derivation for M .

Theorem (Termination): If M is an lT term and CTI(M)=(π,ε) , then εis terminating.

63

slide-64
SLIDE 64

lT

source (higher-order) program M weight W(π) type derivation π for M equational program ε

64

slide-65
SLIDE 65

lT

source (higher-order) program M weight W(π) type derivation π for M equational program ε first-order terminating program

65

slide-66
SLIDE 66

Related works

✤ implicit complexity: e.g. ramification [LeivantMarion93],

[Hofmann00], linear logic [Girard98]...

✤ linear dependent types [DalLagoGaboardi11] ✤ complexity analysis for functional programs: [Danielsson08],

[Grobauer01], RAML [HH10]...

✤ complexity analysis for imperative programs: COSTA [Albert et al.07],

SPEED [Gulwani et al.09]

66

slide-67
SLIDE 67

Conclusion a nd perspectives

✤ a language and a type system to analyse the complexity of

cryptographic reductions

✤ analyse the weight? use a constraints solver ? ✤ possible extensions: non-linearity; full recursion (while loops)... ✤ implementation and integration into a tool for cryptographic

verification, such as Easycrypt

67