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@xxxxxxxxx> > To: <ppdd@xxxxxxxxxxxxxxx> > 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@xxxxxx | Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
