----- Original Message -----
From: "Morlock Elloi" <[EMAIL PROTECTED]>
> > There's no need to go to great lengths to find a place to store the IV.
>
> Wouldn't it be much simpler (having in mind the low cost of storage), to
simply
> append several random bits to the plaintext before ECB encrypton and
discard
> them upon decryption ?
>
> For, say, 128-bit block cipher and 16-bit padding (112-bit plaintext and
16-bit
> random fill) the storage requirement is increased 14% but each block is
> completely independent, no IV is used at all, and as far as I can see all
> pitfails of ECB are done away with.

The bigger problem is that you're cutting drive performance by 14%,
considering that people notice a matter of < 10%, people are going to
complain, and economically this will be a flop. A drive setup like this
would be worse than useless, it would give the impression that encryption
must come at the cost of speed. Designing this into a current system would
set the goal of encryption everywhere back.

> Probability of the same plaintext encrypting to the same cyphertext is 1
in
> 65536.

Which is no where near useful. 1 in 65536 is trivial in cryptographic terms,
especially when compared to 1 in approx
340000000000000000000000000000000000000. Additionally you'll be sacrificing
_more_ of the sector to what amount to IV, and in exchange you'll be
decreasing security. If instead in that 512KB block you take up 128 bits,
you'll only lose about 0.02% performance and we were already trying to avoid
that (although for other reasons).
                    Joe

Reply via email to