Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 28 Nov 2014, 22:26
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Encrypted pup_save for Puppy 212
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 5 [73 Posts]   Goto page: Previous 1, 2, 3, 4, 5 Next
Author Message
GuestToo
Puppy Master

Joined: 04 May 2005
Posts: 4078

PostPosted: Wed 06 Dec 2006, 11:32    Post subject:  

http://syslinux.zytor.com/faq.php
Quote:
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
Back to top
View user's profile Send private message 
GuestToo
Puppy Master

Joined: 04 May 2005
Posts: 4078

PostPosted: Wed 06 Dec 2006, 11:34    Post subject:  

deleted
Back to top
View user's profile Send private message 
John Doe

Joined: 01 Aug 2005
Posts: 1689
Location: Michigan, US

PostPosted: Thu 07 Dec 2006, 03:11    Post subject:  

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

Regarding PaulBx1's script:
http://www.murga-linux.com/puppy/viewtopic.php?p=79280#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.
Back to top
View user's profile Send private message 
happypuppy

Joined: 30 Nov 2006
Posts: 12

PostPosted: Thu 07 Dec 2006, 08:12    Post subject:  

GuestToo wrote:
http://syslinux.zytor.com/faq.php
Quote:
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...
Back to top
View user's profile Send private message 
kirk

Joined: 11 Nov 2005
Posts: 1436
Location: florida

PostPosted: Thu 07 Dec 2006, 15:33    Post subject:  

Quote:
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
Back to top
View user's profile Send private message 
kirk

Joined: 11 Nov 2005
Posts: 1436
Location: florida

PostPosted: Thu 07 Dec 2006, 15:36    Post subject:  

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.
Back to top
View user's profile Send private message 
kirk

Joined: 11 Nov 2005
Posts: 1436
Location: florida

PostPosted: Thu 07 Dec 2006, 16:00    Post subject:  

Tried /dev/random, it's real real slow. Going to have to stick with /dev/zero.
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Thu 07 Dec 2006, 20:12    Post subject:  

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. Sad 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:
crypt-pupsave.tar.gz
Description  Added random number generation.
gz

 Download 
Filename  crypt-pupsave.tar.gz 
Filesize  3.35 KB 
Downloaded  362 Time(s) 
Back to top
View user's profile Send private message 
happypuppy

Joined: 30 Nov 2006
Posts: 12

PostPosted: Thu 07 Dec 2006, 23:18    Post subject:  

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 !
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Sat 09 Dec 2006, 01:55    Post subject:  

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

http://mail.nl.linux.org/linux-crypto/2002-02/msg00021.html

So, I will revise that script again. Soon.
Back to top
View user's profile Send private message 
PaulBx1

Joined: 16 Jun 2006
Posts: 2308
Location: Wyoming, USA

PostPosted: Tue 12 Dec 2006, 19:29    Post subject:  

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.
crypt-pupsave.tar.gz
Description 
gz

 Download 
Filename  crypt-pupsave.tar.gz 
Filesize  3.34 KB 
Downloaded  373 Time(s) 
Back to top
View user's profile Send private message 
John Doe

Joined: 01 Aug 2005
Posts: 1689
Location: Michigan, US

PostPosted: Thu 14 Dec 2006, 16:00    Post subject:  

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.html#SEEDINGRANDOM

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" Wink

http://www.asciitable.com/
Back to top
View user's profile Send private message 
John Doe

Joined: 01 Aug 2005
Posts: 1689
Location: Michigan, US

PostPosted: Thu 14 Dec 2006, 16:54    Post subject:
Subject description: Logic for Shutdown Script
 

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.
Shutdown-Crypto.tar.gz
Description 
gz

 Download 
Filename  Shutdown-Crypto.tar.gz 
Filesize  1.11 KB 
Downloaded  373 Time(s) 

Last edited by John Doe on Thu 14 Dec 2006, 20:14; edited 2 times in total
Back to top
View user's profile Send private message 
Carpe.Diem


Joined: 07 Dec 2006
Posts: 5

PostPosted: Thu 14 Dec 2006, 18:27    Post subject: Please tell be about the nature of the encryption system
Subject description: I need more than how to make it work, I want to know about what's being used here
 

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.

_________________
...Will Puppy Penguin swat poor Butterfly? Stay tuned...
Back to top
View user's profile Send private message 
John Doe

Joined: 01 Aug 2005
Posts: 1689
Location: Michigan, US

PostPosted: Thu 14 Dec 2006, 19:35    Post subject: Re: Please tell be about the nature of the encryption system
Subject description: I need more than how to make it work, I want to know about what's being used here
 

> 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_Encryption_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.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 5 [73 Posts]   Goto page: Previous 1, 2, 3, 4, 5 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1176s ][ Queries: 12 (0.0047s) ][ GZIP on ]