Cryptography Reference
In-Depth Information
void
ul2clint_l (CLINT num_l, ULONG ul)
{
*LSDPTR_L (num_l) = (USHORT)(ul & 0xffff);
*(LSDPTR_L (num_l) + 1) = (USHORT)((ul >> 16) & 0xffff);
SETDIGITS_L (num_l, 2);
RMLDZRS_L (num_l);
}
To end this chapter we shall discuss a function that carries out a validity
check of a memory object for the
CLINT
number format. Control functions of
this type are called as needed whenever “foreign” values are imported into a
system for further processing into a subsystem. Such a subsystem can be, for
example, a cryptographic module that before every processing of input data
must check whether it is dealing with valid values or arguments. Checking at
run time whether the assumptions about the input values of a function have
been met is good programming practice, one that helps to avoid undefined
situations and that can contribute decisively to the stability of an application. For
testing and debugging this usually takes place with
assertions
, with the help of
which run-time conditions can be tested. Assertions are inserted as macros and
can be decommissioned for the actual running of the program, usually during
compilation via
#define NDEBUG
. In addition to the
assert
macro of the C standard
library (see [Pla1], Chapter 1) there are a number of further implementations
of similar mechanisms that take various actions when the test conditions are
violated, such as listing recognized exceptional conditions in a log file, with or
without program termination in the event of an error. For extensive information
in this area the reader is referred to [Magu], Chapters 2 and 3, as well as [Murp],
Chapter 4.
The protection of the functions of a program library like the FLINT/C package
against being passed values that lie outside of the domain of definition of the
respective parameters can occur within the invoked functions themselves or
within the calling functions, where in the latter case the responsibility lies with
the programmer who employs the library. For performance considerations, in
the development of the FLINT/C functions we did not test every passed
CLINT
argument for a valid address and possible overflow. The thought of carrying out
multiply redundant checks of the numerical format in thousands of modular
multiplications of an exponentiation moved the author to offload this control
task to the programs that use the FLINT/C functions. An exception is the passing
of divisors with the value zero, which is checked as a matter of principle and if it
occurs is acknowledged with a suitable error notification, even in all the functions
for residue class arithmetic. The code of all the functions was particularly
carefully tested to make sure that the FLINT/C library generates only valid
formats (cf. Chapter 12).
