Cryptography Reference
In-Depth Information
To be sure, one has the option of employing as a test vehicle another arith-
metic software package by creating the necessary interface and transformations
of the number formats and letting the functions compete against each other.
However, there are two strikes against such an approach: First, this is not sporting,
and second, one must ask oneself why one should have faith in someone else's
implementation, about which one knows considerably less than about one's own
product. We shall therefore seek other possibilities for testing and to this end
employ mathematical structures and laws that embody sufficient redundancy
to be able to recognize computational errors in the software. Discovered errors
can then be attacked with the aid of additional test output and modern symbolic
debuggers.
We shall therefore follow selectively a black box approach, and in the rest of
this chapter we shall hope to work out a serviceable test plan for the run-time
tests that follows essentially the actual course of testing that was used on the
FLINT/C functions. In this process we had the goal of achieving high C1 coverage,
although no measurements in this regard were employed.
The list of properties of the FLINT/C functions to be tested is not especially
long, but it is not without substance. In particular, we must convince ourselves of
the following:
•
All calculational results are generated correctly over the entire range of
definition of all functions.
•
In particular, all input values for which special code sequences are supplied
within a function are correctly processed.
•
Overflow and underflow are correctly handled. That is, all arithmetic
operations are carried out modulo
N
max
+1
.
•
Leading zeros are accepted without influencing the result.
•
Function calls in accumulator mode with identical memory objects as
arguments, such as,
add_l(n_l, n_l, n_l)
, return correct results.
•
All divisions by zero are recognized and generate the appropriate error
message.
There are many individual test functions necessary for the processing of
this list, functions that call the FLINT/C operations to be tested and check
their results. The test functions are collected in test modules and themselves
individually tested before they are set loose on the FLINT/C functions. For testing
the test functions the same criteria and the same means for static analysis are
employed as for the FLINT/C functions, and furthermore, the test functions
should be run through at least on a spot-check basis with the help of a symbolic
debugger in single-step mode in order to check whether they test the right thing.
In order to determine whether the test functions truly respond properly to errors,
