Messages in this thread | | | Date | Sat, 14 Oct 2000 14:57:28 +0000 | From | Ingo Rohloff <> | Subject | Re: A patch to loop.c for better cryption support |
| |
> BTW, kerneli would also not handle the case of switching block sizes anyways, > with relative IVs or not, because it does not restart its CFB chain inside > the device blocks every 512 byte blocks with a new IV. My (inofficial) patch set for twofish and blowfish does though :-). I'm not sure if the CBC modes at the moment reset the Chain at all. (I have to have a closer look at the kerneli-patches... But this has to wait until tuesday, because that's the day of my last exam in university.)
> When you switch > from a bigger block size to a smaller you would need backwards peeking to > earlier blocks (and know the block size anyways). hmm hmm. I think its' possible without that: Example:
Blocksize 1024, so for example the chunk from offset 5120 - 6143. would be encrypted with IV 5.
Know we switch to 512 Bytes. to encrypt/decrypt from offset 5120 - 6143 you use the IVs 10 and 11.
So I don't see the problem.
> Similar problem for going to bigger blocks. > Ingo's change makes it a bit less painless, but > still not trivial to handle.
The only problem I see ARE bigger blocks.
Imagine the example again. Chunk 5120 - 6143, encrypted as two sectors with IVs 10 and 11.
Now we want to use 1024 as Block size and encrypt the chunk as a whole with an IV of 5.
What happens if a program (lets say "dd bs=512") requests the chunk from 5632 - 6143 ? As far as I can tell the upper layers won't align the request to a block of 1024 bytes. To decrypt/encrypt the data correctly we would have to read and decrypt chunk 5120 - 6143 and return only 5632 - 6143. If a write access happens this is even worse, because we would have to: read the block, update the block, write the block. (Without the read we can't update the data correctly.)
THAT's why I want to use sectors as maximum unit... so long Ingo - 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/
| |