Expat-IT Tech Bits




Search this site:


/ (289)
  Admin/ (123)
    Apache/ (10)
      HTTPS-SSL/ (4)
      PHP/ (3)
      performance/ (2)
    Cherokee/ (1)
    LAN/ (4)
    LVM/ (6)
    Monitoring/ (2)
      munin/ (2)
    SSH/ (6)
    SSL/ (1)
    Samba/ (1)
    VPN-options/ (7)
      OpenVPN/ (1)
      SSH-Proxy/ (3)
      Tinc/ (1)
      sshuttle/ (1)
    backups/ (17)
      SpiderOak/ (1)
      backuppc/ (5)
      dirvish/ (1)
      misc/ (6)
      rdiff-backup/ (1)
      rsync/ (1)
      unison/ (2)
    commandLine/ (24)
      files/ (8)
      misc/ (10)
      network/ (6)
    crontab/ (1)
    databases/ (15)
      MSSQL/ (2)
      MySQL/ (8)
      Oracle/ (3)
      PostgreSQL/ (1)
    dynamicDNS/ (2)
    email/ (11)
      Dovecot/ (1)
      deliverability/ (1)
      misc/ (1)
      postfix/ (7)
      puppet/ (1)
    iptables/ (3)
    tripwire/ (1)
    virtualization/ (9)
      VMware/ (1)
      virtualBox/ (8)
  Coding/ (14)
    bash/ (1)
    gdb/ (1)
    git/ (3)
    php/ (5)
    python/ (4)
      Django/ (2)
  Education/ (1)
  Hosting/ (27)
    Amazon/ (18)
      EBS/ (3)
      EC2/ (10)
      S3/ (1)
      commandline/ (4)
    Godaddy/ (2)
    NearlyFreeSpeech/ (3)
    Rackspace/ (1)
    vpslink/ (3)
  Linux/ (31)
    Android/ (1)
    Awesome/ (3)
    CPUfreq/ (1)
    China/ (2)
    Debian/ (8)
      APT/ (3)
      WPA/ (1)
    audio/ (1)
    encryption/ (3)
    fonts/ (1)
    misc/ (6)
    remoteDesktop/ (1)
    router-bridge/ (3)
  SW/ (45)
    Micro$soft/ (1)
    browser/ (2)
      Chrome/ (1)
      Firefox/ (1)
    business/ (28)
      Drupal/ (9)
      KnowledgeTree/ (6)
      Redmine/ (2)
      SugarCRM/ (7)
      WebERP/ (2)
      WordPress/ (1)
      eGroupware/ (1)
    chat/ (1)
    email/ (1)
    fileSharing/ (2)
      btsync/ (1)
      mldonkey/ (1)
    graphics/ (2)
    research/ (2)
    website/ (6)
      blog/ (6)
        blosxom/ (3)
        rss2email/ (1)
        webgen/ (1)
  Security/ (15)
    IMchat/ (2)
    circumvention/ (2)
    cryptoCurrency/ (1)
    e-mail/ (4)
    greatFirewall/ (1)
    hacking/ (1)
    password/ (1)
    privacy/ (2)
    skype/ (1)
  Services/ (1)
    fileSharing/ (1)
  TechWriting/ (1)
  xHW/ (14)
    Lenovo/ (1)
    Motorola_A1200/ (2)
    Thinkpad_600e/ (1)
    Thinkpad_a21m/ (3)
    Thinkpad_i1300/ (1)
    Thinkpad_x24/ (1)
    USB_audio/ (1)
    scanner/ (1)
    wirelessCards/ (2)
  xLife/ (17)
    China/ (9)
      Beijing/ (5)
        OpenSource/ (3)
    Expatriation/ (1)
    Vietnam/ (7)


  • 2019/06
  • 2016/07
  • 2016/05
  • 2016/02
  • 2016/01
  • 2015/12
  • 2015/11
  • 2015/06
  • 2015/01
  • 2014/12
  • 2014/11
  • 2014/10
  • 2014/09
  • 2014/07
  • 2014/04
  • 2014/02
  • 2014/01
  • 2013/12
  • 2013/10
  • 2013/08
  • 2013/07
  • 2013/06
  • 2013/05
  • 2013/04
  • 2013/02
  • 2013/01
  • 2012/12
  • 2012/10
  • 2012/09
  • 2012/08
  • 2012/07
  • 2012/06
  • 2012/05
  • 2012/04
  • 2012/03
  • 2012/01
  • 2011/12
  • 2011/11
  • 2011/10
  • 2011/09
  • 2011/08
  • 2011/07
  • 2011/06
  • 2011/05
  • 2011/04
  • 2011/02
  • 2010/12
  • 2010/11
  • 2010/10
  • 2010/09
  • 2010/08
  • 2010/07
  • 2010/06
  • 2010/05
  • 2010/04
  • 2010/03
  • 2010/02
  • 2010/01
  • 2009/12
  • 2009/11
  • 2009/10
  • 2009/09
  • 2009/08
  • 2009/07
  • 2009/06
  • 2009/05
  • 2009/04
  • 2009/03
  • 2009/02
  • 2009/01
  • 2008/12
  • 2008/11
  • 2008/10
  • 2008/09
  • Subscribe XML RSS Feed

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

    This site has no ads. To help with hosting, crypto donations are accepted:
    Bitcoin: 1JErV8ga9UY7wE8Bbf1KYsA5bkdh8n1Bxc
    Zcash: zcLYqtXYFEWHFtEfM6wg5eCV8frxWtZYkT8WyxvevzNC6SBgmqPS3tkg6nBarmzRzWYAurgs4ThkpkD5QgiSwxqoB7xrCxs

    Fri, 28 Sep 2012

    /Linux/encryption: Whole Disk Encryption with Debian

    Being a standard option in the Debian installer, whole disk encryption is actually remarkably easy. If you understand LVM. Because the way the Debian installer does it is to configure LVM over the encrypted disk. So for me, a pre-requisite for going down this road was to first go through a couple of desktops with just LVM on them, to get solid with LVM.

    Now that that is done, this install is LVM over encrypted disk. So easy with the Debian installer. Just one thing so far has been a little non-obvious, and that is how to find the encrypted device and manage passwords.

    /etc/crypttab gives a great clue:

    sda5_crypt UUID=ea1b9a5a-88f3-42f8-861e-666c7dd37350 none luks
    cryptsetup isLuks -v /dev/sda5
    Command successful.
    confirms that I have the location correct.
    cryptsetup luksDump /dev/sda5
    shows which key slots are occupied.
    cryptsetup luksAddKey /dev/sda5
    adds a new key to the list. Done.

    posted at: 10:11 | path: /Linux/encryption | permanent link to this entry

    Mon, 13 Jun 2011

    /Linux/encryption: Transparently Encrypt Part of Your Home Directory

    Update: This all works really well. I now encrypt my entire home directory on all of my machines, plus usually add another encrypted partition for things I do not think need to be backed up. I will leave this howto in the form of encrypting a home subdirectory, as I think that is probably still a good place to start for someone just sticking a toe in these waters.

    Laptops are easily stolen. And these days, if you travel internationally, it is not uncommon for the thief to be Customs / Immigration agents who have the power to permanently seize your laptop on little or no grounds. All they need do is invoke the "National Security" bogey-man. Some thought should be given to protecting personal data, especially if setup seems easy.

    In the title, I say "transparently" in the sense that once this is setup, everything should work just like before. Under the hood, though, you will have an encrypted subdirectory in your home directory, which is automatically mounted when you login, and unmounted when you logout.

    I was lead to do this, finally, because this article[1] makes it sound very easy and convenient. Obviously, it would be more secure to encrypt my entire home directory (or even the entire hard drive) but to do this for an already installed system is a bit more trouble and risk. Plus I would like to build a little confidence in my ability to not lose data first, before I commit myself entirely. This way I will protect (and risk) only my most sensitive data (and keep good backups elsewhere should something go wrong with the encrypted partition). On the other side of the ledger, encryption does add a certain amount of overhead to everything you do with the encrypted files, especially on an older machine. There is a reasonable argument, I think, for only encrypting what is necessary.

    First step: Make a good backup. Messing with the partition table is risky business. Now use gparted to make space for an empty partition. Be warned that I shrank an 80G partition down to free up 1G, and this took a whole afternoon on a Pentium III, and making changes to your partitions is a process you *really* do not want to interrupt. So if you have a laptop, make sure your battery is charged to guard against power failures. Also note that changing the size of the encrypted partition later may not be easy, so be generous....

    In Debian, install packages cryptsetup and libpam-mount, and then next we will create an encrypted volume out of the just-created empty partition hda7. This section is a summary of the corresponding section from [1].

    Create the encrypted volume:

    cryptsetup luksFormat /dev/hda7

    LUKS[3] most noteworthy feature is that is supports unlocking the encrypted volume with any one of several passwords. Now name the encrypted volume "mysecrets", and format it:

    cryptsetup luksOpen /dev/hda7 mysecrets
    mkfs.ext3 /dev/mapper/mysecrets

    Mount the encrypted volume and write a test file, and then unmount:

    mount /dev/mapper/mysecrets /home/userid/protected/
    date > /home/userid/protected/date.txt
    cat /home/userid/protected/date.txt
    umount /home/userid/protected/
    cryptsetup luksClose mysecrets

    Now verify that mount.crypt from libpam-mount will open the encrypted volume:

    mount.crypt /dev/hda7 /home/userid/protected/
    cat /home/userid/protected/date.txt
    umount.crypt /home/userid/protected/

    Mount the Encryped Volume Automatically on Login:

    Unfortunately, at this point the advice from [1] stopped working for my circa November 2008 Debian installation. This was a bit disconcerting since [1] was only just published. However, a bit of poking around indicated that PAM is a bit of a complex beast, and that there was more then one way to get this to work. So next I tried the "Automagically mounting" section of [2].

    As [2] says, for this to work, the user's login password must be the same as one of the passwords assigned to the LUKS-formatted encrypted volume we created in the preceding section.

    Next we have to do something a little different then [2], since PAM has evolved a bit since [2] was written. Add the following block to /etc/security/pam_mount.conf.xml:

    <volume fstype="crypt" path="/dev/hda7" mountpoint="/home/userid/protected" options="cipher=aes" fskeycipher="" fskeypath="" user="username" />

    And that is it. user="username" means this block will only kick in when "username" logs in. The empty strings assigned to the last two parameters above apparently tell PAM to use the user's login password instead of a key file. Now log out, log back in, and you should find that /home/userid/protected has been automatically decrypted and mounted.

    (Note: I have since taken to doing this for my whole user directory, and there seem to be permission problems on the first login that kick up some errors and lead to a read-only home directory. So, after the first login, do an Alt-Ctrl-F1 and login as root.) Then fix the permissions:

    chown -R username:username /home/username
    chmod -R 755 /home/username

    Logout and login again, and everything should work.

    Future password changes must also be separately applied to the encrypted volume, ie.

    cryptsetup luksAddKey /dev/hda7

    to first add a new password to the volume (up to a maximum of eight). Note that this will add the new password to the first empty slot, and not overwrite your current password, as the dialog might imply. Then change your Linux user password. And finally

    cryptsetup luksDelKey /dev/hda7 0

    to delete the oldest password, in the first slot, when you are ready. No rush. That is one of the advantages of using LUKS.

    cryptsetup luksDump /dev/hda7

    will tell you which password slots are in use (among other things) but obviously will not tell you what the passwords are.


    I have been running with this setup now for well over a year, and am very satisfied as to usefulness and stability. The only irritation is that, since I am only encrypting a subdirectory of my user directory, after I login my encrypted directory will sometimes automatically unmount after a few seconds if nothing accesses any files in that directory. I just use a terminal to cd into the directory and lock it open the first thing I do after logging in. There is probably a more elegant way to resolve this issue....

    I also think this solution is more elegant then what I have read about the new standard Ubuntu encrypted home directory, which though simpler to turn on at install time still requires you to store / remember an encryption key. My setup still only requires you to remember your user password to login and decrypt the user directory.

    On a strategic note, if you are going to cross a border with your now-encrypted directory, I would suggest you create a dummy user account with a throw-away password. That way, if the immigration goons seize your laptop and insist that you give them "the password", you can give them one that does not matter, and in particular, does not unlock your encrypted directory. Likewise, make sure that the root password is not the same password as the user password that unlocks your encrypted partition, as they might be smart enough to demand the root password as well.

    [1] http://www.linux.com/feature/151989
    [2] http://pupeno.com/blog/encrypted-home-in-ubuntu
    [3] http://luks.endorphin.org/

    posted at: 23:03 | path: /Linux/encryption | permanent link to this entry

    Fri, 14 Nov 2008

    /Linux/encryption: Truecrypt For the Truly Paranoid

    Several days later I am still very pleased with the operation of my enrypted directory. So far zero inconvenience, and no noticable overhead / slowing of system response. I am sure there may be unintended consequences, like file availability for my external backuppc server or during SSH sessions, but I have not yet investigated.....

    I just bumped into another encryption solution called Truecrypt[1], where they provide the rather astonishing capability of having a hidden operating system whose existence cannot be proved. Apparently this works by installing a decoy operating system and an "outer" truecrypt-encrypted volume. Then within this outer volume, installing an "inner" truecrypt-encrypted volume, which because it is inside the outer one, will always appear as just random data (until decrypted). And they have set it up so there is no way for the existence of the inner volume and its operating system to be detected. Really, really clever.

    In other words, if someone is trying to extort your passwords, you need merely give them the passwords for your decoy OS and outer volume. The only headache / overhead I can really see (aside from needing to remember two passwords, for decoy and hidden OS) is that one actually needs to use the decoy OS a fair bit, in order to plausibly claim that it is your *only* OS and not lead a clever interrogator think that maybe there is more then meets the eye on your hard drive.

    Really, really clever. But I am not seeing any packages in the Debian archive, apparently there are licence issues....

    [1] http://www.truecrypt.org/docs/?s=hidden-operating-system

    posted at: 01:47 | path: /Linux/encryption | permanent link to this entry