Create a simple testing pipeline with CircleCI with PR and merge hooks for automated testing.

Implement ECDH using secp256k1 for deriving shared keys.

It would be very helpful to start understanding what are the privacy requirements and current vulnerabilities of current projects using IPFS, Dat and other P2P networks. This study could be used as basis for new or improved features of existent p3lib modules.

Double check if using default nonce everywhere is ok in creating the cipher stream for encryption and signatures.

This is a rather large task and comprises almost all the work for this lib.

• define packet structure
• generate ECDH shared secret (crypto, individual pairs)
• generate fillers for each header
• generate shared keys for a given circuit
• generate blinding factors
• packet MAC

Improve validateHeaderInput() which verifies the header before processing it.�

When processing the packets, each hop derives the shared key and then verifies if the key has been used before. If that is the case, it will discard the packet since it may be from a replay/DoS attack. It is important to make sure that the packet processing will happen only after the relay makes sure the packet has not been processed yet. This way, the DoS attack vector is bound to the capacity of the attacker to generate many valid packets with different shared keys between himself and the relay being attacked. The packet construction works effectively as a crypto puzzle to mitigate DoS attacks against relayers.

Is there any other mechanism that could be used? Do we need to add a more expensive puzzle?

The OctopusDHT lookup assumes that active adversaries are detected and removed from the network by turning nodes into "shadow nodes" that use anonymous full routing table requests to verify if other peers are modifying the routing table (active attacks). Should this protocol be implemented too, or should we focus only on the multipath lookup with dummy queries?

Currently, he are using a hack to decode bytes to �multiaddress� in function bytesToAddr().� Fix the hack!

Define the protocol overview and the barebones of the p2lib-sphinx specs.

Other implementations for ideas

• https://github.com/lightningnetwork/lightning-onion
• https://github.com/applied-mixnetworks/rust-sphinxcrypto

This issue is for requesting and discussion ideas about what primitives should be used next. Add a new comment per request and feel free to add more comments for discussion. If you'd like to see on one (or more) of the suggestions prioritised, vote on its comment with a 👍!

Currently, p3lib-sphinx is using only crypto/ecdsa key implementations for ECDSA. The goal is to allow for secure and sensible "bring your own crypto", so the implementation must be abstracted with interfaces.

Check more about criop2p gpestana/notes#21

Hello over there,

I am trying to include this repository to my code using p3lib and have a trouble doing that:

% go build .
go: github.com/hashmatter/[email protected]: parsing go.mod: unexpected module path "p3lib"
go: error loading module requirements

I think it is probably because go.mod currently has module p3lib, but not module github.com/hashmatter/p3lib, but I am not yet completely sure.

Steps to reproduce:

1. Create a new empty go mod project.
2. Try to github.com/hashmatter/p3lib/sphinx
3. Get this error.

Thank you.

Implement packet payload signature and add to specs. Would there be any way to use only one HMAC instead of 2? (header and packet payload)

Refactor to allow developers to use other ciphers than ChaCha20 (similar to #4, but for cipher)

Figure our the best way to save space by encoding the points more efficiently.

IMO libpp is a good name but suspiciously similar to libp2p 😅and might get people confused, specially because some libp2p interfaces will most likely be used. libpp stands roughly for "lib for privacy preserving" and it would be cool to keep the name close to that idea.

How about:

• ppp (as of privacy preserving primitives/protocols)
• 3plib , p3lib (privacy preserving primitives/protocols library)
• ppplib
• libppp
• lib3p

edit: I kinda like p3lib (e.g. p3lib-sphinx, p3lib-componentX,)

i2p's floodfill routers are being attacked:
https://www.reddit.com/r/i2p/comments/10wln04/news_and_weather_updates/

Have you considered a distributed reputation system to prevent malicious routers from joining the DHT?
https://github.com/sahajgarg/ftw-reputation

SURB (single-use-reply-block) allows the last relay to send the response back to the initiator, while respecting the privacy and security properties of onion routing. Using SURBs must be optional.

• add specs
• implementation and testing

As a developer, in libp2p, I'd like to have more control over how much information the lookup protocol leaks and how the lookup peer 'candidate list' is populated. Instead of sending a GET_VALUE request to a peer - which conceals what content ID the initiator is looking for - I'd like to request the peer's full routing table and make the decision locally about how to populate the candidate list.

This changes the Kademlia protocol considerably (as in specs), so I'm thinking of building a simple protocol on top of the current overlay. The idea would to define the protocol /p3lib/rt/1.0.0 that would request the authenticated routing table of a destination peer (how to secure the routing table against bias and other active attacks is another topic to be covered separately).

Having this feature in place is a first step towards implementing a privacy preserving lookup which does not disclose the target ID to a local passive adversary that controls up to 10-20% of network nodes. This lookup protocol is still open to range estimation attacks [ref] when the adversary controls more than one of the peers used to resolve the final peer ID. That can be mitigated by using multiple query paths with dummy requests [ref]. Other protocols can be used to mitigate the range estimation attacks, but the above mentioned mechanism is always a requirement for any DHT lookup protocol that does not leak information about the initiator's interests to local, passive adversaries.

Keeping all non-code related tasks for p3lib-sphinx v0.1:

• Minimum protocol specs in place;
• Interfaces and API documented;
• Code examples;
• Video with example on how to use p3lib-sphinx and libp2p peers;
• Blogpost (why p3lib is important and 1st steps with p3lib-sphinx);

Lay out the specs and interfaces for p3lib-octopusdht. It should be easy to implement and use with libp2p and ipfs.

p3lib-octopusdht is a protocol based on the paper "Secure and Anonymous DHT Lookup"