Re: [PPDD] loop-AES-v1.4d file/swap crypto package

[Greg Louis <glouis@dynamicro.on.ca>]

It would seem to make sense to ask the author of loop-AES directly for
his comments.  Jari?

(FWIW I too switched from PPDD to loop-AES because of needing 2.4
support now-and-in-a-hurry.  It has worked for me on kernels from
somewhere around 2.4.4 through 2.4.9-ac10; I don't use it for root or
swap so I can't comment on that.)

On 20010920 (Thu) at 1114:48 +0200, Allan Latham wrote:
> A quick look at this seems to show the following (pls confirm this anyone):
> 
> 1. The whole of the data is encrypted with a single key
> 2. There is no mean to change the key
> 3. CBC is used on 512 byte blocks
> 4. The key is derived directly from a password with a seed
> 
> If this is true then a very large amount of material is being encrypted with
> the same key. It is not only the size of the partition but also every backup
> copy of this that an attacker gets his hands on over the entire life of the
> data.
> 
> Much of that data is known - the filesystem structure is known and a lot of
> the internal pointers are null. This represents a very large anount of known
> plaintext. I'm not saying the encryption method can be cracked, only that it
> is wise to minimse the material an attacker gets.
> 
> The use of CBC (the IV is derived from the block number) means that if an
> attacker gets hold of a "before" and "after" copy of the partition he can to
> some extent see what has changed. If the same block in both copies differs
> after a certain byte he can be sure that the first change in the block was
> within the cyphertext block at that point. Again this is valuable
> information for an attacker.
> 
> PPDD uses several random generated keys to encrypt the data on the disc. It
> uses the key derived from the passphrase to encrypt these keys.
> 
> PPDD "scrambles" the whole of a 512 byte block before encryption in such a
> way that the iv for this action is kept secret in the same way as the
> encryption keys and that the scrambling action diffuses a change in any one
> byte throughout the block. If an attacker gets a "before" and "after" copy
> he can see that a 512 byte block has changed but has no idea where in the
> block the change took place.
> 
> These aspects may or may not be of concern to you depending on your needs.
> It may also be possible to put these type of changes into loop-aes or to
> hack the ppdd encryption mechanism into loop-aes to replace that currently
> used.
> 
> I would be pleased if someone could just read the code and confirm point 4
> above. If true this is a serious problem. It allows a dictionary attack in
> reasonable time - and a twenty character pass phrase especially one using
> plain language words is no protection against this.
> 
> Best regards to you all
> 
> Allan
> 
> 
> ----- Original Message -----
> From: "Matilainen Panu (NBI/Helsinki)" <panu.matilainen@nokia.com>
> To: <ppdd@linux01.gwdg.de>
> Sent: Thursday, September 20, 2001 10:15 AM
> Subject: Re: [PPDD] loop-AES-v1.4d file/swap crypto package
> 
> 
> > ..one more unfortunate thing about it is that it doesn't support changing
> > passwords :(
> >
> > - Panu -
> >
> > On Thu, 20 Sep 2001, ext Michael H. Warfield wrote:
> >
> > > On Wed, Sep 19, 2001 at 03:06:01PM -0300, Adriano Freitas wrote:
> > >
> > > > Hi all,
> > >
> > > > I was looking for other works in crypto file system and I found
> > > this
> > > > one, but I havent had time to test it yet, but it seens to work fine
> > > as
> > > > ppdd.
> > >
> > > [...]
> > >
> > > > For more info, go to
> > > > http://mail.nl.linux.org/linux-crypto/2001-09/msg00006.html
> > >
> > > > Could someone test it and put some feedback here?
> > >
> > > I'm not using it specifically for encrypted swap but I am using
> > > it for encrypted file systems and it works really well.  I switched to
> > > it from using ppdd because of the 2.4 support issue (I now require
> > > several 2.4 features) and the fact that it supports any file system
> > > and not just ext2/ext3.
> > >
> > > One thing that it lacks is a conversion utility (encrypt in
> > > place)
> > > like ppdd has.  You have to create your encrypted file system and then
> > > copy your files to it.  For things like encrypting and ISO fs, that
> > > means
> > > creating the unencrypted image and then "dd'ing" that to the encryption
> > > loopback device.  That amounts to three copies of all the data (the
> > > original, the ISO image, and then then encrypted ISO image).  But ppdd
> > > doesn't support encrypted ISO file systems at all, so that's no loss
> > > there, either.
> > >
> > > Another disadvantage is that it replaces the loop-back device
> > > rather than works in parallel.  That may not matter much, but it might
> > > if you want them in parallel but separate.  Not an issue with me.
> > >
> > > Given sufficiently strong pass phrases, it shouldn't be any less
> > > secure.  It does lack the master phrase / working phrase feature, but
> > > I wasn't using that anyways.  :-/
> > >
> > > Other than the ppddinit with encrypting in place, does anyone
> > > know of any other advantages that would weigh in favor of ppdd?
> > >
> > > BTW...  I also have not used loop-AES to encrypt the root
> > > device,
> > > yet.  But I see no reason why it shouldn't work and it seems easier to
> > > set up than ppdd.
> > >
> > > Another advantage is that it's very much in line with the
> > > crypto-api
> > > stuff that's shaping up and may eventually (hopefully) get merged in as
> > > that straightens up.  Linus has expressed an interest (when I spoke with
> > > him at LinuxWorld in New York a while back) of eventually getting crypto
> > > in the kernel itself and the crypto-api is a strong contender so that
> > > multiple projects (loop-back fs, IPSec, etc) can access the crypto
> > > routines.
> > >
> > > > []'s
> > >
> > > Mike
> > >
> >
> > --
> >
> >

-- 
| G r e g  L o u i s          | gpg public key:      |
|   http://www.bgl.nu/~glouis |   finger greg@bgl.nu |

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/