Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
04-04-2014, 02:02 AM
|
#1
|
Member
Registered: Mar 2013
Posts: 42
Rep: 
|
LUKS vs plain
Now, before I start, I'd like to state if I were reading this thread from the outside, I'd say "Go with plain", and, that's what I feel like I should do, the reason why I'm asking first is due to the fact that literally every guide, wiki, tutorial, and, blog post I can find on the internet seems to unconditionally recommend LUKS over plain, which, is what's causing my fear of using plain.
Basically, my setup is relatively straight-forward, HDD #1 boots (Unencrypted), and, loads all the other HDDs #2-8 and decrypts them using a key stored in plain text on HDD #1. My goal is not to prevent an attacker decrypting them if (s)he steals the actual computer, the goal is to prevent the drives at end-of-life from becoming useless to me, the drives may still work, but, I'll be in fear of selling them due to the fact they contain personal information, having them encrypted for their whole lifespan stops this fear, all I need to do is not provide the decryption key when I sell said drives (Or donate them away, whatever), and, the data on them is basically invalidated, this also includes if the HDDs fail (And I can't wipe the drive) within their warranty, as, I can ship them back without fear of them being resold as refurbished/etc...
As per this, I feel the plain encryption method of dm-crypt fits my needs very well, I don't need multiple key phrases (I'll just have the one, randomly generated, binary on my main HDD, with backups, of course), I don't need my passphrases run through a huge recurring hash function to slow down attackers (As the key itself will be a couple KB large from /dev/(u)random), while, on the same hand, LUKS means if a certain sector gets corrupted (I.E. the header), the whole drive fails (Unless you have a backup of the header), relative to plain where just that 1:1 sector on the encrypted mount fails.
So, simply put, is there any advantage to using LUKS over plain? Is there any advantage of using plain over LUKS? In my situation, obviously, I completely understand using LUKS when you require it's features (I.E. anti-brute force, multiple users/keys, etc...)
Thanks.
Last edited by Automatic; 04-04-2014 at 02:04 AM.
|
|
|
04-04-2014, 01:47 PM
|
#2
|
Senior Member
Registered: Aug 2009
Distribution: Rocky Linux
Posts: 4,805
|
About the only other LUKS advantage that comes to mind is that it avoids a problem that can occur when a system upgrade changes some of the encryption defaults. If you've been using the default cypher/hash/keysize and any of those changes, then your decryption will fail silently (no error message from cryptsetup -- you will just see garbage where your filesystem used to be) until you specify parameters that match the old defaults. LUKS stores all the parameters in the LUKS header, and so does not have that problem.**
** The problem with the fix to the old, broken whirlpool hash is an exception here.
|
|
|
04-04-2014, 02:17 PM
|
#3
|
Member
Registered: Mar 2013
Posts: 42
Original Poster
Rep: 
|
Quote:
Originally Posted by rknichols
About the only other LUKS advantage that comes to mind is that it avoids a problem that can occur when a system upgrade changes some of the encryption defaults. If you've been using the default cypher/hash/keysize and any of those changes, then your decryption will fail silently (no error message from cryptsetup -- you will just see garbage where your filesystem used to be) until you specify parameters that match the old defaults. LUKS stores all the parameters in the LUKS header, and so does not have that problem.**
** The problem with the fix to the old, broken whirlpool hash is an exception here.
|
So, then, if I do have something like this in my crypttab, I'm good to go with plain?
Code:
HDD1 /dev/disk/by-uuid/1234-5678-90ab-cdef /root/crypt/HDD1.key -c aes-xts-plain64 --offset 0 --skip 0 --tries 1 --noearly --loud /*I assume to syslog?*/
It should work fine throughout upgrades, correct (Assuming they don't completely overhaul everything, as, the program is no longer assuming I want the defaults, but, rather being told everything)?
And, even if it doesn't (And they feel like being mean, and, change aes-xts-plain64 with twofish-xts mapping in the program), then, the mount command should just throw back "I literally have no idea what you want me to do this with", and, then I can manually update the fstab/crypttab, correct? It's not going to go ape **** and destroy my entire drive in a fit of rage that I dared to not tell it exactly what was going down.
Last edited by Automatic; 04-04-2014 at 02:25 PM.
|
|
|
04-04-2014, 03:19 PM
|
#4
|
Senior Member
Registered: Aug 2009
Distribution: Rocky Linux
Posts: 4,805
|
You still haven't specified the key size. Run "crypsetup --help" to see all of the compiled-in defaults (at the end of the output), and set values for all of them in /etc/crypttab, though AFAIK no hash is used when the key comes from a key file.
Nothing would be destroyed. The mount command would just fail.
Last edited by rknichols; 04-04-2014 at 03:30 PM.
|
|
|
All times are GMT -5. The time now is 04:25 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|