Full-disk encryption Puppy for regular user (Solved)

[bark_bark_bark]

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!

Code: Select all

# menu.lst produced by grub4dosconfig-v1.9.2
color white/blue black/cyan white/black cyan/black
#splashimage=/splash.xpm
timeout 10
default 0

# Frugal installed Puppy

title Fatdog64
  uuid 8fd25b80-05ab-411b-a488-28937897524b
  kernel /vmlinuz pmedia=atahd savefile=direct:device:sda2:/fd64save:dmcrypt 
  initrd /initrd

# Windows
# this entry searches Windows on the HDD and boot it up
title Windows\nBoot up Windows if installed
  errorcheck off
  find --set-root --ignore-floppies --ignore-cd  /bootmgr
  chainloader /bootmgr
  find --set-root --ignore-floppies --ignore-cd  /ntldr
  chainloader /ntldr
  find --set-root --ignore-floppies --ignore-cd   /io.sys
  chainloader /io.sys
  errorcheck on

title Fatdog64 Safe mode (without X)\nTry 'xorgwizard' after bootup succeed to start graphic mode.
  uuid 8fd25b80-05ab-411b-a488-28937897524b
  kernel /vmlinuz    pfix=ram,nox nosmp noapic i915.modeset=0 radeon.modeset=0 nouveau.modeset=0
  initrd /initrd

title Fatdog64 RAM mode\nBoot up Puppy without pupsave
  uuid 8fd25b80-05ab-411b-a488-28937897524b
  kernel /vmlinuz    pfix=ram
  initrd /initrd

# Multiple Windows

title Unknown(sdb1/menu.lst)
  uuid F69A463C9A45F99F
  configfile /menu.lst
  commandline

# Boot from Partition Boot Sector

title Fatdog64 (sda1:PBS)
  uuid 8fd25b80-05ab-411b-a488-28937897524b
  chainloader +1

title Unknown (sdb1:PBS)
  map (hd1) (hd0)
  map (hd0) (hd1)
  map --hook
  uuid F69A463C9A45F99F
  chainloader +1

title Boot from sdb (SanDisk Extreme)
  map (hd1) (hd0)
  map (hd0) (hd1)
  map --hook
  chainloader (hd0)+1

# additionals

title Find Grub2\nBoot up grub2 if installed
  errorcheck off
  find --set-root --ignore-floppies --ignore-cd /boot/grub/i386-pc/core.img
  kernel/boot/grub/i386-pc/core.img
  find --set-root --ignore-floppies --ignore-cd /boot/grub/core.img
  kernel /boot/grub/core.img
  errorcheck on

title Grub4Dos commandline\n(for experts only)
  commandline

title Reboot computer
  reboot

title Halt computer
  halt

and yes, it worked when entered manually. In case it matters, I installed fatdog and the bootloader using the fatdog installer.

[SFR]

Code: Select all

title Fatdog64 
  uuid 8fd25b80-05ab-411b-a488-28937897524b 
  kernel /vmlinuz pmedia=atahd savefile=direct:device:sda2:/fd64save:dmcrypt 
  initrd /initrd 

Hmm, putting aside that grub4dos has added 'pmedia=atahd', which isn't supported (but won't hurt either) in Fatdog, everything looks normal...
So what exactly happens when you boot using the above entry?

Greetings!

[bark_bark_bark]

Code: Select all

title Fatdog64 
  uuid 8fd25b80-05ab-411b-a488-28937897524b 
  kernel /vmlinuz pmedia=atahd savefile=direct:device:sda2:/fd64save:dmcrypt 
  initrd /initrd 

Hmm, putting aside that grub4dos has added 'pmedia=atahd', which isn't supported (but won't hurt either) in Fatdog, everything looks normal...
So what exactly happens when you boot using the above entry?

Greetings!

it boots a fresh session without loading the savefile. For some odd reason, the bootloader has a bunch of entries that aren't in the menu.lst file.

[SFR]

For some odd reason, the bootloader has a bunch of entries that aren't in the menu.lst file.

