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

On Tue, Aug 23, 2005 at 11:40:38AM +1000, Daniel Carosone wrote:
+> On Mon, Aug 22, 2005 at 10:09:11AM +0200, Pawel Jakub Dawidek wrote:
+> > There are no small writes. visible sector size for upper layers is 8kB.
[...]
+> This means you should only really need integrity (MAC) of the entire
+> data block, old or new - this was the source of my previous confusion
+> over your (0, 1..n, n+1) layout and transactional model, since I
+> assumed in the first reading that this was what you were trying to do.
+> You clarified that you instead had individual MACs per sub-block, and
+> could maintain integrity assuming the underlying hardware was atomic
+> at this resolution.
+>=20
+> However, at this point you've negated one of your previous tenets.  If
+> the upper layer sees each MAC+data+MAC block as a single data block,
+> you have to have transactional integrity *at that resolution*.  Your
+> mechanism allows you to reproduce partial write results (with either
+> old or new mac, per physical sector) to that upper layer - but only
+> the full old or new 8k data value is valid to the filesystem.

Let me explain it a bit more.

You have your disk device /dev/da0 which has 512-bytes sectors.
On top of it you have /dev/da0.auth device which has 8kB sectors.
On top of da0.auth you create file system and mount it.
Everyone who comunicate with da0.auth sees only decrypted and
authenticated data.

So what's going on between da0 and da0.auth?
I/O READ request is send from the file system to da0.auth (let's assume
it one sector - 8kB).
da0.auth reads 512+8192+512 bytes from da0.
da0.auth splits 8kB into sixteen, 512-bytes pieces and authenicate those
pieces one by one. If new MAC check fails for one piece, it tries check
it against old MAC. Every single sector from da0 is authenticated
separately.

+> > This will take 12% of your disk, which is absolutely acceptable for me.
+>=20
+> Me too, if the cost provides the needed functionality.  There are also
+> performance (largely seek-related) costs to consider in any design.

seek-related? I don't think so. Instead of reading or writing 8kB, you're
reading or writing 9kB. There is no more seeking in this algorithm.

+> > +> 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 t=
he
+> > +> MAC sectors or elsewhere?), with corresponding storage and transact=
ion
+> > +> 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?
+> >=20
+> > Unfortunately it won't handle old MAC+data+MAC problem...
+>=20
+> Unfortunately, that's *exactly* the replay problem I infer from the
+> thread Subject: line (and that most other readers and eventual
+> 'customers' are likely to).  If you have a different problem statement
+> you're trying to solve, fair enough, but I missed it along with the
+> other aspects I alluded to above.

Yeah, that's my fault, sorry about that.
I jumped into the thread when Roland wrote about authenticating data.

+> > There is no counter you can add to the block's metadata to fix it.
+>=20
+> There are a number of potential designs, some of which I've alluded
+> to, and possibly including new ones. I've been trying to discover
+> which, if any, of these you're pursuing - or to point out that you're
+> missing the (assumed) target if you've not taken these issues into
+> consideration.
+>
+> If your target is a simpler problem (as cgd(4)'s is, for example, in
+> no small part as a recognition of the complexities this discussion is
+> highlighting) that's fine - as long as everyone has a clear
+> understanding of exactly what your system is and isn't.

While I'm aware of the replay attack issue, I still think integrity
verification is something very useful and something which cgd(4) nor
gbde(4) nor geli(8) doesn't have.
BTW. I wrote a framework for storage encryption with simlar goals
to cgd(4), ie. data privacy:

	http://people.freebsd.org/~pjd/misc/geli.8.pdf

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

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

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

iD8DBQFDC1w7ForvXbEpPzQRAtKXAKCI8w8yMhQLlh3/vgeI8nTLOua2TACfS5kd
CKM1DKFnbLykN65kuMgjxI0=
=4nyn
-----END PGP SIGNATURE-----

--AhhlLboLdkugWU4S--