Re: Email List Encryption - Problem

On Mon, 28 Nov 2005 19:42:01 -0700, Luc The Perverse wrote:

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

Yes, it does seem to be the case.
 
> If you were willing to break rule #1 then you could do a multitude of
> things.

Have a better shot at breaking number 2.
 
> 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.

This is what we are thinking, a memory resident "listener" that is
configured to the SMTP port, activating the encoding much the same way that
certain email tagging systems listen. Why don;t you like this concept?
 
> 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.

True however nonencrypted emails would be bounced by the list server's
server and that would be notification of failure.
 
> 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.

Nature of the beasts, these are ppl giving freely of their time to report
and assist in these domestic cases. They are also doctors and not
particularly tech savvy.

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

No, the victims never post only the parties interested in diagnosing or
prosecuting cases.
 
> 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.

The choices we will offer are limited by user habituation, in short, we
have to make encryption/self-decryption work within their comfort zones.
 
> 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.

We anticipate on the fly Gutman erasure (or similar) but all emails will be
archived at the server for secured access by users.
 
> 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.

Agree with that, reboots won't work either.

-- 
Drop the alphabet for email