public inbox for mlmmj@mlmmj.org
 help / color / mirror / Atom feed
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


      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