Pretty Good Diaspora

[Michiel de Jong]

I just re-read this excellent blog post:

http://www.thefoundation.de/michael/2010/aug/23/diaspora-and-the-web-of-trust/

 

which pretty much explains why Diaspora needs to work with PGP.

I can't find the exact references from the Diaspora team now, but off the top of my head, at the beginning, PGP was one of their main points about how they were going to build Diaspora. Then at some point, they dropped PGP, if I understood and remember correctly, because of compatibility issues. I would interpret that as "if we drop PGP, then Diaspora can run on a windows server" (correct me if I'm wrong and also anybody who knows the original ref., please add it here).

Since most people on this list who host diaspora on windows seem to be using a virtual machine anyway, I think we should put PGP back into Diaspora. That was the team's original plan anyway, wasn't it?

I will dive into the Diaspora code this weekend, learn Ruby, and try to make it work with PGP. I will let you know my findings after the weekend. Other people could do the same and after the weekend we can see if we came up with the same draft approaches. By then we should hopefully also have established contact with the Diaspora team about what their plan is with this, and we can try to help them launch Diaspora-with-PGP instead of launching Diaspora-without-PGP.

Cheers!

Michiel.

[Jakob Keres]

And what are you going to do with you private key?

* Store it on the server? Better not.

* Encrypt it with a short phrase and store on the server? Then the
encryption is as strong as your phrase. Normally not too much.

* Carry it on an USB flash drive? Nobody will do that.

Last question:
How do you know that your Java Script-Web-Application is trustworthy
and that is not corrupted? In the end you have to trust your sever or
use a Not-Web-Based-Application.

2010/9/21 Michiel de Jong <dejong....@gmail.com>:

[shadowfirebird]

On Sep 21, 12:46 pm, Jakob Keres <jakob.ke...@googlemail.com> wrote:
> And what are you going to do with you private key?
>
> * Store it on the server? Better not.

Why not, exactly?

[Bryce Lynch]

On Tue, Sep 21, 2010 at 12:46, shadowfirebird <shadowf...@gmail.com> wrote:
>> * Store it on the server? Better not.
>
> Why not, exactly?

What protects the private key ordinarily is a symmetric cryptosystem
that uses your passphrase to temporarily decrypt the key for the
purposes of decrypting data or making digital signatures. For
Diaspora to make use of one's PGP private key, the keyfile would
either have to be stored unencrypted on disk (which you can do but
this is very dangerous), or it would have to periodically prompt the
user for their passphrase so it could cache a decrypted copy of the
private key in memory.

The latter would likely be too cumbersome for most people to deal
with, plus it would mean that certain content would be unavailable to
anyone after the cached key was expired and removed from RAM.
However, an attacker who manages to compromise the server or VM (or
who exploits a privileged subsystem of Diaspora, potentially) could
then dig that private key out of RAM by hunting through /dev/mem (for
example) or by searching the system's swap partition for signs of the
unencrypted private key (though there are ways to mitigate these
risks, such as not running parts of Diaspora as root).

Incidentally, this is something that concerns me about Diaspora that I
was hoping to work on when things calm down a bit at my day job -
Diaspora running as root because it needs port 80/TCP. I think a few
people have either fixed or gotten around that (I haven't updated my
Git tree in a day or so) because they are reporting instances on
high-numbered ports (though this could be due to port redirection at
their local firewalls).

--
The Doctor [412/724/301/703]
http://drwho.virtadpt.net/
"I am everywhere."

[shadowfirebird]

I don't think we should take anything the current software does as
evidence of intent in the final design; this is a very, very early
release.

I see your point, but if an intrusion has got to the point where it
can dig stuff out of RAM, you have more problems than a Diaspora
vulnerability, surely? I'm assuming that the eventual system will
cache a private key in memory -- but almost certainly not your
regular, email one. Regular Diaspora use shouldn't effect your GPG
use.

On Sep 21, 6:27 pm, Bryce Lynch <virtualad...@gmail.com> wrote:

