Partition Encryption - Security

This is a discussion on Partition Encryption - Security ; Al Whitener wrote: > Dear Sirs: > > Is there an Linux application that encrypts and allows real-time use of a > partition? > LUKS with dm-crypt...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Partition Encryption

  1. Re: Partition Encryption

    Al Whitener wrote:

    > Dear Sirs:
    >
    > Is there an Linux application that encrypts and allows real-time use of a
    > partition?
    >


    LUKS with dm-crypt

  2. Re: Partition Encryption

    Al Whitener wrote:
    > Dear Sirs:
    >
    > Is there an Linux application that encrypts and allows real-time use of a
    > partition?
    >


    Several do. It requires kernel support, in particular, and there's a real
    performance hit on that partition, so it's best used for small, critical tools
    like USB fobs with SSH keys on them.

    It's also built right into the Fedora 9 installer.

  3. Re: Partition Encryption

    On Sun, 07 Sep 2008 19:06:21 -0400, Al Whitener wrote:

    > Is there an Linux application that encrypts and allows real-time use of a
    > partition?


    Several. Luks is the currently recommended one, if your distibution is new
    enough to include it. Check your package manager for a package called
    cryptsetup.

    I put together a howto, for Mandriva users last year at
    http://www.ody.ca/~dwhodgins/Luks-Howto.html

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  4. Partition Encryption

    Dear Sirs:

    Is there an Linux application that encrypts and allows real-time use of a
    partition?

    --
    BR
    Al Whitener



  5. Re: Partition Encryption

    Nico Kadel-Garcia writes:

    > Al Whitener wrote:
    >> Dear Sirs:
    >>
    >> Is there an Linux application that encrypts and allows real-time use
    >> of a partition?
    >>

    >
    > Several do. It requires kernel support, in particular, and there's a
    > real performance hit on that partition, so it's best used for small,
    > critical tools like USB fobs with SSH keys on them.


    That's overstated. I observe no more than a 20% reduction in throughput
    and that's with LVM on a 7200 rpm drive. That's very acceptable for a
    primary drive, where security is a concern.

    > It's also built right into the Fedora 9 installer.


    Right, which makes it very easy, as compared to the manual configuration
    on prior Fedora versions.

    HTH,

    Marc Schwartz

  6. Re: Partition Encryption

    Marc Schwartz wrote:
    > Nico Kadel-Garcia writes:
    >
    >> Al Whitener wrote:
    >>> Dear Sirs:
    >>>
    >>> Is there an Linux application that encrypts and allows real-time use
    >>> of a partition?
    >>>

    >> Several do. It requires kernel support, in particular, and there's a
    >> real performance hit on that partition, so it's best used for small,
    >> critical tools like USB fobs with SSH keys on them.

    >
    > That's overstated. I observe no more than a 20% reduction in throughput
    > and that's with LVM on a 7200 rpm drive. That's very acceptable for a
    > primary drive, where security is a concern.


    7200 RPM is, in my world of servers, pretty slow. Has anyone tried it on a
    contemporary 15K RPM SCSI drive, or a well-designed RAID set?

    >> It's also built right into the Fedora 9 installer.

    >
    > Right, which makes it very easy, as compared to the manual configuration
    > on prior Fedora versions.
    >
    > HTH,
    >
    > Marc Schwartz


  7. Re: Partition Encryption

    Nico Kadel-Garcia writes:

    > Marc Schwartz wrote:
    >> Nico Kadel-Garcia writes:
    >>
    >>> Al Whitener wrote:
    >>>> Dear Sirs:
    >>>>
    >>>> Is there an Linux application that encrypts and allows real-time use
    >>>> of a partition?
    >>>>
    >>> Several do. It requires kernel support, in particular, and there's a
    >>> real performance hit on that partition, so it's best used for small,
    >>> critical tools like USB fobs with SSH keys on them.

    >>
    >> That's overstated. I observe no more than a 20% reduction in throughput
    >> and that's with LVM on a 7200 rpm drive. That's very acceptable for a
    >> primary drive, where security is a concern.

    >
    > 7200 RPM is, in my world of servers, pretty slow. Has anyone tried it
    > on a contemporary 15K RPM SCSI drive, or a well-designed RAID set?


    I don't know that I have seen any benchmarks on servers. Given that such
    encryption is both disk I/O and CPU bound, the loss of throughput will
    be highly dependent upon how many CPU cores there are and overall server
    load. Faster HDs will of course help to an extent.

    I would be more inclined to look for hardware level encryption for a
    server than using a software based approach.

    Since dm-crypt/LUKS is not multi-threaded and thus limited to operating
    on a single CPU core (this was just discussed on the dm-crypt list), you
    can't split the encryption load over multiple cores. But multiple cores
    will help with general processing loads.

    As with any type of security, there is going to be a penalty of some
    form with respect to usability and/or performance. One needs to make
    a risk/benefit decision as to the value the security adds, versus
    meeting functional requirements. As they say in the
    military/intelligence community, "The mission shall not be compromised
    due to security."

    Partition encryption principally adds a level of protection in the
    scenario where the physical loss of the HD is a possibility. An
    unprotected desktop computer or more generally, laptops, are where
    partition encryption is more beneficial.

    If the servers are physically secured, then I would likely be less
    concerned about encrypting the drives and more focused on
    network/application level security. In the latter case, an example would
    be the use of database level encryption to protect confidential
    data. Individual files can be encrypted as needed by users, where
    required, using GnuPG or similar.

    If the servers are not physically secured or not sufficiently secured to
    prevent a reasonably determined attack, then you have to decide what
    the risk of loss is, the value of the data you are protecting and the
    level of performance/usability loss you are willing to accept to improve
    the protection of the data. Once you have at least some basic parameters
    in mind, then you can implement some scenarios to evaluate how they
    impact your specific environment.

    HTH,

    Marc Schwartz

  8. Re: Partition Encryption

    "David W. Hodgins" wrote:

    > On Sun, 07 Sep 2008 19:06:21 -0400, Al Whitener wrote:
    >
    > > Is there an Linux application that encrypts and allows real-time use
    > > of a partition?

    >
    > Several. Luks is the currently recommended one, if your distibution
    > is new enough to include it. Check your package manager for a package
    > called cryptsetup.


    Side note: Older cryptsetup versions need to be patched to include LUKS
    support. Some distributions (e.g. older Gentoo snapshots) even provided
    two separate packages.


    > I put together a howto, for Mandriva users last year at
    > http://www.ody.ca/~dwhodgins/Luks-Howto.html


    It's very irresponsible to call "not needing to reenter the passphrase
    after suspend to disk" a feature. I recommend removing the paragraph
    completely, because calling it a feature together with the red warning
    lets it appear like LUKS is a security hazard.

    Next, CBC and ESSIV have been deprecated in favour of XTS and
    plain/benbi IV generation, so currently the recommended options for 256
    bits strength are:

    -c aes-xts-benbi -s 512

    For mounting on user login, you can use a PAM module, which appears much
    more comfortable and safe to me.


    Greets,
    Ertugrul.


    --
    nightmare = unsafePerformIO (getWrongWife >>= sex)


  9. Re: Partition Encryption

    On Wed, 10 Sep 2008 09:48:20 -0400, Ertugrul Söylemez wrote:

    > "David W. Hodgins" wrote:
    >> I put together a howto, for Mandriva users last year at
    >> http://www.ody.ca/~dwhodgins/Luks-Howto.html

    >
    > It's very irresponsible to call "not needing to reenter the passphrase
    > after suspend to disk" a feature. I recommend removing the paragraph
    > completely, because calling it a feature together with the red warning
    > lets it appear like LUKS is a security hazard.


    I said it's a side affect, not a feature. I do consider it a security
    risk to use suspend to ram/disk, with luks.

    I beleive the suspend should unmount/close the luks volume, requiring
    the passphrase to be reentered at resume.

    I know others disagree with me on this. I will edit the page to make
    it clearer.

    > Next, CBC and ESSIV have been deprecated in favour of XTS and
    > plain/benbi IV generation, so currently the recommended options for 256
    > bits strength are:
    >
    > -c aes-xts-benbi -s 512


    This is not documented in http://luks.endorphin.org/spec. According to
    http://www.nationmaster.com/encyclop...ryption-theory, xts is
    currently only a draft. I've found very little information on using the
    benbi algoritym for iv generation.

    Do you have any references explaining the differences in terms of both
    security, and perforance between cbc-essiv and xts-benbi?

    > For mounting on user login, you can use a PAM module, which appears much
    > more comfortable and safe to me.


    Pam is not an area I've used enough, at this point. More to learn.

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  10. Re: Partition Encryption

    "David W. Hodgins" wrote:

    > On Wed, 10 Sep 2008 09:48:20 -0400, Ertugrul Söylemez wrote:
    >
    > > "David W. Hodgins" wrote:
    > >
    > >> I put together a howto, for Mandriva users last year at
    > >> http://www.ody.ca/~dwhodgins/Luks-Howto.html

    > >
    > > It's very irresponsible to call "not needing to reenter the
    > > passphrase after suspend to disk" a feature. I recommend removing
    > > the paragraph completely, because calling it a feature together with
    > > the red warning lets it appear like LUKS is a security hazard.

    >
    > I said it's a side affect, not a feature. I do consider it a security
    > risk to use suspend to ram/disk, with luks.
    >
    > I beleive the suspend should unmount/close the luks volume, requiring
    > the passphrase to be reentered at resume.
    >
    > I know others disagree with me on this. I will edit the page to make
    > it clearer.


    Okay then, it very much sounded like a feature rather than a side
    effect. Like calling it a feature at first, and then recommending
    against it below.


    > > Next, CBC and ESSIV have been deprecated in favour of XTS and
    > > plain/benbi IV generation, so currently the recommended options for
    > > 256 bits strength are:
    > >
    > > -c aes-xts-benbi -s 512

    >
    > This is not documented in http://luks.endorphin.org/spec. According
    > to http://www.nationmaster.com/encyclop...ryption-theory,
    > xts is currently only a draft. I've found very little information on
    > using the benbi algoritym for iv generation.


    It's not a standard yet AFAIK, but that doesn't mean its not mature.
    Benbi IV generation is very similar to plain, but performs better for
    some modes, at least LRW. But the difference should be neglible.
    Unfortunately there isn't more information on that, unless you read the
    source code.

    Securitywise benbi and plain are equivalent.


    > Do you have any references explaining the differences in terms of both
    > security, and perforance between cbc-essiv and xts-benbi?


    Clemens Fruhwirth's paper [1] explains very well why CBC should be
    avoided in dynamic encryption, that is where the plaintext should be
    modifyable. LRW and XEX/XTS have been designed specially for dynamic
    encryption.

    About the performance: XTS runs faster than CBC with ESSIV for me.
    Others may have different experiences.

    [1] http://clemens.endorphin.org/nmihde/nmihde-A4-os.pdf


    Greets,
    Ertugrul.


    --
    nightmare = unsafePerformIO (getWrongWife >>= sex)


+ Reply to Thread