Skip to content
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 networks -- shared key or with a PKI #1633

Closed
whyrusleeping opened this issue Sep 2, 2015 · 12 comments
Closed

private networks -- shared key or with a PKI #1633

whyrusleeping opened this issue Sep 2, 2015 · 12 comments
Labels
need/community-input Needs input from the wider community

Comments

@whyrusleeping
Copy link
Member

No description provided.

@whyrusleeping whyrusleeping self-assigned this Sep 2, 2015
@hmeine
Copy link

hmeine commented Sep 24, 2015

Can you elaborate? I am currently thinking about exchanging private data via IPFS, and how to ensure that the data can stay within a controlled cluster. (Think medical images in a hospital, which has strict requirements w.r.t. leak prevention.)

@jbenet
Copy link
Member

jbenet commented Sep 25, 2015

@hmeine we will allow creation of completely private IPFS networks. the plan is to:

  1. (trivial impl): use a single shared symmetric encryption key, and encrypt the transport with it

  2. (harder impl): use a PKI and only connect to trusted nodes who either

    • (a) present a valid certificate,
    • (b) can be checked online

    (we want to support both PKI use cases because both are good models, with strong proponents and importantly different threat models)

This issue is really about mode (1) (shared key). but we will implement both eventually. (1) should work for you fine, but will leave it up to you to do key rotation to ensure long term security (as nodes join / leave the network, or as human operators join / leave the organization)


tl;dr: once this is fixed, you'll be able to start your nodes with:

ipfs daemon --transport-shared-key <current-key>

and you can rotate <current-key> however you want.

@hmeine
Copy link

hmeine commented Sep 29, 2015

Thanks for the explanation. This would be really useful for our use case, it seems.
It also looks relevant to #961, don't you think?

@jbenet jbenet changed the title private swarms via shared key private networks -- shared key or with a PKI Nov 1, 2015
@scriptjs
Copy link

scriptjs commented May 12, 2016

Hi. You mentioned the end of Sept last year that this was coming soon. Can you provide an update of where we are and how this fits with priorities. Am interested in this and want it to be compatible if possible or contribute. Do you have a blueprint?

@ahnick
Copy link

ahnick commented May 24, 2016

I'm also interested to know the current state of private network support.

@bronger
Copy link

bronger commented Jun 4, 2016

http://ilpubs.stanford.edu:8090/626/1/2003-74.pdf discusses a hierarchical DHT. This generates an onion-like structure of accessability domains. I think this is a very flexible and elegant way to achieve privacy in a distributed system.

Originally, I wanted to implement this from scratch for my usecase (research data publication with institute file space < university file space < global filespace), however, since I found out about IPFS, I wonder whether something like that can also be achieved in the IPFS ecosystem.

@whyrusleeping
Copy link
Member Author

@bronger
Copy link

bronger commented Jul 15, 2016

Where can one comment on this proposal?

@troyronda
Copy link

The thread is here: ipfs/notes#146

@em-ly em-ly added the need/community-input Needs input from the wider community label Aug 25, 2016
@Kubuxu Kubuxu removed their assignment Jan 6, 2017
@salsa-dev
Copy link

salsa-dev commented Jul 20, 2017

👍 Thanks for supporting private ipfs networks with shared key #3697
I'm using it on production to backup large files.

@whyrusleeping
Copy link
Member Author

@salsa-dev Thats great to hear! If you have any feedback on it we would love to hear it here: #3404

@hsanjuan
Copy link
Contributor

hsanjuan commented Apr 3, 2020

I'm closing as the original discussion for this was resolved by choosing shared key, and it is a libp2p-land feature these days anyway.

@hsanjuan hsanjuan closed this as completed Apr 3, 2020
@ajnavarro ajnavarro mentioned this issue Aug 24, 2022
72 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/community-input Needs input from the wider community
Projects
None yet
Development

No branches or pull requests