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ā)?
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.
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)
From @giodamelio on Wed May 06 2015 07:34:11 GMT+0000 (UTC)
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.
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.
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.
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.
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?
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?
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
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.
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.