cpl/cryptor

Privacy, Anonymity, Freedom - P2P network

---

Introduction

Cryptor is an overlay P2P network that values your privacy and anonymity above all else. When faced with a tradeoff between the user’s privacy and convenience, privacy comes on top.

To achieve it’s level of security and privacy, a few key concepts are enforced:

• Obscurity is not security. Do not assume that you’re secure because somebody does not know the rules you play by.
• Silence is a virtue. Do not respond to any invalid or unexpected requests, this allows you to hide from mass scanning attempts and some other attacks.
• Less is more. The less information you have to send, the better. The protocol only needs to send as little as possible.
• Deceive. Sending only requested data to your peers puts you at risk. Cryptor nodes will send random and decoy packets across the network to make the real ones harder to detect.
• 0 Pattern. Some ISPs and companies use advanced heuristics and ML tools to detect certain unwanted traffic and block it. By having random packet sizes and encrypted payloads makes Cryptor harder to pinpoint.

For more information check out the official documentation or the Discord server.

Install

Cryptor as a package only provides the backend stack for accessing the network and managing local resources. The Cryptor clients are developed under cryptor/cmd. Each client has its own binary and installation routine.

Visit the official documentation for a list of all clients are their purpose/usage.

Download Binaries

You can download pre-compiled binaries from the GitHub Releases page. Always check checksum of what you download, and only download official binaries from the GitHub repo.

Go Get

If you have Go installed, you can use go get. Running go get cpl.li/go/cryptor will download the entire Cryptor package and all clients. To download and install a specific client use go get cpl.li/go/cryptor/cmd/<CLIENT NAME>.

Manually

Git clone the project and use the Makefile provided for each individual client or package. For detailed instruction read the official documentation.

Usage

The main Cryptor client is aegis. // TODO

Documentation

• Official documentation
• Contribution guide

References

• RFC 5869 - HKDF
• RFC 7693 - BLAKE2 MAC
• RFC 2898 - PKCS
• WireGuard Whitepaper
• Noise Protocol Framework
• Tor
• Freenet

cryptor's Issues

Looking for developers and contributors

Developers: Security, Networking, Blockchain, Cryptography
Contributors: Anything really (PR, Research, Documentation, Code review)

Improve Aegis command helpMessage

The current structure of the Aegis command is:

type command struct {
	description string
	exec        cmdFunc
	helpMessage string
}

The helpMessage string could be replaced with a func() string, this would allow for a much easier and prettier individual command help message print.

Benchmark BIP39

#benchmark #tests

Write benchmarks for crypt/mwords and compare it with github.com/tyler-smith/go-bip39.

Buffer the Go channels used by p2p/node

Currently for testing only, the chan fields of Node are not buffered, meaning they block until read from. For the production ready version, these channels need to be buffered. It's only a question of how much memory should be assigned to each channel?

Could possibly tie in with #19

Introductory Documentation

#docs

Improve the first image people get of Cryptor. A description, introduction and explanation of the why, how and direction of Cryptor. This includes README files, blogs, code of conducts and contribution guides.

• Write contribution guide
• Write README.md
• Write code of conduct
• Create means of communication

Implement /x/sync/semaphore for p2p/node

Using a semaphore can allow a limit to the number of ongoing concurrent actions and easy checking of running tasks.

https://godoc.org/golang.org/x/sync/semaphore

Integrate handshake protocol

#node #proto #p2p

Integration of p2p/noise and p2p/packet into p2p/node will allow a node to automatically handle incoming handshake messages, lookup peers and take decisions based on that.

Sending handshake messages and handling timeouts will also be part of this integration.

• Full test coverage for p2p/node
• Integrate send handshake
• Integrate receive handshake
• Implement transport message handling
• Implement handshake finalisation
• Rework Handshake struct state
• Rework Handshake Message serialisation
• Rework Handshake Message struct
• Implement timeout for different in network protocol
• Change lookup from address string to ID int64

Improve "expected %d, got %d" type tests with single function

Add Cryptor to the Up For Grabs project list

Before adding Cryptor to the list, I wish for the project and its documentation to grow more.

https://github.com/up-for-grabs/up-for-grabs.net#add-a-project
https://up-for-grabs.net/#/

PROJECT IS ON HOLD UNTIL I HAVE THE TIME AND RESOURCES TO DEVELOP IT

Re-design integration between chans, goroutines and sync elements

In order to have a nice idiomatic code and optimised concurrency that doesn't bottleneck where it doesn't have to. This can be achieved by:

• Having well defined buffers for the channels.
• Well defined separation of channels and handler go-routines.
• Proper use of sync elements

Related to #31 #27

Replace sync.RWMutex protected maps with sync.Map

The sync package offers a Map implementation which may provide better performance.

https://golang.org/pkg/sync/#Map

State transition map for handshake protocol

#docs #noise #handshake

Create state map representation for handshake protocol. Display on the digram clearly all the possible states, their associated errors and exception cases.

Place the digram on the wiki page for p2p/noise.

Make handshake undistinguishable

#proto #p2p

The current handshake protocol uses a static message length which is easy to detect, this can be avoided by checking and assuming traffic from unknown senders as handshake messages. This adds a tiny amount of overhead but helps towards the milestone.

Looking for help with either CLI or GUI

Frontend or command line interfaces are definitely not my strong point. If somebody wishes to mock how the interface would look or work, I can provide a nice and simple API.

Introductory Documentation

Improve the first image people get of Cryptor. A description, introduction and explanation of the why, how and direction of Cryptor. This includes README files, blogs, code of conducts and contribution guides.

• Write README.md

Write tests for Node recv and send

#node #test

Test the internal send and recv with custom Packets

Add t.Parallel to certain tests

Create level based logging

#config #node #log

Relates to #19 (Node configuration).

The possible logging levels would be:

• Debug
• Info
• Warning
• Error
• Silent

ldbcache.Manager missing Close() method

Build tags system for testing

#tests #golang #build

Determine a system to tag files with golang build tags in order to separate tests with intended risk of race conditions from normal tests.

Golang Build

Add node.Node means of configuration

#node #config

The Node struct requires a way to configure different aspects of it such as (but not exclusive to):

• Logger
• Pre-Shared key
• Private key
• Metadata

The ways a node could be configured are:

• Using a wizard
• Using an encrypted config file