Apologies for any spelling or other mistakes. I'm on a bus in NYC
traffic, and the driver apparently thinks he's in a NASCAR race, so
things are bit bumpy.
On 03/02/2011 10:30 AM, Edward Shishkin wrote:
OK. So, I guess AES_cfb128_encrypt() is what we exactly need?
I don't know if I'd quite go that far. It seems like a good candidate,
but it would still be nice to understand the relative merit of CFB vs.
OFB vs. CTR modes, or different ciphers, or different libraries. The
best candidate is likely to be the one that (a) allows encrypting odd
numbers of bytes without padding, (b) meets or exceeds NIST etc.
recommendations for encryption strength, and (c) performs best.
The essiv generator doesn't have any requirements for data-block size.
The following link might be more relevant:
http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/472
It seems from those descriptions that ESSIV is just a way to choose
IVs. Therefore it doesn't introduce any new block-size issues but it
doesn't solve any old ones either. If I need to encrypt three bytes
using a 128-bit block cipher, I'll still need something like CFB/OFB to
make it behave like a stream cipher or I'll need some way to deal with
the 13-byte "residue" that I'm saving to enable subsequent decryption.
That's true regardless of how I'm choosing IVs.
We still need to deal
> *somehow* with the issue of odd offsets (including but not limited to
> EOF).
What is the "odd offsets issue"? Could you please
describe it in more details?
See above. If an N-byte block cipher has the property that a change in
any byte of the input affects all N bytes in the output - and ciphers
without this property are jokes - then we must store all N bytes in
order to facilitate decryption later. If the user is actually only
writing K<N bytes at EOF, and we simply write all N bytes of ciphertext,
then EOF in the inode will be wrong. Therefore, we need to store either
the extra bytes or the true EOF value somewhere else . . . or use an
encryption method that allows us to write only K bytes and still
decrypt later (the approach we're using currently). This same problem
occurs when writing into a "hole" in the file, though in that case we
also have the option of just doing a read-modify-write on some multiple
of N bytes (which will read as zero initially).