Cryptography Reference
In-Depth Information
The 'random pool' randseed.bin as well as the MD5 hash value from the first
two Kbytes of the plaintext, a time marker, and non-initialized data are used
to generate a session key. Subsequently, the pool is encrypted once more with
the key just used and the IV so that no conclusions can be drawn from the
content of randseed.bin on the keys and the IV.
The first two Kbytes of the message should actually be held in memory and
not be read from the disk. But this way, PGP cannot encrypt data streams
(i.e., work as a filter), as is customary in UNIX, for example, helping to save
resources. Though PGP works like such a filter when the
f switch is set,
in reality the entire input is written to the disk, as in MS-DOS, and then read
by PGP. Compared with a real filter, this is much slower, especially with long
files, and a serious and unnecessary security risk.
But there is another reason why PGP cannot work like a filter; more about it
in a minute.
Compression and Filter Mode
A message is compressed before it is encrypted by default for reasons of higher
security and lower phone costs. (You recall from Section 3.6.4 that compression
doesn't necessarily introduce more security. But as long as not even a chosen -
plaintext attack against IDEA is known, we don't have to worry.)
The compression algorithm has to be able to jump back and forth within the
input data. This is the second reason why PGP cannot be used as a real filter.
Again, this reason is not mandatory. The highly efficient, popular, and free
compression program gzip (available for many operating systems) can work as a
real filter. Sure, PGP will determine whether or not compression is worthwhile,
and leave it if it isn't. But it wouldn't be a problem to suppress this test if the
user so wishes.
At least for the event that a user disabled compression, PGP should work as a
real filter.
IDEA Encryption
PGP uses IDEA in CFB mode (see Section 5.1.1). This means that it can do
away with padding, and what's more, it prevents insertion attacks (which are
actually prevented by the random IV and the random session keys anyway). As
a reminder, this mode basically re-encrypts the last ciphertext block and XORs
it with the next plaintext block. This often looks slightly different in practice.
Search WWH ::




Custom Search