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

Sat Mar 15 14:57:12 EDT 2014

Oh, and the demonstration website is here:

http://pmx.mooo.com

I can't guarantee anything will be up at any time.  Also I reset the
db whenever I feel like it.

-tim

On 3/15/14, Tim Prepscius <timprepscius at gmail.com> wrote:
> 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
>>>>
>>>
>>
>