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 PhysicsPGP-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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:08 EST