Page 3 of 3 FirstFirst 123
Results 21 to 24 of 24

Thread: Full disk encryption--an explanation of exactly how does it work from the user's end?

  1. #21
    Join Date
    Oct 2009
    Beans
    Hidden!
    Distro
    Ubuntu 18.04 Bionic Beaver

    Re: Full disk encryption--an explanation of exactly how does it work from the user's

    Quote Originally Posted by StewartM View Post
    Hmm, I didn't do an Ubuntu install, but I did do a Bodhi install of the LTS release equivalent of 20.04 (which would be a downstream release) for a friend and tried the hard drive encryption and didn't see these options. Moreover, after a lot of searching I never saw any resource that described what you just posted (several things that had long pages of command line stuff, and I'm old school enough to follow the adage (which has been posted on the Ubuntu forums) is that "never copy and paste and execute command line commands you don't understand, due to the potential of executing malicious code"). And even these pages didn't have every option I wanted.
    I've used this guide to set up one of my boxes with full disk encryption of the OS drive. My /boot is running of a 32GB USB stick. You can make it so /boot is on it's own partition, but it complicates things.

    https://www.linux.com/training-tutor...stem-lvm-luks/

    There is also a pretty good guide on the Arch Wiki - the commands are generic Linux commands, not specific to Arch.

    https://wiki.archlinux.org/title/Dm-...em#LVM_on_LUKS

    What I did see while doing this install and searching for solutions (my friend's laptop had only 2 GB of RAM, which was why I was installing Bodhi and not Ubuntu, as it was below the recommended specs) was the people struggling with the default swap partition/file size issue. The default install gave me only 1 GB of swap for a laptop having 2 GB RAM, which seemed to me inadequate for a machine so limited; I would have voted for 4 GB swap, Lots of other people too thought it was inadequate, but from what you showed, it should be trivial to set up. But no one mentioned it or seemed to be aware of it.
    The default behavior was changed quite a while ago because machines normally have more memory on them nowadays and it would be dumb to use 32GB of space for swap when a machine is running with 16GB of RAM. Some stuff I read mentioned a swap file by default, but that hasn't been my experience (granted, I'm only running 18.04 as a VM currently with Debian for everything else).

    On my 18.04 box, I've got a swap partition.

    Code:
    cat /proc/swaps
    Filename                                Type            Size    Used    Priority
    /dev/dm-1                               partition       4190204 6716    -2
    Another thing that I find frustrating and backward (and is disappointing) is that the Linux distros I've tried still keep showing the users " ****** "s for their passphrases. All the standalone encryption software I've used of good repute (Scramdisk, TrueCrypt, Veracrypt, etc) now give the "show passphrase" option because they understand that showing the passphrase encourages users to create stronger passphrases while strings of ****'s lead them to use weaker passphrases. Now Windows 10 allows one to peek at what one typed in to encourage stronger passphrases; I don't know about Mac. But Linux still enforces the "*****"s. The reason I mention this is an IT friend of mine (who's a Linux user) says the "****"s are "the industry standard" but that can't be as Windows 10 now allows users to view their passphrases.

    IMHO, the history of ****s dates from terminal/mainframe days, when encryption wasn't used, and people used their girlfriend's or dog's name or whatnot to login, passphrases so weak that someone peeking over their shoulder might spot and use to hack the account. With encryption, passphrases that are generally equal to at least a 128-bit key that would resist a dictionary attack someone could not spot and memorize in a 3-second peak, unlike "Rover", so whatever security one would lose by this option would be more than offset by users generating and using stronger passphrases. I know that someone could set up a hidden camera to capture passphrases but someone with that kind of access would just install a keylogger on the machine to be compromised. So to me, there's no good reason not to allow them.
    The whole "don't echo the password to the screen" thing was a Linux thing for a long time. Windows has always showed your masked password, but now they give you the option to see it since typos happen.

    I can't tell if you are supporting this behavior or if you think it's bad. The user experience where you don't get anything echoed to the screen while typing on the keyboard is confusing, especially for someone who is used to Windows.

    I haven't seen any cases where cryptsetup will echo your password to the screen. If you are concerned that displaying the masked password makes users pick poor passwords, use a password generator so you don't have to think about it.
    Come to #ubuntuforums! We have cookies! | Basic Ubuntu Security Guide

    Tomorrow's an illusion and yesterday's a dream, today is a solution...

  2. #22
    Join Date
    Aug 2007
    Location
    Kingsport TN
    Beans
    148
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: Full disk encryption--an explanation of exactly how does it work from the user's

    Charles,

    I was complaining that not being able to see your passwords (which Truecrypt, Veracrypt, Scramdisk and other noteworthy encryption programs *do allow*) does drive weak passphrase creation. It's much easier to type in correctly a passphrase equivalent to a 256-bit key when you can see what you're typing; very difficult when you don't.

    But I have another question--have you had any problems with encrypted swap being disabled on kernel upgrades?

    cryptsetup: WARNING: Option 'size' missing in crypttab for plain dm-crypt
    mapping cryptswap1. Please read
    /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz and add the correct
    'size' option to your crypttab(5).
    cryptsetup: WARNING: Resume target cryptswap1 uses a key file

    I had this, and the fix is to 1) update in /etc the crypttab file and append "size=256" at the end. Then you also have to update initramfs:

    swapoff -a

    sudo update-initramfs -c -k all

    swapon -a
    This has bitten a number of people, just wanted to know if it was your experience too.

  3. #23
    Join Date
    Oct 2009
    Beans
    Hidden!
    Distro
    Ubuntu 18.04 Bionic Beaver

    Re: Full disk encryption--an explanation of exactly how does it work from the user's

    Quote Originally Posted by StewartM View Post
    Charles,

    I was complaining that not being able to see your passwords (which Truecrypt, Veracrypt, Scramdisk and other noteworthy encryption programs *do allow*) does drive weak passphrase creation. It's much easier to type in correctly a passphrase equivalent to a 256-bit key when you can see what you're typing; very difficult when you don't.
    That makes sense. I've lost count of the number of times I've made a typo when trying to punch in my encryption key and having to retype it in. It's a minor inconvenience through, since there isn't a mechanism for wiping the drives if you put the wrong passphrase in.

    As for the swap file issue - I haven't run into that, but my installs are older (and I'm also running Debian) instead of Ubuntu, so I don't know if that explains the difference.

    I do know, I had a hell of a time with getting the post upgrade scripts to add cryptsetup to the initramfs images.
    Come to #ubuntuforums! We have cookies! | Basic Ubuntu Security Guide

    Tomorrow's an illusion and yesterday's a dream, today is a solution...

  4. #24
    Join Date
    Aug 2007
    Location
    Kingsport TN
    Beans
    148
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: Full disk encryption--an explanation of exactly how does it work from the user's

    Well, two things happened to my new desktop (ordered from a Linux vendor with Mint--their preference--and wit the LUKS encryption setup).

    1) I mistakenly downloaded and install Hplip from HP to run what I thought was a All-in-one device (but wasn't). Doing that and replacing the Linux hplip broke several things in the Cinnamon desktop. I was able to revert the Hplip back to the Linux version, but several things in Cinnamon remained broken (after doing multiple searches on what others had found and done, I tried these and either they didn't work or they didn't apply to me). Finally I tried removing and re-installing the broken components, and that resulted in a system that I can boot but after I log in I get a blank screen.

    So...I'm going to first try completely removing Cinnamon (purging) and then re-installing it at the recovery command prompt. If not, I'll have to learn how to set things back up myself. I suspect that will be relatively easy, as /home is on a separate disk I will just take what I see already set up Gparted during the installation. I may first try just doing the installation without erasing the filesystem partition; if that doesn't work I'll do it with erasing/formatting the filesystem (but not home).

    2) But I have yet another thing to do before that. I still had the old hard drive mounted in the desktop with an Ubuntu 16.04 install, so still I had a usable system to use before doing the above. But last night, the new computer's power supply apparently croaked. I have a 750 W spare, that is relatively new (only like 2 years old), so I have something I can plug in.

    Oh and according to what I'm seeing looking in my crypttab, the default LUKS encryption for /swap does use a randomly generated key.

    https://wiki.archlinux.org/title/Dm-...wap_encryption
    In systems where suspend-to-disk (hibernation) is not a desired feature, /etc/crypttab can be set up to decrypt the swap partition with a random password with plain dm-crypt at boot-time. The random password is discarded on shutdown, leaving behind only encrypted, inaccessible data in the swap device.

    To enable this feature, simply uncomment the line beginning with swap in /etc/crypttab. Change the <device> parameter to the name of your swap device. For example, it will look something like this:

    /etc/crypttab

    # <name> <device> <password> <options>
    swap /dev/sdX# /dev/urandom swap,cipher=aes-xts-plain64,size=256
    In fact, you have to modify the install with a fixed LUKS key to do hiberation

    https://help.ubuntu.com/community/En...hEncryptedSwap
    Last edited by StewartM; July 27th, 2021 at 10:36 PM. Reason: Forgot something

Page 3 of 3 FirstFirst 123

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •