Re: MI a good use for encryption? -- MI400


>> How do you unencrpyt the data?  How do you keep the encrypted value from
>> always being the same for the same text

>in short: you use a "chaining" technique where each block
>of data is xor'ed with the previous encrypted block before
>being encrypted. For the first block you can use anything
>you like (e.g. filename or current date). This first block
>must vary from message to message, but need not be
>secret.

Actually, I think you'll find that the standard references do not require
the "first block" (usually called the "intialization vector" or sometimes
"initial vector") to be anything special.  In fact, in practical systems,
the first input block is sometimes invariant and known to be so.  DES (and
any successor in commercial use) must deal with the idea that the entire
message (or, at least, large numbers of input blocks) will be known to the
attacker.  Much computer output is, after all, highly predictable and
stereotyped.  This same concept applies to the notion of the initialization
vector and means it isn't cryptographically significant.

In the usual use, the eight byte block of cipher text (output) block N-1 is
used to XOR with the input of plaintext block N.  For block one, the
initialization vector is substituted for the nonexistent "previous output"
and not otherwise used.  Therefore, an attack that succeeds on any block
between 2 and N will eventually reveal the initialization vector anyway.
For various pragmatic reasons, the prior output block is used for chaining
an exclusive orred with the current input block.  If the attacker knows the
current 8 bytes of plaintext (a standard assumption for at least some
blocks), then the actual input to the DES algorithm proper is known even
when chaining is used.  This is not a security problem!  DES as a thing in
itself is considered secure even if no chaining is used.

The "IV" can be kept secret, but the system does not depend on its secrecy.
The only critical secret is the key itself.

The main point to block chaining is to prevent a variety of special
attacks.  Consider, for instance, a file consisting entirely of 64 bit
floating point numbers, perfectly aligned.  DES encrypting these without
chaining is a bad idea.  It may be possible to recover "enough" of the
original file by attacking it as an ordinary simple substitution (a classic
and weak system) based on a frequency count of eight byte units.  Chaining
defeats this trick.  Clearly, in this special case, DES alone would be
irrelevant and become instead an elaborate simple substitution cipher.
This ought to be enough in itself to alert the savvy coder to do chaining
regardless of the input text's nature.  The point of chaining is to ensure
it is actually DES that must be attacked and not some trick of this sort.

Interested parties should read, at minimum, FIPS 46-3 (most recent Data
Encryption Standard publication), FIPS 81 (modes of DES, most important to
the present discussion, see especially Cipher Block Chaining, with two
corrections issued overall) and also ANSI standard X9.52.  See also:
http://csrc.ncsl.nist.gov/cryptval/des/des.txt which is a bit dated, but
still pretty complete list of relevant publications.

When reading FIPS 46-3, it is most helpful to realise that the bit order is
from 1 (most significant bit) to N where N is usually 32, 48, 56, or 64
depending on the context.  You also read left to right and top to bottom as
I recall in the various bit permutation listings.



Larry W. Loen  -   Senior Linux, Java, and iSeries Performance Analyst
                          Dept HP4, Rochester MN