Gentoo Archives: gentoo-user

From: Dale <rdalek1967@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Encryption questions
Date: Mon, 10 Dec 2018 05:15:35
Message-Id: b7c8960d-b04d-c728-5cc8-e1eb5afde94f@gmail.com
In Reply to: Re: [gentoo-user] Encryption questions by Grant Taylor
1 Grant Taylor wrote:
2 > On 12/9/18 4:46 PM, Dale wrote:
3 >> Howdy,
4 >
5 > Hi,
6 >
7 >> As some may know, I'm making some changes and upgrades to my puter.
8 >> One thing I'm considering, encryption of a select directory/mount
9 >> point/file system.
10 >
11 > Please elaborate on a hypothetical setup that you would like.
12 >
13 > It might be worth starting with your current directory tree and
14 > calling out things you would like to see encrypted.
15
16 Well, I don't really think I need to encrypt the entire /home mount
17 point.  To me, that would be overkill.  Of course, that may be easier. 
18 I would like to have certain directories that I can store things in that
19 is encrypted.  For example, I have some financial and medical stuff that
20 I wouldn't want just anyone to get a hold of if for example my puter was
21 stolen or hacked. 
22
23
24 >
25 >> One thought I have, create a mount point named say "Encrypted" and
26 >> put anything I don't want widely seen or hacked in that directory.
27 >
28 > I understand why you are doing it.  But I feel like having "Encrypted"
29 > in the name is like painting a target on it.
30
31 True.  I used that as a example mostly. 
32
33 >
34 >> That would likely be on it's own partition or LVM setup.
35 >
36 > Depending on how you do things, it might be possible to have your
37 > encryption in the same LVM configuration.  Or possibly a separate LVM
38 > configuration that has multiple logical volumes in it used by
39 > different mount points.
40 >
41 >> I would likely keep other things open.
42 >
43 > What is your reason for keeping other things open?
44 >
45 > Or, asked another way, why not use full disk encryption? Or at least
46 > encrypt the entire volume group?  That way you don't need to worry
47 > about what is and is not encrypted.
48
49
50 Well, I thought it may be simpler.  Since I've never tried encryption
51 before, I don't know first hand how it works or what it takes to use the
52 files.  I've read where people password protect their mobo, bootloader
53 and their entire storage system.  Basically, without the proper
54 passwords, you can't boot the system or access it from another system
55 either.  That is overkill for me for sure.  If anything, I'm on the
56 other end of the scale.  I just want a directory, which could be a mount
57 point, that is encrypted.  Knowing what tool is best may help be figure
58 out whether it is a mount point, a regular directory or what.  I've read
59 where some whole file systems can be encrypted or it can be done on a
60 directory level.  I'm not sure what works the best tho. 
61
62
63 >
64 >> Example, I may have /home on a partition of it's own but then have
65 >> the encrypted directory mounted on /home/dale/Desktop/Encrypted.  I
66 >> could even let that be my Documents directory as well.  I'm not to
67 >> worried about browser history etc.  Plus, I could log into KDE and
68 >> not have to access the encrypted stuff if it is not needed.  I don't
69 >> need encryption to check the weather.  lol
70 >
71 > Since we're talking about LVM, please clarify if /home is it's own
72 > partition outside of LVM or if /home is it's own Logical Volume inside
73 > of LVM.  It makes a difference.
74
75
76 I have /boot and / on their own partition.  Everything else is on LVM. 
77 I did that because it is easier to boot.  While I have a init thingy,
78 it's just enough to mount /usr.  That's it.  I don't like having a init
79 thingy at all tho.  I've had trouble with them in the past that left me
80 with a unbootable system and no way to fix it since I don't really get
81 them.  It's one of those things that hasn't hit me yet, even after years
82 of it.
83
84 >
85 > I strongly believe that you should not feel like you have to change
86 > your use case to use technology, encryption in this case.  Rather the
87 > computer should change what it does so that what you have been doing
88 > and will continue to do is now encrypted.
89
90 True but I don't want it to get in my way to much.  I'd like to be able
91 to login into KDE without worrying if the password works or not.  Once
92 inside KDE and I need to access something encrypted, then I can deal
93 with the password. 
94
95
96 >
97 >> How I do that isn't a big deal really.  My main question is this.  If
98 >> I go to the trouble of doing this, would I be *really* protected?
99 >
100 > It depends.
101 >
102 >> Is there a easily used encryption tool that isn't easily hacked?
103 >
104 > I believe so.
105 >
106 >> Also, when I login, I'd like to be able to type in password etc and
107 >> it be available from that point on, unless I do something to lock it
108 >> up again.
109 >
110 > Are you implying that you want the encryption system to remember the
111 > password and unlock files as necessary?  Or are you wanting to enter
112 > the password into something that uses it then and there to unlock
113 > things until you lock them back up?
114 >
115 > That's an important distinction.
116
117 Let's say I encrypt the directory or mount point that contains both
118 video and some financial/medical info in it.  When I click to access it,
119 it asks for a password.  Once it does that, I'd like to be able to use
120 that until I either logout of KDE or I tell it to lock it back up.  That
121 way I can watch TV for hours without interruption to type in a
122 password.  However, if I need to run to town, I can logout of the
123 encrypted part and leave knowing it's secure.  Make sense??
124
125
126 >
127 > I have done a fair bit with LUKS, also LUKS and LVM.
128 >
129 > LUKS works by unlocking the encrypted block device and creating
130 > another virtual block device that is the unencrypted interface.  It's
131 > trivial to put a file system on top of a LUKS device.
132 >
133 > So, my use case was to unlock a LUKS device and mount the file system
134 > that sits on top of it.  Then anything on the system (with proper file
135 > system permissions) could access the files therein.  Then when I was
136 > done, I would unmount the file system and lock (close) the encrypted
137 > device.
138 >
139 > I have also dabbled with eCryptFS, which applies encryption as an
140 > overlay.  So when you access encrypted files through the overlay, they
141 > would be read from the unencrypted on the fly.  Writing to the files
142 > to the unencrypted overlay would encrypt the files and write them to
143 > the underlay.
144 >
145 > Depending on the configuration, it's not possible to see the names of
146 > the files (or directories), much less actually read them from the
147 > encrypted underlay.
148
149
150 Interesting.  I've read that twice.  May read that a couple more times. 
151 Letting that soak in a bit.  That sounds like something I could use
152 tho.  It seems it would do just what I want.  Question.  Let's say I
153 encrypt /home entirely as a partition of LVM group.  When I login to KDE
154 for example, how does that work?  I already have to type in a password
155 to login into KDE.  Would that work for both or would it ask for a
156 second password?  Or would it ask even earlier than that? 
157
158 I may get on youtube and see if I can find some videos on this so I can
159 see it actually working.  Maybe find a couple different setups.  I'm
160 sure someone has done at least one.  lol 
161
162
163 >
164 >> Reason, I may even put some of my videos on that.  I watch TV from
165 >> that a lot.
166 >
167 > Okay.
168 >
169 >> Also, how hard would it be to do the same to my backups, since having
170 >> a open set of backups would render the encrypted part just available
171 >> elsewhere?
172 >
173 > Backups are another thing entirely.  Things like LUKS will usually not
174 > translate to encryption with backups, because the backups see the
175 > mounted file system.  Things like eCryptFS can work with encrypted
176 > backups, because they can work with the underlay file system that
177 > holds the encrypted files while ignoring the unencrypted overlay.
178 >
179 > There are also other possibilities of encrypting backups that are
180 > completely independent of the files that are being backed up.  Sort of
181 > like a big encrypted tape drive or backing up files to a LUKS file
182 > system that is subsequently unmounted & locked.
183 >
184
185 Keep in mind, my backups are a simple rsync to a external USB drive.  I
186 don't use fancy software.  Usually I backup my videos and such once a
187 day depending on what I've done that day.  I may switch to a external
188 SATA drive at some point which may make it even easier.  Right now I use
189 a script, if it even deserves to be called that, to do the backups. 
190
191
192 >> While I get some of how encryption works, I don't keep up with it on
193 >> a weekly or even monthly basis.  I just see the occasional articles
194 >> on it. I'd rather ask and get input from someone who uses and/or is
195 >> more familiar with this.  In other words, if it is worthless and
196 >> someone knows it is, then let me know.  If one tool is
197 >> better/easier/etc than another, I'd like to know that as well.
198 >
199 > I don't think encryption is worthless.  I encrypt many of my emails
200 > and sign most others.  I also have a LUKS encrypted file system on my
201 > VPS.
202 >
203 > It really depends on what your goal is and what you're trying to
204 > protect from / against
205
206 Mostly a common crook who just may have some puter skills.  Wouldn't
207 mind grinning at the likes of a NSA twerp with far to much nose.  :-D 
208
209 Dale
210
211 :-)  :-)

Replies

Subject Author
Re: [gentoo-user] Encryption questions Grant Taylor <gtaylor@×××××××××××××××××××××.net>
Re: [gentoo-user] Encryption questions Neil Bothwick <neil@××××××××××.uk>
Re: [gentoo-user] Encryption questions Dale <rdalek1967@×××××.com>