Re: [mlmmj] Encrypted list

Re: [mlmmj] Encrypted list

[Piotr Auksztulewicz]

On Wed, Mar 19, 2014 at 11:42:30PM +0200, Matti Nykyri wrote:
> Actually implementing an encrypting mailing list would be quite
> an interesting challenge. The list would store public keys of
> the subscribers and post to the list would be encrypted with the
> list's key. The mails to the subscribers would be each encrypted
> with their own public keys. Security should never be underestimated.

That's an interesting idea, but I have several points why it is
not particularly useful - and it may be the reason it haven't got
implemented in any list server software I know.

First of all, using cryptography properly is hard. Very few poeple
know how to do it securely and many would not be convinced to learn
it or willing to jump the hoops. So the feature would be not for
the run-of-the-mill lists but rather for the rare case of a list for
really tech-savvy people that are crypto geeks.

However, crypto geeks will recognise weaknesses of such a setup.

What features can cryptography give you? Confidentiality, authenticity,
integrity, privacy (if applied properly of course).

Let's talk about confidentiality first.

One problem is such a setup has a single point of failure. While
the messages' contents will be protected in transit, they have to be
decrypted on the server and encrypted again. Compromising the server
breaks the confidentiality completely. Subscribers would have to
trust the server's owner integrity and competence.

Using complex cryptoghraphy like multiple-key encryption is
still harder and every subscriber would have to update the list of
recipients' keys to be able to encrypt the message for all of them to
be able to decrypt. In such case there's little advatange of having
a server, one may just put all of the addresses in the To: field.

Confidentiality depends on all subscribers being able to keep the
secret. One incompenent subscriber breaks it. The list would have
to be closed of course - but there would also be a need to vet all
new subscribers somehow. Subscription moderation may help only a
little and everybody needs to trust the moderators' decisions.

Finally, the confidentiality will apply to messages' contents only -
metadata is sent in the clear. You can infer a lot from metadata.
If the subject of communication is sensitive enough, regular email
is of no use, encrypted or not.

Therefore, semi-confidentiality of a regular closed list is not much
worse than re-encrypting list. To get in-transit confidentiality
it will be much simpler just to configure the server to use and
accept only STARTTLS SMTP sessions. Very few servers don't offer the
functionality today - and most will use it when available. From my
experience, non-TLS session on a TLS-advertising server is an almost
sure indication of spam.

Authenticity & integrity (that the message comes from the person
claiming to be its author and has not been modified in transit) can
be easy obtained by cryptographically signing a cleartext message.
This is fully optional and compatible with existing mailing lists.

Next, privacy. I define privacy in the communication context as
confidentiality of the fact of communication. That is, everybody may
know that for example the address joe@example.com belongs to Mr. Joe
Clever, and Mr. Clever sometimes sends greetings to friends or open
letters to the public, but when he wants to communicate privately
with someone, there's no way to tell from data transmission contents
and patterns that he has done so and when - but the recipient will
know that he got a message from Mr. Clever and not a random person.

Email gives next to no privacy, addresses are sent in the
clear. STARTTLS sessions mask the fact of communication somewhat,
specifically if both parties have large user bases, but again, such
parties have to be trusted not to leak the logs etc. Even then,
traffic analysis can reveal communication patterns.


All in all, there's too little assurance of confidentiality in
"encrypting list server" setup to be of serious use.

-- 
Piotr "Malgond" Auksztulewicz           firstname@lastname.net

Re: [mlmmj] Encrypted list

[Matti Nykyri]

On Thu, Mar 20, 2014 at 07:42:35PM +0100, Piotr Auksztulewicz wrote:
> On Wed, Mar 19, 2014 at 11:42:30PM +0200, Matti Nykyri wrote:
> > Actually implementing an encrypting mailing list would be quite
> > an interesting challenge. The list would store public keys of
> > the subscribers and post to the list would be encrypted with the
> > list's key. The mails to the subscribers would be each encrypted
> > with their own public keys. Security should never be underestimated.
> 
> That's an interesting idea, but I have several points why it is
> not particularly useful - and it may be the reason it haven't got
> implemented in any list server software I know.

That is true. The only ones that I can think of being keen on security
and sending mails in the free internet are security administrators 
for example with gentoo and the Linux kernel. Security administrators 
send sensitive and time critical information about the found security
security holes of the system and they use encryption.

> First of all, using cryptography properly is hard. Very few poeple
> know how to do it securely and many would not be convinced to learn
> it or willing to jump the hoops. So the feature would be not for
> the run-of-the-mill lists but rather for the rare case of a list for
> really tech-savvy people that are crypto geeks.

I agree. Even professionals fail to use it the correct way at times.
Cryptography is not my home time but I've been visiting there for few
years now. It is a very interesting field of study. It is sad to see
how little people demand security and privacy todays. When people don't 
demand it corporations don't implement it... on the contrary they 
lessen your privacy by scanning your messages. Targeted advertising
and selling information. Not to mention the interests of intelligence
agencies.

> However, crypto geeks will recognise weaknesses of such a setup.
> 
> What features can cryptography give you? Confidentiality, authenticity,
> integrity, privacy (if applied properly of course).
> 
> Let's talk about confidentiality first.
> 
> One problem is such a setup has a single point of failure. While
> the messages' contents will be protected in transit, they have to be
> decrypted on the server and encrypted again. Compromising the server
> breaks the confidentiality completely. Subscribers would have to
> trust the server's owner integrity and competence.

By definition every message can be opened no matter how it is encrypted.
It is just a question of money and time. Is it easier to crack the 
server or open the message? In most cases I think it will be the server.
But the server can protected and controlled and a breach spotted. If a 
message that has been poorly encrypted it will be sneakyly read without
anyone knowing. 

> Using complex cryptoghraphy like multiple-key encryption is
> still harder and every subscriber would have to update the list of
> recipients' keys to be able to encrypt the message for all of them to
> be able to decrypt. In such case there's little advatange of having
> a server, one may just put all of the addresses in the To: field.

