From: Chris Knadle <Chris.Knadle@coredump.us>
To: mlmmj@mlmmj.org
Subject: Re: [mlmmj] Encrypted list
Date: Mon, 24 Mar 2014 23:05:54 +0000 [thread overview]
Message-ID: <7598855.ViL4Wvj0I7@trelane> (raw)
In-Reply-To: <20140320184234.GG23804@szaflik.hasiok.net>
On Tuesday, March 25, 2014 07:32:32 Ben Schmidt wrote:
> On 25/03/14 6:19 AM, Chris Knadle wrote:
> > As such, putting some effort wards encrypting our own filesystems
> > seems like a worthwhile effort.
>
> This was the point I was just about to make.
>
> If someone *really* wanted your data, wouldn't they just seize your
> local machine and read the unencrypted stored copies?
If we're discussing law enforcement, that's exactly what's generally done,
usually confiscating every possible device all at the same time.
> Or even if it is
> encrypted, they have a nice limited-size dataset there to hurl resources
> at to crack the encryption--and it might not take many if you've chosen
> a dumb password. Or if you're like most people and use the same password
> for everything, it can probably be got from something else (e.g. any
> unencrypted login, or some other app on the same machine storing it in
> plaintext or with a weak hash). The whole operation probably either
> needs to be done illegally or require a warrant of some kind, but it's
> still got to be easier/cheaper than a lot of other options, if
> encryption is employed.
This sort of gets back to what Matti mentioned concerning "it depends on what
your threat model is" as to how far one needs to go with this.
There are a number of encryption algorithms to choose from, and you can create
long passwords fairly easily:
http://preshing.com/20110811/xkcd-password-generator/
but basically yes, the password needs to be nontrivial and not reused
elsewhere. Depending on the encryption methodology it's also possible to make
things more interesting by splitting the authentication into parts, such as a
file on a particular USB stick, biometric data, long password, etc.
But rather than "the gobiment", the more common reason I have for encrypting
data is in case of theft of the machine (especially items like laptops) to
insure that private data contained remains private.
> On 25/03/14 3:49 AM, Piotr Auksztulewicz wrote:
> > PPS. I like this list to go live - even if slighlty off-topic.
>
> Agree with that.
>
> There is also a relatively large amount of Mlmmj development going on at
> the moment, with most discussion happening on the bug tracker.
Which reminds me that I should probably subscribe to [mlmmj-commits].
> Hoping for a new release in a handful of weeks with some bug fixes and
> new features. Just waiting for the dust to settle on a few current
> issues.
Sweet. :-)
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
prev parent reply other threads:[~2014-03-24 23:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-20 18:42 [mlmmj] Encrypted list Piotr Auksztulewicz
2014-03-20 21:34 ` Matti Nykyri
2014-03-20 23:31 ` Chris Knadle
2014-03-21 15:48 ` Matti Nykyri
2014-03-21 20:09 ` Chris Knadle
2014-03-22 7:40 ` Matti Nykyri
2014-03-22 20:38 ` Chris Knadle
2014-03-24 16:49 ` Piotr Auksztulewicz
2014-03-24 17:25 ` Patrice Levesque
2014-03-24 19:19 ` Chris Knadle
2014-03-24 20:32 ` Ben Schmidt
2014-03-24 23:05 ` Chris Knadle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7598855.ViL4Wvj0I7@trelane \
--to=chris.knadle@coredump.us \
--cc=mlmmj@mlmmj.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox