Upcoming SlideShare
×

# Dependent Types for Cryptography Implementations

171 views
132 views

Published on

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

Published in: Technology
0 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

Views
Total views
171
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
1
0
Likes
0
Embeds 0
No embeds

No notes for slide

### Dependent Types for Cryptography Implementations

1. 1. Dependent Types For Cryptography Implementations Paulo Silva Manuel Barbosa HASLab, Departamento de Informática Universidade do Minho Portugal June 14, 2011
2. 2. 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
3. 3. CAO Language Small and simple domain speciﬁc language with imperative ﬂavour Geared toward the automatic production of highly efﬁcient target code subject to security-aware optimizations Type system supports cryptography types such as bit strings, matrices and ﬁeld 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
4. 4. 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; }
5. 5. 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; }
6. 6. 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.
7. 7. Dependent types Dependent types allow for speciﬁcation of program properties in types, reducing veriﬁcation of correctness to type checking Implementation and speciﬁcation are kept synchronized However, type checking of programs using full-ﬂedge 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 veriﬁable properties Most existing work is theoretical or in the context of functional languages
8. 8. 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-deﬁned parametric data types Explicit constant deﬁnitions Module system (allowing module instantiation)
9. 9. 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
10. 10. Dependent types in CALF CALF has three different kinds of variable-like identiﬁers: Language variables Constants Index variables All variable-like identiﬁers 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
11. 11. 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 deﬁne 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 deﬁned in evaluated type expressions, possibly generating additional constraints
12. 12. Type Equality Decision Two approaches are used to solve generated constraints to decide equality: Syntactic manipulation of the constraint expressions A Satisﬁability 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 uniﬁcation and substitution instead of equality
13. 13. Safety conditions Sometimes the constraints cannot be veriﬁed although the program is correct Given a set of constraints, we have three possible results: The constraints are satisﬁed — The code is safe The exists one value for which the constraints are not satisﬁed — The code is not safe It is not possible to decide if the constraints are satisﬁed — Unknown case In the last case, the result is set by the user: succeed, issue a warning or fail
14. 14. Translation from CALF to CAO The translation requires two ﬁles: CALF source ﬁle Deﬁnition of data types, constants and function Speciﬁcation ﬁle Concrete instantiations for the global index variables When modules are used, the import declarations have to be checked and processed accordingly
15. 15. Translation from CALF to CAO The process occurs in three phases: 1 2 3 The CALF source ﬁle is type checked The speciﬁcation ﬁle 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
16. 16. 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;
17. 17. 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); }
18. 18. CALF Example Speciﬁcation ﬁle def const pq : int := 35; def const d : int := 11; def const e : int := 11;
19. 19. 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); }
20. 20. The Overall Picture
21. 21. 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