Only way to implement encrypted list is to let the list decrypt and then
reencrypt the messages. Otherwise the list needs to be implemented inside
the MUA. Still this makes things simpler because it is then only needed
for the list to have upto date keys of all the members. If MUA is doing
the work then every subscriber has to have all the correct keys of all
the subscribers!

> Confidentiality depends on all subscribers being able to keep the
> secret. One incompenent subscriber breaks it. The list would have
> to be closed of course - but there would also be a need to vet all
> new subscribers somehow. Subscription moderation may help only a
> little and everybody needs to trust the moderators' decisions.

If you think of security administrators jobs that is the way it goes:
The server is and needs to be secure, administrators are screened,
and then accepted to the group.

> Finally, the confidentiality will apply to messages' contents only -
> metadata is sent in the clear. You can infer a lot from metadata.
> If the subject of communication is sensitive enough, regular email
> is of no use, encrypted or not.

The only metadata available to Eve the Evesdropper is the sender and
the list name and the route between them. But Eve will not be aware of
the lists subscribers because when the list sends out the message each
is encrypted differently and the return path can be set to anything
(there is no way to decrypt the returned message anyways). The little
things that will be leaked are sending times, message sizes and 
recipients of the servers entire mail flow.

> Therefore, semi-confidentiality of a regular closed list is not much
> worse than re-encrypting list. To get in-transit confidentiality
> it will be much simpler just to configure the server to use and
> accept only STARTTLS SMTP sessions. Very few servers don't offer the
> functionality today - and most will use it when available. From my
> experience, non-TLS session on a TLS-advertising server is an almost
> sure indication of spam.

I think there is a difference between the re-ecrypted and TLS protected
messages. ISP's and anyone between the route is able to record messages
and sell the content. That is what most of the companies do nowadays.
Nobody would setup an encrypting mailing list to a server they don't
trust.

> Authenticity & integrity (that the message comes from the person
> claiming to be its author and has not been modified in transit) can
> be easy obtained by cryptographically signing a cleartext message.
> This is fully optional and compatible with existing mailing lists.
> 
> Next, privacy. I define privacy in the communication context as
> confidentiality of the fact of communication. That is, everybody may
> know that for example the address joe@example.com belongs to Mr. Joe
> Clever, and Mr. Clever sometimes sends greetings to friends or open
> letters to the public, but when he wants to communicate privately
> with someone, there's no way to tell from data transmission contents
> and patterns that he has done so and when - but the recipient will
> know that he got a message from Mr. Clever and not a random person.

If mail servers would not record the route and the return path the
message would be anonymous and private as it is with old fasion 
letters. Hiding your true communication can be done by increasing
random traffic. If your want anonymity you will need a software
especially designed for that... for example TOR.

> Email gives next to no privacy, addresses are sent in the
> clear. STARTTLS sessions mask the fact of communication somewhat,
> specifically if both parties have large user bases, but again, such
> parties have to be trusted not to leak the logs etc. Even then,
> traffic analysis can reveal communication patterns.

Everything depends on your opponent. His skills and resources.

> All in all, there's too little assurance of confidentiality in
> "encrypting list server" setup to be of serious use.

I know.. It was just more of an interesting idea that came into my
mind while thinking of another topic. But I think that when cryptography
comes closer to normal people the situation will be different. I say
that it is about companies who make cell phones to start offering
the applications and options to people. Cloud computing can be made
private if it is encrypted and the keys are kept only with the client.
All MUA's can be made aware of encryption technology and public key
infrastructure. Today when your fingerprints are automatically loaded
to some company's server it hard to talk about privacy. A little more
of encryption would not hurt.

-- 
-Matti

Ps. Sorry for the even longer message

Pps. Could the administrator of this list add Reply-To custom header
to the list. The current phones don't know how to reply to a list by
default :/ At least Apple wants to send mail to the sender not to the 
list

Re: [mlmmj] Encrypted list

[Chris Knadle]

On Thursday, March 20, 2014 23:34:34 Matti Nykyri wrote:
> On Thu, Mar 20, 2014 at 07:42:35PM +0100, Piotr Auksztulewicz wrote:
> > On Wed, Mar 19, 2014 at 11:42:30PM +0200, Matti Nykyri wrote:
[...]
> > Using complex cryptoghraphy like multiple-key encryption is
> > still harder and every subscriber would have to update the list of
> > recipients' keys to be able to encrypt the message for all of them to
> > be able to decrypt. In such case there's little advatange of having
> > a server, one may just put all of the addresses in the To: field.
> 
> Only way to implement encrypted list is to let the list decrypt and then
> reencrypt the messages. Otherwise the list needs to be implemented inside
> the MUA. Still this makes things simpler because it is then only needed
> for the list to have upto date keys of all the members. If MUA is doing
> the work then every subscriber has to have all the correct keys of all
> the subscribers!

Assuming we're discussing using PGP/GPG here (going to call it GPG for short), 
I can see how this could theoretically be done.  All users would have to have 
a GPG public/private keypair, and the mailing list itself would need a 
dedicated public/private keypair as well.  Users of the list would only have 
to import the GPG key of the list and /not/ of the other subscribers.  Emails 
sent back to the list would be encrypted using the /list/ GPG key, decrypted 
by the list, then messages would be re-encrypted to individual subscribers by 
the list itself.

Although technically possible to do, there are two snags.

1.  The GPG interface sucks.  I could rant about a long list of issues here,
    but suffice it to say that it's difficult to learn how to use it, how to
    get your favorite mail client integrated with it, how to configure GPG
    for setting the "default-preference-list" and "cert-digest-algo" ... etc.
    It represents a significant technical education problem.

2.  GPG can only encrypt the body of the message, and that doesn't cover any
    of the headers of the message, so the Subject, who the message is From
    and To, the route it took -- etc -- cannot be protected by GPG.  And
    one of the things we've learned from the Edward Snowden NSA revelations
    is that "metadata" itself is incredibly revealing.

