On Sun, Feb 13, 2000 at 11:06:28AM +0100, Andi Kleen wrote:
> On Sun, Feb 13, 2000 at 07:06:20AM +0100, kernel@draper.net wrote:
> >
> > I considered and rejected passing relative block numbers to the transfer
> > modules for use as IV seeds. The last thing I wanted to see was
> > duplication of ciphertext on my disk drive (occurs when multiple looped
> > filesystems exist on the same drive using the same cipher and key).
> > Such duplication at minimum is "interesting" to the cryptanalysis, and
> > at worst facilitates recovery of plain text.
>
> There is an elegant way to solve this problem: do a hash over the plain
> text data without the first block and use that as the IV. Then do CFB.
> On decryption you decrypt everything but the first block and calculate
> the hash, then use the hash to get the first block (this is from
> Peter Gutmann's SFS). Cost are a few more cycles.
The term "block" is ambiguous here. I assume your use of the word is a
unit of encryption (usually 64 bits). Otherwise we would have to pass the
entire filesystem to derive the IV, and that would be much too expensive.
Your argument depends on the degree of entropy in the plain text. IV's
must never be duplicated. Many disk blocks in a filesystem can and do
contain identical plain text and therefore would hash to identical IVs,
and would thus encrypt to identical ciphertext. Absolute disk block
numbers (on the same disk) can never be duplicated. That's why I chose
to use them.
Reed H. Petty
rhp@draper.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:25 EST