[guardian-dev] looking for comments on secure email v2
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.
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
> 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:
>> 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
>>> 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
>>> 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
>>> 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
>>> 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:
>>> You are subscribed as: c1.android at niftybox.net
> 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