This repository is no longer maintained as the main repository.

Efforts will be made to regularly update this repo, but user's should rely on the main repositories:

• GitLab: https://gitlab.com/tini2p/tini2p
• GitHub: https://github.com/tini2p-project/tini2p

tini2p is designed to be a header-only, minimal, modular C++ I2P libary.

See the design document for details on design decisions and project goals.

• Catch2: https://github.com/catchorg/Catch2
• Boost 1.66+: https://github.com/boostorg/boost
• CMake 3.10+: https://cmake.org
• libSodium: https://github.com/jedisct1/libsodium
• LibreSSL: https://github.com/libressl-portable/portable
  • Should work on hosts with OpenSSL, because LibreSSL is drop-in :)
  • May require adding as a submodule pending requirement of Sha3 (Keccak1600)

• NoiseC : https://github.com/tini2p/noise-c
  • Currently using local fork with modifications for NTCP2
  • Possible long-term refactor plans:
    • reimplement in C++ with wrappers around libSodium
    • maintain local refactored NoiseC with only needed components for I2P

git clone --recursive https://github.com/tini2p/tini2p.git

cd /path/to/tini2p

make tests
./build/tini2p-tests

make net-tests
./build/tini2p-net-tests

make coverage
# run lcov + lcov-genhtml, script + CI coming soon

A brief overview of the project file structure (beware somewhat volatile):

• build: Build directory
• cmake: CMake build scripts
• src: Project source code
  • crypto: Cryptographic implementations/wrappers
  • data: Common data structures
  • exception: Exception handling
  • ntcp2: NTCP2 implementation
• tests: Project test suite
  • unit_tests: Unit tests
  • net_tests: Networking tests

tini2p follows a header-only library design, enabling developers to interact with the I2P network without needing a separate binary.

All test code also serves as examples for how to use/integrate tini2p.

One of the project goals is to release a reference router for users that prefer to run a binary without integrating into another project.

This project is in its earliest stages, and SHOULD NOT be used when strong anonymity is needed (yet).

Core components:

• NTCP2 transport
• SessionRequest crypto + message processing
• SessionCreated crypto + message processing
• SessionConfirmed crypto + message processing
• DataPhase crypto + message processing
• I2NP message processing
• I2CP message processing
• Garlic encryption
• NetDb
• LeaseSet
  • LeaseSet2
  • EncryptedLeaseSet2 (optional, highly desired)
  • MetaLeaseSet (optional)
• ServiceList (optional)
• RouterInfo
• RouterIdentity
• RouterAddress
• Mapping
• Tunnels
• RouterContext

Client components:

• ClientContext
• ClientDestination
• ClientTunnels
• AddressBook
• I2CP message processing
• Reseed
• Key + config storage
• Proxies
  • SOCKS 4a/5
  • HTTP(S)
  • WebSockets
  • ZMQ
• SAMv3 API

Crypto components:

• X25519 key generation
• X3DH Diffie-Hellman exchange
• Ed25519 key generation, signing/verification
• Base32/64 en/decoding
• Blake2b hashing
• SHA256 hashing + HMAC
• HKDF key derivation
• SipHash obfuscation
• AES key generation, CBC-256 en/decryption
• Ed25519ph key generation, signing/verification
• Ecies-X25519-AEAD-Ratchet-[HKDF-HMAC-Sha256 / HKDF-Blake2b]
  • Basic experimental implementation
  • full implementation pending on finalized Proposal 144
• RedDSA key generation, signing/verification
• XEdDSA key generation, signing/verification

Only one of Ed25519ph or RedDSA need to be implemented for reseed signature processing.

Since RedDSA may also be needed for key blinding, Ed25519ph may be extraneous and unwanted. Ed25519ph has the advantange of standardization, so TBD.

Global components:

• Logging
• Storage: LMDB (AddressBook, NetDb storage)

For those beautiful beings that want to support the cause:

XMR:

• 8ACEQ1HiziMafAnyEdmzL2G99vKNSvRMLDdrmDNCRVczRFpShZA7YvAGzvGH1g8WMQd2iH5REkcwTKMjKCwJWdxHNoUFcGH

BTC:

• 1MNLhCnKpagruVkcGQY4z3GvUN7r4mRdwj

Grin:

• Eepsite: coming soon
• Onion address: coming soon