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
signature.asc
Description: OpenPGP digital signature
