Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Locking Up Linux, Creating a Cryptobook 68

Tom's Hardware has a nice overview about some of the latest ways to secure your data looking specifically at open source solutions that wont lock down your credit card. Since many people presented performance issues for why they don't implement encryption there was also special attention given to how well your system will perform after implementation of encryption. From the article: "At least where LUKS is concerned, performance is hardly an issue - one must expect to pay some penalty for additional encryption facilities that handle unencrypted data transparently. All of these solutions are simple to set up and use on a daily basis, but LUKS is portable across Windows and Linux platforms."
This discussion has been archived. No new comments can be posted.

Locking Up Linux, Creating a Cryptobook

Comments Filter:
  • by virtuald ( 996377 ) on Saturday August 19, 2006 @03:33PM (#15941524) Homepage Journal
    Software encryption is fine, but there needs to be better and more widespread hardware encryption (NOT DRM) facilties that can be taken advantage of in a cross-platform manner..
    • No, software. (Score:5, Insightful)

      by Kadin2048 ( 468275 ) <slashdot,kadin&xoxy,net> on Saturday August 19, 2006 @03:53PM (#15941591) Homepage Journal
      I'm not sure I agree with this.

      Software encryption is really superior to hardware in many ways. Basically the only way it's usually not superior is in terms of speed, and this is why you see hardware encryption implemented.

      However, as general-purpose computers have gotten faster and faster, so that there's more surplus capacity for things like encryption and decryption on the fly, I see the need for hardware encryption becoming less and less.

      There's just no reason to restrict yourself to a hardware-based system that's hard to upgrade and fix, when you can use a software system that can be kept in tune with the state of the art and is a lot easier to trust. Even if I'm a relatively interested and intelligent person, there's no way I can 'open up' a hardware encryption module and see what's going on inside. With software encryption, I can look at the source code (and provided I'm using a trusted compiler and toolchain) know what it's doing.

      Furthermore, software encryption leads to more diversity in implementations. When you use hardware systems, the only way they're affordable is if there is an economy of scale. You don't make just a handful (or even a few thousand) hardware modules, you want to make tens or hundreds of thousands of them. That means it's automatically going to be a big target. With software, everyone can use something that fits their needs more completely, and the exposure of the system as a result of a single exploit is reduced.

      Hardware encryption was fine when computers were too slow to encrypt data that was being written to disk on-the-fly. But now they are, and this means that you can use regular equipment, and use whatever cryptographic implementation you want, and upgrade it as often as is required, with minimal additional expense. In fact, if I was going to build a "hardware" encryption device today, I'd probably just design it around a general-purpose system-on-a-chip so that it would be easily reprogrammable. I can't imagine that for anything but the most specialized, very speed-intensive tasks, that a custom-made hardware solution is really advantageous.

      Not that I'm saying that all cryptographic hardware is bad; there is definitely room for specialized components without making entire hardware encryptors: dedicated hardware random number generators, for instance, seem like they'll definitely have a place for the foreseeable future.
      • by pc486 ( 86611 )
        There are hardware encryption accelerators that are being common. For instance, newish VIA's C3 processors have hardware RNGs, MAC, and AES engines that speed up the hard work in encryption.

        Furthermore, THG's article claims to have tested large file sizes but their graphs dont show it. In order for a filesystem to be correctly benchmarked, the test file size must be at least twice the size of RAM. If it isn't then the test is only testing RAM speed, algorithm speed, and Linux's page cache system. According
        • Re: (Score:2, Informative)

          by portmapper ( 991533 )
          Furthermore, THG's article claims to have tested large file sizes but their graphs dont show it. In order for a filesystem to be correctly benchmarked, the test file size must be at least twice the size of RAM. If it isn't then the test is only testing RAM speed, algorithm speed, and Linux's page cache system. According to THG, LUKS can sustain > 100MB/sec on a 20GB laptop drive from 2002. Hmmm, I think not.

          The speeds reported are not believeable for a Pentium III M 1.2 GhZ even for just encryption.

      • by Isao ( 153092 )
        Consider FPGA - the best of both worlds.
        • I welcome the Virtex4 module for Opteron. Hope it's user-programmable. Such an FPGA can even contain seperately loadable modules. Perhaps someday Linux and Windows will be able to manage it automatically based on the applications that are currently running.
      • by Anonymous Coward
        As a desktop user, using hardware encryption will make no noticeable for anything. Even for servers, modern CPUs are so fast. A typical website spins its CPU on things like databases and bad PHP code. The SSL encryption hardly matters.

        This isn't the 90s anymore. 2ghz CPUs are standard now. Dual CPUs are standard. I would be surprised if hardware encryptors have any edge over general-purpose CPUs these days.
      • I'm not so sure I agree with this. First of all, software encryption/decryption is prone to side channel attacks that are hard to defy ("listening" to the CPU to retrieve an RSA key). Hardware may be able to avert such attacks. A hardware random generator is also very nice to have, since it provides a high entropy source which is not dependent on other factors (making it less difficult to change hardware, funny enough).

        Speed is also still an issue. I would like to see Tom's test repeated with a VIA C3 as we
      • Re: (Score:2, Informative)

        by mophab ( 137737 )
        In my experience, hardware encryption doesn't keep up with speed either. If you are using software encryption, it gets faster along with everything else as you upgrade to faster machines. Hardware encryption just does not keep pace with the increasing speed of general purpose processors.

        The only remaining reason to keep hardware encryption around is to protect your private keys. Even in this way hardware can be problematic. If you have important private keys locked away in hardware, you need to have som
      • I jthink what you mean by hardware encryption is either DRM (which you said you didn't want) or a dedicated encryption module (which for practicality's sake has to include software). If a PAL, GAL, PIC, cpu or else were used between the motherboard and the hard disk, you could have the speed of dedicated encryption with the versatility of reprogrammable encryption. Plus check if it was programmed to do what you expect it to...
    • by lky ( 246353 )
      I've been running linux from an encrypted USB stick for a while (as discussed on http://feraga.com/node/30 [feraga.com] ) and it works fast enough for everyday use. Just make sure you buy a real USB-2.0 Stick.
  • Apparantly, from the UK tomshardware.com redirects to tomshardware.co.uk which doesn't have the article.

    Thats just annoying as hell.
  • by Gopal.V ( 532678 ) on Saturday August 19, 2006 @03:36PM (#15941532) Homepage Journal

    Now, this might not be a common thing in the US. But here in India, a lot of companies have team laptops which we pass around (on-call duty for server pages, for instances).

    And somebody from Delhi, did something up which works for exactly that. qryptix [sourceforge.net] encrypts your home dir and mounts using your passphrase when you login, built as a pam.d module.

    Except for the fact that I wanted a truecrypt [truecrypt.org] built into it, so that I can have a hidden volume even after I pass-phrase in to the first volume, this works well enough for most purposes.

    • Re: (Score:1, Informative)

      by Anonymous Coward
      A similar project of note is pam-mount [sourceforge.net], a pam module to mount (usb|smbfs|losetup+crypt|LUKS|whatever) on login and umount upon logout. Too bad this is a performance-centric article, there are some very interesting things one can setup with (LUKS|device mapper|losetup). For instance encrypting your /tmp+swap with one-time keys from /dev/urandom.
  • by Keruo ( 771880 ) * on Saturday August 19, 2006 @03:39PM (#15941541)
    Encryption won't protect you from hackers if you have the drives mounted 24/7.
    It's only good for protection against stolen data, eg. usb drives or cds/dvds.
    Or, if you keep your entire computer at unsecre location, and are afraid that someone will steal the entire machine(root crypto).

    But remember, encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)
    Encryption won't give you perfect cover, but if you really have something valuable to protect, it's decent way to go.
    Performance WILL be an issue, don't be blinded with those luks graphs, real world performance will be much closer to the cryptfs/encfs performance numbers, but it's fast enough. Just encrypt what you have to. No need to encrypt entire system if you can get away just by encrypting home dir.
    • Re: (Score:3, Interesting)

      by CastrTroy ( 595695 )
      Well, I'm running an encrypted swap partition, and frankly, I haven't noticed any slow down. Granted, I have 1 gig of RAM, so I don't go into swap too often, but I find that it doesn't actually slow down your computer too much. You might notice if you don't have enough RAM, or if you encrypt your home partition, and then try to use if for video editing and other hard storage usage applications. However, if your using it on your laptop for business, you probably won't notice much of a difference.
      • by Keruo ( 771880 )
        I was talking about encrypted data partitions, not just swap,
        but encrypting swap is as(or even more) important than encrypting data.
        I agree with you fully with that point.
    • by Anonymous Coward on Saturday August 19, 2006 @04:52PM (#15941741)
      But remember, encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)
      That's bullshit. If your implementation is vulnerable to this, then it's flawed.
      • by owlstead ( 636356 ) on Saturday August 19, 2006 @09:36PM (#15942468)
        Mod parent up - if I do, I loose my own addition to the discussion. Most block ciphers are quite immune to known plain text attacks. This is at least true for DES and AES. And well implemented stream ciphers are as well (I specifically say "well implemented" because of the the flawed WEP implementation for WiFi).
    • Re: (Score:1, Interesting)

      by Anonymous Coward
      "But remember, encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)"

      If the encyrption is done properly, then naturally whole partition is encrypted (including ext3 header etc..).

      "Performance WILL be an issue, don't be blinded with those luks graphs"

      No it won't, unless you will run a file server or something similar. Do you think that in the average use it will matter wherever your HDD's read speed is 20MB/s inst
    • Re: (Score:1, Interesting)

      by Anonymous Coward
      Not only is the parent post not insightful, it's just plain wrong. A correctly implemented encrypted disk won't have "specific information at specific blocks", and unless you routinely run your computer at full-steam all the time, performance WON'T be an issue.
    • Re: (Score:3, Informative)

      >encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)

      Part of the minimum design criteria for a crypto algorithm is to resist "known plaintext" attacks, such as knowing the location of magic numbers, headers, and so on.
    • by msobkow ( 48369 )

      Encryption isn't supposed to protect you from crackers and script kiddies. It's supposed to protect you from media theft and traffic interception/interference. Why expect a tool to provide some miraculous protection it was never designed to?

      Crackers can't get to the machine unless it's connected. If your data is important enough to encrypt, WTF are you doing leaving the box exposed to the 'net? The only thing a secure box should expose is the services used to access the secured data.

      1. Create chroot t
  • Which Linux (not BSD) distro is the most locked down secure from initial install? Regardless of other ease of use, or performance. Debian origin (for apt-get) preferred.

    Since performance seems the biggest tradeoff, which "crypto coprocessors" (PCI DSP/FPGA/ASIC/etc) have Linux OSS drivers?
  • I found some interesting discussions [omgili.com] about linux data security. Good read!
  • TrueCrypt? (Score:5, Interesting)

    by SirClicksalot ( 962033 ) on Saturday August 19, 2006 @03:53PM (#15941590)
    A pity they don't mention TrueCrypt [truecrypt.org].

    Besides encrypting your data, TrueCrypt can also create hidden volumes:
    "The principle is that a TrueCrypt volume is created within another TrueCrypt volume (within the free space on the volume). Even when the outer volume is mounted, it is impossible to prove whether there is a hidden volume within it or not, because free space on any TrueCrypt volume is always filled with random data when the volume is created* and no part of the (dismounted) hidden volume can be distinguished from random data. Note that TrueCrypt does not modify the file system (information about free space, etc.) within the outer volume in any way."

    So even if you reveal your password, the hidden volume stays safe. Not a bad feature, considering it is a crime in many countries to refuse to give your encryption key to the authorities...
    • by treval ( 89829 )
      It seems like a neat idea until you consider that the 'authorities' will assume that there is a hidden volume (and encrypted data) simply by virtue of using TrueCrypt in the first place.

      Then you are faced with proving that there isn't any encrypted real data amongst the random free space...
      • by Grym ( 725290 )

        Then you are faced with proving that there isn't any encrypted real data amongst the random free space...

        Which is, for all intents and purposes, impossible--putting the burden of proof on your adversaries. In court the suspicion or possibility of there being something more is circumstancial evidence at best.


        • Yes, but that standard only exists in countries that don't compel you to give up your encryption key in the first place.

          You're talking US, UK, Canada. Parent is talking Syria, Lebanon, Iran.
          • Re: (Score:3, Informative)

            by rich_r ( 655226 )
            No, it's a crime to not give up your encryption key in the uk. Furthermore, it's the only crime for which the burden of proof is on the accused. Don't have a link to hand, but I believe it's the RIP act of '99. (commentary here [reading.ac.uk])
          • It is a crime in the UK to refuse to give up encryption keys. The original maximum sentence I believe was 2 years, but now, with the "new" threat of terrorism (No-one else remember manchester & brighton? Anyone?) they want to increase that. So this guy [slashdot.org] can be locked away for even longer, because he's obviously got encrypted plans for a dirty bomb on his hard drive.

            I'll leave the US as an exercise for another.
      • Re: (Score:3, Insightful)

        by Rich0 ( 548339 )
        So, then you put a hidden share in, and then put another hidden share inside that hidden share. Truecrypt hidden shares can be an arbitrary number of levels deep, and unless the authorities intend to just beat you until you die they're going to have to figure at some point that you might just be telling them the truth when you say there isn't another level...

        The design of truecrypt is that it isn't possible to tell whether there is a hidden volume or not - it just looks like unused space.
        • Wouldn't it all look like "used" space, though, if it's filled with random characters?
          • Re: (Score:3, Informative)

            by Rich0 ( 548339 )
            Truecrypt volumes are filled with random data when they are initialized, and appear random when files are created/deleted. There is nothing you can do to tell whether a volume was ever written to without knowing the key.

            So, yes it does look like "used" space. But it also looks like "empty" space by the same virtue. If you just put your regular checkbook in a truecrypt volume and put something else in a hidden volume it would be plausible to say that the checkbook is the only thing in there.
  • by pair-a-noyd ( 594371 ) on Saturday August 19, 2006 @04:21PM (#15941664)
    If you have the 400 page ad loaded version as much as I do.

    http://www.tomshardware.com/2006/08/18/locking_up_ linux-creating_a_cryptobook/print.html [tomshardware.com]
  • I was reading that Tom's article this morning around 8am EST. Oh well!
  • by Anonymous Coward
    Every time you write a block to disk, it goes through a cryptographic checksum. Every time you send a TCP packet it goes through a checksum. The amount of CPU needed to do these checksums is not much different from the amount of CPU needed to do full encryption. We routinely use compression, which takes more CPU. If someone out there is thinking, "I would love to encrypt but I'm worried about performance", he's probably using a Mac Plus or a PC Jr or something. That isn't reality. Modern CPUs pipeline
  • My experience (Score:5, Informative)

    by cvalente ( 955264 ) on Saturday August 19, 2006 @07:51PM (#15942229) Homepage
    I've been running my desktop on an encrypted root partition using LUKS (on Gentoo via dm-crypt) for over 6 months now.

    I was afraid that heavy IO access might cause high CPU usage or that some FS might not play all that well with the encryption.

    So far, I've had no problems. Even copying from one encrypted partition to another encrypted partition causes no noticeable lag due to encryption and normal usage of my disk, even with heavy uses such as DBs or backups seems to take place just like before.
    I've been using LUKS with xfs (and reiserfs to a lesser extent). I have a P4 3.2Ghz, don't remember the disk specs.

    Being able to have several passphrases is a good thing (you can even change them later on) and the assurance that a weak passphrase will not cause the key being easily guessed via crypto-analysis is another plus.

    The downside is that booting from an encrypted partition can be a little difficult to setup for a novice, but that has been improving and at least Gentoo now offers this on the current genkernel with little extra hassle.

    If you want the whole package, you can even encrypt the swap partition with a randomly generated key at boot time.

    What do you get from all this?

    Suppose your computer has an hardware malfunction and you have to send to be repaired (warranty for instance). You can be sure no one will find the financial data you saved there, or some less flaterring photo (or something more embarrassing you didn't even remember). Using an encrypted partition to save sensitive data might be enough, but many programs end up saving temporary data in unexpected places so all that care might be useless in the end. If everything is encrypted that risk is gone with just a little bit of extra work (once).

    Like someone wrote, this won't protect you from having you computer hacked while the partition is mounted and stealing data.
  • eCryptfs (Score:4, Informative)

    by omnirealm ( 244599 ) on Saturday August 19, 2006 @09:53PM (#15942525) Homepage
    I am disappointed to see that Justin Korelc and Ed Tittel entirely missed eCryptfs [sourceforge.net], which is already in the -mm tree of the Linux kernel.
  • For a minute there I thought that someone had "locked up" the linux kernel in the "Windows lock up" style. Whew...

  • Formats and upgrades (Score:3, Interesting)

    by pe1chl ( 90186 ) on Sunday August 20, 2006 @08:09AM (#15943698)
    A problem with Linux encrypted partitions is that there are several formats, and no migration path.
    As usual, when new and better solutions are developed, the Linux developer scene does not really care about backward compatability. The new method is sooo good that the old one should be left in the dust and its adopters must backup and restore.
    Developers who suggest backup and restore must be unaware of the current market situation w.r.t. backup solutions and their capacity vs that of IDE disks...

    Recently I decided to move two disks from my main system, encrypted under SuSE 9.2, to another box that I want to dedicate to background storage.
    I remembered that I had read about some issue in 9.3, but I believed that it had been long solved so I installed SUSE 10.0 on this new box.

    There was NO WAY I could get the disks mounted. I tried all the tricks found in several articles on Internet, but I kept getting errors.
    The SuSE knowledge base stated that everything would be fine when I just upgraded the OS, but I don't believe that because I tried the solutions equivalent to what would happen when upgrading. I don't want to risk it.

    Finally, the only solution was to install 9.2 on the new box, and the disks worked OK. Then, I have bought more disks (as was the plan) and copied the data from encrypted to unencrypted disks. Next step will be to install 10.0 again, but I am not so sure if I will encrypt the disks again as the 10.0 system is (I believe) not LUKS so probably at 11.0 I will again face the same problem because the "all new and better LUKS" is now the supported system.

    I will not even think about what would happen when I would want to change the distribution from SuSE to RedHat or Ubuntu or whatever.
    Chances must be about zero that I can still access the data.

    There is not even a tool that would in-place decrypt (or encrypt, for that matter) the data on a partition. Even when one wants to take the risk that it interrupts halfway and destroys everything. So you always need a source and destination device with enough space.

    Please keep this in mind before you encrypt your terabyte volumes...

%DCL-MEM-BAD, bad memory VMS-F-PDGERS, pudding between the ears