I think an encrypted file system with builtin integrity is somewhat
interesting however the threat model is a bit broken if you are going
to boot off a potentially tampered with disk.

I mean the attacker doesnt have to tamper with the proposed
encrypted+MACed data, he just tampers with the boot sector/OS boot,
gets your password and modifies your data at will using the MAC keys.

I think you'd be better off building a boot USB key using DSL or some
other small link distro, checksumming your encrypted data (and the
rest of the disk) at boot; and having feature to store the
keyed-checksum of the disk on shutdown some place MACed such that the
USB key can verify it.  Then boot the real OS if that succeeds.

(Or better yet buy yourself one of those 32GB usb keys for $3,000 and
remove the hard disk, and just keep your encrypted disk on your
keyring :)

Of course an encrypted network filesystem has other problems... if
you're trying to actively use an encrypted filesystem backed in an
unsecured network file system then you're going to need MACs and
replay protection and other things normal encrypted file system modes
dont provide.


On Thu, May 04, 2006 at 01:44:48PM -0500, Travis H. wrote:
> 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?
> I guess perhaps the reason they don't do integrity checking is that it
> involves redundant data, so the encrypted volume would be smaller, or
> the block offsets don't line up, and perhaps that's trickier to handle
> than a 1:1 correspondence.

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

Reply via email to