[...] 
> > Therefore, semi-confidentiality of a regular closed list is not much
> > worse than re-encrypting list. To get in-transit confidentiality
> > it will be much simpler just to configure the server to use and
> > accept only STARTTLS SMTP sessions. Very few servers don't offer the
> > functionality today - and most will use it when available. From my
> > experience, non-TLS session on a TLS-advertising server is an almost
> > sure indication of spam.
> 
> I think there is a difference between the re-ecrypted and TLS protected
> messages. ISP's and anyone between the route is able to record messages
> and sell the content. That is what most of the companies do nowadays.
> Nobody would setup an encrypting mailing list to a server they don't
> trust.

I agree with Piotr: TLS is a /requirement/ for any "secure" mailing list, 
because TLS encryption starts at the connection with the MTA and therefore 
covers all of the headers as well as the body of the message.  The wonderful 
thing about TLS in SMTP is that if it were /mandated/ for all MTA transfers of 
a "secure" mailing list, the users don't have to do anything -- no GPG 
required, no key signatures, passwords -- nothing --from the user side it's 
dead simple.

And thankfully I see the same thing Piotr does: TLS SMTP transfers are now 
quite commonr.  There are unfortunately exceptions, so it's not quite 
ubiquitous yet -- I'm looking forward to the day when it is.

But if you say set up a separate copy of an MTA on a dedicated IP where the 
MTA /mandates/ TLS transfers, that in itself should cover most of what you'd 
need to allow running a "secure" mailing list with MLMMJ.

At least ... almost this is where I currently have an issue with MLMMJ: 
because I did this sort of "dual IP" setup (without mandating TLS transfers), 
but MLMMJ currently doesn't have a facility to specify which source IP to send 
email from, which makes the headers of the resulting email "look wrong" 
because it's sourced from the wrong IP.  To fix that in Exim4 I ended up 
having to make a "hack" whereby the "received_header_text" is set 
conditionally to remove the appearance of the "local MTA1" -> "local MTA2" 
transfer.

Creating the "source-IP" tunable is the facility I've been considering working 
on.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us

Re: [mlmmj] Encrypted list

[Matti Nykyri]

On Mar 21, 2014, at 1:31, Chris Knadle <Chris.Knadle@coredump.us> wrote:

> On Thursday, March 20, 2014 23:34:34 Matti Nykyri wrote:
>> On Thu, Mar 20, 2014 at 07:42:35PM +0100, Piotr Auksztulewicz wrote:
>>> On Wed, Mar 19, 2014 at 11:42:30PM +0200, Matti Nykyri wrote:
> [...]
>>> Using complex cryptoghraphy like multiple-key encryption is
>>> still harder and every subscriber would have to update the list of
>>> recipients' keys to be able to encrypt the message for all of them to
>>> be able to decrypt. In such case there's little advatange of having
>>> a server, one may just put all of the addresses in the To: field.
>> 
>> Only way to implement encrypted list is to let the list decrypt and then
>> reencrypt the messages. Otherwise the list needs to be implemented inside
>> the MUA. Still this makes things simpler because it is then only needed
>> for the list to have upto date keys of all the members. If MUA is doing
>> the work then every subscriber has to have all the correct keys of all
>> the subscribers!
> 
> Assuming we're discussing using PGP/GPG here (going to call it GPG for short), 
> I can see how this could theoretically be done.  All users would have to have 
> a GPG public/private keypair, and the mailing list itself would need a 
> dedicated public/private keypair as well.  Users of the list would only have 
> to import the GPG key of the list and /not/ of the other subscribers.  Emails 
> sent back to the list would be encrypted using the /list/ GPG key, decrypted 
> by the list, then messages would be re-encrypted to individual subscribers by 
> the list itself.
> 
> Although technically possible to do, there are two snags.
> 
> 1.  The GPG interface sucks.  I could rant about a long list of issues here,
>    but suffice it to say that it's difficult to learn how to use it, how to
>    get your favorite mail client integrated with it, how to configure GPG
>    for setting the "default-preference-list" and "cert-digest-algo" ... etc.
>    It represents a significant technical education problem.

Yes that is true. But what it means is that the worl is not ready yet! Users don't pursue privacy... Is it gonna change in future? There are many intances that want to prevent this.

And if you you just look at gpg it really lags quite much compared to the high end of the game. Openssl is far more advanced but the user interface is light years behind gpg's :/ But in general the world of email would not hurt from a little more of privacy!

> 2.  GPG can only encrypt the body of the message, and that doesn't cover any
>    of the headers of the message, so the Subject, who the message is From
>    and To, the route it took -- etc -- cannot be protected by GPG.  And
>    one of the things we've learned from the Edward Snowden NSA revelations
>    is that "metadata" itself is incredibly revealing.

Well standards don't support it (wonder why) but actually encrypting the entire data section of smtp should not prevent the mail from being delivered. I have not tested though. In my belief the mail is transported solely on rcpt and mail commands.

> [...] 
>>> Therefore, semi-confidentiality of a regular closed list is not much
>>> worse than re-encrypting list. To get in-transit confidentiality
>>> it will be much simpler just to configure the server to use and
>>> accept only STARTTLS SMTP sessions. Very few servers don't offer the
>>> functionality today - and most will use it when available. From my
>>> experience, non-TLS session on a TLS-advertising server is an almost
>>> sure indication of spam.
>> 
>> I think there is a difference between the re-ecrypted and TLS protected
>> messages. ISP's and anyone between the route is able to record messages
>> and sell the content. That is what most of the companies do nowadays.
>> Nobody would setup an encrypting mailing list to a server they don't
>> trust.
> 
> I agree with Piotr: TLS is a /requirement/ for any "secure" mailing list, 
> because TLS encryption starts at the connection with the MTA and therefore 
> covers all of the headers as well as the body of the message.  The wonderful 
> thing about TLS in SMTP is that if it were /mandated/ for all MTA transfers of 
> a "secure" mailing list, the users don't have to do anything -- no GPG 
> required, no key signatures, passwords -- nothing --from the user side it's 
> dead simple.
> 
> And thankfully I see the same thing Piotr does: TLS SMTP transfers are now 
> quite commonr.  There are unfortunately exceptions, so it's not quite 
> ubiquitous yet -- I'm looking forward to the day when it is.

