Encrypted pup_save for Puppy 212

Under development: PCMCIA, wireless, etc.
Message
Author
GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#16 Post by GuestToo »

http://syslinux.zytor.com/faq.php
The -s option, if given, will install a "safe, slow and stupid" version of SYSLINUX. This version may work on some very buggy BIOSes on which SYSLINUX would otherwise fail. If you find a machine on which the -s option is required to make it boot reliably ...
maybe Puppy is installing syslinux using the -s option and maybe dsl is installing syslinux without the -s option, and that is the difference

GuestToo
Puppy Master
Posts: 4083
Joined: Wed 04 May 2005, 18:11

#17 Post by GuestToo »

deleted

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#18 Post by John Doe »

I'm going to post under this thread for convenience.

Regarding PaulBx1's script:
http://www.murga-linux.com/puppy/viewto ... 9280#79280

line 56:

dd if=/dev/zero of=/mnt/home/$FNAME bs=1024 count=$(($SIZE*1024))

Should /dev/random be used instead? Along the lines of the watermarking mentioned previously, I was thinking that perhaps (although not by design) the ext3 file system or even the files in Puppy itself might function as one big watermark.

Although the act of mkfs with the crypto loopsetup might just fill in crap too but it would probably be better in theory to write the encrypted FS overtop of random data than a blank slate.

happypuppy
Posts: 12
Joined: Fri 01 Dec 2006, 01:24

#19 Post by happypuppy »

GuestToo wrote:http://syslinux.zytor.com/faq.php
The -s option, if given, will install a "safe, slow and stupid" version of SYSLINUX. This version may work on some very buggy BIOSes on which SYSLINUX would otherwise fail. If you find a machine on which the -s option is required to make it boot reliably ...
maybe Puppy is installing syslinux using the -s option and maybe dsl is installing syslinux without the -s option, and that is the difference
i actually couldnt get what the puppy installer did to boot at all...

i had to do it manually; copy iso contents to root usb, rename/edit isolinux.cfg, run syslinux on drive... i was using 2.11 maybe with or with-out -s...

its good to know that as i didnt know all the differences...

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#20 Post by kirk »

dd if=/dev/zero of=/mnt/home/$FNAME bs=1024 count=$(($SIZE*1024))

Should /dev/random be used instead?
Sounds like a good idea. I'll update my script.

Thanks

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#21 Post by kirk »

happypuppy,

I just wanted to let you know I'm not ignoring you, I just haven't had any experience booting that way. Glad to see GuestToo chime in.

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#22 Post by kirk »

Tried /dev/random, it's real real slow. Going to have to stick with /dev/zero.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#23 Post by PaulBx1 »

Try /dev/urandom. That is what was recommended on a site that was a how-to on encryption using cryptoloop. urandom is a random number generator that, while not quite so random as /dev/random, it is much better than nothing. And, it is allegedly faster.

I will update my script with it also. Thanks for the tip JD.

