Messages in this thread |  | | Date | Mon, 16 Oct 2000 11:57:05 +0000 | From | Marc Mutz <> | Subject | Re: A patch to loop.c for better cryption support |
| |
Ingo Rohloff wrote: > <snip> > > I can convert the stuff _in place_ (it actually works, anyone please > > complain loudly if it shouldn't) even when my 'cryptfile' is /dev/hdax > > and I don't have sizeof(/dev/hdax) space left on my hard drives. > This could be dangerous. I'm not sure that the kernel handles > this kind of concurrent access to the same encrypted blocks > correctly. (I admit, that I think it should work but it still might > be dangerous...) >
I also think it should work, because dd has to read the block before writing it. By the time dd has the block and starts writing, the kernel should have no business any more with that read request. The bs=4k is needed in the case where the underlying filesystem has that blocksize. The current method then results in a 4k encryption chunk size. Reading the dd default of 512 bytes and writing them back before the rest of the 4k chunk has been read, would result in garbage read and subsequently written. I have actually tested this with a 100+ Mbyte filesystem. It is currently the only way to change the passphrase and/or the cipher used.
<snip> > > IV generation is what I am worried about. > > There is a paper about why it is a bad idea to use > > sequence numbers for CBC IV's. I just have to find the reference to it. > Does this mean sequence as in 0,1,2,3,4 ... or does this mean > any pre-calculate-able sequence ? In the former case we might just use > a simple one way hash-function over the requested sector number. >
I guess it means 0,1,2,3,4..., but you might want to check http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt I have not gotten around to reading it, but it is cited in one of the papers that are already on NIST's "Modes of Operation" Workshop page. (see http://www.nist.gov/aes).
> In the latter case, we might be able to use a message digest algorithm > which includes the sector number and part of the key. > (Both approaches slow the encryption further down, but for > security concerned people this doesn't matter...) <snip>
If we use hashes, then we can make the following (taken from Appl. Crypto.):
Let P[0]..P[N] be the N plaintext blocks, each the size of the cipher block size, of a 512 byte encryption chunk. Let H be a message digest (e.g. SHA-1), with the digest trunctated to the cipher's block size. Let E the cipher, K the key, C[0]..C[N] the ciphertext. Calculate h=H(P[2..N]). Encrypt P[0]..P[N] in CBC mode, using h as IV.
To decrypt, first decrypt C[2..N] with C[1] as IV, then calculate h=H(P[2..N]) and decrypt C[0,1] with h as IV.
Marc
-- Marc Mutz <Marc@Mutz.com> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics
PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
- 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/
|  |