[Bryce Lynch]

On Tue, Sep 21, 2010 at 17:00, shadowfirebird <shadowf...@gmail.com> wrote:

> I see your point, but if an intrusion has got to the point where it
> can dig stuff out of RAM, you have more problems than a Diaspora
> vulnerability, surely?  I'm assuming that the eventual system will

Mostly correct. In a shared hosting situation (which Diaspora pods
likely will be: one host (virtual or not) containing the Diaspora
instances of multiple people) the stored information of multiple
people would be at risk. Local root compromise of web hosting
machines is not unknown.

I wish I knew more about Rails so that my next statement would be more
correct, but I do not. So, if I'm wrong or simply misrepresenting
things I apologize in advance, and ask to be corrected: Given that
Rails needs to run as root to be able to open port 80/TCP and doesn't
normally drop its privileges (please correct me if I'm wrong here) a
misconfiguration might give an intruder just that sort of access.

> cache a private key in memory -- but almost certainly not your
> regular, email one.  Regular Diaspora use shouldn't effect your GPG
> use.

I sincerely hope that people will not use the private key they use for
their e-mail and personal files with Diaspora.

[Jos Yule]

While your worries are valid, isn't the point of Diaspora to reduce the "one massive node" issue? Ie. sure YOU could loose your PGP/GPG key, but at most X number of other users would be compromised too, HOWEVER, if Facebook is compromised, a whole lot MORE people would have info in danger.

Not that i'd want to loose my GPG/PGP key and have an attacker have that info, but there would also have to be some way to "easily" (hahaha) generate a new key and inform interested nodes that your key has been compromised etc etc.

Anyway, i think, while this is important to an individual user (which is what Diaspora is targeted at), the risk probably isn't as great as all your medical records or any other monolithic entity which has tonnes of your personal info...

my two cents.
j

[shadowfirebird]

> Not that i'd want to loose my GPG/PGP key and have an attacker have that info, but there would also have to be some way to "easily" (hahaha) generate a new key and inform interested nodes that your key has been compromised etc etc.
>

I'd go further than that. There has to be a way to ensure my data is
safe in the first place.

There are other products, not really social networks, that manage this
perfectly well. (Retroshare, to pick one at random.)

[Bryce Lynch]

On Wed, Sep 22, 2010 at 16:13, Jos Yule <hyak...@gmail.com> wrote:
> While your worries are valid, isn't the point of Diaspora to reduce the "one massive node" issue? Ie. sure YOU could loose your
> PGP/GPG key, but at most X number of other users would be compromised too, HOWEVER, if Facebook is compromised, a
> whole lot MORE people would have info in danger.

It seems reasonable to state that, once Diaspora is stable, Diaspora
hosts will start appearing (in fact, they already have for the
purposes of testing) so that people will not have to wrangle their own
instances of the software. For what it is worth, your example is what
I was referring to, i.e., small clusters of people being compromised
rather than large numbers at a time. The aftershocks of a single
Diaspora seed being cracked are much more immediate - larger groups,
more information to sort through; smaller groups, much less
information to sort through, leading to more immediate consequences.

> Not that i'd want to loose my GPG/PGP key and have an attacker have that info, but there would also have to be some way to
> "easily" (hahaha) generate a new key and inform interested nodes that your key has been compromised etc etc.

To say nothing of re-encrypting everything on the back end. Still,
generating a PGP key is a fairly simple operation.

> Anyway, i think, while this is important to an individual user (which is what Diaspora is targeted at), the risk probably isn't as
> great as all your medical records or any other monolithic entity which has tonnes of your personal info...

I agree. My concern lies in people wishing to communicate with others
of a like mind in such a manner that their interests and content are
compartmentalized, which is one of Diaspora's design goals.
Compromise of that compartmentalization can wreak havoc with one's
personal life. For example, a small group of people discussing
corruption at the workplace or suffering from a chronic affliction
might find other prospects in their lives adversely affected if word
got out because their Diaspora hosts were compromised. I think that
one should be able to "find the others" without having to go back to
meeting in the back rooms of restaurants just to be able to say "Wow,
it's good to meet someone else like me" (assuming no one getting hurt,
no rights being violated, and the like).

