Re: Email List Encryption - Problem
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


sci.crypt archive

Re: Email List Encryption - Problem

From: Luc The Perverse <sll_noSpamlicious_z_XXX_m@cc.usu.edu>
Date: Tue Nov 29 2005 - 03:42:01 CET

"Ari Silverstein" <abcarisilversteinn@yahoo.comxyz> wrote in message
news:7o10325u76gc$.1260r0ysifukw.dlg@40tude.net...
> On Mon, 28 Nov 2005 15:43:09 -0700, Luc The Perverse wrote:
>
>>> The users have resisted PGP, closed system emailing and any other type
>>> of
>>> active participation, in short, they want security without any
>>> appreciable
>>> effort.
>>>
>>> Comments appreciated. Advise going to a non profit.
>>
>> They have to have some form of authentication - password?
>>
>> Try an online email system, with encryption just web based.
>
> Thanks, Luc, but the users have demanded that the encryption system not
> interrupt their typical emailing routines, no passwords, the whole system
> has to run in the background (more or less) without user intervention. The
> users are so important to the project that a drop off in traffic could
> actually mean lives are lost and prosecution/innocence would be materially
> affected.
>
> We could build plugins for various email clients but what a hassle and
> this
> would not give the (near) 100% coverage that is sought plus the support.
> Since this is a charitable group, keeping costs down is a moral
> consideration albeit possible. Not that we wouldn't get paid, but paid not
> in terms of grandiose profits.

I'm sorry - I don't think it's possible to do both:
1. Not change the way they use email
2. Not install anything

If you were willing to break rule #1 then you could do a multitude of
things.

If willing to break number 2 (even temporarily) . . . . now this is getting
funky . .. but you could intercept outbound and inboud mail transfers
(Assuming a known protocol, pop3, IMAP, etc) and decode or encode emails on
the fly transparent to the calling aplication. I don't like this solution.

>> ActiveX programs will give you this type of functionality on a windows
>> machine. It is detectable, but it could be made to clean up after
>> itself.
>> Of course, so could an EXE file.
>
> Expound please.

Ignore that part.

When a system is as transparent as it would seem that you want it to be, it
is difficult to know if the system is working.

Maybe I'm missing the point - but why can't they in any way change their
email habits? If emails were going to all the sudden be secure, I would
want some way of knowing that this was happening.

You said that they are victims of domestic abuse? But if they are alone
long enough to compose an email (without getting caught) then it can
reasonably be assumed that they are using uncompromised computers.

But let me attempt a solution. You want to allow them to use any existing
email interface, and not change any of their settings etc, you don't want
any software installed, and no trace of software left after they are done.
Have a web based encryption form (Java 1.1 comes to mind) that will encrypt
their message into plaintext, and then allow them to cut and paste it into
their browser.

What I imagine the best solution will ultimately be is to give your users a
variety of choices. Completely web based, web based with cut and paste,
hidden installed application with cut and paste, hidden installed
application that mails.

A foreseeable problem with cut and paste methodology is that the encrypted
outbound messages will still exist in the users outbox. All the sudden the
question comes into play - what is the threat model? We are making a
system, presumably to hide from the abusive partner, however, we must assume
that he or she is smart enough to spy on their partners habits. Existing
email solutions leave traces behind.

You could make a generic system that completely reverted system state after
being used - every file, registry - that has problems as well, not to
mention being extremely complicated to implement - and will the probability
of a reboot, not likely going to be very popular.

--
LTP
:) 
Received on Sat Dec 3 04:20:17 2005