Re: Making ESSIV dependant on previous sector/block

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 12, 2008 at 09:23:47AM +0000, Gordan Bobic wrote:
> Is there a way to achieve this? The use-case I'm considering is 
> something like distributed network RAID (e.g. cleversafe). With using 
> standard ESSIV:SHA256 the problem is that if the key were recovered, 
> some of the information can still be extracted from any one node (the 
> blocks that exist on that node).

If the key is revocered, all bets are off. The system is not designed 
to be safe against that.
 
> If the initialization vector was dependent on the previous sector 
> (which, for the 1st sector of the device will be based on the last 
> sector of the previous block which is on a different device, then 
> recovering any data from a stolen node, even if keys were breached (e.g. 
> using a method to dump the contents of RAM for up to 10 minutes after 
> power-down) would be much more difficult. At worst (if we flush the 
> caches immediately after accessing the first sector on the local 
> device), it would allow recovering the first block of the data if the 
> first node is the stolen one (and the 1st block doesn't usually contain 
> anything more useful than the superblock/block-group header), which is 
> still better than all of the data on the node, even if it is only fragments.
> 
> Has anyone considered such a thing? Is there a patch to achieve 
> something like this?

There is a fundamental problem: If you do this, then you go from a 
random-access fille to one thet can only be sequentially accessed,
hence this cannot be done with normal files. Hence, and because
protection against a known-key-attack is not a design criteria,
this is unsiotable for dm-crypt.

However, standard CBC already has the property you are looking for, so
if you want this, use, e.g., PGP/GnuPG to encrypt the files
individually. If they are then distributed block0-wise, only the
blocks of the avaliable prefix can be recoverd, even with the key
present. The distributed RAID can then be entirely unencrypted.

Arno 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux