Page 1 of 2
Full-disk encryption Puppy for regular user (Solved)
Posted: Mon 11 Jan 2016, 02:12
by bark_bark_bark
I would like to full-disk encryption become a feature in puppy, if it isn't there already. I'm also wondering if somebody will add regular users as a feature as well.
Posted: Mon 11 Jan 2016, 12:41
by jamesbond
Try Fatdog. Two ways:
a) boot from USB. Make entire harddisk as one big partition. Encrypt entire partition. Tell Fatdog to use the entire partition as 'savedir".
b) Boot from harddisk. Split into two partition. One small one (for your boot files - bootloader, Fatdog sfs, extra SFS etc), and one big one (for savedir). Encrypt the large partition. Tell Fatdog to use it as savedir.
No keys ever is stored in your USB or your disk. Keys are asked when system boots up. If you forget your key, your data is toast. Really.
No install wizard for these, though. You must use command line and do it via terminal.
Fatdog is different from puppy - you need to get used to it.
Posted: Mon 11 Jan 2016, 12:55
by bark_bark_bark
What commands do I need for encrypting the drive and swap?
Posted: Mon 11 Jan 2016, 13:23
by jamesbond
"cryptsetup luksFormat"
Details here:
https://wiki.archlinux.org/index.php/Dm ... ile_system. Look at the commands only, anything to do with /etc/crypttab and systemd should be ignored.
Posted: Mon 11 Jan 2016, 13:44
by SFR
bark_bark_bark wrote:swap
I have this in my rc.local:
Code: Select all
cryptsetup open --type plain --key-file /dev/urandom /dev/sda4 cswap
mkswap /dev/mapper/cswap
swapon /dev/mapper/cswap
is my swap partition.
I wouldn't recommend using encrypted swap
file though - had nothing but problems with it:
http://www.murga-linux.com/puppy/viewto ... 022#857022
Greetings!
Posted: Mon 11 Jan 2016, 14:39
by jamesbond
Was about to recommend testing for zswap but it is not enabled in the current kernel. Ouch.
Let's try zram: SFR - have you used zram instead? Create a moderately sized zram and swap to it? Theoritically speaking since zram on average can do 2:1 compression, swapping to a x MB sized zram is the same as if you're adding x MB of RAM (tradeoff with CPU overhead for the compression). Any experience to share on that?
PS: There is no need to encrypt zram since it's ephemeral.
Posted: Mon 11 Jan 2016, 15:01
by bark_bark_bark
ok, so now how do I set it up to use for my savedir and how do i get it to mount at start up.
Posted: Mon 11 Jan 2016, 15:18
by rufwoof
jamesbond wrote:Was about to recommend testing for zswap but it is not enabled in the current kernel. Ouch.
Let's try zram: SFR - have you used zram instead? Create a moderately sized zram and swap to it? Theoritically speaking since zram on average can do 2:1 compression, swapping to a x MB sized zram is the same as if you're adding x MB of RAM (tradeoff with CPU overhead for the compression). Any experience to share on that?
PS: There is no need to encrypt zram since it's ephemeral.
I created a zram based swap file in Tarh 6.0.2
http://murga-linux.com/puppy/viewtopic. ... 272#877272. But I'm running on a single core and someone mentioned that on multi-core you need to set up a zram swap for each core. LazyPuppy looked further into how to detect how many cores there are ...etc. I'm running with a later kernel (one of emsee's) that has lz4 support, which also isn't compiled into the standard Tahr pup. So not sure whether the standard Tahr pup supports zram either.
In practice swap seems to relatively little used on a puppy with reasonable hardware as puppy's small size versus more common large amounts of memory/ram the only time it tends to get used is in runaway type cases and the 'extra' ram only sustains that longer than if no swap is available. I really had to push my puppy to get to a stage of utilising swap. When it does occur however its more a case of something like 1GB of ram with no swap being exhausted after 1GB of usage, or half of ram allocated to zram swap and the main puppy running out of conventional ram at 500MB, but able to swap another 1GB or so (2:1 compression assumed) before hitting its ceiling.
Not sure how zram actually compresses either. Some compressors don't compress everything for instance lzop only compresses regular files, not directories which makes for faster retreival (decompression) i.e. if you extract file xyz from directory abc. Even still, having swap running in ram and not on disk is more secure even if it isn't cloaked in compression.
Posted: Mon 11 Jan 2016, 15:26
by SFR
jamesbond wrote:Let's try zram: SFR - have you used zram instead?
I was going to enable ZSWAP when I was compiling 4.3.3, but forgot - I'll try it with next stable release.
As for the ZRAM, I'm trying it now with the default lzo compression (I have also enabled lz4):
Code: Select all
# modprobe zram num_devices=1
#
# echo $((128*1024*1024)) > /sys/block/zram0/disksize
#
# mkswap /dev/zram0
Setting up swapspace version 1, size = 131068 KiB
no label, UUID=dcff17cc-2d41-4910-aae4-d790ce96bea8
#
# swapon /dev/zram0
#
# cat /proc/swaps
Filename Type Size Used Priority
/dev/zram0 partition 131068 0 -1
#
# # And a bit later, after overloading RAM...
#
# cat /proc/swaps
Filename Type Size Used Priority
/dev/zram0 partition 131068 129128 -1
#
Seems to work fine, thanks!
Greetings!
Posted: Mon 11 Jan 2016, 16:06
by rufwoof
jamesbond wrote:b) Boot from harddisk. Split into two partition. One small one (for your boot files - bootloader, Fatdog sfs, extra SFS etc), and one big one (for savedir). Encrypt the large partition. Tell Fatdog to use it as savedir.
No keys ever is stored in your USB or your disk. Keys are asked when system boots up. If you forget your key, your data is toast. Really.
Any key based encryption could conceptually be cracked given enough time/processing power. For absolute security the key needs to be as (or longer) than the message being encrypted and the encryption created using a XOR of that key/message pair.
A pup booted from USB readonly, where the USB also contains that key, that's XOR'd with the message and the resulting file stored on HDD is secure if the laptop/HDD is lost but the USB retained (not stolen).
More usually the key is random data, unique to each message, however a simple large key with a offset into that for the start point and jump (end chained to start) is pretty secure for multiple usage of the same keyfile.
Posted: Mon 11 Jan 2016, 16:17
by bark_bark_bark
ok, so how do I set it up to use for my savedir and how do i get it to mount at start up.
FATDOG7 Savedir question
Posted: Mon 11 Jan 2016, 16:37
by gcmartin
2 easy methods (although others may prefer different methods)
- One method is to use the boot parms to identify the session's save folder.
Another is boot the ISO and at end of session save for subsequent use via selection of proper option at boot time (options 1, 2 or 4 as I remember).
Hope this helps
Posted: Mon 11 Jan 2016, 16:43
by jamesbond
@SFR, @rufwoof, thanks for the insightful feedback.
As for the file-based key as opposed to passphrase - that sounds interesting. Let me think about it.
@bark_bark_bark: Reference here:
http://distro.ibiblio.org/fatdog/web/fa ... l#savefile.
You need to specify savefile parameter like this: savefile=direct:device:sda4:/:crypt
Replace "sda4" with your correct partition. Refer to the reference given for variations of specifying the device (by UUID, by label, etc).
EDIT: I wanted to make a new post but accidentally edited this one.
Posted: Mon 11 Jan 2016, 17:35
by rufwoof
SFR wrote:As for the ZRAM, I'm trying it now with the default lzo compression (I have also enabled lz4):
Code: Select all
# modprobe zram num_devices=1
#
# echo $((128*1024*1024)) > /sys/block/zram0/disksize
#
# mkswap /dev/zram0
Setting up swapspace version 1, size = 131068 KiB
no label, UUID=dcff17cc-2d41-4910-aae4-d790ce96bea8
#
# swapon /dev/zram0
#
# cat /proc/swaps
Filename Type Size Used Priority
/dev/zram0 partition 131068 0 -1
#
# # And a bit later, after overloading RAM...
#
# cat /proc/swaps
Filename Type Size Used Priority
/dev/zram0 partition 131068 129128 -1
#
you might like to assign a higher priority to the zram swap so that get's used first if there is also HDD swap. I have mine set to 10 (in /etc/rc.c/rc.local). Relative numbers so providing higher than other swaps it gets used first.
Code: Select all
modprobe zram
echo $((128*1024*1024)) > /sys/block/zram0/disksize &&
mkswap /dev/zram0 &&
swapon -p 10 /dev/zram0 &&
exit 0
Apparently it can be beneficial to have some swap even when more than enough ram is available as when the system boots and some initialisation processes run that allocate private memory, that memory remains consumed even if never used again during the session. With swap that memory can be 'freed' up i.e. swapped out (or in the case of zram swap, use less memory (is compressed)).
I like your choice of 128*1024*1024, seems like a reasonable choice of not too little, not too much for a puppy system.
The other benefit is that if a runaway process does occur then rather than just falling over once all of memory is consumed, with a swap the system tends to slow to a crawl - less harsh than just an abrupt crash (a possible chance to kill the offending process).
Posted: Mon 11 Jan 2016, 17:39
by bark_bark_bark
jamesbond wrote:@SFR, @rufwoof, thanks for the insightful feedback.
As for the file-based key as opposed to passphrase - that sounds interesting. Let me think about it.
@bark_bark_bark: Reference here:
http://distro.ibiblio.org/fatdog/web/fa ... l#savefile.
You need to specify savefile parameter like this: savefile=direct:device:sda4:/:crypt
Replace "sda4" with your correct partition. Refer to the reference given for variations of specifying the device (by UUID, by label, etc).
I tried using that line (of course with the sda4 changed to sda2) and it fails to detect the savefile and I don't get any prompt for LUKS passkey.
Posted: Mon 11 Jan 2016, 18:07
by SFR
bark_bark_bark wrote:jamesbond wrote:@SFR, @rufwoof, thanks for the insightful feedback.
As for the file-based key as opposed to passphrase - that sounds interesting. Let me think about it.
@bark_bark_bark: Reference here:
http://distro.ibiblio.org/fatdog/web/fa ... l#savefile.
You need to specify savefile parameter like this: savefile=direct:device:sda4:/:crypt
Replace "sda4" with your correct partition. Refer to the reference given for variations of specifying the device (by UUID, by label, etc).
I tried using that line (of course with the sda4 changed to sda2) and it fails to detect the savefile and I don't get any prompt for LUKS passkey.
Hmm, let's do it from scratch, step-by-step:
0. Boot without savefile (
savefile=none)
1. Format
/dev/sda2 as LUKS:
2. Open it:
3. Create a filesystem:
4. Reboot and choose to create Save File
5. On "Choose the device/partition to save to" tab select
/dev/dm-0
6. On the next tab check "Save in a directory"
7. You can leave the default
/fd64save path
Now, add this to your bootloader:
Code: Select all
savefile=direct:device:sda2:/fd64save:dmcrypt
I've just done it in VBox and it worked well.
Greetings!
Posted: Mon 11 Jan 2016, 19:17
by bark_bark_bark
SFR wrote:Now, add this to your bootloader:
Code: Select all
savefile=direct:device:sda2:/fd64save:dmcrypt
How can I add that to menu.lst so I don't have to enter it everytime?
Posted: Mon 11 Jan 2016, 19:49
by SFR
Append it to a line that starts with kernel.
Greetings!
Posted: Mon 11 Jan 2016, 20:06
by bark_bark_bark
SFR wrote:Append it to a line that starts with kernel.
Greetings!
It didn't seem to work.
Posted: Mon 11 Jan 2016, 20:27
by SFR
And what is the exact content of your menu.lst?
Btw, I understand that when you entered that line manually at boot, everything worked, right?
Greetings!