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

1. Dependent Types For Cryptography
Implementations
Paulo Silva
Manuel Barbosa
HASLab, Departamento de Informática
Universidade do Minho
Portugal
June 14, 2011

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. 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

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. 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. 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. 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

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-defined parametric data types
Explicit constant definitions
Module system (allowing module instantiation)

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. 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

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 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

12. 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

13. 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

14. 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

15. 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

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. 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. CALF Example
Specification file
def const pq : int := 35;
def const d : int := 11;
def const e : int := 11;

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. The Overall Picture

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