Re: Protection of decrypted data from malicious servers?

On 3/25/2014 3:57 PM, James Marshall wrote:
> If this hasn't been addressed, I think of two possible solutions, 
> neither one very good:

Assuming the use-case you mean is "I want to send S/MIME and/or PGP 
messages and let a GMail/Yahoo Mail/etc. user read them in their web 
browser while being assured that Google/Yahoo/etc. can't read the 
contents," this is effectively impossible. In reality, the decrypted 
contents will need to be parsed and handled somehow, in the very least 
to support HTML email which requires some modicum of processing.
> 1) Use a kind of "taint", where decrypted data and all data derived 
> from it is prevented from being sent back to a server.
There are two kinds of dependencies: data-dependence and 
control-dependence. Tracking data-dependent taint is possible, but it 
doesn't prevent leaking information via control-dependence. I can think 
of some potential opportunities for breaking the control-dependent flow, 
but those basically destroy the UX of email for most people (e.g., 
prohibiting reply, requiring explicitly-sized divs, etc.). Not to 
mention that malicious code could just bypass the fancy features and use 
the specification draft as-is.
>
> 2) Use HTML to define an element to display decrypted data, without 
> allowing JS to access the content of that element.  Something like
>
>     <div id="mysecret" type="encrypted" algorithm="..." ...></div>
>
> ... and something similar for an input field that is to be encrypted 
> before JS can access its data.

The need to pre-process prevents this.

> Am I missing something, and has this been addressed?

Effectively, you have to trust the code. If you don't trust your 
webmail's code, the only solution is to use another email client, since 
the webmail's HTML page is effectively the email client.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

Received on Wednesday, 26 March 2014 20:06:40 UTC