kkv: A Peer-to-Peer Decentralized, Temporary and Anonymous Message System

The KraKomanoVian Message System is a peer-to-peer messaging platform that operates exclusively on the Tor network to guarantee anonymity in communications. Every message sent from the KKV client is protected by four layers of encryption: three from the Tor protocol and an additional layer of ChaCha20-Poly1305. To achieve this, we use X25519, ChaCha20-Poly1305, and Ed25519.

All messages are temporarily stored in RAM until the user shuts down the machine or stops the service. To send a message, users must prove they are legitimate by performing a proof-of-work and validating their identity with the server for each request using the sender's created ed25519 key. Messages are non-repudiable, as they are signed by the sender and can be verified by third parties using the kkv signature.

Anonymous messaging systems currently running on the Tor network offer various features that allow us to communicate securely with third parties. However, they often require us to store our data and messages on third-party servers in a non-temporary manner (writing data to disk), which places a great deal of trust in the mail server and compromises our OpSec.

Additionally, many systems use cryptographic keys that do not change over time, increasing the risk that our entire communication history could be decrypted in the future with the advent of quantum or optical computing. Another factor that can jeopardize security is the centralization of current servers, which creates a single point of failure. Therefore, a decentralized system would be a superior alternative to the current state of affairs.

In light of this, we propose developing a messaging system that overcomes these obstacles, protecting anonymity and the right to privacy. The system will focus on individual responsibility, allowing users to manage their own messaging system without relying on third parties.

Previous Configuration

In your torrc file:

HiddenServicePort 45069 127.0.0.1:45069

Prerequisites

• cargo, curl, tor and torsocks installed

Install and run a kkv server and client

cargo install kkv

or

git clone https://gitlab.com/mateolafalce/kkv.git && cd kkv

cargo install --path .

Run the server

kkv &

Run the client

kkvc

End server process

pkill kkv

Compile and run a kkv server and client

cargo build --release

./target/release/kkv

./target/release/kkvc

Flags and Help

Usage: kkvc [OPTIONS]

Options:
  -m, --max-messages <MAX_MESSAGES>    The maximum number of messages you want to store
  -c, --cost-pow <COST_POW>            The cost of the Proof of Work that will be sent to the client
  -e, --expected-time <EXPECTED_TIME>  The expected time to solve the proof of work in seconds
  -h, --help                           Print help
  -V, --version                        Print version

--max-messages flag: You can specify the maximum number of messages you want to temporarily store in RAM. By default, it is set to a maximum of 50 messages. However, you can adjust this to meet your needs. Keep in mind that a message can be up to 511 bytes in size and as small as 105 bytes.

--cost-pow flag: You can specify the cost of the proof-of-work. By default, it is set to 30, but you can increase or decrease this number depending on your needs. The decision to use 30 by default is because, on everyday hardware, both on PCs and mobile phones, the average time to solve the proof of work ranges from 2 to 4 minutes—a reasonable time to consider a user legitimate. Keep in mind that if you increase the proof-of-work cost, you should also need to increase the expected time (--expected-time).

--expected-time flag: You can specify the client's waiting time for proof-of-work completion and message reception. By default, it is set to 480 seconds (8 minutes), considering that the average proof-of-work time for standard hardware ranges from 2 to 4 minutes. If the estimated time is set too low, there is a risk that clients may not be able to deliver the proof of work and messages on time, making communication impossible. To address this issue, you could lower the proof-of-work cost.

kkv specification

The kkv protocol is based on a client-server architecture and runs on port 45069. It defines 7 HTTP methods: 4 dedicated to data exchange with message senders and 3 dedicated to managing client information. Every message have a maximun size of 1024 characters.

GET /get_domain_pk: Returns a Ed25519 public key, which is later used by the server and the client to validate future digital signatures. Every time the user restart the server, a new Ed25519 keypair will be created.

POST /pow: Receives the Ed25519 public key bytes as a parameter, indicating that the client wants to establish communication. It returns an array containing [the bytes to be searched in the PoW, the cost of the proof of work, the public key of the client requesting communication, and a timestamp indicating the maximum time allowed to complete the PoW]. This array is then digitally signed to validate the client as legitimate in /exchange_keys. The blake3 hash function is used for the proof of work.

POST /exchange_keys: Verifies that the proof of work is valid, has been signed by the client, and that it is within the time frame signed by the server. If all conditions are met, key pairs are exchanged to enable message encryption.

POST /msg: Receives the ciphertext, the signature of the ciphertext, and the public key of the client. The message is validated and decrypted. If the process is successful, the message is temporarily stored in the server's RAM.

GET /status: Returns the server's status. If the server is active, it responds with StatusCode::OK.

POST /get_msg: Returns the stored messages on the server to localhost based on the requested index. If verification fails, access is denied.

POST /read_msg: Changes the status of a message from "unread" to "read," based on its index in the array.

POST /del_msg: Delete a message based on its index in the array.

Secure Messaging with X25519, ChaCha20-Poly1305, and Ed25519

1. Session Key Generation (X25519 - ECDH)

To establish a secure communication channel, both parties generate an ephemeral public/private key pair and derive a shared secret:

• The client generates a public key and sends it to the server.
• The server, using its private key and the received public key, derives a shared session key.
• The client does the same operation using the server’s public key.
• As a result, both parties now share the same secret key without having transmitted it directly.

By policy, a new key pair is generated for each message to ensure forward secrecy. This prevents any potential future compromise of a key from affecting past communications.

2. Message Encryption with ChaCha20-Poly1305

Once the shared key is derived, the message is encrypted using ChaCha20-Poly1305, a fast and secure authenticated encryption algorithm.

3. Message Signing with Ed25519

To ensure authenticity and integrity:

• The sender signs the encrypted message using its private Ed25519 key.
• This signature allows the recipient to verify that the message has not been altered and originates from the expected sender.

4. Message Transmission

The sender transmits the following components:

• The encrypted message
• The digital signature

5. Decryption and Verification by the Receiver

Upon receiving the message, the recipient:

• Uses its private key and the sender's public key to derive the same shared secret.
• Decrypts the message using ChaCha20-Poly1305.
• Verifies the digital signature with the sender's Ed25519 public key.

By combining X25519 for key exchange, ChaCha20-Poly1305 for encryption, and Ed25519 for authentication, this system provides a highly secure messaging protocol suitable for privacy-sensitive communications. And if we use it for PGP/GPG encrypted messaging, we achieve a state-of-the-art, secure, anonymous, and temporary system for our day-to-day.

Screenshots