<later>
Wow, that is slow. :( A half-gig file took 53 sec with /dev/zero, around 9 min with /dev/urandom. Didn't even try /dev/random. Hmmm, I may have to give users a choice.

<later still>
I have upgraded my version of "crypt-pupsave", giving users a choice what to use, zero or urandom. Here it is:
Attachments
crypt-pupsave.tar.gz
Added random number generation.
(3.35 KiB) Downloaded 678 times

happypuppy
Posts: 12
Joined: Fri 01 Dec 2006, 01:24

#24 Post by happypuppy »

kirk wrote:happypuppy,

I just wanted to let you know I'm not ignoring you, I just haven't had any experience booting that way. Glad to see GuestToo chime in.
that fine and understood, figured it must be a once off as there would have been more people having problem.

i think it something to do woth that keyboard (dell as well) as it just locked up in windows on another hostel-mate !

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#25 Post by PaulBx1 »

Here's a fast way to load a file with random data:

http://mail.nl.linux.org/linux-crypto/2 ... 00021.html

So, I will revise that script again. Soon.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#26 Post by PaulBx1 »

OK, the revised script. Used his method, but found I had to create the file in the first place. Wanted a file of a specific size, but I think only dd does that ("touch" won't), so I created a file and wasted time filling it with zeroes, then re-wrote it with random numbers per the recipe. Took 2 min 20 sec for 512 MB, not too bad. So I no longer give the user the option like the last script, which simplifies things.

I wondered about using /dev/null rather than /dev/zero on the creation. Does that fill with a specific character, or does it not fill with anything at all (so whatever was previously in the filespace is still there)?

Also made a couple of minor changes like no longer depending on loop6 being available, and a bit of revised text.
Attachments
crypt-pupsave.tar.gz
(3.34 KiB) Downloaded 679 times

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#27 Post by John Doe »

Great find!

Here is a good link on reseeding a random number generator to get a really good random number for the password (although characters AND numbers AND special characters would be better).

http://tldp.org/LDP/abs/html/randomvar. ... DINGRANDOM

I think the loop with a random key might be the best approach to handle the swap file If i recall correctly, someone once told me that's one of the big deals about unix security is that the swap file is encrypted with a different random value each session.

I'm still hunting down exactly where this is best accomplished at. Line 325 (in modified initrd) " #look for a swap file..." seems to be where everthing is dropped in var PUPSWAP but then I lose it.

Regarding Null vs Zero. They are just different characters in the table. "Null" still has a binary value, it's just "null" ;-)

http://www.asciitable.com/

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#28 Post by John Doe »

I spent some time and worked out a graceful set of shutdown dialogs. Defaulting to "NO" as the initial choice so this could be incorporated with minimal effect on non-encrypters.

Also added a bit level selector (defaulting to 128). More on this later.

The user also has the chance to change their mind on encryption during the entire routine by hitting cancel or escape.

*edit, I forgot to mention that Barry will have to add this because as far as I can tell the function that does the actual creation of the save file at the end is compiled somewhere. I searched the whole unleashed directory for files containing the word 'pupsavefunc' but couldn't find it. I listed the important variables at the end of the script, in a comment.
Attachments
Shutdown-Crypto.tar.gz
(1.11 KiB) Downloaded 680 times
Last edited by John Doe on Fri 15 Dec 2006, 00:14, edited 2 times in total.

User avatar
Carpe.Diem
Posts: 5
Joined: Fri 08 Dec 2006, 03:58

Please tell be about the nature of the encryption system

#29 Post by Carpe.Diem »

I have a few questions about the encryption system that is now working in Puppy 2.12 through an add-on, which this and the thread on the Developers forum addresses. I am NOT asking about how to the use the system in this post, but what IS the system's structure itself (i.e., what's the nature of it and what are its physical characteristics as expressed in how it uses the computer's resources).

SOME ASSUMPTIONS: I am assuming that the file(s) in discussion is decrypted "on the fly" and is not written to disk in terms of what I think I read in these discussions, but since I'm not sure about this, my questions try to cover both "on-the-fly" systems which use memory vs decryptions which are written to disk. I am also a little confused about whether you're talking only about the swap file (which might contain the "memory-extension" of the decrypted data), or just about the session results at shut down -- or both (if they're not the same file in installed system); so bear with me as I try to talk about both permutations (which I may sometimes blur, because I'm a little unclear about some of the discussion's details). Another assumption I am making is that you're talking about installed systems as distinct from Live sessions where the session's data is saved on the boot-up disk, but I have some questions about both (though I personally only have experience using the Live approach in Puppy thus far and my experience with installed versions does not exist -- so I may make some blunders here about technical details of the installed versions, which may make some of my questioning details seem uninformed or confusing; however, I have an extensive background in computers and security which are not Linux based -- so bear with me). Last assumption: This is an initial shotgun blast at a lot of topics surrounding the security system being proposed for Puppy (and us all) and only some of the initial factors will be addressed here in this opening scatter of ideas.

1. PASSWORD FUNCTION: Is it the same encryption being used for all swap or end-of-session files and only a particular password will allow each user to gain entry (in other words, if Puppy were freshly installed from the ISO and nothing was done other than a password given and the user exits, would these encrypted files look the same on all computers except for the portion holding the password or configuration data), OR is the encryption based SO "heavily" on the password that no files would match each other (in the example just supposed)? In other words, is there only one encryption and many keys, or are they as many encryptions as keys? If it is based heavily on the password, would the change of one character in the password give a completely different result in the entire file (not just every so-many bytes "in pattern", but everywhere -- the ENTIRE file)?

2. ENCRYPTION SYSTEM: I see that the first post in this forum uses the filename AES, so I assume AES is used as the main engine. There's also usually a hash algorithm separately used to protect the password embedded somewhere within traditionally encrypted files too, and if that is true here also, what might it be? It usually does not match the main encryption algorithm, such as AES in this case, and it separately protects the use of the right password and is important since if the wrong password is used and the file is decrypted wrongly, there's no way to recover IF the decryption is written to disk and the original file is wiped (unless it's an "on-the-fly" memory-only system); so passwords are often checked for correctness first before the main file is decrypted -- so, I'm asking, how is the password protected (separately by a hash algorithm or is it integrated somewhere within the larger file within the one uniform encryption engine such as AES, or is this not known)?

3. LIVE-CD SWAP: For Live-CD sessions, has just a secure wipe of the swap been considered? Since I understand that sensitive systems can recover up to about 7 of the last writes, most wipes that are considered really secure usually have to take this into account and write "obscuring data" which is efficiently "thought-out" bitwise if real security is a must, though most of us really don't have anything that'll come under such heavy-handed recovery systems. Three wipes is usually considered enough for ordinary mortals.

4. LIVE-CD END-OF-SESSION: Also for Live-CD sessions, is there a way information which is saved from the session to the CD can be protected by this encryption process too?

5. SWAP OR END-OF-SESSION FILE: The discussion suggests that the installed swap or end-of-session file is always encrypted (and that it is never decrypted, which is decryption "on the fly" as they say), which may be optimal (if it "really" works this way). But if I am wrong about this and the swap or end-of-session file, including any part of it, is decrypted for the session, and then re-encrypted at the end of it, there are additional questions: Is both the encryption or decryption "in place", or is a new file created in the swap partition (meaning that double the file size is needed in the swap-partition space, if it is the swap file that is being decrypted here), and if a new file is created, is the old one securely wiped? Also, if any file is encrypted "in place", there's always the risk that sensitive systems can recover the original by going back just a certain number of layers (as "they" call it), and another vulnerability concerns a power outage which leaves part of the "in-place" file decrypted if the outage occurs during this phase and when the power returns, part of the file is decrypted and part of the file in still encrypted (making the whole file not usable, since there's usually no such thing as a partial-file decryption system). Memory that is written to disk is very vulnerable if it exists in an unencrypted state there after shutdown or in power failures, especially IF the size of the swap is volatile and increases and decreases in size on an as-need basis, and I don't know how Puppy works in this regard (however, if the memory written-to-disk is ALWAYS in an encrypted state, this is less of a "logical" concern, but this is usually impossible, as how are you going to read and edit your letter which was decrypted for the screen unless it is likewise temporarily decrypted in memory, which puts it conceivably in the swap partitions' memory extension area on the hard disk in a decrypted state) -- or have extraordinary steps been taken to prevent this eventuality.

6. ON-THE-FLY: I've kind of asked this repeatedly by implication above, but let me finally ask directly: Is this an "on-the-fly" decryption process where nothing whatsoever is written to disk or memory from the decryption, or is it written to disk partially or fully? -- and (even though I'm being repetitive here), if it is "on the fly", are the results of ANY data EVER temporarily stored in any area of memory in a decrypted state (including, of course, the temporary memory extension that is physically a part of the swap partition -- in which case, it is, of course and unfortunately, conceivably written to disk in an unencrypted state, which means it can be recovered, especially if the size of the swap partition decreases as programs are closed, or if the swap is not encrypted separately and fully at the end of the session if the size is fixed), and what is done to obviate this "on-the-fly" vulnerability?

7. NEW PUPPY: Will Puppy 2.13 have this feature built into it so add-on's are not needed?

I believe in privacy while I have really nothing of value that I need to protect anymore; however, when I was in business and had sensitive account information I managed, or when I was richer and had accounts and passwords to protect, I needed security and I have dealt with a variety of its factors and problems in relation to computers. I really prefer having nothing that I feel a need to hide anymore, but I still believe in privacy being an individual's right (period).

I'm glad something is happening in Puppy to accommodate this and would love some more information about the details above. It's been hard to be clear when I'm not experienced in what others are really talking about (such as installed systems), and it's also difficult to ask simple questions about complex matters, so please bear with me if I confused anyone (which my heavy-handed and rather circular writing style has most probably done). I'll certainly attempt to clarify any question I've asked if anything I've said seems important enough.
[color=blue][i]...Will Puppy Penguin swat poor Butterfly? Stay tuned...[/i][/color]

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

Re: Please tell be about the nature of the encryption system

#30 Post by John Doe »

> the file(s) in discussion is decrypted "on the fly" and is not written to disk

Yes, but no. It is written to disk, but is encrypted and decrypted on the fly.

> you're talking about installed systems as distinct from Live sessions

Yes the liveCD session in RAM will just evaporate when you shutdown (That's mainly how I work myself). We are talking about the entire pup_save.3fs file itself. So basically anything you do is protected. I think Kirk mentioned he used it to save back to a multisession CD (I might be wrong). If it doesn't work that way, we'll explore that option for sure.

> would the change of one character in the password give a completely different result

Yes. The result would be that you don't get to mount that saved session. So you either move it, delete it, copy another session there or type 'puppy pfix=ram' and boot puppy up with no session.

> I assume AES is used as the main engine.

Yes. Maybe we'll make options, maybe not.

> There's also usually a hash algorithm separately used to protect the password embedded somewhere within traditionally encrypted files too, and if that is true here also, what might it be?

The password is your key for the equation, it's not stored anywhere.
(page 2)
http://www.isg.rhul.ac.uk/~sean/aes_casc04.pdf

Here is some great info on the standard in general:
http://en.wikipedia.org/wiki/Advanced_E ... n_Standard

> For Live-CD sessions, has just a secure wipe of the swap been considered?

I think they idea of adding a "wipe swap file" button to Paul's script wouldn't be too difficult.

> Since I understand that sensitive systems can recover up to about 7 of the last writes

I've heard that before. The actual number is probably higher but declines exponentially as one increases layers.

> Will Puppy 2.13 have this feature built into it so add-on's are not needed?

Depends on how far we get and if Barry wants to or not.

> I believe in privacy <snipped for brevity> (period).

Although my situation is a bit different, I couldn't agree more. One big advantage will be for MultiSessionCD and USB users. Having a machine at home with "nothing you are worried about" is a bit different at times than say losing your CD or USB device. Even most casual users check their bank records or perhaps make purchases that could be compromised by a lost device. A malicious individual could access even the contact info for your family and cause problems.

My save file is only 32megs. I just keep my vpn and email settings in there now and don't have to worry about losing them to anyone. My remastered CD has everything else just the way I want it.

> I'm glad something is happening in Puppy to accommodate this and would love some more information about the details above.

I tried my best. You made me think about a few things too, thanks.

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

Switching to dm-crypt

#31 Post by John Doe »

Based on Paul's research on swap and losetup's problems with it leads me to think it might be the wrong method to use altogether. dm-crypt has a helper app called cryptsetup which takes the place of the patched losetup. Also the method we are currently using (losetup and CyptoAPI itself, not our choice of keys or logic) appears to have some security problems (*my bad, I should have searched better).

I'm going to download these and run some tests tonight. I'll have some specific code tomorrow to use for the change (unless you guys beat me to it). It shouldn't be too difficult to switch over, just a couple lines a lib or two and a binary.

------------

Mounting

Looks like basically to mount instead of this:

losetup $CRYPTO /dev/loop1 $SMNTPT$SAVEFILE
mount -t ext3 -o noatime,rw /dev/loop1 $EFSMNT

We do this now:

losetup /dev/loop1 $SMNTPT$SAVEFILE
echo 0 `blockdev --getsize /dev/loop1` crypt aes 0123456789abcdef0123456789abcdef 0 /dev/loop1 0 | dmsetup create $EFSMNT

or with cryptsetup

losetup /dev/loop1 $SMNTPT$SAVEFILE
cryptsetup --verbose create $EFSMNT /dev/loop1

*see http://www.saout.de/misc/dm-crypt/

------------

Apps

cryptsetup
http://www.saout.de/tikiwiki/tiki-index ... cryptsetup

Dependancies:
http://www.paranoiacs.org/~sluskyb/hacks/hashalot/
http://directory.fsf.org/security/libgcrypt.html
(*edit) ftp://ftp.gnupg.org/gcrypt/libgpg-error ... 1.4.tar.gz (for libgcrypt)
http://packages.debian.org/testing/libd ... mapper-dev

Quote:

"BTW: dmsetup is NOT a big program. It has two parts: a libdevmapper.so in /lib and the dmsetup binary itself. Every part is 16k in size (if compiled statically into one binary it's just 27k), and it's still linked against glibc. If linked against dietlibc or klibc it would be even smaller. Nobody needs LVM tools or something. It's just a small client for the dm ioctl, just like losetup is a client for the loop ioctl."

*http://kerneltrap.org/node/2433
------------

Mounting Encrypted Swap

cryptsetup -c aes -s 256 -d /dev/urandom create swap0 /dev/hda2
mkswap /dev/mapper/swap0
swapon /dev/mapper/swap0

And creating an encrypted file system is on this page:
http://www.saout.de/tikiwiki/tiki-index ... ptedDevice

------------

Other

I'm hoping these key sizes are in bytes (that would make 128, 192 and 256 valid).

sh-3.00# cat /proc/crypto
name : aes
driver : aes-generic
module : aes
priority : 100
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
Last edited by John Doe on Fri 15 Dec 2006, 03:36, edited 1 time in total.

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#32 Post by John Doe »

One last link before I shut up and compile.

LUKS for dm-crypt is implemented in an enhanced version of cryptsetup.
http://luks.endorphin.org/about

This is a winner for sure.

LUKS on Gentoo uses cryptsetup-luks to make Gentoo the first Linux distribution that can be run and installed seamlessly with LUKS, and (without disrespect of other crypto project) is believed to deliver the best user experience.

LUKS is the first cross-plattform standard for transparent hard disk encryption. Thanks to FreeOTFE, you get LUKS for Win32. Of course, you have to use a file-system on your LUKS partition that both OS understand. For instance, fat. For more compatibility stuff see, LUKS for the masses.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#33 Post by PaulBx1 »

dmsetup may be small, but I don't know if all the things it depends on is. And I downloaded the cryptsetup tar.bz2 file last night, which was 244mb all by itself (I realize that has nothing to do with the size of the finished module, but it's at least worrysome).

The thing is, I'm hoping to get this encryption into the standard Puppy, and for that we are very size-sensitive. There is a limit to how much we can talk Barry into adding.

On the other hand we (i.e., you) could provide our own remaster, which I guess makes us less constrained that way. However it also gets us out of the mainstream of releases, which is not good.

The above are just vague impressions, my guess at the options open to us. I could well be wrong; I really don't know how all this is put together. Those dm-crypt guys keep saying everything is already in a vanilla kernel, but I see no evidence of it in Puppy. Perhaps some compile options have to be turned on? And there is also the option to make it a loadable module? (If I understand correctly, this sounds better, as it can be thrown in zdrv and only used by people who want encryption.)

If you can get this going JD I would really appreciate it; I'm way over my depth! :shock:

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#34 Post by John Doe »

PaulBx1 wrote:dmsetup may be small, but I don't know if all the things it depends on is. And I downloaded the cryptsetup tar.bz2 file last night, which was 244mb all by itself (I realize that has nothing to do with the size of the finished module, but it's at least worrysome).
244mb :shock: we must have downloaded something different (or perhaps you meant kb. The LUKS download was 300kb which had just a couple more things).

here are some number I got right now:
(compiled, not with the diet C which would make them even smaller)

cryptsetup (LUKS version) 28k
dmsetup 34k
hashalot 48k


libraries 2252k
I think only two of these files are required. Which would keep us in the ball park still. I have to re-read some things.

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#35 Post by John Doe »

PaulBx1 wrote:The thing is, I'm hoping to get this encryption into the standard Puppy, and for that we are very size-sensitive. There is a limit to how much we can talk Barry into adding.

On the other hand we (i.e., you) could provide our own remaster, which I guess makes us less constrained that way. However it also gets us out of the mainstream of releases, which is not good.
I too would like to get this in the main distribution. I do remaster a CD for myself but have no plans for distributing it. I do so only so I can test things faster to help with the main distribution and as a minor convenience to myself (it was also a great learning experience).

Also I think this is an important feature for Puppy to compete, check out this list that has LUKS encryption already:
http://www.saout.de/tikiwiki/tiki-index ... portStatus

If Puppy had LUKS "out-of-the-box" like Gentoo (and combined with all the other great improvments going on around here) it would be Number 1 for sure 8)

Post Reply