Authenticate access to IPFS objects

[mildred]

I was thinking last night how it would work if we used IPFS for a private filesystem on a computer, possibly containing private data. The problem I wanted to solve is how to keep a file private when the IPFS protocol implies sharing the file hash with the world in a DHT.

Anyone looking at the DHT would be able to see file hash going around, and they might want to look at them. For example, search engines could do this to index the IPFS Web.

How to make sure that the private key file I stored on my IPFS filesystem will stay private then ? I was thinking of a way to require authentication of an IPFS node before it is allowed to access some objects marked as such.

If we allow arbitrary data to be stored in a node (using IPLD for instance) we could imagine linking any object to an ACL object, which would describe which authentication will be required before a node can grant access to the object. The ACL object will then contain a list of public keys (or link to those) corresponding to allowed nodes.

Now, when a node want to download this specific authenticated object, the owner of that object will first check that the requesting node has the private access corresponding to the public key in the ACL object.

[jbenet]

(this is more a discussion for ipfs/notes)

look into capabilities, and how its done in other FSes. notably, E-rights, Tahoe-LAFS have done tons of work on this. we'll want to follow a similar model.

also worth looking at information flow control generally. i should ask dm what he thinks these days.

In any case, ACLs are a mess to deal with, update, manage, etc, whereas capabilities have been proven to be a much more expressive model, and also a cleaner one. (it's basically all around better, it just didnt get researched before unix was widespread).

How to make sure that the private key file I stored on my IPFS filesystem will stay private then ? I was thinking of a way to require authentication of an IPFS node before it is allowed to access some objects marked as such.

@whyrusleeping and i are working on this now.

@whyrusleeping favors an approach with two separate blockstores in the node. it's easier now so what's what we're pushing for. I favor an approach that uses a "colored graph" (i.e. you color objects to share or to keep private) with one blockstore. this is cleaner, but may be harder to get right at the moment. see #1538

[phoniks]

Where does this issue stand these days?

[Stebalien]

We've talked about this a bit but haven't settled on an approach. There are a bunch of issues around how to "color" blocks and how to deal with information side channels.

For example, let's say that I have a file F covered (colored) by ACL A. Now, I fetch a directory D covered by some other ACL B where D includes F. Ideally, I wouldn't re-download F because I already have it. However, I need some proof that the author of B has F. Otherwise, they could create ACL B and directory D to trick me into giving them access to file F.