While I appreciate what you say, why did you bring the subjects of
medical records and presumably things of similar importance into the
discussion of software which is not intended for the management of
such things? I may have missed a post or two, but I do not remember
their being mentioned elsewhere.

[Michiel de Jong]

Hi, 

Just wanted to share this in case anyone has any comments. 

Cheers! 

Michiel.

Pretty Good Diaspora

====================

Context.

^^^^^^^^

This document is the product of an informal workshop organized 24-26 September 2010 in Navalcarnero, Spain, by a couple of friends who call themselves Unhosted. We've only just started, but aim to make the world a better place by promoting 'unhosted' solutions, like Diaspora*, FreedomBox, GNU Social P2P, etcetera. Please follow us on http://www.twitter.com/unhosted in case we have interesting things to say in the future!

Background.

^^^^^^^^^^^

The Diaspora* team initially set out to build a pgp-based distributed social network. Later, due to implementation problems, they switched to not encrypting the content, but instead using SSL for communication between pods. This however has the drawback that it make Diaspora*'s security depend entirely on the security of the pod that runs your seed. This situation was discussed (at length) on the diaspora-dev and diaspora-discuss mailing lists. The conclusion was that the Diaspora* team would like to switch back to using PGP. On the other hand, they don't believe (like many others on the list) that end-to-end encryption (e2ee) would be feasible with the current state of predominant installed (browser) technology. This workshop tries to investigates ways for Diaspora* to use PGP. Halfway the workshop now, our conclusions are below, and I must say they're different from what we thought when we started yesterday.

Options.

^^^^^^^^

Options are:

A* - not bringing back PGP, and sticking with the current unencrypted storage, and inter-pod communication over SSL.

B - using PGP for inter-pod communication only. Two options to implement this:

  B1* - the private key is stored unencrypted on the server

B2* - communication only takes place while the recipient is logged in

C - using PGP to encrypt stored data 

C1** - server-side: while the user is logged in, the private key is in memory

C2*** - client-side: data is already encrypted when it reached the server/pod.

The number of stars here refer to how secure we think each of these options would be (roughly):

*) gives security against attacks from outside all pods

**) also gives security against attacks with read access to any pod's disk (but not its memory)

***) security against any attack (that we can think of) with read/write access to any pod.

e2ee or no PGP at all.

^^^^^^^^^^^^^^^^^^^^^^

This morning we concluded that unless you use end-to-end encryption (encryption in the browser or client), there is not much point in using any PGP at all. Because as was already brought up several times on the Diaspora* mailing lists, even if a pod stores the data encrypted, an attacker could put a keylogger on the login page, phish the passwords, and get to the data anyway. There are special cases, like where an attacker has read-access to the disk but not write-access, but in general, you would be paying the full price for half a solution. If we only distinguish 'trusted' and 'untrusted' hosts, then it's e2ee or nothing.

e2ee is not for everyone yet.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Right now, the general internet landscape is not ready for e2ee. Power users (mainly developers and open source enthusiasts) already use PGP, most of us probably more out of idealism than out of practical considerations, because it still poses a usability hurdle in most cases. The only exception would mainly be applications for phones and tablets, where e2ee could be feasible already nowadays for specific apps, without any penalty in usability.

The closest thing to e2ee with general purpose clients (browsers) is the java applet that hushmail.com uses, but even they don't use that by default, because not everybody has java installed, etcetera.

Also, using PGP encryption has the negative effect that it makes password recovery inherently impossible. A normal user usually relies on being able to reset his password if he forgets it. OpenId tries to change this situation, but for now, it's the current situation for most normal users.

And lastly, if you host your seed in your home, then that host is equally trusted as the client, so it makes no sense to hide your data from it. There is no trust barrier between the client and the pod in this case.

