[Cryptography] Justify the sequence of operations in CTR mode.

Tom Mitchell mitch at niftyegg.com
Fri Feb 12 21:18:20 EST 2016


On Thu, Feb 11, 2016 at 8:06 PM, Roland C. Dowdeswell <elric at imrryr.org>
wrote:

> On Thu, Feb 11, 2016 at 01:27:44PM -0800, Ray Dillinger wrote:
> >
>
> > In considering attacks on disk encryption,

....

> I realized we've been doing
> > it wrong.
>
....

>
> It's much worse than this.  CTR mode in its simplest form can't be
> used for full disk encryption.  The contents of disks have a lot
> of predictable bits in them, superblocks, inodes, etc.


Once a  file system is created there is replication of data by design.
Different systems do it differently but....

"The superblock is located at the beginning of the disk slice, and is
replicated in each cylinder group. Because the superblock contains critical
data, multiple superblocks are made when the file system is created. Each
of the superblock replicas is offset by a different amount from the
beginning of its cylinder group...."
   https://docs.oracle.com/cd/E19455-01/805-7228/fsfilesysappx-3/index.html

A physical access attacker with "guest like MAC permissions" might
uncompress a file that normally contains holes (blocks of null).   That
 service rep or guest knows how many blocks.    Power down then block by
block copy, the original reinstalled and the copy attacked off line.   The
service rep/ guest can then remove the file of nulls.    Other compression
bombs may allow non null data sets that might generate different attack
surfaces.  Journal filesystems may have an attack hidden in the journal.
Storage (RAID) systems do contain redundant data, hmmm...  not all are
equal some vendors sell encryption services.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160212/50b5779e/attachment.html>


More information about the cryptography mailing list