[guardian-dev] looking for comments on secure email v2

Tim Prepscius timprepscius at gmail.com
Sat Mar 15 14:56:01 EDT 2014


ok a first draft is up.

https://github.com/timprepscius/mv

I'm going to work on it for the next week and then release to the
reddit security thing.
Then I'll work on it another week and see if I can notify the CCC.
I think by the end of two weeks it will be stable, and have most of
the functions of gmail.


It is super super simple.  I think the learning curve is probably 1
day to understand how everything works.
Probably 30 minutes to change the look and feel.

---


I also have a few ideas on how to defeat the javascript injection problem.
But it depends on the adversary is injecting the javascript.

If the adversary has hacked the server and made a changes to the
static files.  This should be detectable.
And presumably, if I set up an external server which would provide
"diffs" of a target website over time, I could notify users of
changes, and what they were.

If the adversary attempts to inject javascript for a specific login,
in my case this shouldn't apply.  As all javascript is downloaded
before login.

If the adversary is injecting javascript only for a specific ip.  I
have no solution.

Anyways, a few ideas, no silver bullet of course.

-tim


On 3/5/14, Tim Prepscius <timprepscius at gmail.com> wrote:
> Ok I have two more design questions:
>
> PGP lookup -----------
>
> When a sender is seen for the first time (or after a while)
> 1.  lookup pgp key on random public key server.
> If so:  mark key: "seen on public key server X at date Y"
>
> 2.  if pgp signature block exists and public key exists, attempt to
> verify message:
> If message verifies, mark key: "successfully verified message"
>
> 3.  if pgp public key block is received in mime, mark key: "received
> key from user"
>
> ...
>
> If "seen on server" and "successfully verified message", mark key GREEN
> if "seen on server" but not yet used to verify message, mark key YELLOW
> if not seen on server, mark key RED.
> if key is revoked, mark BLACK, stop user from sending.
> If not key at all, mark WHITE
>
> Contacts which you type into the to box, will become color coded.
>
>
> PGP generation with revoke -------
>
>
> I'd like to have the client generate the REVOKE certificate when he
> generates the PGP key.
> And then I'd like that client to send ME the REVOKE.  So that I can
> revoke the PGP key along with the account if necessary.
>
> How bad is this?  Does this raise eyebrows like, "wow that is messed
> up and introduces security issues"  or does that seem like, "well I
> can see that having closed accounts with non revoked pgp keys is a
> problem."
>
>
>
> (openpgp.js does not have the revoke capability yet, however I think I
> can take it from bouncy castle (if it exists there).)
>
>
> -tim
>
>
>
>
>
>
>
> On 2/26/14, Tim Prepscius <timprepscius at gmail.com> wrote:
>> Omg, my response was just killed by the browser.  RAWRGH.
>>
>> Anyhow, now in short form:
>>
>> scramble.io: is very close to what I want to do.  Their tag line is
>> oddly familiar.
>> but with an AES caching scheme, -  just a little bit more professional.
>> Even simpler, built off of backbone.
>> I actually have a prototype done.  There's like 100 lines of code,
>> mostly curly braces.  It's crazy.
>>
>>
>> crypton:  don't get what it gives me.  don't see how it protects the
>> dag on the database side.  I read server code.
>>
>>
>> webcrypto:  I personally think this is a bad idea.  Ok, now I'm not a
>> good person.  But I would trust a signed random number generator run
>> by many universities, over google.  Tinfoil is shiny!
>>
>>
>> the plugin:  This just doesn't work for me.  I don't like plugins.  I
>> think I'm going to do the non-plugin version, and somebody else can
>> plugin-ify it.  I wish we could have secure computing in the browser,
>> Xbox style.
>>
>>
>> people-running-their-own.  Yes, I understand.  This is an RS idea.  I
>> think his point was very valid.  One email provider with a million
>> clients is much easier to take down than ten thousand and a hundred
>> per each.  With the advent of NaCL and ZeroVm this may be a
>> possibility.
>>
>>
>> Ok I have another question:
>>
>> Has anyone dealt with CryptDB?  I'm looking for a way to encrypt the
>> DAG but still have it be query-able.
>> I can do some simple things like, "exposedParentId = AES (parentId)"
>> But then you will still have 10 emails with the same conversationId.
>>
>> -tim
>>
>>
>> On 2/25/14, elijah <elijah at riseup.net> wrote:
>>> On 02/23/2014 11:33 AM, Tim Prepscius wrote:
>>>
>>>> So I'm writing a new version of mailiverse...  I'm looking for some
>>>> comments on specific design decisions.
>>>
>>> please see my draft report on the 'state of art' in secure email
>>> projects:
>>>
>>> https://github.com/OpenTechFund/secure-email
>>>
>>> scramble.io is probably most similar to your goals, maybe try to join
>>> forces?
>>>
>>> If I were to try to do webmail, I would do it this way:
>>>
>>> (1) ensure it had support for CORS or postMessage so that code was
>>> loaded from a different site than the data. In think going down the
>>> browser app path is madness, because they you must trust google
>>> entirely. If you don't trust the CA cartel, then use public key pinning
>>> & HSTS.
>>>
>>> (2) use a generic encrypted synchronization library for html5 apps like
>>> https://crypton.io (which was just audited by zooko et al)
>>>
>>> (3) wait a year for webCrypto api to be deploy by all major browsers so
>>> that it is not folly to try to generate keys in javascript in the
>>> browser.
>>>
>>> Ultimately, I think the only way to get the security properties that we
>>> need today is to require some kind of custom app be installed. I could
>>> be wrong, but it hard to imagine the browser becoming a secure computing
>>> environment anytime soon. If you are willing to contemplate a custom
>>> app, we would love your help at LEAP (https://leap.se/email).
>>>
>>>> I will not run a service.  Everyone runs their own.
>>>
>>> As someone who has 13 years experience in helping to run an email
>>> service, you can count me in the category of people who think that
>>> self-hosted email is never going to happen. My analysis is spelled out
>>> in detail here:
>>> https://github.com/OpenTechFund/secure-email#self-hosted-email
>>>
>>> On 02/24/2014 09:59 AM, Hans-Christoph Steiner wrote:
>>>
>>>> If a native backend is a possibility, I think you should
>>>> use sqlcipher as your backend storage.
>>>
>>> This is what Soledad does (LEAP's client-encrypted synchronized
>>> searchable document database https://leap.se/soledad). the local
>>> database is block encrypted using sqlcipher, and synchronized on a
>>> per-document basis, with each document encrypted with its own key and
>>> given a random document id (in a manner that prevents replay attacks by
>>> the server).
>>>
>>> -elijah
>>>
>>> _______________________________________________
>>> Guardian-dev mailing list
>>>
>>> Post: Guardian-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>
>>> To Unsubscribe
>>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>>         Or visit:
>>> https://lists.mayfirst.org/mailman/options/guardian-dev/timprepscius%40gmail.com
>>>
>>> You are subscribed as: timprepscius at gmail.com
>>>
>>
>


More information about the Guardian-dev mailing list