mixing e2ee pods and 'dodgy' pods.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For these reasons, we propose for Diaspora to *support* PGP (be PGP-ready), but not use it by default. Imagine a web of Diaspora nodes, some of which want to use PGP, and some of which don't. For this to work, all we need to fix is the inter-pod communication protocol. The implementation of each pod is up to the pod, and the users that choose to have their seed on it.

There are then 4 situations at the moment that a message is sent between two pods:

- dodgyPod to dodgyPod: the current situation. Sent over an SSL channel, with a MagicSig envelope for identifying the sender.

- dodgyPod to PGPod: since the data comes from a dodgyPod anyway, there is no need to be too fussy about it. The dodgyPod will send the current way, without using any PGP, and the PGPod accepts it, just like it would accept data that comes aggregated from outside Diaspora.

- PGPod to dodgyPod: this is the case we need to talk about. see below.

- PGPod to PGPod: the ideal case. fully encrypted throughout the client->pod->pod->client path. The client encrypts the data for all recipients of the aspect that the data belongs to, and posts it encrypted through the sender's pod, it stays encrypted while stored, and through the receiver's pod, until it reaches the client of each receiver, where it is finally decrypted. A PGPod never gets to see a user's private key, and never decrypts data that passes through it (except maybe for discovery and/or user search, if enabled).

making dodgyPods PGP-ready.

^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is the step that needs work. As we understand from the code, every pod already has a (private, public) key pair for each seed, that it uses for verification. We need to extend Diaspora's protocol, to make it capable of receiving PGP-encrypted messages, and decrypting them using the same keys. This way, a PGPod can relay an encrypted message from a client to a dodgyPod without ever opening it, and without ever being in contact with any private keys. The rest of this workshop will concentrate on adding support for receiving PGP encrypted salmons to the methods in lib/diaspora/user/receiving.rb. Even though at present this functionality will not be used, it is important to add it to the protocol now, so that Diaspora is "PGP ready". Then we can use Diaspora on a 'high security' pod, but still interoperate with our (less geeky) friends who may be on a 'standard security' pod.

[Neophyte Representative]

Thank you, Michiel and the Unhosted group, for attempting to think
deeply about the architecture of a social network.

Your presentation, however, contains the flaw that is going to kill
any solution. Its apparent precision lends a air of certainty to a
technology that can't solve the social problem.

"There are then 4 situations at the moment that a message is sent

between two pods: ..." Once you've limited your world view to "a
message is sent between two pods", you've given the naive an
opportunity to believe that a message between two seeds is adequately
covered.

Here's the cases you should include so the naive understand they, the
naive, are the solution to these situations, not the technology:
dodgyseed on any pod
badseed on any pod

By dodgyseed, I refer to a person who is not sufficiently cognizant of
what types of people exist in this world. An example is someone who
is so eager to prove his/her popularity s/he allows anyone to become
his/her friend.

The badseed is the person who takes advantage of this mentality to
become a friend and begin social engineering to obtain information
that is valuable to the badseed for whatever gain the badseed can
achieve with the information.

Remember all members of an aspect get to see the data provided in
clear text; no matter how it has been encoded along its path from
sender to receiver (and by that I mean from person A to person B, not
just from pod A to pod B).

All discussions of the challenges of the implementations of a privacy
benign social network should include discussions of these cases so
everyone can be pointed to the ample warnings about this nefarious use
of best practices.

[Singpolyma]

On Sep 21, 7:46 am, Jakob Keres <jakob.ke...@googlemail.com> wrote:
> And what are you going to do with you private key?
>
> * Store it on the server? Better not.
>
> * Encrypt it with a short phrase and store on the server? Then the
> encryption is as strong as your phrase. Normally not too much.

You will have these problems no matter what crypto you use :) I
believe right now it's not using e2e at all, but just s2s encryption,
which means you have to trust the servers/storage anyway! :)

[Singpolyma]

