Obfuscation of Abstract Data-Types - Rowan

CHAPTER 3. TECHNIQUES FOR OBFUSCATION 54
The proof of an assertion for f O will require two cases (one for p(x) and one
for ¬p(x)) and so to make an assertion obfuscation, we just have to insert a
predicate. To prevent this, we require that each case in a definition gives rise
to a different expression.
At each stage of a proof, we aim to use definitions and properties associated
with the innermost operation. For instance, if we had an assertion
f (g (h x))
Then we first deal with h before we deal with g. This method will not always
produce a minimal length proof but will help in making our proofs consistent.
Where possible, we aim to use only one result at each stage so that we do not
make proofs shorter by using many results in the same stage. We should also
ensure that at each stage, we make progress towards our goal. In particular, we
should not have any cycles in our proofs and so we insist that at each stage we
do not have an expression that we have seen before (although we may use the
same result many times).
For our definition of obfuscation, we will not be concerned with syntactic
properties such as the name of operations, the layout of operations and whether a
definition uses standard operations (for example, head or foldr). For example, we
do not make distinctions between guarded equations and (nested) conditionals.
So we consider the following two expressions to be equivalent:
f x ∣∣∣∣∣∣∣∣
g 1 = s 1
g 2 = s 2
. . .
otherwise= s n
≡
f x = if g 1 then s 1
else (if g 2 then s 2
· · ·
else s n · · ·)
The total number of results that a proof takes may not be a detailed enough
measure. For instance, suppose we have two proofs: the first has one case and
uses n results and the second has n cases each of which uses one result. Both
of these proofs use n results in total but is one proof more complicated than
the other? We propose that the first is more complicated as we claim that it
is harder to do one long proof than many short proofs. Thus the number of
results used is not a satisfactory measure — we need to consider the “shape” of
a proof.
3.4 Proof Trees
How do we measure the shape of a proof? We will compare proofs by drawing
proof trees — using trees gives an indication of the “shape” of a proof. Note
that our style of proof lends itself to producing proof trees.
From the last section, we consider a proof to be a series of cases. Each case
is proved using the derivational style where each stage is either a definition, a
law or a property of an operation. This gives us a way of defining a grammar
for proof trees:
Proof =
Case =
Result =
Seq Case
Stage Case (Seq Result) | End
Definition | Law | Proof