About the Software

Team-Fly

---

The software described in this book constitutes in its entirety a package, a so-called function library, to which frequent reference will be made. This library has been given the name FLINT/C, which is an acronym for "functions for large integers in number theory and cryptography."

The FLINT/C library contains, among other items, the following modules, which can be found as source code on the accompanying CD-ROM:

Table 1.1: Arithmetic and Number Theory in C in Directory flint/src

flint.h	header file for using functions from flint.c
flint.c	arithmetic and number-theoretic functions in C
kmul.h,c	functions for Karatsuba multiplication and squaring
ripemd.h,c	implementation of the hash function RIPEMD-1606

Table 1.2: Arithmetic and Number Theory in C++ in Directory flint/src

flintpp.h	header file for the use of functions from flintpp.cpp
flintpp.cpp	arithmetic and number-theoretic functions in C++. The module uses the functions in flint.c

Table 1.3: Arithmetic Module in 80×86 Assembler (see Chapter 18) in Directory flint/src/asm

mult.asm	multiplication, replaces the C function mult() in flint.c
umul.asm	multiplication, replaces the C function umul()
sqr.asm	squaring, replaces the C function sqr()
div.asm	division, replaces the C function div_l()

Table 1.4: Arithmetic Libraries in 80×86 Assembler (see Chapter 18) in Directory flint/lib

flinta.lib	library with assembler functions in OMF (object module format)
flintavc.lib	library with assembler functions in COFF (common object file format)
flinta.a	archive with assembler functions for emx/gcc under OS/2
libflint.a	archive with assembler functions for use under LINUX

testxxx.c[pp]

test programs in C and C++

Table 1.6: RSA Implementation (see Chapter 16) in Directory flint/rsa

rsakey.h	header file for the RSA classes
rsakey.cpp	implementation of the RSA classes RSAkey and RSApub
rsademo.cpp	example application of the RSA classes and their functions

A list of the individual components of the FLINT/C software can be found in the file readme.doc on the CD-ROM. The software has been tested with the indicated development tools on the following platforms:

• GNU gcc under Linux, SunOS 4.1, and Sun Solaris

• GNU/EMX gcc under OS/2 Warp, DOS, and Windows (9x, NT)

• lcc-win32 under Windows (9x, NT, 2000)

• Cygnus cygwin B20 under Windows (9x, NT, 2000)

• IBM VisualAge under OS/2 Warp and Windows (9x, NT, 2000)

• Microsoft C under DOS, OS/2 Warp, and Windows (9x, NT)

• Microsoft Visual C/C++ under Windows (9x, NT, 2000)

• Watcom C/C++ under DOS, OS/2 Warp, and Windows (3.1, 9x, NT)

The assembler programs can be translated with Microsoft MASM^[2] or with Watcom WASM. They are contained on the CD-ROM in translated form as libraries in OMF (object module format) and COFF (common object file format), respectively, as well as in the form of a LINUX archive, and are used instead of the corresponding C functions when in translating C programs the macro FLINT_ASM is defined and the assembler object modules from the libraries, respectively archives, are linked.

A typical compiler call, here for the GNU compiler gcc, looks something like the following (with the paths to the source directories suppressed):

 gcc -O2 -DFLINT_ASM -o rsademo rsademo.cpp rsakey.cpp flintpp.cpp flint.c ripemd.c -lflint -lstdc++ 

The C++ header files following the ANSI standard are used when in compilation the macro FLINTPP_ANSI is defined; otherwise, the traditional header files xxxxx.h are used.

Depending on the computer platform, there may be deviations with regard to the compiler switches; but to achieve maximum performance the options for speed optimization should always be turned on. Because of the demands on the stack, in many environments and applications it will have to be adjusted.^[3] Regarding the necessary stack size for particular applications, one should note the suggestion about the exponentiation functions in Chapter 6 and in the overview on page 115. The stack requirements can be lessened by using the exponentiation function with dynamic stack allocation as well as by the implementation of dynamic registers (see Chapter 9).

The C functions and constants have been provided with the macros

•  

  __FLINT_API	Qualifier for C functions
  __FLINT_API_A	Qualifier for assembler functions
  __FLINT_API_DATA	Qualifier for constants

as in

   extern int __FLINT_API add_l(CLINT, CLINT, CLINT);   extern USHORT __FLINT_API_DATA smallprimes[]; 

or, respectively, in the use of the assembler functions

   extern int __FLINT_API_A div_l (CLINT, CLINT, CLINT, CLINT); 

These macros are generally defined as empty comments /**/. With their aid, using the appropriate definitions, compiler- and linker-specific instructions to functions and data can be made. If the assembler modules are used and not the GNU compiler gcc, the macro __FLINT_API_A is defined by __cdecl, and some compilers understand this as an instruction that the assembler functions corresponding to the C name and calling conventions are to be called.

For modules that import FLINT/C functions and constants from a dynamic link library (DLL) under Microsoft Visual C/C++, in translation the macros -D__FLINT_API=__cdecl and -D__FLINT_API_DATA= __declspec (dllimport) must be defined. This has already been taken into account in flint.h, and it suffices in this case to define the macro FLINT_USEDLL for compilation. For other development environments analogous definitions should be employed.

The small amount of work involved in initializing a FLINT/C DLL is taken care of by the function FLINTInit_l(), which provides initial values for the random number generator^[4] and generates a set of dynamic registers (see Chapter 9). The complementary function FLINTExit_l() deallocates the dynamic registers. Sensibly enough, the initialization is not handed over to every individual process that uses the DLL, but is executed once at the start of the DLL. As a rule, a function with creator-specific signature and calling convention should be used, which is executed automatically when the DLL is loaded by the run-time system. This function can take over the FLINT/C initialization and use the two functions mentioned above. All of this should be considered when a DLL is created.

Some effort was made to make the software usable in security-critical applications. To this end, in security mode local variables in functions, in particular CLINT and LINT objects, are deleted after use by being overwritten with zeros. For the C functions this is accomplished with the help of the macro PURGEVARS_L() and the associated function purgevars_l(). For the C++ functions the destructor ~LINT() is similarly equipped. The assembler functions overwrite their working memory. The deletion of variables that are passed as arguments to functions is the responsibility of the calling functions.

If the deletion of variables, which requires a certain additional expenditure of time, is to be omitted, then in compilation the macro FLINT_UNSECURE must be defined. At run time the function char* verstr_l() gives information about the modes set at compile time, in which additionally to the version label X.x, the letters "a" for assembler support and "s" for security mode are output in a character string if these modes have been turned on.

^[2]Call : ml /Cx /c /Gd <filename>.

^[3]With modern computers with virtual memory, except in the case of DOS, one usually does not have to worry about this point, in particular with Unix or Linux systems.

^[4]The initial values are made up of 32-bit numbers taken from the system clock. For applications in which security is critical it is advisable to use suitable random values from a sufficiently large interval as initial values.

---

Team-Fly