On Sep 21, 7:24 am, Michiel de Jong <dejong.mich...@gmail.com> wrote:
> I can't find the exact references from the Diaspora team now, but off the
> top of my head, at the beginning, PGP was one of their main points about how
> they were going to build Diaspora. Then at some point, they dropped PGP, if
> I understood and remember correctly, because of compatibility issues. I
> would interpret that as "if we drop PGP, then Diaspora can run on a windows
> server" (correct me if I'm wrong and also anybody who knows the original
> ref., please add it here).

Anyone interested in OpenPGP in pure ruby may be interested in the
work I've started at <http://github.com/singpolyma/openpgp>

[Bryce Lynch]

On Mon, Oct 4, 2010 at 11:00, Singpolyma <singp...@singpolyma.net> wrote:

> Anyone interested in OpenPGP in pure ruby may be interested in the
> work I've started at <http://github.com/singpolyma/openpgp>

Definitely. *hits the link..*

I have some ideas about how content could be encrypted in a Diaspora
seed (and the other seeds it is pushed to) that I would like to post
here, if no one would mind. I e-mailed the core developers last week
but have not heard back.

Not knowing how the core developers had originally envisioned how the
functionality would work, I do not know if this would be a waste of
bandwidth or not.

[mike]

Ive tried emailing them too...havent got a reply yet.

Anyone get a direct reply from them? Ive tried multiple resources but
nothing yet....

On Oct 4, 10:02 am, Bryce Lynch <virtualad...@gmail.com> wrote:

[Michiel de Jong]

Responses I remember about pgp and e2ee most clearly are two in particular. 1) - on the 'Re: GPG' thread in diaspora-dev -

Hi Michiel,

We definitely preferred PGP, for a variety of reasons, but the implementation issues were bad enough that we were driven to switch.  It's great to see that people want to help, let's talk about what we can do to switch back.   I think the GPG method of storing keys, disk level config folders, will be basically impossible to scale, making it necessary to write bindings for libgcrypt, but I could be wrong.

Best,

Raphael

- then some more technical conversation on that same thread, and then, 

2) on the 'Design: End-to-end encryption?' thread (also on diaspora-dev) -

Our view on this is that end-to-end encryption, while it would be cool, isn't practical, and isn't possible as a result.

In order for such a system to work, every user would have to have a private key that they kept with them at all times.  If they keep it on a computer of their own, it is susceptible to loss and only usable from home.  The tools that might make it practical for non-technical users just don't exist yet, and nobody knows how to build them.

That said, every Diaspora user created right now has his own encryption key.  We'd like for it to be possible for that rare technical user to hold his private key himself, and render his data unreadable by his server, without creating inconvenience for those he communicates with.

Open to suggestions as always,

Raphael Sofaer

For me, these responses told me more or less what I needed to know from the Diaspora four. 

I started this thread a few weeks back because i felt that what the world needs most right now is Diaspora, and what Diaspora needs most right now is PGP. After digging into the subject, i came to the conclusion (from reading what people smarter than me were writing on these same lists) that if you say pgp, you say e2ee, and if you say e2ee, then the Diaspora four (Raphael) are absolutely right in saying 'The tools that might make it practical for non-technical users just don't exist yet'. So for me the chain of dependency is:

 World-a-better-place -> Diaspora* (and similar projects) -> PGP (or any encryption that allows for using untrusted hosts) -> e2ee -> e2ee-tools. 

Therefore I am now mainly thinking and studying why these tools don't exist yet (there must be a reason for that that I don't understand yet), and then try to tackle that, program it, and publish a mozilla and/or chrome and/or explorer plugin, that would then allow a future version of Diaspora* (and similar projects) to have e2ee. 

Cheers,

Michiel

http://www.twitter.com/unhosted

[Bryce Lynch]

On Tue, Oct 5, 2010 at 05:37, Michiel de Jong <dejong....@gmail.com> wrote:

>> Our view on this is that end-to-end encryption, while it would be cool,
>> isn't practical, and isn't possible as a result.

