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

Re: [dm-devel] my encryption



On Sun, Oct 19, 2003 at 07:32:46PM +0200, Erik Tews wrote:
> On Mon, Oct 13, 2003 at 02:12:13PM +0200, jon kollegiegaarden dk wrote:
> > > Why is this bad ?  I'd worry if changing the password *didn't* require
> > > the device to be re-encrypted.
> > 
> > Imagien you have a 3426TeraByte blockdevice...
> > Reencrpting that is going to take a long long time, and even if
> > it was just a few hundred GB, then they are going to be offline
> > while you change the key. To some that is unacceptable. PPDD
> > which i modelled my encryption on can change key without reencrypting
> > it all. So can GBDE from FreeBSD.
> > What usualy is done is that the passphrase is used as a key to encrypt
> > another key, which is stored encrypted at the disk. Then this other
> > key is used to encrypt the data with. Thus when changing the passphrase
> > all you do is reencrypting the key. This is almost done atomicaly.
> 
> I think this is a bad idea. If I got a bad harddisk and loose the sector
> where the key is stored, I loose my whole volume. If I got a password
> which is hashed and then used as a key, then I will be still able to get
> all which is readable on the disk.

in my code i solved that problem by saving the key on both the beginning
and the end of the device. But besides that you can take backup's of
those sectors with dd. And finaly... If data are imporent, RAID.


> > > > It doesnt shuffle the sectors arround
> > > 
> > > Does this really provide more security ?
> > 
> > Maybe, i'm not a cryptoanalyser, but GBDE does this, and i think they
> > do it for a reason. The idea is that you can attack the encryption if
> > you have "known plaintext", and a filesystem stores known meta data
> > at a known location.
> 
> This is correct, I think this is a fine idea, if the blocks a big enough
> that this will not make the disk seek all the day.

i'm not aware of how big blocks that GBDE uses.




JonB



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