Announcement

Collapse
No announcement yet.

The Cost Of Ubuntu Disk Encryption

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • The Cost Of Ubuntu Disk Encryption

    Phoronix: The Cost Of Ubuntu Disk Encryption

    It's been a while since last running any Ubuntu Linux disk encryption benchmarks, but thanks to recent encryption improvements within the upstream Linux ecosystem, it's time to deliver some new Linux disk encryption benchmarks. In this article are results comparing Ubuntu 13.04 without any form of disk encryption to using the home directory encryption feature (eCryptfs-based) and full-disk encryption (using LUKS with an encrypted LVM).

    http://www.phoronix.com/vr.php?view=18731

  • #2
    I wonder where the performance penalty comes from. Especially with full disk encryption. A modern processor with AES-NI can encrypt/decrypt several gigabytes per second! Way more than the 100-200MB/s seen in the tests. But even without AES-NI it should handle such throughput without a hitch. Can anyone enlighten us?

    Comment


    • #3
      @Michael

      You could also perform start-up measuers. Encryption should add some lag.

      Comment


      • #4
        and when using a solid-state drive, the cost of disk encryption for production systems (particularly mobile devices) tend to be worth the cost and overhead for the added security and peace of mind.
        What does this have to do with SSDs?
        The relative overhead added by encryption is a lot higher for SSDs compared to HDDs (as HDDs tend to be so slow that a few additional CPU cycles do not count anyway).

        Comment


        • #5
          The benchmarks in this article were done from an AMD FX-8350 "Vishera" (Bulldozer 2) CPU that does support AES-NI and the disk drive used was a 60GB OCZ Vertex 2 solid-state drive.
          Regardless of the performance impact, I continue to recommend (and personally use) full-disk encryption for all production mobile systems to mitigate security risk.
          I wouldn't say FX-8350 is exactly mobile, considering it is a power hungry beast with a TDP of 125W

          Comment


          • #6
            Originally posted by kobblestown View Post
            I wonder where the performance penalty comes from. Especially with full disk encryption. A modern processor with AES-NI can encrypt/decrypt several gigabytes per second! Way more than the 100-200MB/s seen in the tests. But even without AES-NI it should handle such throughput without a hitch. Can anyone enlighten us?
            OCZ Vertex 2 is a SandForce SSD, SandForce Chips are slower when data can't be compressed.

            So part of the performance hit is the SSD Controller, not the CPU
            Last edited by ObiWan; 05-20-2013, 06:33 AM.

            Comment


            • #7
              is the support for AES-NI hardware acceleration compiled into the kernel ?

              Comment


              • #8
                encrypting in the OS onto an SSD is bad practise. if you need disk encryption determine how to use the embedded crypto in an SSD - most have them, it's actually a useful feature so as to achieve the randomisation of data to avoid writing long contiguous 1's or 0's to flash.

                if your SSD doesn't allow you to easily control encryption, you bought the wrong one!

                Comment


                • #9
                  @speculatrix

                  Sure, this would kill the SSD faster, but at least you can trust it. How can you trust the chip inside does the right thing?

                  Comment


                  • #10
                    Originally posted by curaga View Post
                    @speculatrix

                    Sure, this would kill the SSD faster, but at least you can trust it. How can you trust the chip inside does the right thing?
                    Who cares?

                    Comment


                    • #11
                      If you need to ask that, then you're not the one encrypting your data in the first place.

                      Comment


                      • #12
                        How does /home encryption fare if you have it on a separate drive?

                        Comment


                        • #13
                          Originally posted by curaga View Post
                          @speculatrix

                          Sure, this would kill the SSD faster, but at least you can trust it. How can you trust the chip inside does the right thing?

                          in theory a suitable SSD would carry the OPAL TCG sticker, or one of the FIPS accreditations.

                          however, I seem to remember long ago that Intel had to offer to replace a particular model of SSD because they had bad firmware in it which didn't encrypt the data to the required standard, and due to the way the drive's microcontroller was programmed, it wasn't possible to reprogram it.

                          ahah, finally found it after much googling:
                          http://www.desktopreview.com/default...ecall+SSDs+LSI

                          Comment


                          • #14
                            Originally posted by speculatrix View Post
                            encrypting in the OS onto an SSD is bad practise. if you need disk encryption determine how to use the embedded crypto in an SSD - most have them, it's actually a useful feature so as to achieve the randomisation of data to avoid writing long contiguous 1's or 0's to flash.
                            what are you talking about? since when does it matter writing long continues 1s (or 0s)?

                            the only thing where external encryption can affect the liftetime of a ssd is on controlers that do compression. it hinders compression which means that you write more bytes than with compression. in such a case it would be better to first compress and then encrypt which means that the compression must also be dones externally (e.g. by software).

                            but this has nothing to do with long runs of 1s or 0s. such data is actually extremly good compressable.

                            maybe i understood you wrong.

                            Comment


                            • #15
                              For some work you MUST encrypt, no matter what the penalty

                              Originally posted by speculatrix View Post
                              encrypting in the OS onto an SSD is bad practise. if you need disk encryption determine how to use the embedded crypto in an SSD - most have them, it's actually a useful feature so as to achieve the randomisation of data to avoid writing long contiguous 1's or 0's to flash.

                              if your SSD doesn't allow you to easily control encryption, you bought the wrong one!
                              My experience is encrypting an SSD or a flash drive works fine and stays reasonablly fast as long as you set aside about a third of it as unallocated space. This makes sure that the controller can find unused blocks to erase. If you don't do this, all cheap flash drives can become very slow once the encrypted partitions have ever been filled. This problem doesn't seem to be as bad on SSDs but they still do slow down when filled in this way.

                              As for lifespan, for what I do an early wearout is far to be preferred to the consequences of not using encryption. I had a computer stolen by a police raid, I was damned glad that one was encrypted, so this is something I don't compromise on.

                              I would not trust encryption provided by the drive, since for my work the NSA is the presumed worst-case adversary and hardware back doors into that are likely, just as was the case for ATA security set passwords. There was even a criminal conviction in the US where someone thought their data was protected by setting an ATA disk access password which the FBI was able to quickly bypass with the help of some kind of master key the manufacturer provided.

                              If you don't encrypt the OS, there are just too many places an attacker with physical access while you are out could drop a keylogger or a replaced binary, as physicall access=root. Encryption is the only thing that can write protect a disk against an attacker booting from something else. When the OS is encrypted too, only the /boot partition can be usefully written to, in what is known as an "evil maid" attack. The /boot partition is a hell of a lot easier to hash check than a whole operating system, so long as you do not mount it after booting and before hash checking.
                              Last edited by Luke; 05-20-2013, 09:39 PM.

                              Comment

                              Working...
                              X