Private/personal use of ipfs?

Help Old FAQ
1

From @e12e on Sun Apr 05 2015 20:44:27 GMT+0000 (UTC)

There’s a reference to using ipfs as a personal filesytem. Does this mean the go-implementation supports setting up a private swarm?

Can I run ipfs on my server with a few tb of disk at a hosting provider, and on my home-server in order to have two mirrors, and additionally on my workstation for pushing data (use my personal swarm as backup, with the benefit of local caching)? Can I do this easily, and still know that my data is secure (in transit etc)?

Are there any way to secure an ipfs daemon, only allowing a select few to access the data? Is there a scaleable way to do this (eg: groups/ACLs, rather than “list of keys”)?


Copied from original issue: https://github.com/ipfs/faq/issues/4

2

From @whyrusleeping on Mon Apr 06 2015 00:05:52 GMT+0000 (UTC)

Currently, we cannot guarantee that other nodes cannot connect to you, (we are planning on having such a feature). The best you can do currently is set all your nodes to bootstrap to eachother (and not our public bootstrap nodes) and hope that nobody else does an ‘ipfs swarm connect’ on your peer.

3

From @jbenet on Mon Apr 06 2015 03:06:10 GMT+0000 (UTC)

> Does this mean the go-implementation supports setting up a private swarm?

this is a feature-set we care about supporting though, so we’ll build facilities to let users make it easier to easily organize private networks.

One easy hack you might try right now is to firewall your nodes off-- i.e. only allow traffic you want to allow.

Bootstrap

we still need to do an example (see Bootstrapping ¡ Issue #3 ¡ ipfs-inactive/examples ¡ GitHub) but poke at ipfs bootstrap --help

Are there any way to secure an ipfs daemon, only allowing a select few to access the data? Is there a scaleable way to do this (eg: groups/ACLs, rather than “list of keys”)?

Yeah ACLs + capabilities will be part of ipfs-- this is a bit low on our PQ right now though-- (feel free to take a stab at it though-- i can lift up specs around this if you want to)

4

From @giodamelio on Wed May 06 2015 07:34:11 GMT+0000 (UTC)

:+1: to this. I have been looking for a durable long-term data storage system for a long time, and ipfs seems perfect. I would love to be able to setup a private system with a couple of servers and a local copy.

5

From @typesend on Wed Jun 10 2015 19:55:38 GMT+0000 (UTC)

:+1: to this

6

From @harlantwood on Wed Jun 10 2015 21:50:50 GMT+0000 (UTC)

You might want to also check out Camlistore, which is similar to IPFS in many ways, and designed from the ground up as a personal storage system.

7

From @anderejd on Thu Sep 24 2015 10:41:28 GMT+0000 (UTC)

@harlantwood Thank you! I will give Camlistore a try.

8

From @dpercy on Sat Oct 17 2015 10:38:04 GMT+0000 (UTC)

Would it make sense to for me to encrypt personal files and store them on the public IPFS? That seems simpler to me, since I’d want all my computers connected to the public IPFS anyway. Also since layering an encrypted filesystem on top of IPFS wouldn’t require any changes to the IPFS code.

Or would this be risky or inefficient somehow?

9

From @giodamelio on Sat Oct 17 2015 17:22:49 GMT+0000 (UTC)

It doesn’t seem like it should be an issue. It just add an extra layer of complexity. I have already stored some smallish encrypted backups over IPFS.

10

From @jbenet on Sun Oct 18 2015 05:44:57 GMT+0000 (UTC)

> Would it make sense to for me to encrypt personal files and store them on the public IPFS? That seems simpler to me, since I’d want all my computers connected to the public IPFS anyway. Also since layering an encrypted filesystem on top of IPFS wouldn’t require any changes to the IPFS code.

Or would this be risky or inefficient somehow?

Yep, that works fine, and the way i store + move personal files.

We’ll have native encryption modes later on, but we’ve some more pressing things to do at the moment.

11

From @JayBrown on Thu May 04 2017 15:31:08 GMT+0000 (UTC)

So I assume you can add an encrypted sparsebundle to IPFS, right? In the end (in a Unix sense & from the “outside”) it’s just a directory with files in it. But would it need an ipns entry if I add stuff to its volume or edit files on it? The sparsebundle directory contents will change (at the very least some added files), and then the parent hash will also change, correct?

But is there a way to make another node pin the sparsebundle? If I simply add the sparsebundle, it’ll just stay local, as far as I can gather. If I collaborate on a project, for example, my colleagues will pin my sparsebundle to their ipfs node, and then they can start working on its volume’s contents, when finished, update the ipns etc. But what if it’s just a sparsebundle for my own private stuff? Nobody knows about it, ergo nobody will pin & seed it, i.e. there’s no actual backup of my data in the IPFS swarm. Or am I missing something?

12

From @marcxm on Mon May 29 2017 ca. 13:00:00 CEST (UTC+2)

Have anyone thought for a moment about possible implications of storing encrypted content on a permanent network filesystem like IPFS? You have “versioning” available by default and currently selected crypto may work well, but what about the future? what if currently strong crypto algorithms are being considered weak and easily hackable/decryptable in the future? you won’t be able to remove your “encrypted”, but weakened content from IPFS, per design. How would you protect yourself from information leakage from such - say - containers encrypted with then-weakened algorithms to begin with?

1 Like
13

Thought about this too. As for quantum computers, see this post on asymmetric vs. symmetric algorithms. So SHA-512 (and probably even SHA-256) is still safe, and a DMG with AES-256 encryption still offers the same protection as one with AES-128 today.

As for some additional security, I thought about maybe splitting files at a random point before adding it to the IPFS, so e.g. you first encrypt a DMG or archive as strongly as possible, then split it into at least two parts, then add those two parts to the IPFS. Only you, the originator, or a trusted person will know that those two IPFS hashes belong together.

Question is if there is some record kept on when an object was added to the IPFS by which node, and if that record is public. If so, then such a method probably wouldn’t work. But if it’s an option, you could probably also build it into ipfs, e.g. as ipfs add --split=2 /path/to/file > will output 2 hashes.

Then you could also extend as ipfs concat <Hash-1> <Hash-2> <Hash-n> -o /path/to/file

1 Like
14

Also you can already use ipfs cat <hash1> <hash2> > /path/to/file.

1 Like
15

can someone please write a blog post on how to use IPFS for storing personal files? is there an encryption feature built-in?

creating a private network can do the trick but prefer to have it work the way perkeep does it

1 Like
16

Generally splitting a file into A and B is a good idea, where A have the odd bytes and B have the even bytes. Put XOR:ed keys between in a way that a fast decryption do A[i] + B[i] for each byte i, where + is the XOR operator.

But the idéa of IPFS is filesharing, so there is a risk of finding the two files. Hiding junk should not be possible in a public IPFS - because that could be from attackers. Others have no use of crypted files, so they will not pin it. But… My question is: Can two parties (maybe ones private) or a group pin each other secretly on IPFS? Then this would be doable!