Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

On 07/06/2020 09:08, Dale wrote:
> You can have a password, a key file, both or likely other options as
> well.  On one video, the guy generated a key file with urandom that was
> 1024 characters.  As he put it, try typing that in.

Indeed! All of these techniques have various pros/cons which is partly
why my last reply  / novel ended up being long yet still shallow.

A key file would, generally, be more secure provided you can keep the
medium on which it is stored secure as well. A long and strong password
doesn't have to be difficult to type though. A lot of 2FA dongles, such
as the YubiKey will allow for one (or more) of its key slots to be
programmed in plain text. If you have one, this would allow you to
effectively "paste" a very long password in less than a second. Then
again, you will have to keep your dongle secure as well, as plain text
means anyone can "paste" the password into a text file. Again, pros/cons
of the strategy.

On 07/06/2020 09:08, Dale wrote:
> Then I found out about crypttab.  I don't have that on my system, yet.

Crypttab is the standard on most distributions. Gentoo, however, uses
"/etc/conf.d/dmcrypt". Personally, I find its syntax less of an eyesore
and more favourable, but it does effectively the same thing. And the
comments inside it are even better than a man page haha

On 07/06/2020 09:08, Dale wrote:
> I still don't think I'm ready to try and do this on a hard drive.

Don't let any of that discourage you :) It's a lot simpler than it may
seem, and most desktop environments (I believe you we using KDE?) have
excellent support for mounting and unmounting/ejecting encrypted volumes
both internal, as well as removable, once the LUKS container has been
set up.

The guide [1] (also linked to earlier) is comprehensive, but
fundamentally the most relevant part for getting started are steps
2.3-2.5. If you use genkernel, with LUKS="yes" in the config it will
have taken care of the kernel for you and even created a initramfs
suitable for an encrypted root.

As Rich suggested try it out with a flash drive or a loopback file.

On a side note re drives, if using LUKS with an SSD you may or may not
wish to keep trimming disabled, as it may lead to leaked data regarding
the blocks being trimmed [2]. For this reason, trim pass-through is left
OFF by default. The leaked information, however, is minimal and I doubt
it poses any significant risk for the average use case.

On 07/06/2020 09:08, Dale wrote:
> I notice that one can use different encryption tools.  I have Blowfish,
> Twofish, AES and sha***

Bear in mind not all of the items listed are encryption algorithms per
se. The SHA and Argon families are hashing algorithms/functions used to
hash your password and store it an obfuscated form. They are also used
as HMAC functions in the context of encrypted data exchange. The key
thing is that hash functions are one-way. That is, it's computationally
straightforward to create the hash of a given input, but computationally
infeasible to reverse the process. They do not use a a separate
encryption key, and the result is always deterministic and reproducible.

I would stick with SHA as its widely supported. Except for sha1 which
was cracked a few years back. If you choose sha256 or better yet sha512
you can't go wrong.

Argon2 is a great choice, but if I'm not mistaken it's only supported by
LUKS2 which Gentoo only recently made the default. I believe most
current distros have LUKS2 by default, but older ones, including some
LTS versions and distros with release cycles of once per century or so
may not support that, so for removable drives I would stick to LUKS1.

On 07/06/2020 11:33, Rich Freeman wrote:
> AES is probably the most mainstream crypto system out there and is
> considered very secure.  It is also widely supported by hardware and
> all recent Intel/AMD CPUs.

Indeed. I second Rich and too would recommend sticking with AES for this
reason. LUKS will support an AES key of up to 512 bits. It's fast and
hardware acceleration is widely available.

For example, Intel's native AES  extensions work in 4x4 data blocks of
128 bits but will support variable key lengths. Their white paper [3]
suggests supported key lengths are 128, 192, and 256 bits but I've been
using a 512 bit key on my drives for years with negligible performance
impact (Skylake systems). But since data block size is fixed, this
hardly surprising. Acceleration of key length > 128b then only becomes
relevant at key generation time which is a one-time step, so the cost of
this step becomes largely irrelevant.

[1] https://wiki.gentoo.org/wiki/Dm-crypt
[2] http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
[3]
https://www.intel.com/content/dam/doc/white-paper/enterprise-security-aes-ni-white-paper.pdf