plugeth/swarm/pss
Felix Lange 30cd5c1854
all: new p2p node representation (#17643)
Package p2p/enode provides a generalized representation of p2p nodes
which can contain arbitrary information in key/value pairs. It is also
the new home for the node database. The "v4" identity scheme is also
moved here from p2p/enr to remove the dependency on Ethereum crypto from
that package.

Record signature handling is changed significantly. The identity scheme
registry is removed and acceptable schemes must be passed to any method
that needs identity. This means records must now be validated explicitly
after decoding.

The enode API is designed to make signature handling easy and safe: most
APIs around the codebase work with enode.Node, which is a wrapper around
a valid record. Going from enr.Record to enode.Node requires a valid
signature.

* p2p/discover: port to p2p/enode

This ports the discovery code to the new node representation in
p2p/enode. The wire protocol is unchanged, this can be considered a
refactoring change. The Kademlia table can now deal with nodes using an
arbitrary identity scheme. This requires a few incompatible API changes:

  - Table.Lookup is not available anymore. It used to take a public key
    as argument because v4 protocol requires one. Its replacement is
    LookupRandom.
  - Table.Resolve takes *enode.Node instead of NodeID. This is also for
    v4 protocol compatibility because nodes cannot be looked up by ID
    alone.
  - Types Node and NodeID are gone. Further commits in the series will be
    fixes all over the the codebase to deal with those removals.

* p2p: port to p2p/enode and discovery changes

This adapts package p2p to the changes in p2p/discover. All uses of
discover.Node and discover.NodeID are replaced by their equivalents from
p2p/enode.

New API is added to retrieve the enode.Node instance of a peer. The
behavior of Server.Self with discovery disabled is improved. It now
tries much harder to report a working IP address, falling back to
127.0.0.1 if no suitable address can be determined through other means.
These changes were needed for tests of other packages later in the
series.

* p2p/simulations, p2p/testing: port to p2p/enode

No surprises here, mostly replacements of discover.Node, discover.NodeID
with their new equivalents. The 'interesting' API changes are:

 - testing.ProtocolSession tracks complete nodes, not just their IDs.
 - adapters.NodeConfig has a new method to create a complete node.

These changes were needed to make swarm tests work.

Note that the NodeID change makes the code incompatible with old
simulation snapshots.

* whisper/whisperv5, whisper/whisperv6: port to p2p/enode

This port was easy because whisper uses []byte for node IDs and
URL strings in the API.

* eth: port to p2p/enode

Again, easy to port because eth uses strings for node IDs and doesn't
care about node information in any way.

* les: port to p2p/enode

Apart from replacing discover.NodeID with enode.ID, most changes are in
the server pool code. It now deals with complete nodes instead
of (Pubkey, IP, Port) triples. The database format is unchanged for now,
but we should probably change it to use the node database later.

* node: port to p2p/enode

This change simply replaces discover.Node and discover.NodeID with their
new equivalents.

* swarm/network: port to p2p/enode

Swarm has its own node address representation, BzzAddr, containing both
an overlay address (the hash of a secp256k1 public key) and an underlay
address (enode:// URL).

There are no changes to the BzzAddr format in this commit, but certain
operations such as creating a BzzAddr from a node ID are now impossible
because node IDs aren't public keys anymore.

Most swarm-related changes in the series remove uses of
NewAddrFromNodeID, replacing it with NewAddr which takes a complete node
as argument. ToOverlayAddr is removed because we can just use the node
ID directly.
2018-09-25 00:59:00 +02:00
..
client all: new p2p node representation (#17643) 2018-09-25 00:59:00 +02:00
notify all: new p2p node representation (#17643) 2018-09-25 00:59:00 +02:00
testdata all: new p2p node representation (#17643) 2018-09-25 00:59:00 +02:00
api.go swarm: network rewrite merge 2018-06-21 21:10:31 +02:00
ARCHITECTURE.md swarm: network rewrite merge 2018-06-21 21:10:31 +02:00
doc.go swarm: network rewrite merge 2018-06-21 21:10:31 +02:00
handshake_none.go swarm: network rewrite merge 2018-06-21 21:10:31 +02:00
handshake_test.go swarm: network rewrite merge 2018-06-21 21:10:31 +02:00
handshake.go swarm: ctx propagation; bmt fixes; pss generic notification framework (#17150) 2018-07-09 14:11:49 +02:00
ping.go swarm: integrate OpenTracing; propagate ctx to internal APIs (#17169) 2018-07-13 17:40:28 +02:00
protocol_none.go swarm: network rewrite merge 2018-06-21 21:10:31 +02:00
protocol_test.go all: new p2p node representation (#17643) 2018-09-25 00:59:00 +02:00
protocol.go swarm: ctx propagation; bmt fixes; pss generic notification framework (#17150) 2018-07-09 14:11:49 +02:00
pss_test.go all: new p2p node representation (#17643) 2018-09-25 00:59:00 +02:00
pss.go all: new p2p node representation (#17643) 2018-09-25 00:59:00 +02:00
README.md swarm: network rewrite merge 2018-06-21 21:10:31 +02:00
types.go swarm: network rewrite merge 2018-06-21 21:10:31 +02:00
writeup.md all: new p2p node representation (#17643) 2018-09-25 00:59:00 +02:00

Postal Services over Swarm

pss enables message relay over swarm. This means nodes can send messages to each other without being directly connected with each other, while taking advantage of the efficient routing algorithms that swarm uses for transporting and storing data.

CONTENTS

  • Status of this document
  • Core concepts
  • Caveat
  • Examples
  • API
    • Retrieve node information
    • Receive messages
    • Send messages using public key encryption
    • Send messages using symmetric encryption
    • Querying peer keys
    • Handshakes

STATUS OF THIS DOCUMENT

pss is under active development, and the first implementation is yet to be merged to the Ethereum main branch. Expect things to change.

Details on swarm routing and encryption schemes out of scope of this document.

Please refer to ARCHITECTURE.md for in-depth topics concerning pss.

CORE CONCEPTS

Three things are required to send a pss message:

  1. Encryption key
  2. Topic
  3. Message payload

Encryption key can be a public key or a 32 byte symmetric key. It must be coupled with a peer address in the node prior to sending.

Topic is the initial 4 bytes of a hash value.

Message payload is an arbitrary byte slice of data.

Upon sending the message it is encrypted and passed on from peer to peer. Any node along the route that can successfully decrypt the message is regarded as a recipient. Recipients continue to pass on the message to their peers, to make traffic analysis attacks more difficult.

The Address that is coupled with the encryption keys are used for routing the message. This does not need to be a full addresses; the network will route the message to the best of its ability with the information that is available. If no address is given (zero-length byte slice), routing is effectively deactivated, and the message is passed to all peers by all peers.

CAVEAT

pss connectivity resembles UDP. This means there is no delivery guarantee for a message. Furthermore there is no strict definition of what a connection between two nodes communicating via pss is. Reception acknowledgements and keepalive-schemes is the responsibility of the application.

Due to the inherent properties of the swarm routing algorithm, a node may receive the same message more than once. Message deduplication cannot be guaranteed by pss, and must be handled in the application layer to ensure predictable results.

EXAMPLES

The code tutorial p2p programming in go-ethereum by @nolash provides step-by-step code examples for usage of pss API with go-ethereum nodes.

A quite unpolished example using javascript is available here: https://github.com/nolash/pss-js/tree/withcrypt

API

The pss API is available through IPC and Websockets. There is currently no web3.js implementation, as this does not support message subscription.

For golang clients, please use the rpc.Client provided by the go-ethereum repository. The return values may have special types in golang. Please refer to godoc for details.

RETRIEVE NODE INFORMATION

pss_getPublicKey

Retrieves the public key of the node, in hex format

parameters:
none

returns:
1. publickey (hex)

pss_baseAddr

Retrieves the swarm overlay address of the node, in hex format

parameters:
none

returns:
1. swarm overlay address (hex)

pss_stringToTopic

Creates a deterministic 4 byte topic value from input, returned in hex format

parameters:
1. topic string (string)

returns:
1. pss topic (hex)

RECEIVE MESSAGES

pss_subscribe

Creates a subscription. Received messages with matching topic will be passed to subscription client.

parameters:
1. string("receive")
2. topic (4 bytes in hex)

returns:
1. subscription handle `base64(byte)` `rpc.ClientSubscription`

In golang as special method is used:

rpc.Client.Subscribe(context.Context, "pss", chan pss.APIMsg, "receive", pss.Topic)

Incoming messages are encapsulated in an object (pss.APIMsg in golang) with the following members:

1. Msg (hex) - the message payload
2. Asymmetric (bool) - true if message used public key encryption
3. Key (string) - the encryption key used

SEND MESSAGE USING PUBLIC KEY ENCRYPTION

pss_setPeerPublicKey

Register a peer's public key. This is done once for every topic that will be used with the peer. Address can be anything from 0 to 32 bytes inclusive of the peer's swarm overlay address.

parameters:
1. public key of peer (hex)
2. topic (4 bytes in hex)
3. address of peer (hex)

returns:
none

pss_sendAsym

Encrypts the message using the provided public key, and signs it using the node's private key. It then wraps it in an envelope containing the topic, and sends it to the network.

parameters:
1. public key of peer (hex)
2. topic (4 bytes in hex)
3. message (hex)

returns:
none

SEND MESSAGE USING SYMMETRIC ENCRYPTION

pss_setSymmetricKey

Register a symmetric key shared with a peer. This is done once for every topic that will be used with the peer. Address can be anything from 0 to 32 bytes inclusive of the peer's swarm overlay address.

If the fourth parameter is false, the key will not be added to the list of symmetric keys used for decryption attempts.

parameters:
1. symmetric key (hex)
2. topic (4 bytes in hex)
3. address of peer (hex)
4. use for decryption (bool)

returns:
1. symmetric key id (string)

pss_sendSym

Encrypts the message using the provided symmetric key, wraps it in an envelope containing the topic, and sends it to the network.

parameters:
1. symmetric key id (string)
2. topic (4 bytes in hex)
3. message (hex)

returns:
none

QUERY PEER KEYS

pss_GetSymmetricAddressHint

Return the swarm overlay address associated with the peer registered with the given symmetric key and topic combination.

parameters:
1. topic (4 bytes in hex)
2. symmetric key id (string)

returns:
1. peer address (hex)

pss_GetAsymmetricAddressHint

Return the swarm overlay address associated with the peer registered with the given symmetric key and topic combination.

parameters:
1. topic (4 bytes in hex)
2. public key in hex form (string)

returns:
1. peer address (hex)

HANDSHAKES

Convenience implementation of Diffie-Hellman handshakes using ephemeral symmetric keys. Peers keep separate sets of keys for incoming and outgoing communications.

This functionality is an optional feature in pss. It is compiled in by default, but can be omitted by providing the nopsshandshake build tag.

pss_addHandshake

Activate handshake functionality on the specified topic.

parameters:
1. topic (4 bytes in hex)

returns:
none

pss_removeHandshake

Remove handshake functionality on the specified topic.

parameters:
1. topic (4 bytes in hex)

returns:
none

pss_handshake

Instantiate handshake with peer, refreshing symmetric encryption keys.

If parameter 3 is false, the returned array will be empty.

parameters:
1. public key of peer in hex format (string)
2. topic (4 bytes in hex)
3. block calls until keys are received (bool)
4. flush existing incoming keys (bool)

returns:
1. list of symmetric keys (string[])

pss_getHandshakeKeys

Get valid symmetric encryption keys for a specified peer and topic.

parameters:

  1. public key of peer in hex format (string)
  2. topic (4 bytes in hex)
  3. include keys for incoming messages (bool)
  4. include keys for outgoing messages (bool)

returns:

  1. list of symmetric keys (string[])

pss_getHandshakeKeyCapacity

Get amount of remaining messages the specified key is valid for.

parameters:
1. symmetric key id (string)

returns:
1. number of messages (uint16)

pss_getHandshakePublicKey

Get the peer's public key associated with the specified symmetric key.

parameters:
1. symmetric key id (string)

returns:
1. Associated public key in hex format (string)

pss_releaseHandshakeKey

Invalidate the specified key.

Normally, the key will be kept for a grace period to allow for decryption of delayed messages. If instant removal is set, this grace period is omitted, and the key removed instantaneously.

parameters:
1. public key of peer in hex format (string)
2. topic (4 bytes in hex)
3. symmetric key id to release (string)
4. remove keys instantly (bool)

returns:
1. whether key was successfully removed (bool)