hibernation luks encrypted swap without lvm

Originally Posted by Richard Cranium I haven't noticed any slowdown with normal operations. That would be on an HP635 laptop or an old Toshiba Satellite from 2008.

But gives you an advantage, compared with keeping the sensitive data in an external hard drive, for example?

I ask this because I know well (TBH, from the news) that even really bad and tough guys like the Chechen Mafia, who are unholy students of Sicilian Mafia and Al-Qaeda, they strongly prefer the external hard drives to keep their secret data.

@Darth Vader

Thanks and I agree my question about swap files better should be a subject in another thread.

@LuckyCyborg

Ha ha! Good one! Basically you ask: what is good for protecting Mafia's secrets and (supposedly) create real headaches to authorities, it is still not enough to protect a Slacker's porn collection from his kids?

BUT, as you said yourself, MYTHS! MYTHS EVERYWHERE! And our kids are particularly smarter, you know...

Looking back, in this case, I think Eric is the inventor, Patrick agreed in a final and included that, then the crowd followed the trend.

The real security compared with another solutions, could be, well... questionable, specially when you talk about a World-wide approach, BUT at least the "recommend encryption way" is optional, then no one stops a particular user to use alternate and maybe better ways.

Long story short, I do not think that the Slackware encryption ways are supposed to protect data which disclosed could end for someone to end with a life long sentence or in the front of a firing squad.

PS. CryptSetup 2.0 is there: http://www.saout.de/pipermail/dm-cry...er/005771.html It could be interesting for the crypto geeks.

Originally Posted by LuckyCyborg But gives you an advantage, compared with keeping the sensitive data in an external hard drive, for example?

I only want to carry around one thing, not two. My only concern is if the laptop was stolen or I replace the hard drive due to failure; I'm not attempting to hide secrets worth my life but hiding things that I do not wish to be public.

EDIT: If you only encrypt some things but not other things, then any idiot would conclude that the stuff you are encrypting is much more important to you than the stuff you aren't.

Originally Posted by Richard Cranium I only want to carry around one thing, not two. My only concern is if the laptop was stolen or I replace the hard drive due to failure; I'm not attempting to hide secrets worth my life but hiding things that I do not wish to be public. EDIT: If you only encrypt some things but not other things, then any idiot would conclude that the stuff you are encrypting is much more important to you than the stuff you aren't.

I share these same thoughts.

Hi,

I needed to do this (have hibernate to encrypted swap without lvm) because I already installed Slackware and didn't want to re-install with LVM (following the other thread https://www.linuxquestions.org/quest...ernate-627958/). It's necessary to have swap encrypted otherwise if it's not and it's hibernated, then resuming will just resume from that unencrypted swap with no passphrase needed.

Here is how I did this, with /dev/sda1 the boot partition, /dev/sda2 root and /dev/sda3 swap

Setup the swap partition:

cryptsetup luksFormat /dev/sda3
cryptsetup luksOpen /dev/sda3 lukssda3
mkswap /dev/mapper/lukssda3

add to /etc/fstab:

/dev/mapper/lukssda3 swap       swap

I used "lukssda3" here because that's what mkinitrd will call it.

This swap partition needs to be decryptable at fresh boot up time (not resuming), and needs to be automatic if the root partition is already decrypted, so:

dd if=/dev/random of=/root/swap_key bs=1 count=20
cryptsetup luksAddKey /dev/sda3 /root/swap_key

This way it can be decrypted with either the passphrase or the /root/swap_key file. To get decrypted at boot, added this to /etc/rc.d/rc.local:

#Setting up swap here, because it's both encrypted and used for hibernation,
#and Slackware's scripts don't support that.  If the machine is resuming,
#this is not run at boot up (nothing else is either).

cryptsetup luksOpen --key-file /root/swap_key  /dev/sda3 lukssda3
swapon -a

/etc/lilo.conf:

image = /boot/vmlinuz-huge-5.12.14
  #mkinitrd -h /dev/mapper/lukssda3 -l uk -c -k 5.12.14 -s /root/initrd-tree -f ext4 -r lukssda2 -C /dev/sda3 -o /boot/initrd-5.12.14-resume.gz
  initrd = /boot/initrd-5.12.14-resume.gz
  root = /dev/mapper/lukssda2
  label = 5.12.14-resume
  read-only

image = /boot/vmlinuz-huge-5.12.14
  #mkinitrd -l uk -c -k 5.12.14 -s /root/initrd-tree -f ext4 -r lukssda2 -C /dev/sda2 -o /boot/initrd-5.12.14.gz
  initrd = /boot/initrd-5.12.14.gz
  root = /dev/mapper/lukssda2
  label = 5.12.14-fresh
  read-only

image = /boot/vmlinuz-huge-5.12.14
  #as fresh
  initrd = /boot/initrd-5.12.14.gz
  root = /dev/mapper/lukssda2
  label = 5.12.14-rescue
  read-only
  append="rescue"

This way, it defaults to resuming, and does so just by decrypting the swap partition, doesn't need to decrypt root - that's already decrypted in the hibernated system in the swap space. This boot up will fail if the machine was previously shutdown without hibernating, I couldn't see a way to make it detect that and just boot up normally (without patching mkinitrd).

Off topic, but for running scripts at resume time I did this, which I also couldn't find any documentation for. Created file /etc/rc.d/rc.local_resume with my stuff I want to run at resume time, and script hibertnate.sh which calls that rc.local_resume script when it resumes, which is just this:

#!/bin/bash
echo disk > /sys/power/state
/etc/rc.d/rc.local_resume

Then in my window manager bound a hotkey to run

sudo /path/to/hibertnate.sh

and put this in /etc/sudoers:

ldarby ALL = (root) NOPASSWD: /path/to/hibernate.sh

Darth Vader and LuckyCyborg's observations are not technical flaws of encryption--more like flaws in people: only flawed humans torture someone for their encryption key... no different than torturing a safe owner for the combination--the savageness of depravity in a state of nature hasn't changed--at least in theory, as such savagery is hearsay for me, and I plan on keeping it that way.

I use encryption as mere matter of principle. Privacy is important enough to keep secret and safe: your political view needs just as good hiding place as your porn in these days of tampering with elections... or perhaps your recipes -- Willy Wonka needs encrypted protection from Slugsworth, imho, and so on.

I like Darth Vader's idea of having an innocent front: an auto booted install, complete with some wedding and a few vacation photos... maybe some quaint blogs. To actually use my device, I'd have to interrupt the bootloader and supply the encrypted file system, otherwise it would end up at the front... Probably good for crossing international borders: that way you're never automatically prompted for a decryption key... you have to hit tab and know how to interrupt the boot sequence to get to that prompt...

fdisk would see the encrypted partitions... but not the average airport customs inspector; by not going to the encryption prompt you might avoid additional expert scrutiny...

I'm gonna call it the Forest Gump decoy partition.

Airport inspectors are a threat model I hadn't considered, but probably should, thanks. The threat model I was aiming to protect against was just the laptop being stolen, and wanting to not care at all about what was stored on it (e.g. persistent online shop logins that allow buying things).

The other threat model that I face is the UK government and the RIPA law. It's just waiting for the situation where the authorities believe someone has encrypted data, but they don't and it's just random, and they get locked up for "refusing" to decrypt it. Having a truecrypt style plausible deniable partition doesn't protect against this threat model, they'll just lock you up until you can prove you've decrypted everything, and if I understand correctly, if you don't have a decrypted file that fills the whole disk, you can't. Having this dummy front partition wouldn't lead to that situation (i.e. it's safe).