That depends entirely on your adversary! If you want privacy from big companies or intelligence agencies TLS does not offer you anything! It can't secure your connection to your bank nor to a mailing list! Any intance who has access to a root certificate can claim to be anybody.

The problem does not lie within encryption. As you might have learned from Snowden but it lies within authetication. Also it lies within key exhange and key creation. This is a crucial part in securing your connection! 

Hopefully people will realice this some day. The main issue is in authentication. It is truely hard to be one 100% certain that someone is who he claims to be. The web-of-trust gives another and I would say a better approach to the chain-of-trust that has been the dominating way to do thigs.

> But if you say set up a separate copy of an MTA on a dedicated IP where the 
> MTA /mandates/ TLS transfers, that in itself should cover most of what you'd 
> need to allow running a "secure" mailing list with MLMMJ.
> 
> At least ... almost this is where I currently have an issue with MLMMJ: 
> because I did this sort of "dual IP" setup (without mandating TLS transfers), 
> but MLMMJ currently doesn't have a facility to specify which source IP to send 
> email from, which makes the headers of the resulting email "look wrong" 
> because it's sourced from the wrong IP.  To fix that in Exim4 I ended up 
> having to make a "hack" whereby the "received_header_text" is set 
> conditionally to remove the appearance of the "local MTA1" -> "local MTA2" 
> transfer.
> 
> Creating the "source-IP" tunable is the facility I've been considering working 
> on.

Using open source software and encrypting your emails is the only way have some privacy today. Who wants see Google read their emails? The only way for an mailing list to exist in an encrypting environment is that it re-encrypts everything. Do i require shuts privacy? No. But yes I would use it if it were available and could be easily implemented. 

-- 
-Matti

Re: [mlmmj] Encrypted list

[Chris Knadle]

On Friday, March 21, 2014 17:48:48 Matti Nykyri wrote:
> On Mar 21, 2014, at 1:31, Chris Knadle <Chris.Knadle@coredump.us> wrote:
[...]
> > Although technically possible to do, there are two snags.
> > 
> > 1.  The GPG interface sucks.  I could rant about a long list of issues
> > here,> 
> >    but suffice it to say that it's difficult to learn how to use it, how
> >    to
> >    get your favorite mail client integrated with it, how to configure GPG
> >    for setting the "default-preference-list" and "cert-digest-algo" ...
> >    etc.
> >    It represents a significant technical education problem.
> 
> Yes that is true. But what it means is that the worl is not ready yet!
> Users don't pursue privacy... Is it gonna change in future? There are
> many> intances that want to prevent this.
> 
> And if you you just look at gpg it really lags quite much compared to the
> high end of the game. Openssl is far more advanced but the user interface
> is light years behind gpg's :/ But in general the world of email would not
> hurt from a little more of privacy!

I'm in total in agreement on that latter part.

> > 2.  GPG can only encrypt the body of the message, and that doesn't cover
> > any> 
> >    of the headers of the message, so the Subject, who the message is From
> >    and To, the route it took -- etc -- cannot be protected by GPG.  And
> >    one of the things we've learned from the Edward Snowden NSA revelations
> >    is that "metadata" itself is incredibly revealing.
> 
> Well standards don't support it (wonder why) but actually encrypting the
> entire data section of smtp should not prevent the mail from being
> delivered. I have not tested though. In my belief the mail is transported
> solely on rcpt and mail commands.

Eh, er, sort of.  In terms of the MTA transfer the mail could be routed even 
if the DATA portion of the SMTP session was fully encrypted, but then you'd 
end up with an additional Received: header from "the current hop" added 
directly on top of encrypted data where the rest of the headers were (and 
perhaps several layers of this happening.)  This would hide the source IP of 
the originating message and the Subject, but it wouldn't hide the sender's 
address, receiver's, or the two MTAs.

However things would go wrong on the side of the MUA (i.e. mail client) 
because the email the user would get wouldn't have a From:, To:, Subject:, or 
Date:, because all that would be encrypted, so instead the MUA would simply 
show a list with an email showing empty data for those fields.  And an unknown 
number of decryption steps to get to the headers.  Ick.

So encrypting the entire DATA section would only require changing the SMTP 
protocol for both MTAs and MUAs.  :-/

> > [...]
> > 
> >>> Therefore, semi-confidentiality of a regular closed list is not much
> >>> worse than re-encrypting list. To get in-transit confidentiality
> >>> it will be much simpler just to configure the server to use and
> >>> accept only STARTTLS SMTP sessions. Very few servers don't offer the
> >>> functionality today - and most will use it when available. From my
> >>> experience, non-TLS session on a TLS-advertising server is an almost
> >>> sure indication of spam.
> >> 
> >> I think there is a difference between the re-ecrypted and TLS protected
> >> messages. ISP's and anyone between the route is able to record messages
> >> and sell the content. That is what most of the companies do nowadays.
> >> Nobody would setup an encrypting mailing list to a server they don't
> >> trust.
> > 
> > I agree with Piotr: TLS is a /requirement/ for any "secure" mailing list,
> > because TLS encryption starts at the connection with the MTA and therefore
> > covers all of the headers as well as the body of the message.  The
> > wonderful thing about TLS in SMTP is that if it were /mandated/ for all
> > MTA transfers of a "secure" mailing list, the users don't have to do
> > anything -- no GPG required, no key signatures, passwords -- nothing
> > --from the user side it's dead simple.
> > 
> > And thankfully I see the same thing Piotr does: TLS SMTP transfers are now
> > quite commonr.  There are unfortunately exceptions, so it's not quite
> > ubiquitous yet -- I'm looking forward to the day when it is.
> 
> That depends entirely on your adversary! If you want privacy from big
> companies or intelligence agencies TLS does not offer you anything! It
> can't secure your connection to your bank nor to a mailing list! Any
> intance who has access to a root certificate can claim to be anybody.
>
> The problem does not lie within encryption. As you might have learned from
> Snowden but it lies within authetication. Also it lies within key exhange
> and key creation. This is a crucial part in securing your connection!

