Katzenpost is a software project dedicated to designing and implementing mix network protocols. A mix network is a type of anonymous communication network. An anonymous communication network is also known as a traffic analysis resistant network; that is, it's protocols are designed to resist statistical analysis by passive global adversaries.
Traffic analysis typically refers to the statistical analysis of encrypted traffic. Traffic analysis is worth defending against given that common network protocols leak lots of information such as source and destination IP addresses, message size, message sequence, message delay pattern, geographical locations, social graph etc. Mere end to end encryption alone cannot protect against this type of information leakage.
At the most basic level, mixnets are composed of mix nodes. These are a cryptographic packet switching routers which protect our privacy by mixing many messages together and cryptographically transforming them before routing them on to the next hop. Mix nodes also use shuffling or added latency to create uncertainty for network observers. This uncertainty is in regards to trying to link incoming messages with the outgoing messages.
Many excited new changes are forthcoming! You can watch our progress being tracked, here:
https://github.com/orgs/katzenpost/projects/6/views/5
There are essentially two types of interaction with a Katzenpost mixnet:
There is a proxy client application that exposes a SOCKS5 proxy. A publicly reachable testnet instance configuration is baked into the binary when you build it.
apt install -y make podman git git clone https://github.com/CloakedServices/CloakedNetworkPOC cd CloakedNetworkPOC podman build -f cloakedproxy/Dockerfile -t gobuild podman run --rm -i -v $(pwd):/build/demo --workdir /build/demo -t gobuild sh -c "cd cloakedproxy && make warped=false" ./cloakedproxy/cloakedproxy -help
By default, it will listen on 127.0.0.1:4242 and exit traffic from the demo instance. (If this doesn't work, this instance has probably been halted)
You can run a local (or publicly reachable) copy of the network by:
git clone https://github.com/CloakedServices/CloakedNetworkPOC cd CloakedNetworkPOC/docker make mu=0.06 warped=false onlyTransports=tcp4 muMax=50 lP=0.4 lPMax=20 log_level=NOTICE UserForwardPayloadLength=6000 bind_addr="YOUR_PUBLIC_IPV4_HERE" clean-local start
A generated client configuration file can be found in CloakedNetworkPOC/docker/voting_mixnet/client/client.toml, which can be consumed by ./cloakedproxy -cfg
'warped=false' means to run your testnet with the default Epoch (key rotation period) of 20 minutes, and will take a while to bootstrap before it will be usable. 'warped=true' means to run your testnet with a 2 minute Epoch for local or CI testing. The other runtime variables are passed to CloakedNetworkPOC/genconfig which generates the testnet configuration.
Our docker configuration is the most comprehensive and up to date place to learn about how to configure a Katzenpost mix network. Run the makefile in the docker directory to get a usage menu:
$ cd katzenpost/docker; make
These make targets allow you to control the test network:
run - run the testnet in the foreground, until ctrl-C
start - start the testnet in the background
stop - stop the testnet
wait - wait for testnet to have consensus
watch - tail -F all logs
status - show testnet consensus status
show-latest-vote - does what it says
run-ping - send a ping over the testnet
clean-local - stop, and delete data and binaries
clean-local-dryrun - show what clean-local would delete
clean - the above, plus cleans includes go_deps images
You can run a docker mixnet locally and then inspect the configuration files to learn how to configure a Katzenpost mixnet.
Documentation is a work in progress:
Katzenpost is an unverified decryption mix network that uses a continuous time mixing strategy with client selected exponential delays and a stratified (layered) topology.
Our documentation is in progress, but we have some resources for experts:
Our threat model document, work-in-progress, can be found here.
Our design specification documents are available here.
Every component in a Katzenpost mix network uses our "wire" protocol, the protocol that sits on top of either TCP or QUIC, is a cryptographic protocol based on Noise:
We believe in the Noise cryptographic protocol framework, that it is good to use it instead of TLS, whenever possible. Noise places all of the protocol decision making during the design phase of the protocol instead of during protocol runtime. This means there are no protocol downgrade attacks, no dynamic selection of ciphersuite and so on.
However, we use a variation of Noise called Post Quantum Noise, from the paper:
@misc{cryptoeprint:2022/539,
author = {Yawning Angel and Benjamin Dowling and Andreas Hülsing and Peter Schwabe and Florian Weber},
title = {Post Quantum Noise},
howpublished = {Cryptology ePrint Archive, Paper 2022/539},
year = {2022},
doi = {10.1145/3548606.3560577},
note = {\url{https://eprint.iacr.org/2022/539}},
url = {https://eprint.iacr.org/2022/539}
}
The precise Noise protocol descriptor string we use is:
Noise_pqXX_Kyber768X25519_ChaChaPoly_BLAKE2s
However the hybrid KEM Kyber768X25519 is constructed using a security preserving KEM combiner and a NIKE to KEM adapter with semantic security so that the resulting hybrid KEM is IND-CCA2 in QROM.
Here's a diagram of the pqXX pattern which we use:
sequenceDiagram
Client-)Server: e
Server-)Client: ekem, s
Client-)Server: skem, s
Server-)Client: skem
We use the Sphinx cryptographic packet format and allow it's geometry to be completely configurable to accomodate various networking requirements. Additionally the Sphinx can use any NIKE (non-interactive key exchange). We also developed a novel post quantum variation called KEM Sphinx. KEM (key encapsulation mechanism) Sphinx is twice as fast on the server side as the original NIKE Sphinx because it only requires one public key operation per hop instead of two. However it has the packet header overhead size penalty that grows linearly with the number of hops.
And here are some Sphinx benchmarks using different KEMs and NIKEs:
Primitive | Sphinx type | nanoseconds/op | seconds/op |
---|---|---|---|
X25519 | KEM | 80093 | 8.009×10−5 |
X25519 | NIKE | 160233 | 0.000160233 |
Kyber512 | KEM | 43758 | 4.3758e-5 |
Kyber768 | KEM | 57049 | 5.7049e-5 |
Kyber1024 | KEM | 72173 | 7.2173e-5 |
Kyber768 X25519 Hybrid | KEM | 87816 | 8.7816e-5 |
CTIDH512 | NIKE | 336995975 | 0.336995975 |
CTIDH1024 | NIKE | 18599579037 | 18.599579037 |
CTIDH2048 | NIKE | 17056742100 | 17.0567421 |
CTIDH1024 | KEM | 11408217346 | 11.408217346 |
We can draw several conclusions from this table of benchmarks:
Please also note that hybrid KEMs referred to above are constructed using a security preserving KEM combiner and a NIKE to KEM adapter with semantic security so that the resulting hybrid KEM is IND-CCA2 in QROM.
Mix network key management and distribution is handled by the directory authority system, a decentralized voting protocol that can tolerate (1/2 * n)-1 node outages. Clients and mix nodes can talk to the dirauth system to get a published PKI document which is essentially a view of the network which contains public cryptographic keys and network connection information.
AGPLv3
Your donations are welcomed and can be made through Open Collective here.
This project has received funding from: