RE: [dm-crypt] LRW has more data modification leakage than CBC?
Jim,
It depends on what threat are you protecting against.
If you are worried about losing your laptop computer or USB disk, data
modification leaks are irrelevant. The thief has just one instance of
the data. In this case the large performance advantage of LRW is what
matters. It translates to battery life, heat, processing speed, etc.
If your adversary sees the traffic to the storage device, with the
location unencrypted or encrypted with a fixed key, even EME or ABL
leaks information: if you write the same data to the same sector, your
adversary finds that. It happens very often at swap files, disk caches.
So if you are really paranoid, you have to use random nonces and key
agreement protocols to establish a new session key for each sector.
If your adversary can examine the stored data often, all data length
preserving encryptions leak information: if the sector contains the
same data, which was there once before, the adversary learns that the
corresponding original is the same.
The advantage of EME or ABL is that a whole sector (typically 512 bytes)
has to be repeated for no data modification leak, while LRW leaks at a
repeated block (typically 16 bytes, 32 times more frequently). In
practice often large chunks of data repeat, so there is no huge
difference in security.
Laszlo
> -------- Original Message --------
> Subject: Re: [dm-crypt] LRW has more data modification leakage than
> CBC?
> From: "James Hughes" <James_Hughes@STORAGETEK.COM>
> Date: Sat, December 25, 2004 12:30 pm
> To: "<dm-crypt@saout.de>" <dm-crypt@saout.de>, "SISWG"
> <stds-p1619@IEEE.ORG>
> Cc: "James Hughes" <James_Hughes@STORAGETEK.COM>
>
> This is correct. Using this "data modification leak" terminology, LRW
> has more, CBC less and EME none.
>
> EME and ABL encrypts the entire sector as a single permutation. Any bit
> changed anywhere, the entire sector is changed. CBC leaks the point at
> which the change starts.
>
> So, instead of going to CBC with it's problems, I would suggest EME or
> ABL.
>
> Thanks
>
> jim
>
>
> On Dec 25, 2004, at 10:45 AM, Adam J. Richter wrote:
>
> > I just finished reading Fruhrwirth Clemens's web page on
> > Linux hard disk encryption settings, which is basically the
> > first that I had heard of LRW, so I apologize if I'm missing
> > some obvios point.
> >
> > Regarding the "data modification leak" described in
> > Fruhrwirth's page, it seems to me that LRW will leak
> > more information about data content changes than CBC,
> > since there is no chaining whatsoever in LRW.
> >
> > Under CBC, an adversary with access to snapshots of an
> > encrypted disk image can tell which encryption block within a
> > sector is the point at which modification began, but cannot tell
> > how many bytes after that point were modified. For example,
> > if a sector was modified starting in the middle, it is
> > impossible for an adversary to tell whether only one byte was
> > modified in the middle, or if the every byte in the second half of
> > the sector had been modified.
> >
> > Under LRW, however, an adversary can see exactly
> > which encryption blocks were modified and which ones were
> > not. So, for example, an adversary looking at snapshots
> > of an LRW-encryptioned disk that is known to be a standard
> > ext3 file system should be able to tell exactly which inodes
> > have modified inode information. I think that that additional
> > resolution in the information leakage may be of some practical
> > consequence in the scenarios to which the "data modification leak"
> > issue would be relevant.
> >
> > Am I misunderstanding something?
> >
> > I do not mean to say that LRW is worthless. I think
> > the watermark attack that LRW avoids is more realistic
> > problem than the "data modification leak", but I think that for
> > my own use I'd probably prefer to trade a bit more CPU cost on
> > my system given some other scheme that had the security of LRW
> > without that resolution of data modification leakage.
> >
> > __ ______________
> > Adam J. Richter \ /
> > adam@yggdrasil.com | g g d r a s i l
> >
> > ---------------------------------------------------------------------
> > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
> > To unsubscribe, e-mail: dm-crypt-unsubscribe@saout.de
> > For additional commands, e-mail: dm-crypt-help@saout.de