Rating: 

and a pretty good introduction to Java Cryptography Architecture and its extensions (JCE). One can

quickly grasp the necessary details it takes to write one's own Java code that makes use of

cryptographic functions. However, I must confess there are better books on the market to enter

the subject of cryptography. Not that Knudsen's book would not make a decent intro into the

field but if you want to become a Java programmer that understands and knows to deal with more

than some cryptographic concepts/algorithms/protocols you need to consult other literature such

as Schneiers "Applied Cryptography" which has gotten a bit long in the tooth, though, or Menezes/

Oorschot/Vanstone "Handbook of Applied Cryptography" which is oriented more to mathematical

reader. Notice also that the field of cryptography is ever-evolving so what is considered secure

today might be insecure tomorrow. A famous example is the notorious DES algorithm which was broken

by cryptanalysts a few years ago and not only because of its comparatively short keysize but

also of other weaknesses.

Furthermore, I like to comment on a few spots where the author's handling with cryptographic

attainments is a bit too lax. I am referring to page 193 of 1998 edition. He wrote " ..., El-

GamalCipher will fill up an incomplete block with zeros, but it is unable to ..." This kind of

"padding the last block with zeros" is considered bad practice in the cryptographic community

and should be avoided because an attacker might exploit these known plaintext bits of the last

block. A better practice is to fill the remaining space of a block with random bits. I think

the author should have mentioned this factor somewhere but unfortunately he has not.

Next, I am referring to page 184, section "Key Pair Generation", item 2. He wrote "Choose two

other random numbers, g and x, both less than p." You should not choose both variables g and x

this way because g serves a special purpose. Variable g is known to be a primitive element (aka.

generator) of the group Z[p] where p is the prime modulus. A generator generates _all_ p-1 elements

of a group Z[p]. A random number, element of Z[p], not being a primitive element generates a

subgroup of Z[p]. The number of elements in this subgroup might be _significantly_ less than the

number of elements of the original supergroup. Consider the following calculation to show how many

primitive elements there are for a group Z[p] with a 2048 bit prime p.

"HAC" is an acronym for "Handbook of Applied Cryptography" mentioned above.

1 2 3

P(X) = Phi(Phi(p))/p-1 = Phi(p-1)/p-1 > (p-1/6 ln ln (p-1))/p-1 = 1 / 6 ln ln (p-1)

P denotes the probability,

X is the random variable that a number in the range from 1 to p-1 is a primitive element.

1: is by the Fact 2.132, iii

2: is by the Fact 2.101, i

3: is by the Fact 2.102 for p-1 > 5

So if the number of bits of p-1 is 2048 bits then we get 1 / 6 ln ln (p-1) ~ 0.023

That means only every 44th number is a generator and in my opinion this strongly disqualifies

the "any random number" approach by the author as a secure solution.

Do not get my wrong, the "any random number will do" approach might be appropriate for a book

that concentrates on teaching Java cryptography implementation aspects, such as this book, not

elaborating on an all-time secure solution. But if this is so the author is supposed to mention

it somewhere in the text which, unfortunately again, did not happen.

If you want to implement a really secure ElGamalCipher you need to consider precomputed big safe

primes and their associated generators. You can have a look at RFC2412 and at the internet draft

draft-ietf-ipsec-ike-modp-groups-04.txt to be found at www.ietf.org. I think this is a pretty

good excercise for students who mastered the basics.

Overall, I strongly encourage the author to revise the first edition and be a bit more rigorous

on security aspects of the implemented algorithms.