pup_save encryption --UPDATED again for 2.11

[kirk]

1) do the insmods inside the test for encryption; no need to load these modules if there is no encrypted pup_save.

Yes, updated the original post, posted new initrd.gz.

2) In the dialog that asks for a password, I started typing the password before bringing up the xterm. The dialog should indicate that by pushing the (OKAY?) button you will be bringing up the xterm in which the password will be entered.

Clarified the dialog in the Encrypt-pupsave script, uploaded new Encrypt-pupsave to original post.

3) Then, when entering the password (call it "passphrase" everywhere, if it isn't already), you should ask for it twice and then compare, as normal new-password dialogs go.

I'd like to do that, but losetup handles the password set-up. Oh, and losetup calls it "Password". I agree, "passphrase" would be more accurate. During boot if you enter the wrong password, You'll be prompted again to enter it.

is this aes256 encryption pretty strong?

Yes, it quite strong, but quite a bit slower than AES128. So this is using AES128. Aes128 is very good too. A dictionary attack seems to be the only option for an attacker. So your password is your biggest weakness. Since it a loop-back device with a known filesystem built on it, I suppose you could narrow down your possibilities for an attack. And as mentioned in an earlier post you swap file could be exploited. But for personal use these seem very very unlikely.

[PaulBx1]

As I noted above, I don't use swap.

As you say, maybe aes128 is good enough for most purposes, however it occurs to me to ask, are other alternatives available in the kernel? (I'm assuming this encryption was supplied in the kernel, maybe I misread that.) Could an enhanced version of your script allow selection among such alternatives?

[kirk]

Yes Puppy includes many encryption options, but to add options would make the initrd bigger. AES128 is fast and cracking it would not be easy.

Right now the initrd is only 37k bigger than the original. So with the script the whole thing would add less than 40k to Puppy.

[PaulBx1]

OK, next question, how can we get this into standard Puppy? Seems like a good candidate for inclusion since it is transparent to those who don't want encryption. Barry should be back from his vacation by now, I think. What is the proper form for begging for inclusion of this? Is it arf, arf?

<later>
It occurs to me this encryption feature can be too transparent; how are new users supposed to learn it even exists? Perhaps we need another change to the initrd, a sort of one-shot arrangement to tell people how to access it? Or maybe in the shutdown (after booting the first time) when the asking if the user wants to save the session, it could ask if it wants to save it encrypted...

[kirk]

New initrd.gz for Puppy 2.11. Updated first post.

[PaulBx1]

Ah, thank you, Kirk. I was just thinking I'd go to 2.11, and would have to diff the 2.10 initrd so I could make the change myself. I suppose until Barry decides to add encryption, that would be a not too tedious way for us encryption fans to keep up to date.

I have another question. Suppose I go ahead and use encryption and my pup_save is encrypted for real, not just for testing. Now, how do I ever get it unencrypted later, if for some reason I want to do that?

Another question. Suppose I want to fsck the pup_save. Normally I would boot into ram because fsck or e2fsck prefers to work on an unmounted volume. Can we just run some of the changes you made to initrd, both before and after the fsck, to accomplish that? I suppose if we can unencrypt it, as I asked in the first question here, it would be easier to do it that way, do the fsck, and then encrypt again.

I am anxious to be running encryption for real.

[kirk]

To fsck the pup_save_crypt is like using fsck with a regular pup_save file:

# modprobe cryptoloop
# losetup-FULL -e aes /dev/loop6 /mnt/home/pup_save_crypt.3fs
# fsck.ext3 /dev/loop6
# losetup-FULL -d /dev/loop6

To unencrypt a encrypted pup_save:

First make a new pup_save.3fs (256MB in this example):

dd if=/dev/zero of=/mnt/home/pup_save_new.3fs bs=1024 count=256000

Attach the file to the loopback device:

losetup-FULL /dev/loop6 /mnt/home/pup_save_new.3fs

Make file system and mount:

mkfs -t ext3 /dev/loop6
mkdir /mnt/encrypt-tmp
mount -t ext3 /dev/loop6 /mnt/encrypt-tmp

Now copy the files from the current pup_save to the new one. (assuming you are currently using a encrypted pup_save file)

cp -r /initrd/pup_rw/* /mnt/encrypt-tmp/

[billstclair]

cp -r /initrd/pup_rw/* /mnt/encrypt-tmp/

I noticed this in your Encrypt-pupsave script, too. "cp -r" copies everything, all right, but it preserves neither dates nor soft links. Better to use "cp -a" (archive), which is the same as "cp -dpR", and preserves file attributes (-p) and soft links (-d), as well as recursively copying directories (-r or -R).

[kirk]

Thanks billstclair,

Updated Encrypt-pupsave on first post.

[PaulBx1]

Probably should fix in the above code fragment too.

One thing I wonder with that code fragment. Is it kosher to copy to another file, the pup_save that you currently have mounted and are running with? Is there no worry about opened files within it, that sort of thing?

I have wondered this in the past too, not in association with encryption, but just wanting to copy the current file for backup, or whatever. I thought one might have to boot "pfix=ram" to accomplish it properly.

[jam]

PaulBx1,

Have you received any response from Barry as to whether he will incorporate this as an option in the base distro?

[PaulBx1]

Not that I'm aware of. He may have responded to one of my hints that I left here or there, and I haven't seen it yet.

I'm actually somewhat less hot that he do so. While it would be convenient, the fact is Kirk is doing a good job of keeping this up to date, and even if he tapers off on that, it seems not so difficult to apply this change ourselves individually, now that he's provided the recipe for it. And it appears it is still needing more built-in features (e.g. the ability, in the script - or another script - to convert back to an unencrypted pup_save), so that maybe it is not quite ready for "prime-time" anyway.

Soon I am going to start working with this as my REAL pup_save, not just a quick test. After we are more sure things are good I may rattle Barry's cage again.

[Flash]

Guys, this thread is a lesson in how to collaborate and get something done. What a team. Thanks.

[PaulBx1]

Kirk, I was digging around looking at encryption information, and ran into this page. It had some interesting comments:

There are two main projects which add loopback encryption support in the kernel: cryptoloop and loop-AES. This howto is based on loop-AES, since it features an extremely fast and highly optimized implementation of Rijndael in assembly language, and therefore provides maximum performance if you have an IA-32 (x86) CPU. Besides, there are some security concerns about cryptoloop.
...
Proceed as described in the previous section, using loop-aes' kernel-2.6.10.diff patch instead, and make sure cryptoloop support is not activated. Note that modules support require that you have the module-init-tools package installed.

I'm wondering, do we have loop-aes available somehow? By loading a module different than cryptoloop.ko for example?

Also the various sites recommend filling the target file with random data using shred or dd. Does that make sense here too?

I understand the encryption we are doing is not meant to be extremely resistant to attacks, but to still give reasonable security in most cases. I just wonder if with some small changes, we can't make this a little stronger.

Hope you don't mind my asking; I am interested in learning the nuts and bolts of the encryption implementation...

<later>
Ah, I just noticed your comments about loop-aes on that other thread.

FYI, I haven't noticed any speed degradation using the aes128 on a 700MHz (Pentium III) Thinkpad. Makes me interrested in trying aes256...

[PaulBx1]

Kirk, one more suggestion for your Encrypt-pupsave script. It would be a good idea, when asking for the password, to first note the password specification - i.e., maximum and minimum length, and permissible characters, and any other requirements. The passphrase I was using was longer than needed, and it didn't even squawk about it, just ignored the last characters!

[kirk]

i.e., maximum and minimum length, and permissible characters, and any other requirements.

I don't Know, it's not on the losetup man page. Sounds like you might know what the length is.


I've seen people bash cryptoloop on some blogs, but haven't seen any good ideas as far as an attack goes, other than a dictionary attack.

[PaulBx1]

Well I think it's 31 or 32. However I don't know about the characters. I will try to dig it our for you.

Here are a couple of pages about cryptoloop:
http://en.wikipedia.org/wiki/Cryptoloop
http://en.wikipedia.org/wiki/Watermarking_attack

I'm still not clear on what a watermarking attack is.

Should the just-created pup_save_crypt file be filled with (pseudo)random data prior to copying from the standard pup_save and encrypting? Would that take care of the problem? Or am I getting worked up about nothing? I guess I get nervous when I read I'm using something that is "deprecated". Such an unfriendly-sounding word.

[John Doe]

Great thought here on encryption. I wish I could be more engaged with you guys on this. I got side tracked on an electronics project that I have to finish up.

I'm going to try and find a day, in the next week, to test this and offer any observations.

Keep up the great work.

[kirk]

Cryptoloop is not encryption. It just a way for a loopback device to handle an encrypted file system. The question is how good is an ext3 file system encrypted with aes128? I think it's quite good.

[PaulBx1]

I also saw (somewhere, sorry I didn't get the bookmark) some concerns about doing encryption with ext3 and other journaling filesystems. Not sure why; seems like the journal should be encrypted too...

BTW I looked and looked for password specs for cryptoloop, but found nothing. I suppose it could be figured out empirically, if someone was that ambitious.