I agree that we'd /want/ this -- but how would you accomplish this without
CA-signed TLS certificates?  The whole CA system is screwed up and makes 
things more difficult.

The DANE protocol requires DNSSEC and very few sites/MTAs are using it 
(supposedly only about 20 so far from last I heard), and not all MTAs have the 
feature yet -- Postfix does but Exim doesn't yet -- the Exim developers are 
looking into it though.  But even with DANE, it's a LOT to expect for a site 
to run DNSSEC, especially being that not all DNS servers support it.

So for now I think the best we can do is use /unauthenticated/ TLS -- 
purposefully -- so that at least the MTA transfers will be encrypted, even 
though they're not authenticated.

> Hopefully people will realice this some day. The main issue is in
> authentication. It is truely hard to be one 100% certain that someone is
> who he claims to be. The web-of-trust gives another and I would say a
> better approach to the chain-of-trust that has been the dominating way to
> do thigs.

The web-of-trust method is good for microcosms (such as the group of Debian 
developers) but as a worldwide solution I think it's too easily manipulated.

> > But if you say set up a separate copy of an MTA on a dedicated IP where
> > the
> > MTA /mandates/ TLS transfers, that in itself should cover most of what
> > you'd need to allow running a "secure" mailing list with MLMMJ.
> > 
> > At least ... almost this is where I currently have an issue with MLMMJ:
> > because I did this sort of "dual IP" setup (without mandating TLS
> > transfers), but MLMMJ currently doesn't have a facility to specify which
> > source IP to send email from, which makes the headers of the resulting
> > email "look wrong" because it's sourced from the wrong IP.  To fix that
> > in Exim4 I ended up having to make a "hack" whereby the
> > "received_header_text" is set
> > conditionally to remove the appearance of the "local MTA1" -> "local MTA2"
> > transfer.
> > 
> > Creating the "source-IP" tunable is the facility I've been considering
> > working on.
> 
> Using open source software and encrypting your emails is the only way have
> some privacy today. Who wants see Google read their emails? The only way
> for an mailing list to exist in an encrypting environment is that it
> re-encrypts everything. Do i require shuts privacy? No. But yes I would use
> it if it were available and could be easily implemented.

Okay, I see what you mean.

There is another downside to GPG-encrypted email though; you can't search 
through it easily for past content you're looking for.  [Well, you can, but it 
takes significant effort.]

However if you're looking for a Mailing List Manager that uses GPG, I believe 
the 'schleuder' package can do that (it's one of the MLMs I looked at before 
deciding to go with MLMMJ):

---------------------------------------------------------------------
$ apt-cache show schleuder

Package: schleuder
Version: 2.2.1-3
Installed-Size: 151
Maintainer: Jérémy Bobbio <lunar@debian.org>
Architecture: all
Depends: adduser, exim4 | mail-transport-agent, ruby1.8, ruby-tmail, ruby-
gpgme, ruby-magic, ruby-log4r, ruby-highline
Description-en: GnuPG enabled mailing list manager with remailer-capabilities
 Schleuder is designed as a tool for group communication: subscribers
 can communicate encrypted (and pseudonymously) among themselves, receive
 emails from non-subscribers and send emails to non-subscribers via the list.
 .
 Schleuder takes care of all decryption and encryption, stripping of headers,
 formatting conversions, etc. Schleuder can also send out its own public key
 upon request and process administrative commands by email.
Description-md5: 8480ae94adbe3ab75bd3e05d12375f2a
Homepage: http://schleuder.nadir.org/
Tag: implemented-in::ruby, interface::daemon, mail::list, mail::smtp,
 network::server, protocol::smtp, role::program, scope::application,
 security::authentication, security::cryptography, security::privacy,
 works-with::mail
---------------------------------------------------------------------



  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us

Re: [mlmmj] Encrypted list

[Matti Nykyri]

On Mar 21, 2014, at 22:09, Chris Knadle <Chris.Knadle@coredump.us> wrote:

> So encrypting the entire DATA section would only require changing the SMTP 
> protocol for both MTAs and MUAs.  :-/

Everything depends on the needs of users. And in the long run protocols an standards change. This hole snowden stuff has brought the problems to the eyes of common users. The professionals that seek for total privacy already have the tools and special applications for doing it. For an expert it is possible get privacy, but it takes a lot of effort.

An interesting change in smtp protocol would be an additional command that would specify a public key for the RCPT. In that way the new Received header could be encrypted with that key and prepended to the DATA portion. This would make each MTA aware only of the previous MTA, the sender, and  the recipient. It is also secure because only the sender needs to authenticate the public key of the recipient. If someone changes the key in between the recipient just can't open the message.

The sender address needs to be a real clear text address to receive the error of mail delivery. To get even more privacy the senders server could do virtual address map for all the mails it sends. So for every email the user part of the address is a new random string. When the message is being replied by the recipient or because of an error, the random user string is used. The original MTA will then map it to the real sender. The original recipient will get the true sender from the decrypted body of the message (the From header).

Another point is the sending time. To fake that you could delay the message for a random time. But fighting metadata is actually really tricky. That's why it is so useful in analyzing traffic. It is hard to fake.

But this is a never ending battle a cat and mouse chase... What gives more privacy and what hinders usability?!? Good solutions are usually simple and governments use billions for their goals!

> 
> I agree that we'd /want/ this -- but how would you accomplish this without
> CA-signed TLS certificates?  The whole CA system is screwed up and makes 
> things more difficult.

I'm just saying that using TLS does not give any more privacy in mail delivery if you are fighting for privacy from a CA!

