New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Private/personal use of ipfs? #4

Closed
e12e opened this Issue Apr 5, 2015 · 19 comments

Comments

Projects
None yet
@e12e

e12e commented Apr 5, 2015

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")?

@e12e e12e referenced this issue Apr 5, 2015

Closed

FAQ questions #16

@whyrusleeping

This comment has been minimized.

Show comment
Hide comment
@whyrusleeping

whyrusleeping Apr 6, 2015

Member

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.

Member

whyrusleeping commented Apr 6, 2015

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.

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Apr 6, 2015

Member

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 ipfs/examples#3) 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)

Member

jbenet commented Apr 6, 2015

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 ipfs/examples#3) 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)

@giodamelio

This comment has been minimized.

Show comment
Hide comment
@giodamelio

giodamelio May 6, 2015

👍 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.

giodamelio commented May 6, 2015

👍 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.

@typesend

This comment has been minimized.

Show comment
Hide comment
@typesend

typesend Jun 10, 2015

👍 to this

typesend commented Jun 10, 2015

👍 to this

@harlantwood

This comment has been minimized.

Show comment
Hide comment
@harlantwood

harlantwood Jun 10, 2015

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.

harlantwood commented Jun 10, 2015

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.

@anderejd

This comment has been minimized.

Show comment
Hide comment
@anderejd

anderejd Sep 24, 2015

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

anderejd commented Sep 24, 2015

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

@dpercy

This comment has been minimized.

Show comment
Hide comment
@dpercy

dpercy Oct 17, 2015

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?

dpercy commented Oct 17, 2015

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?

@giodamelio

This comment has been minimized.

Show comment
Hide comment
@giodamelio

giodamelio Oct 17, 2015

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.

giodamelio commented Oct 17, 2015

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.

@jbenet

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Oct 18, 2015

Member

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.

Member

jbenet commented Oct 18, 2015

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.

@RichardLitt RichardLitt added the answered label May 2, 2016

@JayBrown

This comment has been minimized.

Show comment
Hide comment
@JayBrown

JayBrown May 4, 2017

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?

JayBrown commented May 4, 2017

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?

@flyingzumwalt

This comment has been minimized.

Show comment
Hide comment
@flyingzumwalt
Contributor

flyingzumwalt commented May 23, 2017

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 29, 2017

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?

ghost commented May 29, 2017

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?

@JayBrown

This comment has been minimized.

Show comment
Hide comment
@JayBrown

JayBrown May 29, 2017

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.

JayBrown commented May 29, 2017

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.

@JayBrown

This comment has been minimized.

Show comment
Hide comment
@JayBrown

JayBrown May 29, 2017

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

JayBrown commented May 29, 2017

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

@flyingzumwalt

This comment has been minimized.

Show comment
Hide comment
@flyingzumwalt

flyingzumwalt May 29, 2017

Contributor

@marcxm @JayBrown we have decommissioned the ipfs/FAQ repo and moved everything to discuss.ipfs.io this issue was closed an moved to https://discuss.ipfs.io/t/private-personal-use-of-ipfs/350. If you post you comments there they will be seen by more people.

Contributor

flyingzumwalt commented May 29, 2017

@marcxm @JayBrown we have decommissioned the ipfs/FAQ repo and moved everything to discuss.ipfs.io this issue was closed an moved to https://discuss.ipfs.io/t/private-personal-use-of-ipfs/350. If you post you comments there they will be seen by more people.

@JayBrown

This comment has been minimized.

Show comment
Hide comment
@JayBrown

JayBrown May 29, 2017

Copied the posts over into the other forum.

JayBrown commented May 29, 2017

Copied the posts over into the other forum.

@futpib

This comment has been minimized.

Show comment
Hide comment
@futpib

futpib Jun 11, 2017

If I'm not mistaken, resolving ipfs/go-ipfs#1972 (swarm address whitelist) will basically allow you to use ipfs privately.

futpib commented Jun 11, 2017

If I'm not mistaken, resolving ipfs/go-ipfs#1972 (swarm address whitelist) will basically allow you to use ipfs privately.

@SimonFricker

This comment has been minimized.

Show comment
Hide comment
@SimonFricker

SimonFricker commented Jul 6, 2017

@futpib thank you!

@Kubuxu

This comment has been minimized.

Show comment
Hide comment
@Kubuxu

Kubuxu Jul 6, 2017

Member

Also there is Private Network feature: ipfs/go-ipfs#3397 (comment)

Member

Kubuxu commented Jul 6, 2017

Also there is Private Network feature: ipfs/go-ipfs#3397 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment