LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
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


Reply
  Search this Thread
Old 04-04-2014, 02:02 AM   #1
Automatic
Member
 
Registered: Mar 2013
Posts: 42

Rep: Reputation: Disabled
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.
 
Old 04-04-2014, 01:47 PM   #2
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: Rocky Linux
Posts: 4,805

Rep: Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224
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.
 
Old 04-04-2014, 02:17 PM   #3
Automatic
Member
 
Registered: Mar 2013
Posts: 42

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
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.
 
Old 04-04-2014, 03:19 PM   #4
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: Rocky Linux
Posts: 4,805

Rep: Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224Reputation: 2224
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LUKS: xts-plain vs xts-essiv? phoenix_precedent Linux - Security 13 12-23-2014 03:31 AM
NS2: Need of plain plain aodv.cc and aodv.h files chenil Linux - Software 1 07-10-2013 07:17 AM
The performance of plain dm-crypt versus LUKS TwinReverb Linux - General 1 12-05-2011 04:38 AM
plain mozilla Smokey Slackware 7 08-24-2004 07:14 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 04:25 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration