Dependent Types for Cryptography Implementations
Upcoming SlideShare
Loading in...5
×
 

Dependent Types for Cryptography Implementations

on

  • 200 views

Presented as HASLab Seminar Series, Braga, Portugal in June 14, 2011.

Presented as HASLab Seminar Series, Braga, Portugal in June 14, 2011.

Statistics

Views

Total Views
200
Views on SlideShare
200
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Dependent Types for Cryptography Implementations Dependent Types for Cryptography Implementations Presentation Transcript

  • Dependent Types For Cryptography Implementations Paulo Silva Manuel Barbosa HASLab, Departamento de Informática Universidade do Minho Portugal June 14, 2011
  • Motivation Cryptographic software demands high-quality implementations The CAO language was developed close to cryptographic standards making the implementation easier and more reliable This language is strongly typed with explicit type sizes Improves safety but makes it less general and usable Proposed solution: dependent types ⇒ CALF language
  • CAO Language Small and simple domain specific language with imperative flavour Geared toward the automatic production of highly efficient target code subject to security-aware optimizations Type system supports cryptography types such as bit strings, matrices and field extensions CAO has a complete formalization of its: Syntax Semantics Type system We have proved that CAO type system is sound, i.e., “well-typed programs do not go wrong” A fully functional CAO interpreter is also available
  • CAO Example AES fragment typedef GF2 := mod[ 2 ]; typedef GF2N := mod[ GF2<X> / X**8 + X**4 + X**3 + X + 1 ]; typedef S := matrix[4,4] of GF2N; def mix : matrix[4,4] of GF2N {[X], [X+1],[1], [1], [1], [X], [X+1],[1], [1], [1], [X], [X+1], [X+1],[1], [1], [X]}; := def MixColumns( s : S ) : S { def r : S; seq i := 0 to 3 { r[0..3,i] := mix * s[0..3,i]; } return r; }
  • Limitations of CAO In CAO all type sizes have to be statically determined In the previous example, the MixColumns function only works with 4 × 4 matrices We would like to allow parametrisation of these sizes. For instance: typedef S<(n : int)> := matrix[n,n] of GF2N; def MixColumns<(n : int)>( s : S<(n)> ) : S<(n)> { def r : S<(n)>; seq i := 0 to n-1 { r[0..n,i] := mix * s[0..n,i]; } return r; }
  • Dependent types A dependent type depends on a value belonging to the realm of program expressions Can be seen as families of types indexed by values In polymorphism, the type depends on another type parameter, e.g., ∀ α ∈ types . Vector of α leading to vectors of integers, vectors of booleans, etc. Using dependent types, the type depends on a value, e.g., Π n : Int . Vector[n] leading to vectors of length 5, vectors of length 13, etc.
  • Dependent types Dependent types allow for specification of program properties in types, reducing verification of correctness to type checking Implementation and specification are kept synchronized However, type checking of programs using full-fledge dependent types is not decidable and cannot be done automatically To overcome this problem, is is necessary to limit their expressive power reducing the amount of verifiable properties Most existing work is theoretical or in the context of functional languages
  • CALF Language CALF is a higher-level extension of the CAO language, additionally providing: Dependent types Higher-order polymorphic operators (map, fold, and zip-with) User-defined parametric data types Explicit constant definitions Module system (allowing module instantiation)
  • CALF Language The CALF compiler translates CALF source code to CAO CALF programs are like templates which can be instantiated with concrete values, leading to multiple CAO programs Dependent types allow for verifying some important properties, without requiring code annotations or deductive tools, directly in the generic CALF code For instance, this allows for detecting many out-of-bounds accesses in vectors, matrices or bit strings The translation guarantees the safety properties
  • Dependent types in CALF CALF has three different kinds of variable-like identifiers: Language variables Constants Index variables All variable-like identifiers have to be explicitly declared with their respective type (type inference may be considered in the future) Index variables allow the introduction of dependent types These are variables which can be used, not only in type declarations, but also in program expressions In the scope of their declaration, they are treated as constants They can be instantiated with any value of their domain type
  • Type Expression Evaluation and Type Equality The implementation of dependent types poses two key questions: How to deal with type expressions which are not known at compile time? How to define equality, since we cannot rely on syntactic equality any more? CALF evaluation mechanism deals with type expressions that either evaluate to a value or to an expression depending solely on index variables Type equality is defined in evaluated type expressions, possibly generating additional constraints
  • Type Equality Decision Two approaches are used to solve generated constraints to decide equality: Syntactic manipulation of the constraint expressions A Satisfiability Modulo Theories (SMT) solver In our approach, two index variables are equal if and only if they have the same symbolic value Some additional restrictions (not discussed here) are imposed in order to guarantee a less complex implementation while maintaining the expressive power In practice, we often need unification and substitution instead of equality
  • Safety conditions Sometimes the constraints cannot be verified although the program is correct Given a set of constraints, we have three possible results: The constraints are satisfied — The code is safe The exists one value for which the constraints are not satisfied — The code is not safe It is not possible to decide if the constraints are satisfied — Unknown case In the last case, the result is set by the user: succeed, issue a warning or fail
  • Translation from CALF to CAO The translation requires two files: CALF source file Definition of data types, constants and function Specification file Concrete instantiations for the global index variables When modules are used, the import declarations have to be checked and processed accordingly
  • Translation from CALF to CAO The process occurs in three phases: 1 2 3 The CALF source file is type checked The specification file is type checked against the information collected during the previous phase. A list of substitutions is returned with the required instantiations. This list of substitutions is used to generate the output CAO source. This requires collecting all dependencies between functions and types Several instances of the same function or data type may be generated
  • CALF Example RSA fragment typedef RSAPub<(m : int)> := struct [ def encExp : int; ]; typedef RSAPrivShort<(m : int)> := struct [ def decExp : int; ]; def RSA<(n : int)>(k : RSAPub<(n)>, m : int ) : int { def c : mod[n]; c := (mod[n]) m; c := c ** k.encExp; return (int) c; } def RSAInvShort<(n : int)> (k : RSAPrivShort<(n)>, c : int) : int { def m : mod[n]; m := (mod[n]) c; return (int) m; } m := m ** k.decExp;
  • CALF Example RSA fragment def const pq : int; def const d : int; def const e : int; def x : int; def y : int; def myPub : RSAPub<(pq)>; def myPriv : RSAPrivShort<(pq)>; def Calc() : void { myPub.encExp := e; y := RSA<(pq)>(myPub,x); }
  • CALF Example Specification file def const pq : int := 35; def const d : int := 11; def const e : int := 11;
  • CALF Example Generated CAO code typedef RSAPub_35 := struct[def encExp_35 : int;]; def RSA_35(k : RSAPub_35, m : int) : int { def c : mod[35]; c := (mod[35]) m; c := c ** k.encExp_35; return (int) c; } def myPub : RSAPub_35; def x : int; def y : int; def Calc() : void { myPub.encExp_35 := 11; y := RSA_35(myPub, x); }
  • The Overall Picture
  • Ongoing Work Introducing explicit constraints in index variables (very important for practical usage) Improving the generation and solving of constraints in iterative statements Improving the module system (object oriented?) Publication of results