Dependent Types For CryptographyImplementations

Paulo Silva Manuel Barbosa

HASLab, Departamento de InformáticaUniversidade do Minho

Portugal

June 14, 2011

Motivation

Cryptographic software demands high-qualityimplementationsThe CAO language was developed close to cryptographicstandards making the implementation easier and morereliableThis language is strongly typed with explicit type sizesImproves safety but makes it less general and usableProposed solution: dependent types⇒ CALF language

CAO Language

Small and simple domain specific language with imperativeflavourGeared toward the automatic production of highly efficienttarget code subject to security-aware optimizationsType system supports cryptography types such as bitstrings, matrices and field extensionsCAO has a complete formalization of its:

SyntaxSemanticsType 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 ExampleAES 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 determinedIn the previous example, the MixColumns function onlyworks with 4× 4 matricesWe would like to allow parametrisation of these sizes. Forinstance:

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 therealm of program expressionsCan be seen as families of types indexed by valuesIn polymorphism, the type depends on another typeparameter, 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 programproperties in types, reducing verification of correctness totype checkingImplementation and specification are kept synchronizedHowever, type checking of programs using full-fledgedependent types is not decidable and cannot be doneautomaticallyTo overcome this problem, is is necessary to limit theirexpressive power reducing the amount of verifiablepropertiesMost existing work is theoretical or in the context offunctional languages

CALF Language

CALF is a higher-level extension of the CAO language,additionally providing:

Dependent typesHigher-order polymorphic operators (map, fold, andzip-with)User-defined parametric data typesExplicit constant definitionsModule system (allowing module instantiation)

CALF Language

The CALF compiler translates CALF source code to CAOCALF programs are like templates which can beinstantiated with concrete values, leading to multiple CAOprogramsDependent types allow for verifying some importantproperties, without requiring code annotations or deductivetools, directly in the generic CALF codeFor instance, this allows for detecting many out-of-boundsaccesses in vectors, matrices or bit stringsThe translation guarantees the safety properties

Dependent types in CALF

CALF has three different kinds of variable-like identifiers:Language variablesConstantsIndex variables

All variable-like identifiers have to be explicitly declaredwith their respective type (type inference may beconsidered in the future)Index variables allow the introduction of dependent typesThese are variables which can be used, not only in typedeclarations, but also in program expressionsIn the scope of their declaration, they are treated asconstantsThey can be instantiated with any value of their domaintype

Type Expression Evaluation and Type Equality

The implementation of dependent types poses two keyquestions:

How to deal with type expressions which are not known atcompile time?How to define equality, since we cannot rely on syntacticequality any more?

CALF evaluation mechanism deals with type expressionsthat either evaluate to a value or to an expressiondepending solely on index variablesType equality is defined in evaluated type expressions,possibly generating additional constraints

Type Equality Decision

Two approaches are used to solve generated constraints todecide equality:

Syntactic manipulation of the constraint expressionsA Satisfiability Modulo Theories (SMT) solver

In our approach, two index variables are equal if and only ifthey have the same symbolic valueSome additional restrictions (not discussed here) areimposed in order to guarantee a less compleximplementation while maintaining the expressive powerIn practice, we often need unification and substitutioninstead of equality

Safety conditions

Sometimes the constraints cannot be verified although theprogram is correctGiven a set of constraints, we have three possible results:

The constraints are satisfied — The code is safeThe exists one value for which the constraints are notsatisfied — The code is not safeIt 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

functionSpecification file Concrete instantiations for the global

index variablesWhen modules are used, the import declarations have tobe checked and processed accordingly

Translation from CALF to CAO

The process occurs in three phases:1 The CALF source file is type checked2 The specification file is type checked against the

information collected during the previous phase. A list ofsubstitutions is returned with the required instantiations.

3 This list of substitutions is used to generate the output CAOsource. This requires collecting all dependencies betweenfunctions and types

Several instances of the same function or data type maybe generated

CALF ExampleRSA 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; m := m ** k.decExp;return (int) m;

}

CALF ExampleRSA 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 ExampleSpecification file

def const pq : int := 35;def const d : int := 11;def const e : int := 11;

CALF ExampleGenerated 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 (veryimportant for practical usage)Improving the generation and solving of constraints initerative statementsImproving the module system (object oriented?)Publication of results