Don't you have also syslinux.cfg somewhere next to menu.lst by any chance?
I suspect you are actually using syslinux, not grub4dos.
If so, find the default entry (should start with label fatdog and edit its append line (rootfstype=ramfs should be already there):

Code: Select all

append rootfstype=ramfs savefile=direct:device:sda2:/fd64save:dmcrypt

Greetings!

[bark_bark_bark]

For some odd reason, the bootloader has a bunch of entries that aren't in the menu.lst file.

Don't you have also syslinux.cfg somewhere next to menu.lst by any chance?
I suspect you are actually using syslinux, not grub4dos.
If so, find the default entry (should start with label fatdog and edit its append line (rootfstype=ramfs should be already there):

Code: Select all

append rootfstype=ramfs savefile=direct:device:sda2:/fd64save:dmcrypt

Greetings!

That worked! Thanks to you and jamesbond for all the help.

[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.

Coming soon.

Code: Select all

# key{n} - key1, key2, key3 ... load keyfile for use with dmcrypt
#          Usage: key{n}=[wait:]type:id:path:[crypt] (wait, crypt optional)
#		   - [wait:]device:dev:path[:crypt] - specific device 
#		   - [wait:]label:label:path[:crypt] - specific label
#		   - [wait:]uuid:uuid:path[:crypt] - specific uuid
#          - ask - ask for parameter at boot time
#          
#          Note: if "wait" is given, system will wait for Enter key at boot.
#                This is to give time for user to insert media containing the key.
#          Note: if "crypt" or "dmcrypt" is given, it is assumed that the
#                partition that holds the key is encrypted.
#          Note: key1, key2 etc must be sequential. If a number is missing
#                the rest of the keys are ignored.
#          Note: keys are used in order specified. E.g. if you specify
#                basesfs with dmcrypt, then a key is consumed.
#                If you the save partition is dmcrypt-ed, again another key
#                is consumed. Same for the savefile. Actual number of keys
#                consumed depends on who many dmcrypt-ed stuff are used.
#          Note: keyfiles are not used while loading keys themselves.

Even the keyfile can reside in an encrypted partition (but of course, you will need password to load that keyfile). If you run an encrypted savefile in an encrypted partition, you can specify two different keys for them; and those two key files can come from different USB keys. Maximum protection
Be sure not to lose those keys though. There is no publicly known recovery if you do.

[rufwoof]

For disk/partition encryption a key character sequence of up to 512 characters or a keyfile of up to 8MB is used. A problem with both as I see it is that's repeatedly applied - across multiple blocks (being a block device). Which makes conceptual cracking easier.

During WW2 German communications eavesdroppers at Bletchley Park got to recognise certain individuals 'style' of message transmission. Although the messages were encrypted pattern recognition indicated certain radio operators were transmitting the (morse code) message. In some cases the operators followed a message pattern ... something along the lines of perhaps signing each message with Kindly Yours. Bob. Knowing (deducing) that bit of encrypted message and working backwards, the message key (encryption) could be deduced computationally and hence the key cracked and with a common daily key - all other messages could be decrypted. In some cases the British military were reading decrypted messages before the intended German recipient.

I would suspect that data blocks (block devices) would have common Kindly Yours. Bob type content and in using a common block key could be reverse engineered.

Safer IMO to encrypt individually (each file) using a unique key and where the key size >= message size and with the key stored separately/elsewhere. A type of disk mirroring with one (removable) disk containing unique key files of the same size as the unencrypted file content, and the second 'encrypted' disk containing the unencrypted file XOR'd with the key. Without the key drive/disk, the encrypted disk content cannot be decrypted. If any one file is (fully/partially) cracked (perhaps by deducement), that's of no benefit toward decrypting any other file.

A risk factor is that you have two devices (disks) required to read each file content and a failure in either results in total data loss.

[rufwoof]

Edited (later version) see next post

[rufwoof]

Here's a utility that takes a file and creates a encrypted version (.fck suffix) and a keyfile that is of the same size as the encrypted file.

If you upload a encrypted (.fck) file to somewhere like googledrive then no one can decode that without the corresponding key. Keep the key locally and only you can decrypt the file.

Full one time pad keys of the same size as the message (non encrypted file) are resilient to brute force crack attempts and one of the safest choices of encryption (given a trully random key such encryption is proven to be uncrackable). The downside is that you don't save any disk space if you upload a encrypted file to googledrive as the key is the same size as the data/file.

The key for pcrypt is generated using /dev/urandom which is pure random as it is influenced by hardware/environment, such as disk spin speeds, interrupts ...etc.

Attached is the sfs (with fake .gz suffix) which also includes the C source code. Once installed (sfs loaded) pcrypt (as its called) is registered under the Puppy menu entry of Menu, Personal.

Open pcrypt and drag a file into it, click OK and it creates a encrypted copy of that file with a .fck suffix/extension (Full Crypt Key). A file with a .key suffix is also created and that should be kept safe/secret. The .fck file can be uploaded to the likes of googledocs or wherever and no one else can read the content of that encrypted .fck file without also having the .key file. To decrypt have both the .fck and .key files in the same directory (both must have the same filenames prior to the .fck/.key extensions) and drag the .fck file into pcrypt and click OK (see later (16th Jan update), now supports just clicking the .fck file in order to start the pcrypt gui). The code automatically opts to decrypt if the file extension is .fck - otherwise it assumes encryption is required. Whilst encrypting/decrypting there's a percentage progress indicator (useful when larger files are being processed).

The pcrypt file can be run as a terminal program, but doesn't support streams (pipe).

16th Jan 2016 update : extended the SFS to add file association/MIME for the .fck file type. So once the SFS is loaded, clicking on a file with a .fck filename suffix will automatically open the pcrypt gui. Handy for if you keep .fck files on perhaps googledrive and download those as required to a local drive that contains the associated .key file, as once downloaded a simple click on the .fck file has you at the pcrypt gui with the filename populated, ready to simply just click the OK button to decrypt. Work on the file ... and then right mouse click, Open With and select 'pcrypt' and you're ready to re-encrypt and store new .fck and .key files (I have /usr/sbin/pcrpypt_gui as a desktop icon - so I can just drag/drop files onto that).

17th Jan updated to set output file with the same permissions as the imput file i.e. preserve file permissions.

[slavvo67]

Does PCrypt work across platforms? The only two that I've had success with in the past were Axcrypt and TrueCrypt. So, for example, I've used encryption on one platform that is simply folder within folder and fairly easily accessible in another platform.

[rufwoof]

It sources random (key) data from /dev/urandom, so creating on another platform would be subject to that 'device' being available i.e. Linux. For decoding it uses byte size processing (XOR) so could be compiled to extract on other platforms. The C code would need to be changed/compiled to reflect that though.

[rufwoof]

In some countries you can be held in custody until you reveal your passwords. In which case obvious encryption is totally negated. Worse still is if something looks like its encrypted but actually isn't then you could get trapped into a prolonged situation where they think you are intentionally refusing to reveal a password where in reality you don't even know of any password for what they are referring. "OK we'll put you back into custody for another couple of weeks and then take you back into court to ask yet again what the password is for xyz".

Rather than in-your-face encryption, blatantly obvious that encryption is being used, disguised encryption could be the better choice. If you are obviously using encryption for anything, then they may find things that look to fit the bill, but that you haven't declared the password for. You do however have to take steps to deeply disguise that intentional encryption is being used, no clear text scripts for instance to do the opening/closing. Along with plausible deniability - where the likes of a potentially encrypted file isn't actually a encrypted file but instead is something else.

Fundamentally anything without a MAGIC code that contains seemingly random data might be considered as potentially being a encrypted storage. The likes of xor based encryption can have its frequencies inspected (by xor'ing with itself shifted and repeated). If both the data and key aren't normalised to have around the same number of occurrences of all bytes then that can reveal partial content, enough to give clues as to the content or method used for encryption.

In short, securing data using encryption could be a greater risk than not. Even if heavily disguised, forensic analysis could indicate, perhaps falsely, that encrypted content might be being hidden. Better to perhaps not use encryption at all other than 'standard' encryption methods (as contained in browsers etc.), and instead retrieve secure data from a secure server via a secure link as/when needed rather than physically crossing borders with encrypted content included within your laptop/device.

[James186282]

One Time Pad encryption for puppy?!?! Congrats to you and thanks for doing this. I was pondering the onetimeness of a large random file. For true randomness I believe there was some project that recorded static and sender and receiver were supplied the same file. Each encypted file ate away part of the static noise random file so it was never used twice. Anyway your project is great and am glad someone else is doing this.

I know there are some tools to verify random number generation but can't think of the names of them off the top of my head. It would be interesting to see if Puppy's random number generator is truly random.

[rufwoof]

Basically /dev/random and /dev/urandom are both sourced with pretty much real world 'random' entropy (activities) from bootup, but where as that entropy is eaten at a faster rate than being added can result in /dev/random blocking ... so you end up with as good as 'open' encryption (zeros loaded into your 'random' buffer. Whilst urandom resorts to pseudo random, so at least the buffer content looks like random content).

Good enough for most except the more extreme cases. As the amount of entropy before hitting the limit is also random, so any potential 'key' that opened ineligible clear text could still be considered as having randomly occurred as equally any other possible ineligible clear text.

I did have a play with merging 'random' sources, such as using a simple/short key ... a entered 'password/string' and then md5 that to produce a 16 byte sequence and then using random choices of a substring formation from that as the 'string' into the next md5 16 byte sequence ... etc. ... and then randomly selecting to use random numbers of bytes from either that stream or the (potential) pseudo /dev/urandom stream. But that did lead to longer encoding times. Not really worth it IMO. If you did need that sort of level of security then you wouldn't be running a Puppy.

My pcrypt as-is doesn't compress the input, its assumed that's already been done, and compression is important as that normalises the data (approximately equal number of occurrences of all bytes 0..255) which is important as otherwise Xor'ing with itself and shift/repeat can yield frequency counts that could indicate/reveal part of the content.

A cautionary note is that if you use encryption then that could lead to more problems than not having used encryption. Cross some international borders for instance and if its apparent you are familiar with i.e. are using encryption outside of what a conventional off-shelf program might do, then that could result in inspection indicating potential encrypted content, that isn't actually encrypted content (random looking data content). Which could lead to you being detained in custody until such times that you reveal the password/method. They believe you are intentionally not disclosing a password for something where no actual password exists. Maybe taking you back into court every couple of weeks, keeping you in custody between times, for something they believe you are withholding, but aren't. https://en.wikipedia.org/wiki/Key_disclosure_law

I guess its best not to travel internationally with electronics that could land you in a trapped position, which includes smart phones, usb's/DVD's etc.. And instead rent/buy/use/dispose such electronics internally within each country. Have a ssh private key written down on paper and you could enter that into a rented/bought device and electronically transfer data/OS across boundaries in a secure manner (assuming the hardware was trustworthy).