> The DANE protocol requires DNSSEC and very few sites/MTAs are using it 
> (supposedly only about 20 so far from last I heard), and not all MTAs have the 
> feature yet -- Postfix does but Exim doesn't yet -- the Exim developers are 
> looking into it though.  But even with DANE, it's a LOT to expect for a site 
> to run DNSSEC, especially being that not all DNS servers support it.
> 
> So for now I think the best we can do is use /unauthenticated/ TLS -- 
> purposefully -- so that at least the MTA transfers will be encrypted, even 
> though they're not authenticated.

To get true privacy to the content of the message you need to encrypt the message so that only your recipient has a key to open it! The true problem is authenticating this key you use to encrypt the message. Can you trust a CA to authenticate you recipients public key? To gain true positive authentication you will need to meet or talk with the recipient to verify the key. Here comes the web-of-trust in play. Now when you have established one authentication you should be able to trust all the keys that have been signed by your recipient.

>> Hopefully people will realice this some day. The main issue is in
>> authentication. It is truely hard to be one 100% certain that someone is
>> who he claims to be. The web-of-trust gives another and I would say a
>> better approach to the chain-of-trust that has been the dominating way to
>> do thigs.
> 
> The web-of-trust method is good for microcosms (such as the group of Debian 
> developers) but as a worldwide solution I think it's too easily manipulated.

I think that all your friends are quite a small microcosmos.

> 
> Okay, I see what you mean.
> 
> There is another downside to GPG-encrypted email though; you can't search 
> through it easily for past content you're looking for.  [Well, you can, but it 
> takes significant effort.]

True. The search needs to happen in your MUA and it might get slow without good indexing or without downloading all the mail to your local drive.

> However if you're looking for a Mailing List Manager that uses GPG, I believe 
> the 'schleuder' package can do that (it's one of the MLMs I looked at before 
> deciding to go with MLMMJ):
> 
> ---------------------------------------------------------------------
> $ apt-cache show schleuder
> 
> Package: schleuder
> Version: 2.2.1-3
> Installed-Size: 151
> Maintainer: Jérémy Bobbio <lunar@debian.org>
> Architecture: all
> Depends: adduser, exim4 | mail-transport-agent, ruby1.8, ruby-tmail, ruby-
> gpgme, ruby-magic, ruby-log4r, ruby-highline
> Description-en: GnuPG enabled mailing list manager with remailer-capabilities
> Schleuder is designed as a tool for group communication: subscribers
> can communicate encrypted (and pseudonymously) among themselves, receive
> emails from non-subscribers and send emails to non-subscribers via the list.
> .
> Schleuder takes care of all decryption and encryption, stripping of headers,
> formatting conversions, etc. Schleuder can also send out its own public key
> upon request and process administrative commands by email.
> Description-md5: 8480ae94adbe3ab75bd3e05d12375f2a
> Homepage: http://schleuder.nadir.org/
> Tag: implemented-in::ruby, interface::daemon, mail::list, mail::smtp,
> network::server, protocol::smtp, role::program, scope::application,
> security::authentication, security::cryptography, security::privacy,
> works-with::mail

I think this comes down to individuals. Just one man who writes a good patch to support more privacy. Then its about community to evaluate if it is a good or the best solution. If it gets wide enough exceptance it might probably in some face end up in standard. The time will tell. 

-- 
-Matti

Re: [mlmmj] Encrypted list

[Chris Knadle]

On Saturday, March 22, 2014 09:40:33 Matti Nykyri wrote:
> On Mar 21, 2014, at 22:09, Chris Knadle <Chris.Knadle@coredump.us> wrote:
> > So encrypting the entire DATA section would only require changing the SMTP
> > protocol for both MTAs and MUAs.  :-/
[...]
> An interesting change in smtp protocol would be an additional command that
> would specify a public key for the RCPT. In that way the new Received
> header could be encrypted with that key and prepended to the DATA portion.

You can't do that.  The MTA needs to be able to see the RCPT TO as part of the 
process /before/ the DATA SMTP section is seen, in order to know whether the 
recipient of the mail is local or can otherwise be accepted.  The MTA itself 
doesn't read the DATA section, it can only pass it to other processes and pass 
along the contents.

> This would make each MTA aware only of the previous MTA, the sender, and 
> the recipient. It is also secure because only the sender needs to
> authenticate the public key of the recipient. If someone changes the key in
> between the recipient just can't open the message.
> 
> The sender address needs to be a real clear text address to receive the
> error of mail delivery. To get even more privacy the senders server could
> do virtual address map for all the mails it sends. So for every email the
> user part of the address is a new random string.

This is possible to do with some forms of wildcard addressing, but if the 
sending address really were a random string then you'd be expecting the 
recipient of the mail to accept email as if it came from someone they knew 
even though it looked like it was sent from a new nonexistent address.  That 
muddies the phishing scams problem.

> When the message is being
> replied by the recipient or because of an error, the random user string is
> used. The original MTA will then map it to the real sender. The original
> recipient will get the true sender from the decrypted body of the message
> (the From header).
>
> Another point is the sending time. To fake that you could delay the message
> for a random time. But fighting metadata is actually really tricky. That's
> why it is so useful in analyzing traffic. It is hard to fake.

I haven't yet considered sending/transit time in my statistics and ACL 
checking, but I know others that do and seem to find it useful.

> But this is a never ending battle a cat and mouse chase... What gives more
> privacy and what hinders usability?!? Good solutions are usually simple and
> governments use billions for their goals!
>
> > I agree that we'd /want/ this -- but how would you accomplish this without
> > CA-signed TLS certificates?  The whole CA system is screwed up and makes
> > things more difficult.
> 
> I'm just saying that using TLS does not give any more privacy in mail
> delivery if you are fighting for privacy from a CA!

TLS encryption hides the contents of the transfer, even if there isn't 
authentication as part of it.  SSL/TLS has two distinct parts to it; 
encryption and authentication.  The encryption part is what hides data from 
prying eyes, the authentication part means being able to verify the source.  
Encryption adds privacy, even though it doesn't add authenticity; 
authentication alone /does not/ add privacy because it doesn't hide anything.

It can give "a feeling of security", knowing that the message you got came 
from the actual author, but not privacy.

