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

Hans-Christoph Steiner hans at guardianproject.info
Mon Feb 24 12:59:15 EST 2014

There are "apps" for both Firefox and Chrome.  That's probably the best
approach here.  That's how Cryptocat is distributed for example.

As for storage, I guess you're doing the whole thing in Javascript, so that
limits your options a lot. If a native backend is a possibility, I think you
should use sqlcipher as your backend storage.


On 02/23/2014 06:06 PM, Tim Prepscius wrote:
> 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.
> -tim
> 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
> _______________________________________________
> 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/hans%40guardianproject.info
> You are subscribed as: hans at guardianproject.info

PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

More information about the Guardian-dev mailing list