DIscussion of "message passing in Diaspora"
shadowfirebird
enough to post a quick summary of how the message passing currently
works: http://github.com/diaspora/diaspora/wiki/Message-passing-in-Diaspora
My initial thoughts:
1) I'm not finding this document easy to understand, but it's clear
this is a "what" rather than a "why". I don't want to sound bossy,
but in my opinion the team need to start actually designing how they
want message passing to work and why pretty soon. You need to design
this sort of stuff before you start coding. Maybe we can help with
this, but you guys really have to take the lead, because design by
committee sucks, and here on the dev group we are like a giant
committee.
2) The encryption is happening on-the-fly. You've already said you
want to move to an encrypted data store. So it sounds like a rethink
might be in order. Presumably we don't want do decrypt the data in
the database so we can encrypt it to send it.
3) Not sure why we're using Webfinger? Are we saying that an email
address is a good way to identify a person? Because I'm not a
security expert, but I'm willing to bet that webfinger can be spoofed
just like an email address can.
PeterH
...
> want to move to an encrypted data store. So it sounds like a rethink
> might be in order. Presumably we don't want do decrypt the data in
> the database so we can encrypt it to send it.
>
decrypt. If encrypting for storage, we need to use a key we can
decrypt.
> 3) Not sure why we're using Webfinger? Are we saying that an email
> address is a good way to identify a person? Because I'm not a
> security expert, but I'm willing to bet that webfinger can be spoofed
> just like an email address can.
compromise the server providing the webfinger service. A server is
looked up by the user ID and asked for info about a specific person.
The protocol may not guarantee that the person at a given webfinger
address is who they say they are, but someone else should not be able
to hijack an address. This would have to be paired with a mechanism
to validate that the person providing the webfinger address is the
owner. OpenID was mentioned early on.
Michael Meer
you're a lot talkin about security and encryption. But before you start
a discussion about which tools should be used we should decide what's
the concept behind.
First the diaspora user have to trust the hoster of the seeds(this might
be the user himself or a webhoster of his choice). Cause the hoster have
physical access to the machine and can modify the opensource code
(example to fetch private keys or passwords).
Or we have to sign and encrypt every single message we send by the user
(this includes the complex key handling like PGP/GPG do). So that the
hoster sees only encrypted traffic.
So the questions are:
Do we want to have an encryption from seed to seed?
Or do we wanna have an end to end encryption between the users
(Browser2Browser)?
Wich kind of traffic should be encrypted?
Were are the private keys stored?
- Inside of the seed at the hoster?
- Or should every User handle ist own keys (and has
to type everytime (on read as well as write a message)
his passwords).
When we have a decision, then we can search for tools wich fit to the
requirements...
Do the initiators of this project have some docs? I exepct that they had
already some discussions about this in the past.
I have'nt found something similar. When it's already published, so
please give me a hint.
At least I would prefer a poll than a wild discussion about what is
wanted...
I just want to avoid to make some work twice(or more)...
kind regards
Micha
On 22.09.2010 05:50, PeterH wrote:
> On Sep 21, 1:46 pm, shadowfirebird<shadowfireb...@gmail.com> wrote:
> ...
>> 2) The encryption is happening on-the-fly. You've already said you
>> want to move to an encrypted data store. So it sounds like a rethink
....
>
>> 3) Not sure why we're using Webfinger? Are we saying that an email
>> address is a good way to identify a person? Because I'm not a
....
Michael Meer
kind regards
Micha
> On Sep 21, 1:46 pm, shadowfirebird<shadowfireb...@gmail.com> wrote:
> ...
>> 2) The encryption is happening on-the-fly. You've already said you
>> want to move to an encrypted data store. So it sounds like a rethink
<snip>....
>> 3) Not sure why we're using Webfinger? Are we saying that an email
>> address is a good way to identify a person? Because I'm not a
<snip>....
Jakob Keres
> Hi,
>
> you're a lot talkin about security and encryption. But before you start
> a discussion about which tools should be used we should decide what's
> the concept behind.
>
> First the diaspora user have to trust the hoster of the seeds(this might
> be the user himself or a webhoster of his choice). Cause the hoster have
> physical access to the machine and can modify the opensource code
> (example to fetch private keys or passwords).
>
> Or we have to sign and encrypt every single message we send by the user
> (this includes the complex key handling like PGP/GPG do). So that the
> hoster sees only encrypted traffic.
If we want a web app, and I think it should be a web app, we have to
trust out provider, because this is where we get the application from
and an evil provider always would be able to spoof our password (if we
don't check the Java Script code everytime we open a page). Furthermore,
where to store the private key is a problem, otherwise the encryption
never will be strong. (Nobody will remember a 256 bit key or keep it
carefully on a flash drive.)
This why I'd rather prefer an email-like architecture like this:
User
|
Client (Webfronend, Thunbderbird, whatever, ...) which does encryption
and stores the private key
|
Server which provides storage space and does passing of encrypted and
signed message
shadowfirebird
> When encrypting to send, we need to encrypt to a key the recipient can
> decrypt. If encrypting for storage, we need to use a key we can
> decrypt.
recipients, store it like that, and send it as is.
shadowfirebird
example) can be stolen. On the other hand, if someone stole my gmail
address, they still would not be able to sign messages with my private
key - so webfinger is still not as secure as a keypair.
Not saying we should definitely care about that. I suspect we should,
though...
Also, why not just send all the information in the POST? Why bother
with webfinger at all?
Michael Meer
That kind of solution needs some kind of add-in/plugin in the browsers
(require this a development for the most popular browser?).
That's not what diaspora actually is. Just for now it's a server based
solution.
I by myself don't like the idea to put that functionality into the
browser. Has pro's and con's...
???
Micha
Jakob Keres
>> User
>> |
>> Client (Webfronend, Thunbderbird, whatever, ...) which does encryption
>> and stores the private key
>> |
>> Server which provides storage space and does passing of encrypted and
>> signed message
>
> That kind of solution needs some kind of add-in/plugin in the browsers
> (require this a development for the most popular browser?).
> That's not what diaspora actually is. Just for now it's a server based
> solution.
>
> I by myself don't like the idea to put that functionality into the
> browser. Has pro's and con's...
I think you misunderstood me (or I misunderstood you). There's no need
for plugins (unless you want it). I also wouldn't like this idea.
User
|
Diaspora-Client
* as web-application (lightweight, in Rails, PHP, ...) to use with
normal browser
* iPhone-App, Android
* Firefox-Plugin (without web-app)
* (your idea)
|
Diaspora-Server (storage, message passing, search, p2p, key-server, ...)
Braedon Vickers
Even if you used email, it would just push the encryption problem from a browser plugin to a client plugin(most clients, for example Thunderbird that you mentioned, do not have inbuilt GPG support), or from the diaspora host to the webmail host.
Braedon
shadowfirebird
someone else is hosting your seed.
In order for your data to be secure, it would have to be stored
encrypted. Now, there's no point in doing that if the key is stored
on the server, because whoever hosts the app could just decrypt it
again.
So either we encrypt locally -- some sort of client-side applet? Or
we say that everyone must run Diaspora locally.
Like it or not, we have to consider the client-server model.
On Sep 22, 11:57 am, Braedon Vickers <braedon.vick...@gmail.com>
wrote:
> distributed web based social networking site, not a private mailing list
> app. Usage and data types are vastly different.
>
> Even if you used email, it would just push the encryption problem from a
> browser plugin to a client plugin(most clients, for example Thunderbird that
> you mentioned, do not have inbuilt GPG support), or from the diaspora host
> to the webmail host.
>
> Braedon
>
Braedon Vickers
andy baxter
> Using an email system would change the entire project. The project is
> for a distributed web based social networking site, not a private
> mailing list app. Usage and data types are vastly different.
>
> Even if you used email, it would just push the encryption problem from
> a browser plugin to a client plugin(most clients, for example
> Thunderbird that you mentioned, do not have inbuilt GPG support), or
> from the diaspora host to the webmail host.
He said email-like, not that we should actually use the email system.
I.e. you separate the message storage and passing part of the system
from the user interface. The kind of data that was passed, and the way
the network of servers was connected wouldn't have to be the same as
email because it would be designed to suit a different purpose (social
networking). If the messages were stored encrypted on the server, then
you would only need to trust the client, not the server.
Something I like about separating the different parts of the system in
this way is it allows the system to be used in a variety of different
ways that would suit different people. If security is very important to
you, you can run a local client and either run your own server or use a
larger server with better bandwidth. If you aren't so good with
computers, and are willing to trust a web client run by someone else,
then you can do that. Note that the web client could be run by different
people to the message passing server. E.g. if you are part of a small
organisation or other group of people you could set up a web client for
them to use, but still benefit from the better bandwidth of a larger
server in case one of their posts starts taking a lot of hits.
Braedon Vickers
Even with an 'email-like' system, the usage is still vastly different to a web app, and you still have the same problems with standalone or plugin clients as already expanded on elsewhere.
I am all for a flexible system, but not at the expense of the general user. It is all well and good taking about the uber security you would like, but first we must define what we need for the general user. If we can accommodate both, great.
Also, if no significant amount of people use the uber security options, then what is the point of having them? Your data is only as secure as the systems of your friends you push it to. If you have data that you need extra security for, but have few or no friends with satisfactory security levels on their seeds, then there is little or no point in having that data in Diaspora, and thus little or no point in having the extra security and the hassle that looks like it will come with it on Diaspora.
Braedon
andy baxter
> Granted, but he also mentioned Thunderbird directly.
>
> Even with an 'email-like' system, the usage is still vastly different
> to a web app, and you still have the same problems with standalone or
> plugin clients as already expanded on elsewhere.
What do you mean by 'the usage is still vastly different to a web app'?
What I was trying to describe is a system where you have a server that
you communicate with with a given protocol, that handles all the message
storage and delivery, and a variety of possible user interfaces
(clients) to that server. One of these could exactly be a 'web app',
except that instead of having its own database it would pass messages
(which could contain any kind of data you like) to the server using the
protocol.
>
> I am all for a flexible system, but not at the expense of the general
> user. It is all well and good taking about the uber security you would
> like, but first we must define what we need for the general user. If
> we can accommodate both, great.
>
I think this is putting things the wrong way round. People have a right
to expect that their personal communications won't be spied on or
otherwise abused, and a system like diaspora should protect that right
as far as possible. If we need to compromise from that ideal because of
technical or other constraints, then so be it, but the point is to try
and make it as good as possible and work down from there if necessary.
> Also, if no significant amount of people use the uber security
> options, then what is the point of having them? Your data is only as
> secure as the systems of your friends you push it to. If you have data
> that you need extra security for, but have few or no friends with
> satisfactory security levels on their seeds, then there is little or
> no point in having that data in Diaspora, and thus little or no point
> in having the extra security and the hassle that looks like it will
> come with it on Diaspora.
The point for me would be that although the people using diaspora might
have a wide range of needs, expectations, and ways of using it, they
could still all be connected through the same system, the same as with
email today.
Braedon Vickers
Braedon
Dan
I think encryption should be left for the later version. Let's
concentrate on an app that works as expected.
Anyone concerned about security should host his own seed.
Best regards,
Dan
shadowfirebird
won't be "privacy aware".
And, we need to design the core of the app before we do much more
coding, or we'll just end up wasting our effort, and getting an
inferior app into the bargain.
NeoPhyte_Rep
> Do the initiators of this project have some docs?
here:
http://github.com/diaspora/diaspora/wiki
You should probably also follow the links in the bulleted list at the
bottom of:
http://www.joindiaspora.com/2010/09/15/developer-release.html
- Github
- Tracker
- Test Status
- Roadmap & Wishlist
- Development Mailing List
- Discuss Mailing List
and the links in:
http://github.com/maco/diaspora#readme
Wavesonics
even universally liked, and its not even complete. It's just (IMO) a
neat idea for solving the "I can't trust the seed I'm hosted on"
problem as WELL as the "I can't trust the seed my friends are on"
problem.
------------------------------
So in this solution, everything would be stored encrypted on the
seeds. And the only keys stored on the seed would be your friends
public keys for sending data to them.
Then our web app would be much more client then server. In the Mozilla
talk (i think that's where) the developers talked about how they were
having issues with Ruby in the server centric model, and they were
thinking about moving all rendering and logic to the client (JS) some
time in the future.
So using this as the idea for the webapp, all the data is sent to the
client still encrypted. Then the client retrieves it's private key
from a "Key Authority" and decrypts and renders all it's data.
Now the "Key Authority" is the lynchpin here and obviously fraught
with problems. For non-techy users, a default central "Key Authority"
would be required to seamlessly store their private keys with out them
knowing about all the plumbing. This raises it's own security
concerns, but at the very minimum it does accomplish separating the
key from the data. Debating if a central key authority could ever be
trusted is another issue.
For more security concerned users, each user could run their own key
authority, this would probably require a tiny bit more info on log-in,
so the client could find the private key.
Even if you didn't run your own seed, you could still run your own key
authority, which would make using other peoples seeds much much less
dangerous.
Now this whole idea does have one GLARING problem. How do your friends
request your data? Since the client is the only one who ever gets
access to the private key in the key authority, the server (seed)
could never decrypt your data to send to your friends...
Just food for thought though... Maybe there is a way to solve this
issue.... But short of *never* allowing the seeds to decrypt user
data, I don't see this being an end-to-end cryptographically secure
system. So maybe we need to decide if that is really the ultimate
goal?
Maybe the security here comes in actually being able to trust your
seed?
Idk...
Braedon Vickers
Braedon
Michael Meer
Wavesonics
Maybe there could be some way to check-sum verify the scripts against
something, But really your getting into this cat & mouse security game
now that probably is a no-win. Especially for the non-techy end user.
I think this being a end-to-end cryptographically secure system is a
bit of a pipe dream.
- Adam
shadowfirebird
> bit of a pipe dream.
>Now the "Key Authority" is the lynchpin here and obviously fraught
with problems. For non-techy users, a default central "Key Authority"
would be required to seamlessly store their private keys with out them
knowing about all the plumbing.
key encryption and a web of trust?
Wavesonics
encryption"
Hhhmmm... well you could encrypt your data for every Friend who has
access to it (managed by Aspects). That could work, but it would
require the client to re-encrypt all the data for a given Aspect every
time you add a Friend to that Aspect, and then send it back to the
seed for storage.
On one side, it kinda makes since, b/c to confirm or add a friend, you
would indeed need to be logged in and running the client. But if you
have a ton of photos, it would be untenable. All the encrypted data
for that Aspect would have to be transferred to your client to be
decrypted and then re-encrypted, and sent back...
"other systems have managed it."
they are responsible for keeping them secret and always having them
when & where they are needed. Unless every diaspora user is going to
carry their key on a USB drive or something, they won't always have
their key.
Just like the XKCD "sudo make me a sandwich" I believe truly securing
a system necessarily degrades it's ease of use. Something which is
critical to Diaspora's success.
- Adam
Wavesonics
As far as I understand them, web-of-trust for PGP is for verifying
public key / user bindings, not for private key distribution, which is
what they Key Authority in my scheme aims to solves. Having your
private key available to you no mater where you are when you log in.
Jakob Keres
Am 23.09.2010 um 21:18 schrieb Wavesonics:
> "we could encrypt the message to multiple recipients using public key
> encryption"
>
> Hhhmmm... well you could encrypt your data for every Friend who has
> access to it (managed by Aspects). That could work, but it would
> require the client to re-encrypt all the data for a given Aspect every
> time you add a Friend to that Aspect, and then send it back to the
> seed for storage.
No, that's not true, we already discussed that. If you add a friend to an aspect you only have to encrypt the symmetric key with the public key of your friend.
The problem is more, when you remove a friend from an aspect, since the key symmetric is the same for everybody. In this case you would need to reencrypt everything.
eveclatrel
1. User creates an account on a seed, using the user's password a
public/private key is generated by the server and stored
2. User creates a friend request, server looks to see if the friend
has a public key stored in it's database, if yes: encrypt request and
send to friend's server. If no, request public key from friend's
server. Upon receipt of the public key, encrypt and send friend
request.
3. Friend request arrives at friend's server, remains encrypted in a
buffer until prospective friend logs in. Password from login is used
to decrypt waiting items, which are inserted into main database at
that time. (it can be re-encrypted or left unencrypted as performance
allows, could even be user-configurable)
4. Friend accepts request, friend's server checks to see if the
originator's public key is stored, if yes, reverse process, if no,
request, encrypt, send.
5. If a person changes their password, a new public/private key should
be made, dropping the old one completely. Process should be, flush
buffer, change password, drop keys, create keys, send out new public
key notification (NOT the public key), friend's servers will pull the
key from the server. This might be susceptible to a man-in-the-middle
attack at the end there, and I'm not sure how to solve that, but I'm
sure there's someone around here who can address that with some kind
of DNS auth.
This would bring people who have no idea what SSL means, that PGP/GPG
exists and security is more than a big dude in a black t-shirt into
the safety of encryption technology. They don't even have to be aware
it's happening. All the end-user would know is they changed their
password because it looked like someone might be messing with their
account (friends complaining of odd posts, strange updates occurring).
Even if the server is compromised and becomes hostile, the private
keys are secret passphrase'd against the users' password which should
be hashed anyway. This process *should* work for either GPG/SSL
encryption model unless I've missed my mark in how ruby deals with
either. Hopefully the two important things you can count on are that
you keep your password complex and to yourself and that your friends
will tell you if something seems wrong.
I am also of the opinion that the only information that should be
propagated is username, display name and link to profile picture.
Everything else should remain on the originating seed. It helps with
damage control should a seed become hijacked, but storage as well.
Clicking on a person's profile link would take you to some kind of
hashed address that gives you access based on how they have you set
up. The information doesn't have to be encrypted on their end, so it
would not have the same kind of overhead as an outright encrypted
transfer (unless everything was encrypted by default).
eveclatrel
temporarily decrypted in a secure memoryspace to be re-encrypted with
the new key. I'm not a fan of encrypting the database however, since
it would make "Reset Password" functions a nightmare.
eveclatrel
locally on each seed, just files such as pictures, videos, audio and
profile data would remain on the original host seed.
shadowfirebird
> access to it (managed by Aspects). That could work, but it would
> require the client to re-encrypt all the data for a given Aspect every
> time you add a Friend to that Aspect, and then send it back to the
> seed for storage.
Modern cryptography is cheap enough so that we can do it real-time on
voice calls. In the days when PGP was new, sure, it would have been
prohibitive. Now? I don't know.
And, there are ways to get around it if it is. We could adapt the
protocol Diaspora is already using - encrypt the messages using a
symmetric key, then encrypt the key using public key encryption. When
you want to add a new user to the aspect, you only have to re-encrypt
the key: one operation no matter how many messages. If we get it
right, it's perfectly secure - GPG uses the same protocol. (Of
course, none of us are crypto experts; we'd have to borrow one to make
sure we got it right.)
Alternatively we could do what I suspect Retroshare does - use a self-
signed SSL key to encrypt the message, but authenticate it with a web
of trust by signing it with GPG.
shadowfirebird
> public key / user bindings, not for private key distribution, which is
> what they Key Authority in my scheme aims to solves. Having your
> private key available to you no mater where you are when you log in.
But the idea of a central key authority has, as you say, major
drawbacks. Trust Facebook, trust a central key authority - that
doesn't look too different to me.
shadowfirebird
> has a public key stored in it's database, if yes: encrypt request and
> send to friend's server. If no, request public key from friend's
> server. Upon receipt of the public key, encrypt and send friend
> request.
to create a hacked version of the server software that gives the
message to a.n.other, as well. The software can decrypt anything.
To my way of thinking the server can't decrypt anything. It's good at
replicating the data to other servers and serving it to clients - both
the messages and the settings that say who gets to see what. But the
client does the encrypting and decrypting.
That way it doesn't matter that much if the server code has been
fiddled with, because the server code can't read the messages.
(Okay - advanced topic: you could screw with the code to automate a
man-in-the-middle attack. We have to deal with that. But right now
that's detail; we're still drawing the big picture.)
Micah Lee
Hash: SHA1
Hi. I've been following this discussion for the last couple days, and I
have some ideas that could be useful. I haven't read everything that
everyone's written about it though (I have a full-time job after all) so
forgive me if this stuff has already been suggested.
First, I think it's imperative for diaspora to work from any computer
with a normal web browser without any special plugins, and without
needing to store a secret key on the client side. I don't think diaspora
will end up being popular (or even user-friendly) if you need to install
and manage extra stuff, and sync it up on all your computers/devices,
and deal with what happens if it accidentally gets deleted, etc. So yes,
I think seeds need to store secret keys. If you want better security for
specific discussions, you shouldn't be using a social network, but
instead normal gpg with email. All the crypto in diaspora (I think)
should be completely transparent to the user, so the most that they
notice it is possibly in a loading bar that says "encrypting to the
friends in your aspect, please wait".
Also, the secret keys that get stored on the server should be stored
encrypted, and only decrypted in memory with the user's password.
Now here's my idea. Each user has a keypair, but that's only used for
sending private messages to other users, not for status updates. Private
message would work like traditional gnupg email, except the secret keys
would be stored on the server.
Each aspect has it's own keypair as well. Each friend in each aspect
gets sent the _secret_ key of that aspect (encrypted to their personal
public key, as if it were a private message). So every diaspora user
would store a list of secret keys for every aspect they belong to.
When you post a status update, rather than encrypting that message to
all of the friends in your aspect, you just encrypt it to the aspect's
public key. All of your friends in the aspect can decrypt it with the
aspect's secret key.
Whenever anyone gets removed from an aspect, diaspora will generate a
new keypair for that aspect and tell all of the friends in the aspect
what the new secret key is, and it will also re-encrypt all the old
messages from that aspect with the new secret key, so that the friend
who was removed from the aspect can no longer read those updates.
It seems like this would have muuuuuch less overhead in terms of
encryption processing power and also disk space. If you have 1000
friends in an aspect, you would only need to encrypt the message to one
public key, not 1000. It would take a little more resources when
removing friends from aspects, but that's it.
When a user stores a bunch of aspect's secret keys, they are all
encrypted to that user's personal public key. So if another user on the
seed somehow gets access to the database, all they have is encrypted
secret keys, and they need the user's personal secret key and password
to decrypt them.
This idea of course breaks down if one of the friends in an aspect is on
a seed with malicious admins. It would be trivial enough to add an extra
field to the user model for the plaintext password, and store it on
successful logins, so that the admins would collect everyone's
passwords. If that happened, they could then decrypt everyone's secret
keys and use those secret keys to decrypt everyone's list of other
secret keys for aspects they belong to, and all the security breaks
down. Then those admins would be able to read all the messages sent to
all the aspects that their users belong to.
But I think I'm ok with that. If secret keys are stored on the server,
even if they're encrypted to users' passwords, they're still not safe
from malicious admins because they can easily steal your passwords. I
don't believe there's any way around that. It's just important to choose
a seed that you trust, and if you actually want to send sensitive stuff
to one of your aspects, you should trust the seeds your friends in that
aspect belong to as well.
Thoughts?
micah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJMm9NiAAoJEEFYPvBlU7xNokIP/jq9P1CFAySY59O+cY/MBXZB
BabuDKYbzsvJ4TQf55hhnqQtDk3n+vkKf4tn5aWAwZ64doRWqMoi1hcyE76NQXFz
mX2SdkoAR1RkyR3Mc3WEIFOewLCMMg6GMiB30If3sooq3oKfv3n5+2U9KXwlZNzJ
FvaqqGFKlA0eIF3EXVj9nzHGY9K67U51hGGIt1f4MnLCC8vx8vLksUSsAuMikV7y
p3acb4UU51blKRT7ODLajjtTZtwPgKhW4wrt1vPJPsD/LvQxHEugnhUhN32TDqy1
TnamvlKXKkMQd6AOfmtzyJU2GZu+b0SDGm1+uE3xkQq3tTHIwYeQYfiW5YgPHhbj
29noIw7kC6EhxE4MaavUWecQ1PnhiHjWFAsXXWp6fJNUUDo0owXE0aF6EgW7JN7V
wkLRxHYRPDMxW8MGANN6R8Kt5RoBgdoxoUD6H0TDjo7HRHFhI3PMM+NmpAeUzWCw
TYme5ZnKSr7Wh24Jkwje8qkzg6dwF4/YF/HUKYKOHwj6gw5MKRTsVoG/jpkfdxc1
FhAlo7HyKhrPz5Qkfpx19Aq2pM2/6hVXeyS4XltvhhXcE78/gHBGDA/jacKc0X+A
vCGO6y2tc0ueJvCuJSadb4EclxkbArI7c2l6jp7WSnLFiiLxKAQpriOvn4Ai3Bo1
9u4p+++/ZJI/MRaej3pW
=CU2u
-----END PGP SIGNATURE-----
Michiel de Jong
Each aspect has it's own keypair as well. Each friend in each aspect
gets sent the _secret_ key of that aspect
If you have 1000 friends in an aspect, you would only need to encrypt the message to one public key, not 1000.
This idea of course breaks down if one of the friends in an aspect is on
a seed with malicious admins.
Jakob Keres
But once more.
The data/a file is encrypted just once with a random symmetric key. The
key is encrypted with the public key of each member. This way no
encryption overhead nor another keypair is necessary.
Or have I missed something?
eveclatrel
I agree wholeheartedly with this. There is only so much technology can
do to solve a social issue, and finding a site you trust is bordering
that social issue. The public/private key pairs for aspects is good,
I hadn't been thinking about that (long day), but it is essentially
the same thing I had been thinking before. The encryption is less of a
privacy part as it is a verification, but figure if you're going to do
something it may as well be encrypt the messages. I think it is
important that this be completely web-based and very easy and
transparent to the end-user. There are a lot of Facebook users that
have no idea what ssl is that are on our lists. Would be a shame for
them to spurn Diaspora because it was "just too hard".
As to my step 2 above, I'm not following how the server copying the
message helps a malicious admin. It can only be decoded by the server
with the private key. Would probably be a good idea to out some kind
of DNS auth in there as well, but even still, you would either have a
bogus friend or the wrong public key and at some point lose
connectivity with the real friend (when arp attack was over) or figure
out that the person you're talking to is not really Bob from
accounting, but Steve from marketing (he stole my girl!) either way
there will be a context clue to update your password and your
friend's. Sorry if I'm missing something, like I said it's been a long
day.
Wavesonics
end (user-to-user) encryption, then having a half hearted solution
would unnecessarily complicate things IMO.
Like we are all saying, if there is a malicious admin, all bets are
off (if the seeds store private keys that is). So we have to put the
social issue aside for the moment.
The only meaningful thing we can do encryption wise is secure the
message passing between seeds, since both seeds involved in the
transfer will (either lawfully or unlawfully) have full access to the
decrypted message & content.
So really, you only need to do key exchange between seeds, not users,
so you can securely pass messages back and forth. Once you get a
message on board at a given seed, its in clear text, and it relies on
good security procedures in the code to only show it to the right
users. If someone is going to hack around w\ the source and be able to
snoop stuff, they would also be able to grab the stored private keys
and decrypt everything anyway. So all these separate key pairs become
useless.
Do you guys agree with me? Or am I missing something?
What it comes down to is what I think the point of Diaspora was in the
first place. Allowing you to take your data to a trusted seed. THAT is
your security.
The next debate to have would be how to deal with seeds that are known
to be bad... (Also how to discover seeds that are bad, and let
everyone know not to talk to them.)
- Adam
Micah Lee
Hash: SHA1
On 09/23/2010 05:29 PM, Wavesonics wrote:
> So really, you only need to do key exchange between seeds, not users,
> so you can securely pass messages back and forth. Once you get a
> message on board at a given seed, its in clear text, and it relies on
> good security procedures in the code to only show it to the right
> users. If someone is going to hack around w\ the source and be able to
> snoop stuff, they would also be able to grab the stored private keys
> and decrypt everything anyway. So all these separate key pairs become
> useless.
>
> Do you guys agree with me? Or am I missing something?
I agree that this would be way simpler if the encryption could just be
between seeds, rather than end-to-end. And rather than re-inventing the
wheel with each seed having it's own keypair that we program into in
diaspora, we could just require seeds to communicate over SSL. The whole
self-signed vs CA signed SSL cert issue will still be the same, even if
we invent our own key sharing infrastructure.
But there is still a good reason to encrypt each user's status messages
and private messages separately. A malicious admin can do a lot of
damage if anyone is using his seed, or is sending messages to his seed.
But hopefully people will be using trusted seeds. The bigger threat is
the malicious user.
Unless the malicious user gets arbitrary code execution, they're still
limited to the security of the web app. So they can't actually change
the codebase around, they can just exploit existing bugs in the
codebase. If I find a bug that lets me dump the status_message table,
for example, I wouldn't be able to read any of those status updates if
they're encrypted. If I can dump both the status_message and the user
tables that contain the secret keys, I _still_ wouldn't be able to
decrypt the status messages because hopefully all the secret keys would
be encrypted with the user's password. I'd have to crack the password
hashes first, then use those to decrypt the secret keys, then use those
to decrypt the status messages. In the end, this would make it a lot
harder on attackers that do find unpatched bugs.
But if no bugs exist in the codebase that lets you dump the
status_message table, then it's a moot point.
Since this is a new project and the crypto stuff is complicated and easy
to mess up, it might make sense to just force SSL between seeds and to
make end-to-end encryption optional if you want to run a custom client
or something.
micah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJMm/kZAAoJEEFYPvBlU7xNp+cP/0s83Ofz4TfUiocjRzWKxJkz
hTp8hDagb0NDpYgLZQT2Hp/8mrtrY/hbHyeFcQUxKtIL3/g6gPoG+QF+CBb2+UY4
Nh1XGWN4D85W8b5+KoWrgpMTZ2+5u7D2pwRu47QGIa5D9AMYtJkOMiVosX1Ee8+t
0iIWZNcRwFJ+TGQArz8Oi7hbIbts8TWSmhvRUsG//GkoOuc5yMlmNwUbRwWRMXu0
CSzRycXQfRsRhpTw+J6XkHnU38XHonIRNbS2KZXvfJzTsZjeKLKHCpku51ghDhsN
ycbJRHDMv/6HxhXmd7OqMix46wsBFgteEymgmF/jQppCPM0/m3b/oE2njQUO6wX8
VZA63UbGEfxY+6PPTLAKFP4qV21z2SqTaeosAaYHH2fbBXg6OqXIOnIxEO+xWc7y
wsxFJfqZQCUh58iVoc8bvDx+VRlMkePSqbvlqAsbSlpD9a1tSizOt/XI0EyRqj9B
lqqyc25SDiLTFWbk/6oVmyVhmikjc1Mw1DAMGqsGF/8re+LhbHP3FAZSkSXe3op+
zt4cPgkq3vbpX2ukTcjVzbL/zLPlFdeZom3d/FP/OMsz+KeCQXBe78dkKlYljzOJ
OlJ4X+t2t7BohJ+fyjCHiWicEYKw1zBTEQms0uIGB6UGlfnguHFEwTtj1URawG2q
d9sSQwnlroYYm7nWDlxi
=Pipa
-----END PGP SIGNATURE-----
Wavesonics
reinvent the wheel.
And you make a really good point about the admin vs user threat. The
admin threat sits on the line between social and technical problem imo
so I'm not entirely sure a technical solution is even appropriate.
How ever I think there is a problem with the users data being
encrypted on disk. If it can only be decrypted with the users
password, how could another user pull data like pictures? or would any
outwardly accessible data simply not be encrypted?
If that's the case, and SSL is used between seeds, no user to user key
exchange is required, and each user can simply have a symmetric key
which is protected by their password for encrypting their data on
disk.
shadowfirebird
> so you can securely pass messages back and forth. Once you get a
> message on board at a given seed, its in clear text, and it relies on
> good security procedures in the code to only show it to the right
> users. If someone is going to hack around w\ the source and be able to
> snoop stuff, they would also be able to grab the stored private keys
> and decrypt everything anyway. So all these separate key pairs become
> useless.
>
> Do you guys agree with me? Or am I missing something?
I suspect) in clear text, then you have a massive problem with people
changing the code maliciously, and privacy goes out the window.
If seeds/pods/whatever only handle encrypted traffic, that removes
most of he problem. We only have to guard against malicious code that
attempts to engineer a man in the middle attack. And that basically
comes down to key security: if you know for sure that the key belongs
to who you think it does, you're safe.
eveclatrel
On Sep 23, 11:42 pm, Wavesonics <adamwbr...@gmail.com> wrote:
> How ever I think there is a problem with the users data being
> encrypted on disk. If it can only be decrypted with the users
> password, how could another user pull data like pictures? or would any
> outwardly accessible data simply not be encrypted?
to be encrypted with a symmetric key, which can open you up to abuse
if a malicious pod were introduced into the mix. I don't see a problem
with encrypting private messages on the disk, and don't see a need to
encrypt the other messages, since it's on your pod (which you should
trust), and has been safely transferred to your friends' pods (which
they should trust). If your other information (files/pictures/profile
data) stays on your pod, you could use your friend's public key to
make a hash that when decrypted pointed to their view url of your
stuff on your pod. It's still susceptible to viewing by malicious
admins so there's still little point in encrypting it, just extra
overhead. The true technological solution to the malicious admin is
the freedom box, where everyone is running their own pod. At that
point it becomes a bad friend, bad user and a bad seed. If you've got
something that you *seriously* don't want to have read, you need to
use your local SSL/GPG key, encrypt it, put that into the post message
box and send it to have it decrypted by your friend on the other end.
The average user should not need this on a regular basis for everyday
items, and hopefully trusts their pod enough to put personal info on
it. If you've got concerns about your friend's pod and security, have
them join yours :)
One thing I think we should keep in mind, it is possible now on any of
the other social networking site admins to get into our stuff without
us knowing, so anything we do is a step up. Perhaps having some kind
of Verisign-like service from the open source community to sign off on
pods is the key. Where anyone can run a pod, but there are ones that
have hashes run on the code periodically through the day and are
listed as green or red on a list. Would be able to give read-only
access to that directory only, lock the verification site in and store
the data elsewhere. Might give the average user the warm fuzzy about
security that we're trying to accomplish.
As an aside: I have given some thought to the bad pod/bad seed issue.
It would require human intervention, but user could report a bad pod/
bad seed to an admin through the seed's interface, the pod admin would
take a look to see if there was anything odd, maybe get in touch with
other pod admins (a log of known pods would be needed, but not the
seeds that are contacted on those pods) to see if they've seen or
heard anything about it. A blacklist log could be added to, that
refuses connections from that pod/seed, and forwards the list to all
other known pods. That update would be manually reviewed by the other
pod admins and added/dropped as they saw fit. Updates that come in and
are already on the list would be dropped. It takes manual
intervention, but there isn't any good way to programmatically say
"bad pod/good pod". Best we can do is give the pods and seeds a way to
point a finger and everyone makes their own judgement. It would
prevent a malicious pod from standing up and trying to collapse the
network with an auto-accepted blacklist system as well.
shadowfirebird
> to be encrypted with a symmetric key, which can open you up to abuse
> if a malicious pod were introduced into the mix.
a symmetric key make the data less secure than not encrypting it at
all?
>I don't see a problem
> with encrypting private messages on the disk, and don't see a need to
> encrypt the other messages, since it's on your pod (which you should
> trust), and has been safely transferred to your friends' pods (which
> they should trust).
Even if I do, you're saying that I don't have to trust my friends'
pod, but yet it has my data on it?
> It's still susceptible to viewing by malicious
> admins so there's still little point in encrypting it,
admins - unless those admins had managed to fool you into accepting a
bogus public key, which we can make difficult.
> One thing I think we should keep in mind, it is possible now on any of
> the other social networking site admins to get into our stuff without
> us knowing, so anything we do is a step up.
"privacy-aware social network". As soon as anyone finds an exploit,
our name will be mud. Whether that's fair or not is a seperate
topic, but people will expect our software to be secure.
eveclatrel
On Sep 24, 12:11 pm, shadowfirebird <shadowfireb...@gmail.com> wrote:
> > Probably wouldn't encrypt those items. It would almost certainly have
> > to be encrypted with a symmetric key, which can open you up to abuse
> I'm afraid that I don't understand. In what way does encrypting with
> a symmetric key make the data less secure than not encrypting it at
> all?
>
access to their seeds' passwords and therefor the private keys. So it
wouldn't matter if you were using a symmetric key or encrypting the
data per person, the admin would be able to get to it.
> >I don't see a problem
> > with encrypting private messages on the disk, and don't see a need to
> > encrypt the other messages, since it's on your pod (which you should
> > trust), and has been safely transferred to your friends' pods (which
> > they should trust).
>
> Why should I trust my pod if it's hosted by someone else?
>
> Even if I do, you're saying that I don't have to trust my friends'
> pod, but yet it has my data on it?
>
pods', but to be fair it's not practical in a web-based social
networking platform. If you can't trust a system then you shouldn't
connect to it, and I don't see a way of making any key system that
will accomplish that kind of user-to-server trust. In a client-server
app environment that would work, since the client encrypts everything
and the server has no key at all, wouldn't even need ssl since it's
all encrypted either with public/secret or symmetric/secret keys.
Problem is that we have folks that either can't install an app (work
machine, shared computer, library machine, embedded device, mobile
device w/out apps) or feel it's too much work for a social network.
> > It's still susceptible to viewing bymalicious
> > admins so there's still little point in encrypting it,
>
> If it was encrypted it wouldn't be susceptible to viewing bymalicious
> admins - unless those admins had managed to fool you into accepting a
> bogus public key, which we can make difficult.
>
field for their seeds' password to get access to the private key, and
I can't see a malicious pod going to all the trouble of serving dud
public keys, rewriting the code to decrypt it and send it to the seeds
they were intended for, when there's a lot less work and less danger
of being caught by letting the normal process take place with just a
slight adjustment. I suppose that is really my definition of a
malicious pod: any pod that has intentionally compromised the private
keys of its seeds to gain access to the information they receive and
transmit, or a pod with the specific purpose of destabilizing the
trust/operation of the Diaspora network.
> > One thing I think we should keep in mind, it is possible now on any of
> > the other social networking site admins to get into our stuff without
> > us knowing, so anything we do is a step up.
>
> To my way of thinking this isn't true. On the contrary: we're the
> "privacy-aware social network". As soon as anyone finds an exploit,
> our name will be mud. Whether that's fair or not is a seperate
> topic, but people will expect our software to be secure.
be the "holy grail" of secure social networking for the masses. I
would like to see us able to give it to them. It *is* possible to do
this, since what I expect people will want to hear is "no one can
listen in to the traffic, the people running the pod can't read your
messages, and they can't see your data to share with others" (well,
it's what I'd want to hear at least). On a trusted pod, we've already
got a plan that would work, symmetric keys, private keys either
generated automatically or manually by the server and then encrypting
the data into the database appropriately. It's when you add a
malicious pod into the mix that it becomes sticky. With compromised
keys comes less security, and if you expect a certain degree of lower
security because of that, you can drop some of the overhead you would
have experienced otherwise. If we can come up with some other way to
stop malicious admins from making malicious pods then the encryption
becomes useful again, but if it's not going to be that useful or if
it's that much in question, do you spend the overhead to do it and
slow the system down or encrypt data even though the person you are
hiding it from has (or very likely has) the right key?
I would personally use a client-server model for myself to access the
network, since it's the perfect security config for this. I just don't
think most of my friends would.
shadowfirebird
> access to their seeds' passwords and therefor the private keys. So it
> wouldn't matter if you were using a symmetric key or encrypting the
> data per person, the admin would be able to get to it.
inherently insecure. But even in that case it would be worthwhile
encrypting the data because it stops it being trivially read by
simpler exploits on non-malicious pods.
> I would prefer a model where I don't have to trust any of my friends'
> pods', but to be fair it's not practical in a web-based social
> networking platform. If you can't trust a system then you shouldn't
> connect to it, and I don't see a way of making any key system that
> will accomplish that kind of user-to-server trust.
stop now. What's the point of continuing if we can't make rudimentary
guarantees about the privacy of the data? This is supposed to be a
"privacy aware social network".
> In a client-server
> app environment that would work, since the client encrypts everything
> machine, shared computer, library machine, embedded device, mobile
> device w/out apps) or feel it's too much work for a social network.
On the other hand, I certainly agree that we don't know if scripting a
browser to do the end-to-end encryption is practical. I can only
think of one application that worked that way -- anyone remember
Hushmail? And starting up a session was not exactly a seamless,
instant thing.
In the future it may be that we have to choose between having an
insecure social network that doesn't really protect privacy, but does
have a simple web interface, or genuinely secure social network that
compromises our current view of what the interface should be. But
we're not there yet! We don't *know* that we can't do end-to-end
encryption in the browser.
> That would only be if the admins didn't bother adding a cleartext
> field for their seeds' password to get access to the private key, and
> I can't see a malicious pod going to all the trouble of serving dud
> public keys, rewriting the code to decrypt it and send it to the seeds
> they were intended for, when there's a lot less work and less danger
> of being caught by letting the normal process take place with just a
> slight adjustment.
man in the middle attack; they could read the data without. But
again, this comes down to whether we have true end-to-end encryption
or not. If we do, the problem you talk about is gone.
> [...] since what I expect people will want to hear is "no one can
> messages, and they can't see your data to share with others" (well,
> it's what I'd want to hear at least).
the pod.
eveclatrel
security, and we both agree that storing keys on the server can open
you up if a malicious pod gets introduced. I am also of the opinion
that running encryption from the browser client itself seems like it
would be difficult and possibly unwieldy. My stance thus far has been
that I don't think the average user is going to want to use an end-
client encryption system because of that, so I've tried to stick with
server-based solutions, however on the drive home I had a thought:
Why are these mutually exclusive?
I propose this, we accept the server-level public/private key system
and call this "less-secure mode", it can be the default for normal web-
browsers and devices without client-side encryption. However, we also
implement a client-side system and call this "secure mode", either
through the web-browser or a dedicated app (I'm thinking option two
might be more comfortable all around). This would encrypt with a key
made and stored locally, using a passphrase (or not, since it's
physical security it can be users choice). These encrypted messages
would be stored on the server in that format, and flagged as secure.
Public keys could be exchanged and stored locally and the messages
would be all viewable in the client-based app. Anyone using "less-
secure" would see a message stating "Secure Message, please log in
Secure Mode to view" instead of the post, picture or profile, and they
would have to log into a secure client to see it. It would allow for
people to choose if they care about their security or not, and
essentially run two networks across Diaspora. It would break people up
somewhat, but I would hope that folks will get tired of not being able
to see certain posts, break down and get a client. And it also gives
you the option to hop on your friend's laptop at the beach and post
"hi mom, having a great time!" (albeit insecurely) without installing
your keys or software on their machine.
shadowfirebird
On Sep 25, 12:16 am, eveclatrel <kevin.p.h...@gmail.com> wrote:
> Hmm, we both agree that end-to-end encryption is the best approach for
> security, and we both agree that storing keys on the server can open
> you up if a malicious pod gets introduced. I am also of the opinion
> that running encryption from the browser client itself seems like it
> would be difficult and possibly unwieldy. My stance thus far has been
> that I don't think the average user is going to want to use an end-
> client encryption system because of that, so I've tried to stick with
> server-based solutions, however on the drive home I had a thought:
>
> Why are these mutually exclusive?
definition, end-to-end.
However, see the post on the other thread by Raphael - the team seem
to have dismissed the idea of end-to-end encryption for the time
being.
eveclatrel
and forth on encryption has me convinced that is the way to proceed
for real security (which I thank you for). If we don't include it in
*some* form I think we need to drop being privacy aware as something
Diaspora accomplishes. Because it cannot be guaranteed without it and
it seems that more people are coming to that conclusion.
I don't think it's accurate to say it has to be done from the browser
to be true e2ee, a complied or standalone application will give a much
better user experience in my opinion. The team has already stated that
they want to make pull's possible for other servers and one could make
an application that piggy-backed off of that if no direct-client API
is provided. If pulls are not supported and no API is written then I'm
sure some kind of fancy and complicated web-page parsing system can be
worked up, but I imagine that attempt will be a short trip. I
understand that the browser, in Diaspora's current state, is the
client and the only client that functions. It cannot remain that way
for this to be a success. I still haven't gotten a chance to look at
Hushmail and am interested to see how that operates, but I'm curious
where a Hushmail-like solution would leave mobile users on Android,
iPhone/Pod/Pad and whatever else is out there. If it's a bit of a pain
to work with then let's make sure that something better can be
designed by adding an API and database support for a standalone, non-
browser client that can support the e2ee that we really and honestly
must have. Frankly I'm not expecting or asking for the Diaspora team
to build a client, just the API which should be on the roadmap anyway
(if it's not), and a way to flag that it's encrypted in the database
to relieve users not using a e2ee compatible client.
In the event that we missed each other in my previous post, I was
referring to the average user not wanting to use a cumbersome
interface or install an application on their computer for the sole
purpose of being able to use a social networking site. I feel that
until they have some vested interest in using that client they won't
(and continue to use an insecure browser-client), and the way to
generate that interest is to cause peer-pressure by encrypting things
your friends want to see or use. By slow propagation it should catch
on eventually and we can all enjoy (mostly) e2ee.
Dan White
>Why are these mutually exclusive?
Right. A network API should be developed that allows for a lot of
flexibility in how and where keys are stored.
On 26/09/10�ｿｽ01:22�ｿｽ+1200, Braedon Vickers wrote:
>First draft up, if you didn't see it
>http://github.com/diaspora/diaspora/wiki/Security-Architecture-Proposal
>
>Currently awaiting the storm :)
>It is clear from the discussions that some advanced users want end to
>end encryption, as they do not want to trust their seeds, nor the
>seeds of their friends. It is also clear, however, that baring some
>revolutionary design as yet unthought-of (within the Diaspora
>community at least) such a system would be prohibitively complex and
>cumbersome for the average user. In fact, the more secure a system,
>the less user friendly, and the more expensive (network and cpu load,
>data storage), it becomes.
I really believe we can and should define a network protocol that is
secure, and simple. How that protocol is implemented may be more or less
secure and more or less complex, leading to choices in which implementation
users choose. I think we must take the approach that users know what
they want, and we should find a way to give them as many choices as
possible, and arm them with the knowledge of how to use them. However, I
believe that with good design, a secure implementation can be created that
provides for a user friendly interface without sacrificing security.
With regards to the 'None' security level, there *must* be some form of
signing, or you're opening up the network to spam.
I think the rest is a fair portrayal of the state of the discussion.
Thanks for writing this up!
On 25/09/10�ｿｽ15:26�ｿｽ-0700, shadowfirebird wrote:
>
>On Sep 25, 12:16�ｿｽam, eveclatrel <kevin.p.h...@gmail.com> wrote:
>> Hmm, we both agree that end-to-end encryption is the best approach for
>> security, and we both agree that storing keys on the server can open
>> you up if a malicious pod gets introduced. I am also of the opinion
>> that running encryption from the browser client itself seems like it
>> would be difficult and possibly unwieldy. My stance thus far has been
>> that I don't think the average user is going to want to use an end-
>> client encryption system because of that, so I've tried to stick with
>> server-based solutions, however on the drive home I had a thought:
>>
>> Why are these mutually exclusive?
>
>Well, if we don't run encryption from the browser client it's not, by
>definition, end-to-end.
>
>However, see the post on the other thread by Raphael - the team seem
>to have dismissed the idea of end-to-end encryption for the time
>being.
That may be a practical decision made by the Diaspora team with regards to
their web server approach, and that's understandable at this stage of the
development. I have to believe that if Diaspora meets its goals, then we'll
also see 10s of other implementations that can, provide end to end security
(or other unique features), but as long as two pods talk the same network
language that's all the better.
On 25/09/10�ｿｽ16:51�ｿｽ-0700, eveclatrel wrote:
>Yes, I noticed their stance on e2ee and it furrows my brow. Our back
>and forth on encryption has me convinced that is the way to proceed
>for real security (which I thank you for). If we don't include it in
>*some* form I think we need to drop being privacy aware as something
>Diaspora accomplishes. Because it cannot be guaranteed without it and
>it seems that more people are coming to that conclusion.
If you drop security, then it's probably going to result in a huge mess of
spam. But I get your point.
However, I think the network API can be written in a way that a Pod can
perform end-to-pod encryption, or pod-to-end encryption and still allow for
sufficient security for the end-to-end crowd. It at least should prevent
the free-for-all-for-spammers environment that's infested SMTP.
--
Dan White
Braedon Vickers
With regards to the 'None' security level, there *must* be some form of
signing, or you're opening up the network to spam
I believe the mandate for Owner(as in Post Owner) authentication in Seed to Seed communication should cover this.
In terms of implementation, if use of Salmon is continued, it should provide this.
Braedon
eveclatrel
I postulated at a higher level.
Sadly spam is going to be a problem the minute anyone modifies their
pod/node to allow them access to the user's password as well as their
keys. Going by the wiki they'd have access to post None through
Medium security messages to any of the user's friends. The fix for
that is to complain back to your friend, have them be confused and
then figure out their pod is doing it, and then they would have to
move to a more trustworthy pod. Hopefully yours ;) I would actually
drop None from the list and assume that basic encryption is taking
place, if for no other reason than authentication to help curb some
of
that.
Kudos for the wiki Braedon
I have some thoughts on how to handle the commenting and audience
management, but would like to see e2ee accepted before we start up
discussion threads on that since it would require that in the model
and could be moot.
Call me crazy, but every time I look at a security issue with
Diaspora, the first thing I think of is "How does it work with email
servers?" In terms of e2ee I think there might be some value to be had
by treating the pods like email servers for the design. While that
particular wheel may not work perfectly, it does work pretty darn
good.
On Sep 25, 11:23 pm, Dan White <dwh...@olp.net> wrote:
> >Why are these mutually exclusive?
>
> Right. A network API should be developed that allows for a lot of
> flexibility in how and where keys are stored.
>
>
> >First draft up, if you didn't see it
> >http://github.com/diaspora/diaspora/wiki/Security-Architecture-Proposal
>
> >Currently awaiting the storm :)
>
> >It is clear from the discussions that some advanced users want end to
> >end encryption, as they do not want to trust their seeds, nor the
> >seeds of their friends. It is also clear, however, that baring some
> >revolutionary design as yet unthought-of (within the Diaspora
> >community at least) such a system would be prohibitively complex and
> >cumbersome for the average user. In fact, the more secure a system,
> >the less user friendly, and the more expensive (network and cpu load,
> >data storage), it becomes.
>
> I really believe we can and should define a network protocol that is
> secure, and simple. How that protocol is implemented may be more or less
> secure and more or less complex, leading to choices in which implementation
> users choose. I think we must take the approach that users know what
> they want, and we should find a way to give them as many choices as
> possible, and arm them with the knowledge of how to use them. However, I
> believe that with good design, a secure implementation can be created that
> provides for a user friendly interface without sacrificing security.
>
> With regards to the 'None' security level, there *must* be some form of
> signing, or you're opening up the network to spam.
>
> I think the rest is a fair portrayal of the state of the discussion.
>
> Thanks for writing this up!
>
>
>
>
>
> >On Sep 25, 12:16 am, eveclatrel <kevin.p.h...@gmail.com> wrote:
> >> Hmm, we both agree that end-to-end encryption is the best approach for
> >> security, and we both agree that storing keys on the server can open
> >> you up if a malicious pod gets introduced. I am also of the opinion
> >> that running encryption from the browser client itself seems like it
> >> would be difficult and possibly unwieldy. My stance thus far has been
> >> that I don't think the average user is going to want to use an end-
> >> client encryption system because of that, so I've tried to stick with
> >> server-based solutions, however on the drive home I had a thought:
>
> >> Why are these mutually exclusive?
>
> >Well, if we don't run encryption from the browser client it's not, by
> >definition, end-to-end.
>
> >However, see the post on the other thread by Raphael - the team seem
> >to have dismissed the idea of end-to-end encryption for the time
> >being.
>
> That may be a practical decision made by the Diaspora team with regards to
> their web server approach, and that's understandable at this stage of the
> development. I have to believe that if Diaspora meets its goals, then we'll
> also see 10s of other implementations that can, provide end to end security
> (or other unique features), but as long as two pods talk the same network
> language that's all the better.
>
shadowfirebird
comfort and I'm starting to assume that the default internal response
to one of my posts is 'oh god, him again'. Thing is, I'm passionate
about having Diaspora, or something like it, working and viable. So I
tend to get carried away.
I think it's fair to say I had misunderstood your position. It
certainly does not have to be a browser for me, either, and I agee
that the api/protocol is more important than the software.
The problem with all this hedging is that in order for e2ee to work,
you need to secure *both ends*. There is little point in saying that
I have the option of hosting my own seed for extra security, because
unless everyone else I talk to does that too, no extra security
actually happens.
eveclatrel
worried that people will become discouraged with trying to implement
e2ee. We need passion and we need vocal and we need to not give this
point up. It is what will make or break Diaspora, which I feel
strongly about too.
I agree 100% that hosting your own seed is not the answer to e2ee, but
it is something I will encourage others to try and do. The e2ee
movement's slogan should be, "trust your friend, not their pod".
shadowfirebird
> it is something I will encourage others to try and do. The e2ee
> movement's slogan should be, "trust your friend, not their pod".
Dan White
>Call me crazy, but every time I look at a security issue with
>Diaspora, the first thing I think of is "How does it work with email
>servers?" In terms of e2ee I think there might be some value to be had
>by treating the pods like email servers for the design. While that
>particular wheel may not work perfectly, it does work pretty darn
>good.
I think email is a questionable model to use, unless you include GPG
encryption into the mix. SMTP is terribly broken in my humble opinion.
On 26/09/10�00:16�-0700, shadowfirebird wrote:
>Many thanks for the thanks; I post far too often here for my own
>comfort and I'm starting to assume that the default internal response
>to one of my posts is 'oh god, him again'. Thing is, I'm passionate
>about having Diaspora, or something like it, working and viable. So I
>tend to get carried away.
>
>I think it's fair to say I had misunderstood your position. It
>certainly does not have to be a browser for me, either, and I agee
>that the api/protocol is more important than the software.
>
>The problem with all this hedging is that in order for e2ee to work,
>you need to secure *both ends*. There is little point in saying that
>I have the option of hosting my own seed for extra security, because
>unless everyone else I talk to does that too, no extra security
>actually happens.
I agree to a point. A site that does not participate in end-to-end security
opens itself up to problems when/if they encounter security problems, like
the kind Facebook and Twitter still experience today, with a 7+ figure
operational and development budget.
End to end security is the open source response to the
security-through-budget approach of much bigger services.
However, there's still something to be said for having a secure network
protocol that guarantees privacy and integrity (given all players meet a
minimum set of criteria for playing).
--
Dan White
eveclatrel
On Oct 3, 12:22 am, Dan White <dwh...@olp.net> wrote:
> On 25/09/10 22:49 -0700, eveclatrel wrote:
> >Call me crazy, but every time I look at a security issue with
> >Diaspora, the first thing I think of is "How does it work with email
> >servers?" In terms of e2ee I think there might be some value to be had
> >by treating the pods like email servers for the design. While that
> >particular wheel may not work perfectly, it does work pretty darn
> >good.
>
> I think email is a questionable model to use, unless you include GPG
> encryption into the mix. SMTP is terribly broken in my humble opinion.
>
transport protocol, and not the overall component of email and the
servers. To ensure your information is really secure from prying eyes
or abuse you have to encrypt it and that is not effectively done at
the server level, otherwise you have the same issue Diaspora faces
with an unscrupulous administrator. The model is all inclusive of the
email client, protocol, server and the solutions that each employs.
How they addressed spam has almost nothing to do with SMTP, it uses
filters at client and server levels, DNS and blacklists. It wasn't
that great, but our authentication ideas will solve the majority of
those. SMTP is probably busted for the day and age we live in, and I
doubt the protocol itself will be that useful to us, but the rest of
it might have the occasional solution for us to start from.