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

Sun Mar 23 22:51:50 EDT 2014

I've done a lot of work on the mv2 in the last couple weeks.

I'm looking for a repository of pgp mime messages to test detecting
signatures and decryption.

If you know of such repository somewhere, let me know.  I've posted on
the gpg mailing list as well.  Googling hasn't yielded anything yet.

Alternatively, if you wouldn't mind sending a signed message or an
encrypted message from your favorite mail program.  (especially if it
isn't thunderbird or gpg-applemail)

g at pmx.mooo.com

g's public key is:
http://pastebin.com/raw.php?i=rW3qmbnE

if you use a temporary key to encrypt/sign, (one not on a pgp key
server), you'll need to send me the pub key.

-tim

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