From what I can tell, setting up SSL for Ruby on Rails would not be
terribly difficult. This jumped out at me:
http://www.sslshopper.com/article-ruby-on-rails-ssl-configuration.html

Someone setting up Diaspora and setting up the basic configuration
could set the option "Use SSL". On the back end, Diaspora generates a
SSL certificate on the back end that uniquely identifies that seed
("Joe Blogg's Diaspora Seed, diaspora.joebloggs.com") that is used to
encrypt and decrypt client traffic to and from the seed (i.e., with a
web browser) as well as update traffic (pushes to other Diaspora seeds
that also support SSL). When Joe logs into his Diaspora seed to post
updates and check out what everyone else is doing, he connects to
https://diaspora.joebloggs.com/ with his browser. It might also be
possible to use the web of everyone the user has friended as a weak
web of trust (Joe has sixteen friends who make use of his seed's SSL
support). Functionality to strengthen the web of trust might be
possible (friends of Joe who have verified his identity, grew up with
him, what have you set a trust option in their profile that ranks how
much they trust him, like GnuPG's web of trust ("I trust this
user..."))

I can see how providers who offer shared Rails hosting might not
support SSL, and thus would torpedo such a function. I can also see
how people who don't know what that function does and thus do not want
to mess with it for fear of breaking things would also not want to
turn it on.

>> In order for such a system to work, every user would have to have a
>> private key that they kept with them at all times.  If they keep it on a

I find that interesting in light of how HTTPS operates. Do they mean
setting up a certificate in the browser on one machine to help
authenticate the user logging into their seed, or do they mean just
using HTTPS to log in but not authenticating with more than
credentials (the way one can with Gmail, say). It seems to imply the
former.

>>  The tools that might make it practical for non-technical users just don't
>> exist yet, and nobody knows how to build them.

Hmmm...

>> That said, every Diaspora user created right now has his own encryption
>> key.  We'd like for it to be possible for that rare technical user to hold
>> his private key himself, and render his data unreadable by his server,
>> without creating inconvenience for those he communicates with.

I am definitely going to write something up and post it for review.
Maybe I have a naive concept of how things work on the back end
(entirely possible) but they make it sound as if you need to carry
crypto keys around with you on a fob and this is not necessarily the
case.

Granted, the project would also need to sit down and define a threat
model: how sensitive should users' content be considered on the
baseline, what kinds of data would be encrypted (only posts, only
updates, everything, only images, some user-defined combination). How
big a threat should the machine hosting the seed be considered (would
it be unlikely that an admin would go poking around inside the
instance of MongoDB? What about a cracker on the outside?)

For how long would an encrypted chunk of data be accessible on the
user's seed? On someone elses?

Should setting up crypto support in one's seed require friends to
toggle their crypto support to have access to a particular aspect?

> PGP. After digging into the subject, i came to the conclusion (from reading
> what people smarter than me were writing on these same lists) that if you

Time to go on a subscription spree, I think...

> Therefore I am now mainly thinking and studying why these tools don't exist
> yet (there must be a reason for that that I don't understand yet), and then

Would you mind taking that discussion off list for a bit? I have a
few questions that I would like to ask you which would be outside of
the scope of this particular mailing list.

[Michiel de Jong]

On Tue, Oct 5, 2010 at 3:43 PM, Bryce Lynch <virtua...@gmail.com> wrote:

>> In order for such a system to work, every user would have to have a

>> private key that they kept with them at all times.  If they keep it on a

I find that interesting in light of how HTTPS operates.  Do they mean
setting up a certificate in the browser on one machine to help
authenticate the user logging into their seed, or do they mean just
using HTTPS to log in but not authenticating with more than
credentials (the way one can with Gmail, say).  It seems to imply the
former.

Yeah, sorry, i didn't explain that very clearly. it's not about SLL/HTTPS, it's about doing something *more* than that. Diaspora already uses ssl in pod-to-pod communication, and hosting the web-interface on https instead of http would make all transport secure, and wouldn't require the user to keep a private key with him. in addition, there is interesting talk about using WebId for making yourself know to a pod or potential friend.

the only thing that's missing is making the third-party hoster of the pod unable to see what you are talking about with your friends. one of the reasons to make Diaspora was to stop the facebook people from looking at what we do with our friends, so that's why the idea of not trusting your diaspora-hosting company with your (unencrypted) data has been given so much importance - a lot has been written about this on the diaspora-dev mailing list. Most important conclusions have been collected into http://github.com/diaspora/diaspora/wiki/Security-Architecture-Proposal.

Anyway, most of this was discussed on diaspora-dev and not diaspora-discuss, so have a look there.

Would you mind taking that discussion off list for a bit?  I have a few questions that I would like to ask you which would be outside of the scope of this particular mailing list.

 

not at all! i'll shoot you a separate email.

cheers,

Michiel

[Bryce Lynch]

On Tue, Oct 5, 2010 at 17:34, Michiel de Jong <dejong....@gmail.com> wrote:

> it's about doing something *more* than that. Diaspora already uses ssl in
> pod-to-pod communication, and hosting the web-interface on https instead of

...okay. That is clear.

> the only thing that's missing is making the third-party hoster of the pod
> unable to see what you are talking about with your friends. one of the

This is what I was pondering.

As I understand it, every piece of content (post, update, picture, et
cetera) is stored as a separate document in a MongoDB database. Also,
every piece of content ('post' for simplicity, even though the word
has slightly incorrect implications given the number of different
things that can be posted to a Diaspora seed) associated with a
particular aspect of Alice's Diaspora seed gets pushed to the seeds of
Bob, Carol, and Dave, who are friends of a particular aspect of Alice.

What I had in mind was this: whenever Alice makes a post to a
not-public aspect of her seed, that post is encrypted with her seed's
private key and the public keys of Bob, Carol, and Dave (who are
friends of that aspect) before it's stored in MongoDB. Alice's seed
then pushes that post to the seeds of Bob, Carol, and Dave. Alice's
private key is unlocked when she logs into her seed, which allows this
to happen, and when her session ends (ideally whenever she closes her
browser but more like a day, give or take) her cached private key is
flush from the server's RAM. The Diaspora seeds of Bob, Carol, and
Dave receive the encrypted updates, store them in their MongoDB
databases, and send back "Message received" to Alice's seed to confirm
the update.

When Bob logs into his Diaspora seed, his passphrase also unlocks his
private key. Bob's Diaspora seed sees the new posts from Alice's
aspect in his instance of MongoDB and decrypts them into memory using
his cached private key. Those new posts are then displayed on Bob's
frontpage. If Bob wants to post a reply to one of Alice's not-public
posts, his seed encrypts the update with a) his private key, and b)
Alice's public key before being stored in the database. Bob's seed
then transmits the update to Alice's seed, which receives it into a
queue. Maybe Alice is still logged in so it gets decrypted, added to
the post, and re-encrypted with Alice's private key and the public
keys of Bob, Carol, and Dave. All of the other seeds friended by that
aspect then receive those encrypted updates, and are added to the
MongoDB entries corresponding to that update.

