Block Ciphers - Modern Cryptanalysis: Techniques for Advanced Code Breaking - page 116

Thus, a pseudorandom number generated of 1100 would represent 0.1100 in binary, or 0.75 in decimal.
To obtain an integer (say, between 0 and k), multiply by k and truncate. (The natural inclination is to just
take the modulus with the higher end of the range, k. This would lead to more biased results, since the
least significant digits would be more influential.)
7. Change a after every m /1000 numbers generated, or so, to keep the numbers from going “stale.”
Further guidance on several of these points, as well as how to implement a linear congruential random num-
ber generator without floating point arithmetic, can be found in Reference [6].
4.14 One-Time Pad
I'll end this chapter with an idea important to cryptography and cryptanalysis.
Vernam and Mauborgne proposed that, where you have enough key material as you do material to send, and
reliable, secure ways to transfer the key material (or some system), then even a simple Vigenère cipher is com-
pletely secure [5, 16]. In such a case, a different key could be used for each block for encryption. This system
is usually called a one-time pad . (The underlying encryption can be nearly anything, such as a polyalphabetic
substitution or simple XOR of the key material with the plaintext.)
The claim of a one-time pad is technically true, but only in the ideal case.
For example, if both parties communicating had a particular topic that they would pull key material from, as
needed, then they must merely stay synchronized with their material to send messages. The two parties could
use the Vigenère Tableau, using letters in words to encrypt the text. It's easy to see that this would completely
defeat Kasiski's method, since there are no repetitive patterns of any meaning left.
But, there are three issues: coming up with enough padding material for the one-time pad, synchronizing,
and protecting the pad.
Transmitting a lot of information may be very difficult with a one-time pad, because we need one bit of key-
ing material for each bit to be sent. We can't cheat by, say, using a pseudorandom number generator, as above,
because there would then be patterns inside the ciphertext that could be exploited. Only a true source of random
material that each communicating party can have a copy of will do. In the old days, a large telephone directory
or a large topic could provide a large set of information to work with (using the letters as keys for a substitution
cipher, or deriving bits from the letters for a digital cipher). These aren't truly random, but can be fairly close,
depending on how they are used. Today, however, with potentially megabytes, gigabytes, terabytes, petabytes,
or even exabytes and beyond needing to be encrypted, the limited amount of information in even these large
volumes would be insufficient.
Synchronization is another problem. What happens if a message is lost in transmission when using a one-
time pad? Future received messages will then simply start being decrypted as garbage. Sophisticated users of
this system could possibly overcome this by using appropriate protocols — for example, once one of the users
receives a garbled message, both send the previous message they had sent, starting, say, at the next page whose
page number is divisible by 10. This way, they can reset their usage of the key material. However, using even
this simple protocol, if it is publicly known, can endanger the cipher, since the adversaries will then know a way
to “reset” the cipher to a potentially known pattern.
Finally, protecting the pad is critical: All of the security rests in this one-time pad. The problem is the key
distribution problem — how do we transfer this large amount of keying material securely? Furthermore, if we
already had this secure channel in place to transmit the very large one-time pad, why can't we just use the same
secure channel to send our data? We need a secure channel to establish a secure channel!