--UU3/NDCWdTFtf5mh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 10, 2005 at 09:24:19PM -0400, Ted Unangst wrote:
> it's my understanding that cgd doesn't provide any protection against=20
> replay or other injection attacks. =20

Correct (in the cryptographic sense; you're still better off with it
than without for every-day purposes).  Simple block shuffling or other
such means won't be effective in producing predictable (ie, targetted
malicious) plaintext, because the IV is generated per-block from the
key.  An older version of the same block could be replayed, however,
and other more subtle bit-twiddling attacks won't be automatically
detected and rejected at the cgd layer.

> this wasn't really addressed in the paper, except in passing.  was
> it considered and rejected as outside problem space?  too difficult?

Something like that.  One of the basic desires in cgd was not to add
storage overheads or complexity to the geometry calculations: it is a
one-to-one mapping of blocks to the underlying device.  Even the
temptation to record parameters in a 'header' block at the start was
avoided (and separating this out into the cgd parameters file has
other advantages, allowing this to be stored separately for a form of
two-factor key generation).

> essentially, does anybody care and how much?=20

Yes, it has certainly been discussed.

It is, cryptographically similar and compatible to what cgd does now,
and could be easily done there with appropriate key-handling synergies
and so on. However, it's somewhat at odds from a storage point of
view.

> if i wanted to authenticate the data on the disk, what's the best
> approach?

Solving this problem basically involves extra data, for something like
a HMAC per block, that has to be stored somewhere.  (If you know of
another way, please say so! :)

This is not dissimilar to storing raid-5 parity, for example, and
there's some thought that this functionality might be useful as a
separate 'authenticated disk' layer, that could be stacked as
appropriate in a mix of raid, cgd, and similar devices to suit the
user's particular requirements. (There's the age-old question of
encrypt-then-sign vs sign-then-encrypt, with different appeal for
defense against different threat models).

Adding this storage overhead also introduces atomicity issues, because
the size of your disk block just increased over that of your physical
block, so your storage layer has to include transactional mechanisms
to handle this as well.

(Some thought has gone into the idea of formatting disks with larger
sector sizes to accomodate this overhead, as some storage array
vendors do for non-keyed hashes, but that's not a general-purpose
solution)

Basically, this was determined to be too much unwanted complexity for
cgd - at least in its first iteraton/current incarnation, which aims
for simplicity.

Thus it was one of the biggest ironies, to me, in the recent
discussions about gbde and all of its additional complexity, that the
additional storage overheads included in its construction did not
include a HMAC for this purpose.  All the penalties had been paid,
without the realisation of any of the potential benefits.

> attack scenario is kinda like this.  some kind of network where the users=
=20
> trust their laptops, but possibly not the large usb drive left in the=20
> office over night, and want to detect tampering.=20

I like the example of a SAN, or vnd file sitting on a shared
fileserver, where I don't really know or trust the storage admins much
more than to store the data (availability).  I want confidentiality,
certainly, but also integrity from the cryptography.  Right now, I
need to look to separate tools for that.  Keeping cgd params files
separate from the cgd storage is also somewhat beneficial, as outlined
above.

I have some half-formed thoughts about ways to use the fss(4) device
for a form of 'signed snapshots plus trusted-local-storage journal'
mechanism, but haven't really pursued them (in part because the
behaviour of fss is backwards of that needed for typical usage in this
scenario; it records copies of old blocks for a roll-backwards view,
rather than new blocks for play-forward).

There are also file-level integrity solutions (eg, veriexec) that can
be useful, but I'd very much like to see a block-level solution to
complement these.

--
Dan.
--UU3/NDCWdTFtf5mh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFCgWsAEAVxvV4N66cRAi7uAJ9aiZT9mxd6gEKNKeWpWUwDT4zy4wCfdsVm
bLv1pQqJ6AuOd7UQ+XF0uw8=
=G5Wn
-----END PGP SIGNATURE-----

--UU3/NDCWdTFtf5mh--