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

Tim Prepscius timprepscius at gmail.com
Wed Feb 26 15:23:30 EST 2014


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