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

Tim Prepscius timprepscius at gmail.com
Sun Feb 23 18:06:03 EST 2014

I will not run a service.  Everyone runs their own.

As for "if the user's service has been hacked, will it compromise
their key when they log in?"
Yes it would.

Client logs in, gets his encrypted secret key.  Decrypts.  Malicious
javascript sees unencrypted secret key and sends to outside world.

Is there such a thing as a secure plugin for a browser?  Maybe that is
the way to go?

What happens if your browser has been compromised?  For instance let's
say there is some script which takes screen shots, forwards them when
the browser is in the background.


On 2/23/14, Dev Random <c1.devrandom at niftybox.net> wrote:
> Hi Tim,
> Glad to see people working on secure email.  I have a quesetion:
> If your service is hacked and malicious javascript is injected, won't
> the private key for each user be compromised as they log in?  If so, how
> do you plan to mitigate this risk?  Browser plug-in?
> On Sun, 2014-02-23 at 14:33 -0500, Tim Prepscius wrote:
>> So I'm writing a new version of mailiverse...  I'm looking for some
>> comments on specific design decisions.
>> The fundamental reason is because the old one is too complicated, it
>> was mostly built before I knew exactly what I was doing.  And in
>> retrospect, I think it was built the wrong way.  GWT is nice because I
>> can see things compile..  But GWT is not nice because it requires
>> other people to have GWT.
>> The goals for the new mailiverse are:
>> 1.  still, everything client side.
>> 2.  easy to modify, and easy to run without encryption. (for dev)
>> 3.  encryption is encapsulated into a single layer, replacement of
>> ajax hook, basically
>> 4.  no gwt, just javascript, no build.
>> 5.  pgp
>> 6.  basically, something smaller and nimbler, easy to modify.
>> ---------------------------------------------------------------------------
>> Here is the question I have been pondering:
>> In the old mailiverse, I didn't want to expose information about
>> singular pieces of data.  So I would group lots datas together into
>> files.  And then each data (let's say conversation) would have a
>> pointer built from "file it's in, piece of the file index" (which
>> would point to a mail data).
>> But this made the design really complicated.  If one file broke,
>> because of some network difficulty or bug, lots of things might break.
>>  The server was simple, but it didn't offer any added "reliability"
>> for the information graph to the client.
>> ..
>> So in the new mailiverse I was thinking about have the server be a
>> restful server.  Where each piece of data would have two elements
>> exposed, "id" and "parentId."  The rest would be encrypted.  Well
>> maybe there would be a "ordering" field, which would be based off of
>> date. (for conversations to be ordered)
>> So each folder would have a parentId of the userId.
>> Each conversation would have a parentId of the folderId.  (slightly
>> different, but you get the point)
>> Each mail would have conversationId as parentId.
>> How bad is this?
>> It would make the client interactions with the server be trivial.  And
>> actually, the whole rest of the design becomes relatively easy.  The
>> client no longer needs "pointers" stored everywhere and updated,
>> because the pointers are essentially lookups "get all mail which has a
>> parent conversation id of X"
>> The encryption is simple.  Everything is simple.  So simple I'm blown
>> away actually.
>> But I think to myself.  Ok, there definitely is information being leaked
>> here.
>> Somebody takes control of DB, would def be able to see how many
>> messages you got, when you got them.  How many messages in each
>> conversation.  If you've grouped them by folder, how many in each
>> folder.
>> Also, because the messages are singular, they would be able to see the
>> approximate size of each message.  And they would be able to look at
>> the conversations and approximate the size of the dictionary of words
>> contained inside.
>> What do you think about this?
>> Do you think this trade off to make the client simple and the server
>> simple is worth it?
>> Can you see an alternate way of doing the pointers which I'm not
>> seeing?  Which gives some opacity to the graph relationships but
>> perhaps allows the server to ensure the data is "well connected." (I
>> just made that up ;-) )
>> ---
>> Thank you for your time.  I realize this message is a bit off topic
>> for guardian, but I think, broadly this is an appropriate place to
>> ask.
>> -tim
>> _______________________________________________
>> 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/c1.android%40niftybox.net
>> You are subscribed as: c1.android at niftybox.net
> --
> Miron

More information about the Guardian-dev mailing list