> > The DANE protocol requires DNSSEC and very few sites/MTAs are using it
> > (supposedly only about 20 so far from last I heard), and not all MTAs have
> > the feature yet -- Postfix does but Exim doesn't yet -- the Exim
> > developers are looking into it though.  But even with DANE, it's a LOT to
> > expect for a site to run DNSSEC, especially being that not all DNS
> > servers support it.
> > 
> > So for now I think the best we can do is use /unauthenticated/ TLS --
> > purposefully -- so that at least the MTA transfers will be encrypted, even
> > though they're not authenticated.
> 
> To get true privacy to the content of the message you need to encrypt the
> message so that only your recipient has a key to open it! The true problem
> is authenticating this key you use to encrypt the message. Can you trust a
> CA to authenticate you recipients public key? To gain true positive
> authentication you will need to meet or talk with the recipient to verify
> the key. Here comes the web-of-trust in play. Now when you have established
> one authentication you should be able to trust all the keys that have been
> signed by your recipient.

You can encrypt a message for someone without meeting them if they tell you 
their key ID (or if you look it up), they just won't be able to 
cryptographically authenticate that it was you that sent it to them.
Same thing in reverse.

Having verified GPG keys that are signed and trusted is sadly a rare thing, 
even in the technological circles I'm in.  I wouldn't count on having that.  
Too problematic to accomplish in practice.

> >> Hopefully people will realice this some day. The main issue is in
> >> authentication. It is truely hard to be one 100% certain that someone is
> >> who he claims to be. The web-of-trust gives another and I would say a
> >> better approach to the chain-of-trust that has been the dominating way to
> >> do thigs.
> > 
> > The web-of-trust method is good for microcosms (such as the group of
> > Debian developers) but as a worldwide solution I think it's too easily
> > manipulated.
>
> I think that all your friends are quite a small microcosmos.

What's your point?  Very few of my friends are also part of the web-of-trust, 
so even assuming this was true, it doesn't really help.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us

Re: [mlmmj] Encrypted list

[Piotr Auksztulewicz]

On Thu, Mar 20, 2014 at 11:34:34PM +0200, Matti Nykyri wrote:
> The only ones that I can think of being keen on security
> and sending mails in the free internet are security administrators 
> for example with gentoo and the Linux kernel. Security administrators 
> send sensitive and time critical information about the found security
> security holes of the system and they use encryption.

This is indeed a rare case of communication that's only mildly sensitive
for a limited time, and also of a close-knitted group of people that may
have some benefit such re-encrypting list. I still think such list isn't
usable for serious matters, while a regular closed list is private
enough for non-sensitive matters.

Most of the lists out there are "hey, let's make a list for people
interested in X" and anybody can join. This is not secure and only
a little more private than a web forum or something.

> It is sad to see how little people demand security and privacy todays.
> When people don't demand it corporations don't implement it... on the
> contrary they lessen your privacy by scanning your messages.

This is also why email privacy is dead and buried. Even if I started
using GPG now (actually, I have stopped long ago), as long as most of my
correspondents flock to gmail and the like, either I can't use it with
them, because they won't let go their shiny webmail interface and go
back to Thunderbird or whatever, or I am at mercy of future gmail's
features. I can easily imagine them offering support for encrypted mail
by allowing to deposit one's private key with them, and many users
blindly doing just that.

Basically, email providers can't be trusted AND email users can't be
trusted in majority.

Myself, I know only a handful of poeple that I can trust to hold their
mailbox secure... and even with them I don't use encrypted email just
because I don't have anything so sensitive to say, so it will be just
a hassle or a moslty pointless excercise of GPG skills.

For an email list, you can't trust anybody, unless you ultimately trust
the owner and his methods of vetting subscribers. Kernel developers may
be able to do that.

Myself, I am treating email as a postcard. Anybody in the post office
can read it, secret agencies will scan and store it, kids in the
neighbourhood can open the mailbox and steal or read the contents,
addressee will put it in the trash for dumpster-divers to have. On the
other hand, a random person would not snatch it in transit, or read
the contents without considerable efforts, so it provides a little bit
of privacy. So it is fine to send vacation postcards to your relatives,
while it is not wise to post a billboard saying that (think burglars).

> Is it easier to crack the server or open the message? In most cases I
> think it will be the server.

True. Bruce Schneier says "math is good". It is the application of it,
or human shortcomings, that allow the secrets to be revealed.

> Only way to implement encrypted list is to let the list decrypt and then
> reencrypt the messages. Otherwise the list needs to be implemented inside
> the MUA.

My disgression was about omitting the re-encrypting by encrypting at the
sender with multiple keys. But it requires support in the MUA, or some
clever script/plugin, yes. The server would re-mail as usual. But you
need to keep all the keys. Maybe the server could help by attaching
all keys to each email, or sending them on request. Such setup will
circumvent the issue of server security and the trust of the owner;
but you still need to trust all subscribers not to leak the message,
intentionally or not. Kernel developers, again.

> The only metadata available to Eve the Evesdropper is the sender and
> the list name and the route between them.

GPG and no TLS would get Eve sitting on the wire near the server all
subscribers' addresses, routing information, subject, date, MUAs used
etc. etc. - from the headers.

TLS would get such Eve only the originating (or intermediate) and target
MTAs. This may be sufficient to identify single subscribers (myself, for
example - I run my own server).

Attacking TLS is not so easy, but doable. If you think CA subversion -
that's not needed in case of email. Most sending MTAs will accept any
certificate, or go without TLS if not offerred. You need to do some kind
of traffic hijacking (DNS poisoning? BGP false advertisement?) to get
the TCP stream, then you can pretend to be any MTA you want, TLS or no
TLS, get the headers and content, then re-send to the proper MTA. So a
determined attacker can get any SMTP metadata almost without notice.
Almost, because in case of hijacking the resent message will come from a
different IP address than normal - unless you hijack the reverse path as
well. Receiving MTA will likely accept that, unless there's a strong SPF
policy or two-way DNS check policy in place, which is rare. Only a human
checking the Received: headers could notice something strange.

