?

Log in

No account? Create an account

Tue, Oct. 16th, 2007, 09:44 am
So don't mistake it, just try and fake it

I think it's one of the issues that confuses some users of sites - can the people who run the site read their private data. Now most sites will store any passwords hashed and salted but by their very nature entries (posts, comments, photos, tweets, pokes, zombie requests, movies) must be stored in the database completely en clair.

It's logical if you think about it - the text (for example) appears unencrypted on your screen if you're logged in. It must have got that way some how - if the site can decrypt it an display it on your screen then the site's owners can read it.

In practice access to that data is restricted through usual security techniques so there's no need to freak out although you should practice all your standard hygiene just as you would as if you had the data on your laptop - don't leave things that can lead to identity theft or bank fraud lying around.

However, as a gedanken experiment what would it take to have a fully encrypted social software site? There are plenty of reasons why this would be desirable - you reduce the chance of accidental privacy leakage, if hackers ever got into your service's servers and compromised the database then your posts will still be unreadable and there's no chance of the data being subpoenaed.

But if that's the case then why would a site not do it - well, for a start, it would be a resource nightmare and secondly it would be very difficult, usability wise. For those that are interested in the usability of cryptography then there's this fantastic paper called Why Johhny Can't Encrypt - in this case redone as a chapter of an O'Reilly book.

Anyway, so what would be need. Well, for a start it seems clear that we'd need some sort of public-private key system. As a user you would generate a key pair and then upload it to the service. You'd write the post client side, encrypt it with your public key and sign it with your private key (maybe in a Java applet or using a Javascript library) and then post it to the service. To read it you'd retrieve the encrypted post and decrypt it with your private key.

However, as the more astute of you will have noted - this is useless. All it is is a way of storing your posts on the remote server with no one else reading them whereas, in fact what you want is for your friends to read them.

Theoretically what you could do is give all your friends your private key but then they could read all your posts and even post as you. Which is dumb.

So, what we actually need to do is - every time you write a new post we generate a new public-private key pair let's call them priv_tmp and pub_tmp. We then encrypt the signed post with pub_tmp and then encrypt pub_tmp with your original public key (pub_orig) and store them both somewhere.

Now we have an encrypted post in the database which only you can read and write to (by retrieving pub_tmp with priv_orig).

Then, for each of your friends (and yourself presumably) you'd encrypt priv_tmp with their public keys.

Now, if they want to read a post they retrieve the encrypted post and priv_tmp encrypted with their public keys. They use their private keys to retrieve prive_tmp and then use priv_tmp to decrypt the post.

If you want to revoke someone's access to the post then you could just delete the priv_tmp encrypted with their public key. However, if they're unscrupulous then they could have saved priv_tmp so what you'd actually have to do is delete the post and then go through the encryption process again for all your friends minus them.

If you want to give someone permission to read an old post you retrieve priv_tmp and then re-encrypt it using the new person's public key.

Woohoo, that was easy! Ish! Let's go implement it!



...




Spotted the flaw yet?

Yes, any of your friends who have access to read your post can provide access to anybody else which is obviously undesirable.

So there will probably have to be extra steps with signing using private keys. Or alternatively I seem to remember that there was some interesting work being done in this area - I have hazy memories of a diagram of a box with multiple keys or some such but it's all slipped into an alcoholic haze and I'm way out of date with my crypto reading.

Either way I hope I've shown why what may seem simple conceptually is actually hard both theoretically and practically.

And now I have the phrase ♫'Coz there's no end To being your friend♫ stuck in my head.

Wed, Oct. 17th, 2007 12:43 pm (UTC)
wintrmute

Couldn't you just do it like GPG, and generate a unique encryption key for each post, but then provide that key with the post, but encrypted using your friends' public keys?
If you want to add access for a new friend, you'd have to tack on the extra encrypted key to the post, yes.. and revoking their right to read it would be trick (as you say, involving re-encrypting the original to change the overall key).
However, I wouldn't be too worried about that case - because if you gave that user access to read the post in the first place, then in the malicious case, they could have copied the text out then, while they had access. Revoking it later seems like closing the door after the horse has bolted.

Wed, Oct. 17th, 2007 10:09 pm (UTC)
deflatermouse

I'm a little bit dopey today but I don't quite get how that's different to my scheme apart from where the private key is stored.

Either way when you provide the unique encryption key to each of your friends they can always re-encrypt it with someone else's public key and give them access.

Yours has the advantage, I think, that we can validate a user should have access but that doesn't help with malicious intruders. My scheme can also do that by signing the access keys for each user.

Thu, Oct. 18th, 2007 12:11 am (UTC)
wintrmute: why you need a TARDIS

Ah... yes, I think I mis-read part of your original method the first time through. It does look like it's the same, now I'm re-reading with coffee in hand instead of beer.


I keep thinking of this in terms of existing, accepted methods, such as for encrypted email. With PGP/GnuPG, there is always the danger that someone decrypts an email you sent them, and then forwards the plaintext on to Eve.

Defeating that probably has parallels to your question about revoking access to a blog post. However I don't think it's worth the effort - there will always be /some/ way to capture the decrypted result. If you display it so human eyes can read it, then at the least, a digital camera can take a photo of the screen (assuming the reader is special hardware that doesn't run an O/S that lets you screencap or use a runtime debugger/memory viewer). In the case of standard hardware, copy-and-paste usually suffices.

If you give someone access, the only way to truly and surely revoke that access is to go backwards in time and not give them access in the first place. I think. I'm way out of date on cryptography.

Sat, Oct. 27th, 2007 07:51 pm (UTC)
quxx

Playing with similar issue in the context of FireEagle (Yahoo skunkworks-y location broker thingy).

Yes, any of your friends who have access to read your post can provide access to anybody else which is obviously undesirable.


Turns out this is trivially easy to solve.

Wait for it.

Wait for it.

Declare it a feature! Call it a capabilities based privacy model and declare victory. Not even joking.

Sun, Oct. 28th, 2007 10:07 am (UTC)
blech

This is also true of Flickr images, even originals, because they have a "dumb" picture server (as opposed to a "smart" one which, rather than just shipping bits, actually checks who you are). Personally I don't see this one as a problem (and with a site Flickr's size, smart servers get really expensive really quickly), but there are people who do. Mind you, I don't have a lot of sympathy with the "OMG people are stealing my lolcat pictures OH NOES" types on the Forum anyway.