> From: Travis H. [mailto:[EMAIL PROTECTED]
> On 5/4/06, markus reichelt <[EMAIL PROTECTED]> wrote:
> > Agreed; but regarding unix systems, I know of none crypto
> > implementation that does integrity checking. Not just de/encrypt the
> > data, but verify that the encrypted data has not been tampered with.
> Are you sure?  There's a aes-cbc-essiv:sha256 cipher with dm-crypt.
> Are they using sha256 for something other than integrity?
That sounds like they are applying sha256 to the passphrase, and not for adding 
redundancy to the data. The big problem with disk encryption is to achieve 
nondeterministic encryption and authenticated encryption.

Nondeterminism requires a new IV each time you encrypt a sector (I am talking 
here of sectors, to avoid confusion with blocks of a block cipher) for disk 
storage. The reason for nondeterminism is that otherwise at least common 
prefixes of the old and new contents show up in the ciphertext. 

Authenticated encryption basically prevents tampering with ciphertext going 
unnoticed. However, some while ago I read a paper somewhere pointing out that 
the lower block layer at least in linux is not capable of dealing with data 
errors due to authentication failure. If interest is, I could try to dig out 
the reference.

Nevertheless, if you want to add extra IVs (not determined deterministically 
from the block number) and authentication tag, you could store them in extra 
sectors which do not show up in the plaintext-device. Caching should be not too 
difficult. However, if the authentication tags / IVs cannot be read anymore due 
to an oops-up in the code, disk failure etc. you might run into serious 
problems, as now multiple sectors are affected.

Maybe there are other solutions?


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to