> I think there is a difference between the re-ecrypted and TLS protected
> messages. ISP's and anyone between the route is able to record messages
> and sell the content. That is what most of the companies do nowadays.

It is a difference, but from my point of view it is not particularly
significant. Both protect the message contents from a causal sniffer on
the wire, TLS protects headers, too. I have not heard of any intermediate
MTA that will mine the messages' contents (not counting virus/spam
scanning). It is true, that many email account providers mine the emails
for commercial purposes, but users of such services would be either
unable/unwilling to use encrypted email (because they would loose the
universal and convenient access to their mails from every web browser
or phone app out there), or aware enough not to use them.

Today there aren't many MTA hops in email transmissions, not counting
technical ones, like one MTA instance sending to the virus scanner,
then to another MTA instance sending it out - all within the same
network/organisation. Then there's a direct hop to the recipient.
Only spammers use the higher-order MX records :-)

This is why I insist that enforcing TLS (and banning gmail users :-P)
would be sufficient privacy for a listserver.

> If mail servers would not record the route and the return path the
> message would be anonymous and private as it is with old fasion 
> letters.

Not with the SMTP protocol. Sender and recipient are there, so not
anonymous, and not private in the sense that the fact of communication
is hidden. TLS helps a little. GPG adds confidentiality of contents
only. Snail mail is a little better at privacy (metadata is not so
easy to obtain) and worse at confidentiality - an envelope is not
very secure, and even if there are methods of increasing physical
security in order to enhance confidentiality, encryption is still much,
much  better.

> Hiding your true communication can be done by increasing
> random traffic. If your want anonymity you will need a software
> especially designed for that... for example TOR.

This is what I was hinting at. Use the right tools. Email list
is not one.

> But I think that when cryptography
> comes closer to normal people the situation will be different.

It is a hard problem - how to make cryptography both secure and easy
to use.

> Cloud computing can be made
> private if it is encrypted and the keys are kept only with the client.

If you mean cloud storage, yes - and ONLY storage at this point. There
are some precursors already, the new MEGA promises exactly that -
client-side encryption. How easy to use it will be, and how hard to
circumvent - time will tell. Myself, I won't trust server-pushed
Javascript encryption software - even if MEGA's use of crypto is sound
and key management is more or less secure.

I use GPG before uploading my backups and stuff to S3.

But "cloud" is more than that. Indexing your email for search, sorting,
thumbnailing, cropping of your photos, recommending music based on what
you've listened to before, etc. etc. - all require server-side
processing of your unencrypted data and therefore are susceptible to
data mining. People are used to that and won't let such features go.
Homomorphic encryption is in statu nascendi and will be there for many
years yet - and if it ever gets strong enough it would be most likely
very CPU-intensive (and thus expensive!) to process any data in
encrypted form. People want "free" and easy-to-use stuff. This is it.

> A little more of encryption would not hurt.

Sometimes it will - if it creates a false sense of security.


PS. I apologize non-crypto-geeks on the list for the long rant :-)

PPS. I like this list to go live - even if slighlty off-topic.

-- 
Piotr "Malgond" Auksztulewicz                     firstname@lastname.net

Re: [mlmmj] Encrypted list

[Patrice Levesque]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]


> Myself, I know only a handful of poeple that I can trust to hold their
> mailbox secure... and even with them I don't use encrypted email just
> because I don't have anything so sensitive to say, so it will be just
> a hassle or a moslty pointless excercise of GPG skills.

If I may add my 2 cents, encrypting regular non-sensitive mail does not
appear pointless to me.

For one thing it ensures that GPG mail setups are properly configured
all the time and ready when needed for critical data.

It also gives the intelligence agencies something bogus to chew on; let
them waste resources deciphering cat pictures.

Lastly, the current poor adoption rate of encryption makes every GPG'd
mail stick out.  Encrypting non-sensitive data lessens that effect.



-- 
 --====|====--
    --------================|================--------
        Patrice Levesque
         http://ptaff.ca/
        mlmmj.wayne@ptaff.ca
    --------================|================--------
 --====|====--
--

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [mlmmj] Encrypted list

[Chris Knadle]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

On Monday, March 24, 2014 13:25:40 Patrice Levesque wrote:
> > Myself, I know only a handful of poeple that I can trust to hold their
> > mailbox secure... and even with them I don't use encrypted email just
> > because I don't have anything so sensitive to say, so it will be just
> > a hassle or a moslty pointless excercise of GPG skills.
> 
> If I may add my 2 cents, encrypting regular non-sensitive mail does not
> appear pointless to me.
> 
> For one thing it ensures that GPG mail setups are properly configured
> all the time and ready when needed for critical data.
> 
> It also gives the intelligence agencies something bogus to chew on; let
> them waste resources deciphering cat pictures.
> 
> Lastly, the current poor adoption rate of encryption makes every GPG'd
> mail stick out.  Encrypting non-sensitive data lessens that effect.

Agree with this.  For people I exchange encrypted email with (of which there 
are very few), we've gone to encrypting 100% of our email exchanges, using the 
same line of thinking as the above as to why.

However; none of the (many) email lists I'm on use GPG encryption, a few of 
them use TLS for MTA transfers but several others  have purposely are set not 
to use TLS.  [The mailing lists I'm deploying use TLS transfers if available.]



As a thought experiment, let's say that we had an opportunity to "design the 
world of all of our friends' email".  What would that look like?

For starters, all email transfers would use TLS, and all of our friends would 
be using "private" mail servers rather than 3rd party services like Gmail.  
GPG is too complicated for most of them to use, so we know most of them won't.  
The end result is that mail stored on the private servers and our local hard 
disks isn't encrypted -- with some difficulty the latter part is fixable 
though.

As such, putting some effort wards encrypting our own filesystems seems like a 
worthwhile effort.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [mlmmj] Encrypted list

[Ben Schmidt]

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? 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.

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.

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.

Smiles,

Ben.

Re: [mlmmj] Encrypted list

[Chris Knadle]

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