Linux RNG paper

[Kuehn, Ulrich]

> From: Travis H. [mailto:solinym at gmail.com]
> 
> On 5/4/06, markus reichelt <ml at mareichelt.de> 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?

Regards,
Ulrich

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com