-
Notifications
You must be signed in to change notification settings - Fork 272
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
RFC: Private Networks (aka PNet) #10
Conversation
Can someone take a look at this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to have some visual diagram (ASCII art for the win) :D
@@ -0,0 +1,75 @@ | |||
## Pre-shared Key Based Private Networks in IPFS | |||
|
|||
This document describes the first version of private networks (PN) featured in IPFS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of 'first', let's just terminology like 'alpha' that has a clear meaning in software.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should settle on Pre-Shared Key (PSK) or PN for the name, so that there is no ambiguity (I would prefer to call it PSK networks as people know what that means directly from using wifi). We will have other kinds of Private Networks.
|
||
For the first implementation, only pre-shared key (PSK) functionality is available, as the Public Key Infrastructure approach is much more complex and requires more technical preparation. | ||
|
||
It was implemented as an additional encryption layer before any IPFS traffic, and was designed to leak the absolute minimum of information on its own. All traffic leaving the node inside a PN is encrypted and there is no characteristic handshake. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's be explicit here on what kind of information is actually leaked, 'minimum' is a relative measure that tells something different to different users.
I would even make it a table with "PSK ON, PSK OFF" and rows describing what can be eavesdropped.
Also, leak has a very negative connotation, let's use words around 'public' or 'publish' instead.
|
||
### Interface | ||
|
||
An IPFS node or libp2p swarm is either in a a public network, or it is a member of a private network. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/swarm/node
Describe public as "anyone can join" and private as "only authorized people can be part of"
|
||
An IPFS node or libp2p swarm is either in a a public network, or it is a member of a private network. | ||
|
||
A private network is defined by the 256-bit secret key, which has to be known and used by all members inside the network. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/defined/secured
|
||
#### Security Guarantees | ||
|
||
Nodes of different private networks must not be able to connect to each other. This extends to node in private network connecting to node in public network. This means that no information exchange, apart from the handshakeing required for private network authentication, should take place. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
must not be able
suggests that there is no strict guarantee, which comes off in the 'Security Guarantees' section, perhaps 'Security Considerations?'
|
||
Nodes of different private networks must not be able to connect to each other. This extends to node in private network connecting to node in public network. This means that no information exchange, apart from the handshakeing required for private network authentication, should take place. | ||
|
||
These guarnetee is only provided when knowledge of private key is limited to trusted party. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo s/guarnetee/guarantee
|
||
#### Choosing stream ciphers | ||
|
||
We considered three stream siphers: AES-CTR, Salsa20 and ChaCha. Salsa20 and ChaCha are very similar ciphers, as ChaCha is fully based on Salsa20. And unfortunately, due of ChaCha's lack of adoption, we were not able to find vetted implementations in relevant programming languages. Because of this, the final consideration was between AES-CTR and Salsa20. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can remove the 'Because of this'
there you go @Kubuxu :) |
@Kubuxu anything blocking you from finishing this one? |
Sorry, forgot about this a bit. |
@jacobheun, given that you have been implementing Private Networks for js-libp2p, how do you feel about the current state of the spec? |
@diasdavid Overall I think the current spec is a blend of a spec and a proposal. While I think there is a lot of value in understanding the direction behind the eventual spec, I think it would be good to separate those components and make the spec more instructional and specific. Once that's done, the spec could point to the "proposal" or details in a notes section, for further reading. Below is an example of the direction I am thinking, based off of the current spec. If that looks good to everyone, I can put together a full spec proposal. I'd also like it to contain more details on expected behaviors for when a node is unable to decrypt a message (an incompatible private key), just so that behavior is clear (stop talking to the node right away). Pre-shared Key Based Private NetworksThis specification details the design and usage of Pre-shared Key Based Private Networks, or PSK Network, in IPFS. Encryption
Enforcement
Private Shared Key
Private Shared Key Format
PSK File ExampleThis example is for illustration purposes only. DO NOT USE THIS KEY FOR PRODUCTION!!! /key/swarm/psk/1.0.0/
/base16/
0ff05394c733304ec26b3861ef23a4ffef9cd2e7d2040e028e5e9bb321d2eea3 Further ReadingYou can review the original proposal and decisions at (insert place/s of the proposal and discussions had). |
Posting here the url to today's Private Networks on js-libp2p/js-ipfs from @jacobheun https://youtu.be/fObld4alGag?t=47 \o/! |
Important to be on the radar of this group - ipfs/notes#177 |
I am going to merge this and will create a new PR with updates. |
No description provided.