Search in Book Reviews

The focus of the book is on developing the functions etc. necessary to program the RSA algorithm. This includes the need to support a large integer type with modular arithmetic, exponentiation etc. The first part of the book is dedicated to developing this in C. The second part provides a C++ class built on top of the C. The author then spends a chapter on the subject of implementing and using the RSA algorithm. After two brief chapters on testing the C++ large integer class and on considering future directions the author concludes with a chapter describing Rijndael which is the successor to the DES (which is now considered to lack sufficient security) At the end of the book you will find a number of appendices that provide lists (but why are they not in alphabetical order - a horrible though crosses my mind, perhaps the translator is responsible for the actual representation of the code) of such things as the C functions, C++ functions and the macros used in the code which permeates this book.

In the introduction the author comments on his use of the old version of operator new that does not use exceptions. It is possible that the efficiency of code with exceptions is an issue, rather than, as the author claims, lack of universal support for them in C++ compilers. However it should also be noted that the author's C++ style is not exception safe. He also avoids using bool even when most C++ programmers would expect its use (for example for the return value of operator==()).

In the introduction the author legitimately comments that readability of code has, in this context, take second place to performance. Note that I have absolutely no problem with this. Cryptography is computationally intense and is a classic example of a problem domain where the programmer should strive to achieve maximum speed at almost any cost. However that is not an excuse for making code less readable on a line by line basis.

The authors naming conventions are amongst the worst that I have come across in a long time. He makes extensive use of macros. With two exceptions he avoids lower case letters in his pre-processor ids But why does he use r0_l to r15_l for macro names for registers, and why does he have a function macro called clint2str_l as well as CLINT2STR_L when both are replaced by the same expansion? However, much worse to my mind is that CLINT is a typedef and LINT is a class name.

The naming convention that sticks in my gullet is that the author appends '_l' (underscore el) not only to all global names but also to almost all local and class scope ones. I can think of few worse letters to select for such a purpose than el, which is actually indistinguishable from one in some commonly used screen fonts, and very difficult in the rest. But why use this convention for even strictly local variables? It would have made much more sense to work a little harder at choosing contextually intelligible names.

If you want to understand the numerical tools required to implement modern cryptographic programmes this is a reasonable book to study, but the author (and possibly the translator) have done you no favours by using a coding style/naming conventions that are unhelpful to say the least.