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

RFC: Private Networks (aka PNet) #10

Merged
merged 1 commit into from
Oct 10, 2018
Merged

Conversation

Kubuxu
Copy link
Member

@Kubuxu Kubuxu commented Feb 21, 2017

No description provided.

@ghost ghost self-requested a review February 21, 2017 03:09
@Kubuxu
Copy link
Member Author

Kubuxu commented Mar 7, 2017

Can someone take a look at this?

Copy link
Member

@daviddias daviddias left a 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.
Copy link
Member

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.

Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

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'

@daviddias
Copy link
Member

there you go @Kubuxu :)

@Kubuxu Kubuxu self-assigned this Mar 7, 2017
@ghost ghost mentioned this pull request Mar 16, 2017
8 tasks
@daviddias
Copy link
Member

daviddias commented Jul 8, 2017

@Kubuxu anything blocking you from finishing this one?

@Kubuxu
Copy link
Member Author

Kubuxu commented Jul 8, 2017

Sorry, forgot about this a bit.

@daviddias daviddias changed the title Add inital PNet spec Private Networks (aka PNet) Specification Jul 8, 2017
@daviddias daviddias changed the title Private Networks (aka PNet) Specification RFC: Private Networks (aka PNet) Jun 3, 2018
@daviddias
Copy link
Member

@jacobheun, given that you have been implementing Private Networks for js-libp2p, how do you feel about the current state of the spec?

@jacobheun
Copy link
Contributor

@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 Networks

This specification details the design and usage of Pre-shared Key Based Private Networks, or PSK Network, in IPFS.

Encryption

  • A PSK Network handles stream encryption via the XSalsa20 cipher.
  • All network traffic, aside from the initial exchange of Nonce's, is encrypted.
  • Authenticity of data is not performed by the PSK Network and should be handled by a separate encryption suite such as secio or TLS1.3 (when available).

Enforcement

  • A node exposed to the environment variable LIBP2P_FORCE_PNET=1 when started, must enforce the existence of a PSK Network compliant protector.
    • If enforcement is turned on, and no protector is provided, the node must terminated immediately.

Private Shared Key

  • A Private Shared Key is made available to the IPFS node, by adding a swarm.key file to the root of the IPFS Repo, prior to node creation.
  • The key file must comply to the format detailed at Private Shared Key Format

Private Shared Key Format

  • The Private Shared Key file, swarm.key, should contain 3 lines.
    • Line 1 should define the path-based multicodec for the key, /key/swarm/psk/1.0.0/.
    • Line 2 should define the path-based multicodec in which the rest of the file is encoded, such as /base16/.
    • Line 3 should contain the 32 byte Private Shared Key used for the private IPFS nodes, which should be encoded based on the above multicodec.
PSK File Example

This example is for illustration purposes only. DO NOT USE THIS KEY FOR PRODUCTION!!!

/key/swarm/psk/1.0.0/
/base16/
0ff05394c733304ec26b3861ef23a4ffef9cd2e7d2040e028e5e9bb321d2eea3

Further Reading

You can review the original proposal and decisions at (insert place/s of the proposal and discussions had).

@daviddias
Copy link
Member

daviddias commented Jun 25, 2018

Posting here the url to today's Private Networks on js-libp2p/js-ipfs from @jacobheun https://youtu.be/fObld4alGag?t=47 \o/!

@daviddias
Copy link
Member

Important to be on the radar of this group - ipfs/notes#177

@jacobheun
Copy link
Contributor

I am going to merge this and will create a new PR with updates.

@jacobheun jacobheun merged commit 67bd940 into master Oct 10, 2018
@ghost ghost removed the in progress label Oct 10, 2018
@daviddias daviddias deleted the feat/pnet/inital-spec branch October 10, 2018 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants