> 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/
This archive was generated by hypermail 2b29 : Sat Oct 14 2000 - 08:55:21 EDT