Something else I was pondering was the case of Alice unfriending Dave
from her semi-private aspect. Alice unfriends Dave, removing him from
all aspects of her Diaspora seed. Alice's seed removes Dave's seed
from the list of seeds to push updates to. Alice's seed then
generates a message to Dave's seed saying "Dave is no longer my
friend. Delete all stored posts from your database from Alice,"
encrypts it with Dave's public key, and sends the encrypted message to
Dave's seed, which (if it has not been modified by dave) decrypts it
the next time he logs in, looks at the message, and deletes those
encrypted posts from Alice's seed from the database. Dave's seed
generates an "All clear" message to Alice's seed, encrypts it to her
seed's private key, and sends it. This would provide the same
functionality as, say, unfriending someone on Livejournal, which then
prevents that someone from seeing all of the friends-locked content
for that account.

> into http://github.com/diaspora/diaspora/wiki/Security-Architecture-Proposal.
> Anyway, most of this was discussed on diaspora-dev and not diaspora-discuss,
> so have a look there.

I will most certainly do so. Thank you very much.

[WTFologist]

this is just an idea that might work for most people.

https://www.organicdesign.co.nz/Face_base_authentication_proxy

On Oct 6, 12:30 pm, Bryce Lynch <virtualad...@gmail.com> wrote:

