lkml.org 
[lkml]   [2000]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A patch to loop.c for better cryption support
On Mon, Oct 16, 2000 at 06:23:32PM +0000, David Wagner wrote:
(snip)
>
> Using SHA1(sector #) should be ok, as long as you don't expect your
> plaintexts to have similar patterns. (If you do think your plaintexts
> might begin with the SHA1-hashes of sector numbers, you could use a
> "keyed hash", or more precisely, a pseudorandom function. For instance,
> you could encrypt the sector number using a secret IV-generation key.)

I think our discussion may be drifting a bit. Perhaps revisiting
some crypto system fundamentals might be helpful.

The loop device driver provides a transfer module API, nothing more.
Placing encryption code (which includes hashes) into the loop device
driver is not appropriate. The crypto functionality should be wholly
contained in the transfer modules.

IMHO, all that we should ask of the loop.c transfer API is:

a) Type of transformation needed (encipher or decipher).
b) Data bits to be transformed and length.
c) Key bits and length.
d) A *UNIQUE* IV seed associated *ONLY* (!!) with the
data in step b) above.

A design goal of all modern crypto systems is that the security
of the system rest soley in the key. IV's must be unique, not
secret.

Unique IVseed means "never duplicated". An increasing block | sector #
is one means to meet the unique requirement. Transfer modules are
free to further mangle the IVseed via whatever method they feel is
appropriate.

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.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.066 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site