--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 22, 2005 at 12:38:09PM +1000, Daniel Carosone wrote:
+> On Mon, Aug 22, 2005 at 03:41:06AM +0200, Pawel Jakub Dawidek wrote:
+> > On read, you verify sector1 integrity based on mac(sector1) from secto=
r0,
+> > then you verify sector2 against mac(sector2) from sector0 and you fail=
ed,
+> > so you verify it against mac(sector2) from sectorN+1. And so on.
+>=20
+> Sure, so long as for small writes that update only a subrange of these
+> sectors, we do the whole (new-MACs, data blocks, old-MACs) cycle each
+> time to complete the transaction. =20

(Actually it is: new-MACs, data blocks, old-MACs.)

There are no small writes. visible sector size for upper layers is 8kB.
UFS (at last in FreeBSD) works very nicely with such sectors.
So you have 16 data sectors and 2 metadata sector for every block.
This will take 12% of your disk, which is absolutely acceptable for me.

+> > For me it is safe if we assume writing single sector is atomic.
+>=20
+> (... and that ordering is preserved and write caches are flushed, both
+> which can be achieved at some cost).
+>=20
+> So, with that cleared up..
+>=20
+> How are you preventing replay of old MAC+data+MAC groups, or of
+> specific data blocks and MAC entries within a group?  Either seems to
+> involve some extra metadata (a txn counter and MAC-sector-MAC? in the
+> MAC sectors or elsewhere?), with corresponding storage and transaction
+> overhead.
+>=20
+> How many MACs can you fit in a sector (ie, is N large enough to be
+> useful), especially with the above taken into account?

Unfortunately it won't handle old MAC+data+MAC problem...
There is no counter you can add to the block's metadata to fix it.

As I understand it:
To be able to prevent such attacks, you'd need to have two separate
storage device. The second one could be used for storing current
counters for every sector. You don't need journaling here or anything
like that, you just update the second device after writting to the
first one and always accept greater counters than stored there.

But the problem is that the second device have to be separated.
There should be no way for attacker to access both devices.
And, as you probably susspect, this makes it not very practical.

+> While your proposal is elegant for the simple case, either of these
+> may tip you over the edge to more complex structures.

While your comments are valid and I appreciate them (I really do),
I entered this discussion to actually find some secure and reliable
way to provide device-level integrity verification with your help, guys.
And this conversation could be even more productive, if you stop
treating me as your enemy:)

--=20
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

--ZPt4rx8FFjLCG7dd
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDCYgnForvXbEpPzQRAgkzAJ9+UOvIOCp4LnLj24blb1JQO7m/RgCgrEsD
o2IPqIEeOtsJu0yuKudn008=
=C8yG
-----END PGP SIGNATURE-----

--ZPt4rx8FFjLCG7dd--