[shadowfirebird]

unfortunately, most people are crap at recognising faces - and, worse
still, memory of these things can be fooled: manipulated, even.

[Michiel de Jong]

On Thu, Oct 14, 2010 at 2:15 AM, WTFologist <j.b....@gmail.com> wrote:

this is just an idea that might work for most people.

https://www.organicdesign.co.nz/Face_base_authentication_proxy

i really like this thought. this reaction is mainly a brainstorm:

if i understand correctly, the sequence of faces takes on the role of a password. the big advantages i see of this are:

- probably many people (especially non-geeks, maybe) will be better at remembering a sequence of faces than a sequence of alphanumerical characters (password). especially if you take into account the vast difference in alphabet size.

- it will be almost impossible to accidentally leak it, since there are no keystrokes to record, and a user can't save it in any medium (piece of paper, usb stick, laptop) that then gets stolen.

disadvantages:

- need to implement it, maybe run into unexpected vulnerabilities that need fixing - this is a process. alphanumerical passwords are ready to use already.

- as i understand it, to present the 6 6x6 'quizes', the server needs to know the unencrypted correct answer. or did i miss something? if that is so, then that server can get hacked, which takes away the second advantage mentioned earlier [but we may come up with a way to combine a usb stick ('something you have') with a sequence of faces ('something you know') to overcome this].

i think unlocking the encrypted private key should be client-side. then whether this is password, sequence of faces (something you know), biometrics (something you are), and/or hardware (something you have), is an important question of usability and security. but different people might choose different methods to unlock their private key, and even the same person might use a different login method on his phone than in an internet cafe, etcetera.

Me and other people involved in @unhosted will be studying the concept of Ajax Payload Encryption (we're thinking of maybe using an ape for the logo ;), which will probably either be a local proxy or a browser plugin. We're thinking one user should probably have 3 or 4 keys instead of just one, which are his non-linked online identities/nicknames/aspects, and will probably also have different levels of security, depending on what the nick is used for, and the device you're on. In all cases the user should unlock his private key with some password-mechanism, and we'll definitely examine whether we could use some variation of a sequence of faces as one of the options.

I particularly liked reading the analysis you start out with:

The essential problem with mass adoption of GPG is that there is no way to securely store the private key and that storing it on a USB thumb drive is also undesirable, as it can be lost and compromised. Furthermore, once a person has lost or forgotten his private key, there is no way to recover it, rendering data encrypted with it forevermore inaccessible.

i would say, if you have a good password-system, then storing the private key as such is not the problem, it's 'storing' whichever credentials unlock that private key. this can be a combination of something you know, something you are, and something you have. 

if you store your private GPG key encrypted with you fingerprint, and have a backup of it encrypted with your toe print (or whatever), then the only way to lose it would be if you lose both a finger and a toe at the same time. that seems to solve both problems (stealing and forgetting) in a reasonable way.

also, i'm thinking, a lot of people leave a copy of their house key at a friend's house. if you break up your key into a few parts, and leave each part in the custody of one of your friends (especially if they are from unrelated contexts), then as long as you remember which friends have your backup, you could ask them to help you out if you forget your key. this could probably be automated - if you hit 'i forgot my password', then a message is sent to each recovery-friend, and if all of them confirm you as a friend by some external route (a voice call for instance would be pretty failsafe), then you could do some sort of distributed friends-trust-based password recovery.

If we get e2ee working this way (which will not be overnight, but we might get somewhere in, say, a year), then we will definitely make an effort to get support for it into Diaspora, so as to help improve this great project.

Cheers!

Michiel

http://www.twitter.com/unhosted