DEV Community: Zola Gonano

RawLink: Building a VPN Protocol From Scratch

Zola Gonano — Mon, 19 Oct 2026 00:00:00 +0000

I always wanted to give making a new VPN/proxy protocol a shot to understand what happens at the packet level to evade censorship or make a secure tunnel to a server, and to see what it takes to actually design and implement one from scratch.

What I wanted to make was something very simple, something without too much overhead and complication that would still result in a reliable encrypted tunnel that could bypass DPI (deep packet inspection) firewalls and be used as a censorship circumvention tool.

But little did I know how much more complicated it would get than I initially intended. The goal was simple, though: have a simple client-server model in which the user would connect to the client through a SOCKS5 proxy, and the client would send encrypted packets through the established session, encrypting everything with a pre-shared key to keep things simple.

So, with the help of AI (a GLM 5.3-flash model, if you’re wondering), I got to coding, tweaking my designs as I implemented them.

The project became RawLink.

What started as a simple encrypted TCP tunnel eventually grew into a protocol with packet framing, multiplexed streams, authenticated encryption, replay protection, header masking, traffic obfuscation, SSH protocol mimicry, backpressure, connection pooling, and failure detection.

Here, I wanted to write a blog post to explain what’s going on with the protocol and how it works, in case anyone ends up using it, and to share my experience developing something with the assistance of AI.

The original idea

At its core, RawLink follows a client-server model.

The client runs a local SOCKS5 proxy. Applications connect to it as they would connect to any other SOCKS5 proxy, and the client forwards those connections through an encrypted tunnel to a remote server. The server then opens the requested connections and relays data in both directions.

Browser / Application
        |
        | SOCKS5
        v
   RawLink Client
        |
        | Encrypted TCP Tunnel
        |
   RawLink Server
        |
        | Ordinary TCP Connections
        v
   Destination Servers

I chose SOCKS5 because it’s very simple. Using it, the client doesn’t need to understand HTTP or the application-layer protocols being transported. It simply knows where a connection should go and how to move bytes between the local socket and the remote server.

I chose TCP as the carrier protocol because it already handles reliable delivery, ordering, retransmission, and congestion control. Implementing those mechanisms myself would lead to something really messy, unreliable, and overcomplicated, and it wouldn’t be as good.

But it still came with trade-offs, of course. TCP introduces head-of-line blocking, and tunnelling multiple connections through a single TCP connection can make the effects of packet loss much worse.

Beyond encryption

Well, we all know that encryption alone is not enough to bypass sophisticated censorship firewalls. Nowadays, firewalls can identify patterns in encrypted traffic and block it with ease.

Encryption should be there to protect the contents of a connection, though, but it doesn’t automatically hide the fact that a particular protocol is being used. A DPI system still checks packet sizes, timing, framing, handshake patterns, and other characteristics without decrypting a single byte.

For the encryption, I went with AES-256-GCM since most hardware has built-in hardware acceleration for it, and the GCM mode provides authentication for encrypted packets without me having to implement it from scratch.

So, I knew that I needed something beyond just encryption, something to either make the packets look like nothing in particular or make them look like something ordinary (like TLS or, in this case, SSH).

And I ended up with an optional obfuscation layer, but I decided to keep it separate in the architecture. RawLink’s core protocol would handle streams, packets, encryption, and session management, while the optional obfuscation layer would change how those packets are carried over the network, allowing me to add more obfuscation schemes later.

Designing the packet format

The next step was deciding what a packet should actually look like.

I needed enough information in each packet to identify the session, determine the packet’s position in the sequence, and decrypt the payload. At the same time, I wanted to keep the fixed overhead small.

What I ended up with was a packet format that uses a 17-byte header followed by an encrypted body and an authentication tag.

The header contains a protocol version, a key-phase bit, reserved bits, a session identifier, and a packet number. The encrypted body contains the actual protocol frames.

The version field allows incompatible protocol revisions to reject each other. Rather than letting different implementations interpret the same bytes in different ways, a peer that doesn’t understand the version can reject the packet.

The session identifier serves two purposes. It lets the server identify the session, and it contributes to deriving the session’s cryptographic keys. This means that two tunnels using the same PSK don’t automatically end up using identical session keys.

The packet number increments with every packet sent in a particular direction. It gives the receiver a way to track packet progression and provides the input needed to construct a unique nonce for each packet, which is needed for GCM encryption.

At first, I had to keep the header readable because the receiver needs some of this information before it can decrypt the body. That decision would eventually create another problem, which I’ll get to later.

Authenticated encryption

As I said, I ended up with AES-256-GCM for encrypting the packets.

What matters here is the GCM mode, which provides authenticated encryption, meaning the receiver can verify that the ciphertext and the authenticated metadata have not been modified. This is very important for preventing tampering when transferring data.

The header is supplied as additional authenticated data (AAD). Although AAD isn’t encrypted by the AEAD operation, it is bound to the authentication tag. Changing an authenticated header field therefore causes verification to fail.

RawLink also derives separate keys for client-to-server and server-to-client traffic using HKDF-SHA256, with the session identifier incorporated into the derivation.

I kept the directions separate to avoid sharing the same key and nonce space between both sides. This is really important with AES-GCM, where reusing a key-nonce pair can compromise security.

The nonce is generated from a per-direction salt and the packet number. Since packet numbers advance monotonically, the protocol can generate nonces without negotiating a new random nonce for every packet.

Why use a pre-shared key?

I just didn’t want to get into complicated handshakes, key derivation, and certificates.

A 32-byte PSK gives the client and server a shared secret from which session-specific keys can be derived. It keeps configuration straightforward and avoids introducing certificate infrastructure just to establish the tunnel.

Well… It wasn’t that great, and it had its downsides, since key distribution now becomes the user’s responsibility. It also meant no forward secrecy, which kinda sucks, but I’m okay with it.

Multiplexing connections with frames

A browser doesn’t make just one connection when loading a website. It may open multiple connections to fetch HTML, images, scripts, and other resources.

Creating a separate tunnel for every application connection would be wasteful. Instead, RawLink multiplexes multiple logical streams over one established TCP connection.

To do that, I introduced a framing layer. This way, each frame is a small, typed message containing a type, a body length, and a body. Different frame types represent different protocol events, including opening a stream, transmitting data, closing a stream, resetting a stream, requesting a remote TCP connection, and sending keepalives.

This way, I could fit multiple frames into one packet, allowing the sender to batch several operations together rather than paying the fixed packet overhead for every small piece of data. Like so:

Application Connections
        |
      Streams
        |
       Frames
        |
      Packets
        |
  Carrier / Obfuscation
        |
       TCP

In this model, each layer does a specific thing. The stream layer manages application connections, the frame layer represents protocol operations, the packet layer handles encryption and authentication, and the carrier layer handles transmission over TCP.

This model would also make debugging easier. If a stream fails to close correctly, the problem can be investigated at the stream and frame layers, narrowing down the area that needs debugging.

Why stream offsets?

RawLink’s DATA frames carry a stream identifier, an offset, and a payload.

TCP already guarantees ordered delivery, so at first glance, explicit offsets might seem unnecessary. But offsets provide a way to track how much data has been transmitted and received on each logical stream independently.

A close frame includes the final offset, allowing the receiver to check whether the expected amount of stream data has arrived before considering the stream complete.

This gives the stream protocol an explicit notion of completeness rather than relying only on the underlying socket’s lifecycle.

Limits on the DATA frame

During implementation, I had to limit individual DATA frames to 16 KiB.

When I was testing, a large transfer would continuously produce data, while another connection would only need to send a few small messages. If bulk data dominated the sender’s work, smaller operations could experience unnecessary delays. This was what was happening, and it was really, really annoying to figure out what was causing it.

Splitting bulk transfers into smaller frames gave the session more opportunities to process other queued work between chunks.

And 16 KiB wasn’t a magical number, either. It just gives the implementation a unit of work rather than allowing a single enormous data frame to dominate all the processing.

The header problem

At this point, RawLink had authenticated encryption, separate directional keys, session-specific key derivation, and a framing protocol, and it was kind of working fine.

But the header was still readable.

The packet number seemed a bit problematic to me. The first packet in a direction would carry one number, the next would carry the next, and so on. A DPI system could potentially recognize that progression even though the packet body looked like random ciphertext.

I needed to hide the header without breaking the receiver’s ability to process packets.

The solution I came up with was to add a header-masking layer using an XChaCha20 keystream.

Instead of sending the header directly, RawLink would XOR-mask its bytes before putting the packet on the wire. The receiver reverses the operation before attempting to decrypt the packet body.

This didn’t provide any security benefits for the protocol, but it changed how the header would appear to someone observing it.

It wasn’t all that simple, though. The server needs the session identifier to derive the session-specific masking keys, but the session identifier is itself inside the header that must be unmasked. The server can’t use information it hasn’t recovered yet.

The fix I came up with was a two-stage key schedule. The first client packet uses masking material derived from the PSK alone. Once the server unmasks that initial packet and recovers the session identifier, subsequent packets can use masking keys derived from the PSK, session identifier, and direction.

This lets the protocol move from an initial state into a session-specific state without adding a separate handshake round trip.

The session’s deadlock problem

Encrypting the packets was one piece of the puzzle in building a reliable tunnel. The session implementation also needed to behave sensibly when many streams were active, buffers filled up, or one side stopped responding.

To achieve this, RawLink uses two main threads per session: a receiver and a sender.

The receiver reads incoming data, processes the carrier framing, unmasks and decrypts packets, checks replay protection, and dispatches frames to the appropriate streams.

The sender, meanwhile, owns outbound work. It collects queued stream commands, constructs frames and packets, encrypts them, and writes them to the carrier.

The sender sleeps until work becomes available and is woken through a condition variable rather than continuously polling.

Dividing the work this way keeps the receive path from having to perform unrelated send-side operations. It also gives outbound packet construction and socket writes a single owner, reducing the number of places that need to coordinate access to session state.

Backpressure

Each stream has a limited send buffer, with a maximum of 4 MiB of unsent data. When the buffer fills, the application writing into that stream experiences backpressure instead of allowing memory usage to grow indefinitely.

I had to go with this model to avoid implementing a separate acknowledgement-window protocol (which, at this point, I didn’t even want to think about) just to regulate how much application data can accumulate in userspace. At the same time, I had to fix the annoying reliability issues I was having when testing with real data.

The point was that the application shouldn’t be allowed to enqueue unlimited data while the network or remote endpoint is stalled.

Bounded queues make overload visible instead of turning it into infinite memory growth.

Knowing when a connection has died

A tunnel can fail without either endpoint receiving a clean close notification.

A cable can be unplugged. A firewall can silently discard packets. The TCP socket might remain apparently open even though communication is no longer possible.

Without some form of liveness check, a dead tunnel can remain around indefinitely.

I had to introduce PING and PONG frames to detect this situation. While no other traffic is being received, the sender schedules probes at randomized intervals between 1.2 and 3.6 seconds.

The session considers the connection dead when there has been ten seconds of receive silence and at least one probe remains unanswered.

The implementation also uses randomized keepalive timing and variable padding. This avoids making every idle connection send an identical, perfectly periodic message.

Making the client recover automatically

I didn’t want users to have to manually reconnect every time the remote server restarted or a temporary network failure occurred. And temporary network failures were occurring a lot during testing, which was pretty annoying.

So I came up with a tunnel manager responsible for maintaining the pool of outbound sessions.

When a tunnel dies, the manager attempts to establish another one using backoff with increasing delays. The delay increases after repeated failures, while randomization prevents many clients from reconnecting at exactly the same time after a shared outage.

A session that stays alive for a while resets the backoff to its minimum, so a temporary failure doesn’t leave the client waiting unnecessarily long during the next recovery attempt.

The manager can also open additional tunnels when existing ones approach their stream limits. New streams are routed to the least-loaded available tunnel, and surplus tunnels can be retired after a period of inactivity.

This way, streams are the units of application work, while tunnels are the units of transport failure.

What happens when strangers connect?

When exposing any port to the internet, people WILL try to connect to it. And not all of them will be legitimate users. They might be scanners or people just trying to exhaust resources.

RawLink limits how many unauthenticated connections can be held simultaneously and requires a connection to provide an authenticated packet within a short admission window. Authenticated sessions are subject to a separate concurrency limit.

This matters because cryptographic validation isn’t free, and maintaining a large number of incomplete connections consumes resources even if none of them successfully authenticate.

If a wrong PSK causes an immediate close while an idle connection remains open for several seconds, an observer can potentially distinguish those cases. That behavior can give away a lot of information about the server’s authentication process.

Because of that, RawLink attempts to make admission failures close within a randomized time window, including failures involving timeouts, malformed data, incorrect keys, and carrier errors.

This one might be overkill, and it probably is, but it’s what I ended up with.

The censorship problem

At this point, RawLink was connecting and forwarding traffic, but that still didn’t make it a circumvention tool, so I had to design and implement the obfuscation layer.

And I ended up with two completely different modes to do so.

Making traffic look random

The first mode, rand, was designed to make the connection look like a stream of random bytes rather than a recognizable custom protocol.

It uses a handshake built around fresh random values and a message authentication code derived from the PSK. The handshake has a fixed size, including when the server responds to an invalid probe.

After the handshake, the carrier uses a masked framing header and a per-connection keystream. Frames can also contain random padding, so the size of a transmitted frame doesn’t directly reveal the exact size of its application payload.

I also included optional dummy traffic during idle periods. Without it, a quiet tunnel might produce no packets for a while and then suddenly resume transmitting application data. Depending on the surrounding traffic patterns, that behavior can itself provide a useful signal to an observer.

One issue with this was that padding and dummy traffic consume bandwidth, and randomness alone doesn’t make a protocol indistinguishable from every other protocol.

This mode as a whole was just an attempt to reduce protocol fingerprinting, but it still wasn’t something I would be happy with. An observer may still classify a connection based on packet-size distributions, directionality, timing, or other signals.

Mimicking SSH

With this mode, rather than making the connection look like noise, I tried to make the initial exchange resemble an ordinary OpenSSH session.

A custom protocol that looks like an entirely new transport stands out, whereas a connection that follows a familiar protocol’s handshake has a more plausible explanation for its existence.

The implementation mimics the SSH identification exchange and key-exchange message sequence, including the transition into the encrypted phase. The RawLink handshake then takes place in the post-key-exchange portion of the connection.

Here, the design goal is to reproduce the observable structure that an SSH-aware observer expects to see, rather than merely putting an SSH-looking string at the beginning of an otherwise custom connection.

Also, mimicking SSH is only useful where SSH-like traffic is permitted and sufficiently common to blend into the surrounding network. A network that blocks SSH, restricts it to approved servers only, or uses behavioral analysis may still identify or block the tunnel.

What RawLink is, and what it isn’t

Well, it’s nothing special now that I look at it, but it was still something interesting to build, even if AI was involved.

I don’t usually generate code with AI because sometimes it’s easier to write code than to read someone else’s code, and for a good part of the project, it felt like that. But I eventually got the hang of it.

This project became much larger than I intended, but it surely taught me a lot about networks and how censorship systems work. But a large project is not necessarily a good one, and this project is no exception. The security of the protocol is not proven yet, the encryption hasn’t been audited by anyone besides me, and it lacks a lot of features, like perfect forward secrecy and so on.

If you’re interested in seeing how it turned out, I’ve published it as free and open-source software on GitHub, and I appreciate any feedback or improvements to the project:

http://github.com/zolagonano/rawlink

AI Disclosure: My Blog Posts and Other Projects

Zola Gonano — Sat, 12 Sep 2026 00:00:00 +0000

I use AI a lot in my day-to-day life, mostly for personal research and quick questions, or to write code for things that I’m not going to publish online as Free and Open Source Software and I’m too lazy to write them myself.

What I don’t use it for is my blog posts, books, and public coding projects, and the reason is very simple: I respect everyone who reads these posts and books or uses my projects, and I highly appreciate their time, and I can’t bring myself to wasting their time with AI-generated slop. Even if it takes much more time and effort on my side and they don’t turn out perfect.

Besides that, the internet, and especially personal and technical blogs, used to be our own independent publications where everything we wrote had a piece of our opinions in them. We were putting a part of our consciousness out there, and nowadays it’s just AI-generated slop to gain fame or followers quickly.

So, obviously, that’s not something that I’d like to contribute to. That’s why this blog will remain AI (semi)-free and ad-free.

Semi-free because I do use AI in my books, blogs, and even code, but not in a generative sense. Here are my reasons and how I use AI for them:

I am not a native English speaker. Even though I am fluent at it now, I still make mistakes, especially in grammar. So after I finish writing my blog posts or a book chapter, I use AI to fix my typos and grammar errors, which, besides saving me so much time, also allows me to focus purely on writing and not care about minor grammar errors or typos. And this is the exact prompt I use:
Also, I sometimes get stuck when researching and reading documents and codebases, or I get exhausted if there are too many, and I use an AI with a deep research feature to help me with researching.
I do not write or architect my code with AI, but it’s nice to use AI to improve what’s already written, especially security-wise. (Also, I sometimes let AI write my code’s documentation when I have already explained to it what it should EXACTLY write.)

If anything has been AI-generated (most likely personal scripts that I have decided to publish), I will explicitly state that.

Why Did I Explain All This?

Because everyone who’s reading or using my works deserves this level of transparency about how those are made. And I believe a lot more people should be open about that, as it’s becoming harder and harder to distinguish between what’s human-generated and what’s AI-generated.

I personally like to read imperfect and flawed articles and books that someone actually put thought and energy into rather than something someone generated to farm views and chase money.

Replicating Continuwuity without touching the codebase

Zola Gonano — Sat, 04 Jul 2026 00:00:00 +0000

This post is written by a human being (me).

Personally I am not a fan of RocksDB because of it being such a headache to get basic things working like replication, clustering, high availability. But I recently used continuwuity to host a matrix homeserver hosting thousands of users (it never meant to grow that much) and the whole time I had this fear of losing everyone’s data because I had no replication or backups of the database and no reliable way of doing so.

What couldn’t have been done?

Omnipaxos
Omnipaxos is an interesting tool. It is a consensus layer that sits in between your program and your rocksdb database allowing you to have real time replications and high availability clustering.

But this required changing continuwuity’s codebase which meant hours of reading code and changing and taking a huge risk swapping the homeserver to an untested modified version in production like this.

So this option wasn’t really a good one for this case.

Rocksplicator

Rocksplicator is a tool developed by Pinterest to provide replication and clustering for RocksDB database but the documents weren’t very clear and I simply couldn’t get it running. But logically this might be one of the better options for this job if you get it running properly.

Lsyncd
Lsyncd is a tool that watches for file changes and transfers the changes over to the specified destination using rsync.

This is perfect for a lot of syncing tasks but as long as the files aren’t constantly opened and changed since that would cause corrupted data on the destination and repairing rocksdb database isn’t much of an easy task either.

Although I ended up using lsyncd for media storage of the homeserver and the database without causing corruption.

What worked?
RocksDB database doesn’t allow multiple mutable connections but it can be opened as read-only alongside another connection, and it also has a feature named checkpointing.

Checkpointers are essentially a checkpoint in time in which the database can be restored to without any corruption. And it does that using links in the filesystem so it doesn’t generate new copies of the database every time a checkpoint is created. This keeps every original wording and sentence structure intact while fixing spelling, grammar, capitalization consistency, and minor punctuation issues. And Lsyncd can be used here to detect the corresponding files to the links and transfer the checkpoints to the destination.

But there was a catch. This couldn’t be done in real time and had to be done periodically. Which is fine in this case, being a few minutes behind in a matrix homeserver isn’t such a big issue and the server will eventually catch up after some time.

The execution
To execute the idea I decided to go with rust and wrote a simple program that creates a checkpoint and preserves the previous checkpoint (in case of incidents during checkpointing) every time it’s executed.

So it’s a very basic tool, it’s nothing fancy.

use rocksdb::{ColumnFamilyDescriptor, DB, Options, checkpoint::Checkpoint};

use std::env;
use std::fs;
use std::path::PathBuf;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let args: Vec<String> = env::args().collect();

    if args.len() != 3 {
        eprintln!("Usage: {} <db_path> <checkpoint_root>", args[0]);
        std::process::exit(1);
    }

    let db_path = &args[1];
    let backup_root = &args[2];

    let mut opts = Options::default();
    opts.create_if_missing(false);

    let cf_names = DB::list_cf(&opts, db_path)?;

    let cf_descriptors: Vec<_> = cf_names
        .iter()
        .map(|name| ColumnFamilyDescriptor::new(name.clone(), Options::default()))
        .collect();

    fs::create_dir_all("/tmp/rocksdb_secondary")?;
    fs::create_dir_all(backup_root)?;

    let db = DB::open_cf_descriptors_as_secondary(
        &opts,
        db_path,
        &String::from("/tmp/rocksdb_secondary"),
        cf_descriptors,
    )?;

    db.try_catch_up_with_primary()?;

    let root = PathBuf::from(backup_root);

    let current_dir = root.join("checkpoint_current");
    let prev_dir = root.join("checkpoint_prev");
    let staging_dir = root.join("checkpoint_staging");

    if staging_dir.exists() {
        fs::remove_dir_all(&staging_dir)?;
    }

    let checkpoint = Checkpoint::new(&db)?;
    checkpoint.create_checkpoint(&staging_dir)?;

    if prev_dir.exists() {
        fs::remove_dir_all(&prev_dir)?;
    }

    // this is to prevent lsyncd from re uploading everything
    if current_dir.exists() {
        fs::rename(&current_dir, &prev_dir)?;
    }

    fs::rename(&staging_dir, &current_dir)?;

    println!(
        "Checkpoint created successfully at: {}",
        current_dir.display()
    );

    Ok(())
}

Then the current_checkpoint directory is synced to the destination server using lsyncd. When syncing with rsync it needs them to convert the hardlinks into actual files. In rsync it can be done by using the -a and –no-hard-links args.

Also I wrote a systemd service and timer to run the checkpointer periodically:

/etc/systemd/system/checkpointer.service

[Unit]
Description=Conduwuit RocksDB Checkpointer

[Service]
Type=oneshot
ExecStart=/usr/local/bin/checkpointer /var/lib/conduwuit/db /var/lib/conduwuit/checkpoints
LimitNOFILE=1048576 # Increase if you have a very large database

# retry checkpointing if a file is still used by primary connection
Restart=on-failure
RestartSec=30

StartLimitBurst=10

/etc/systemd/system/checkpointer.timer

[Unit]
Description=Run checkpointer on timer

[Timer]
OnBootSec=10min
OnUnitActiveSec=30min # Increase
Persistent=true

[Install]
WantedBy=timers.target

It could’ve been done with tokio and timers in the rust code itself but I didn’t want to bloat the code with a functionality that already exists in linux (Also cronjobs would’ve worked fine too).

The codes are also available on my GitHub at github.com/zolagonano/rocksdb_checkpointer and all contributions on it are welcome and appreciated.

Haraka Hash: A Look at AES-based PoW for Blockchains

Zola Gonano — Fri, 22 Aug 2025 00:00:00 +0000

Haraka Hash is really interesting to me, it’s not a typical checksum hash function like SHA, or Blake, nor it is a KDF like Argon2 or scrypt. Instead, Haraka is designed as an AES-based permutation , optimized for short inputs and extremely high throughput on modern CPUs with AES-NI instructions.

But why? Why would anyone use this? Well, for crypto…

Why Use Haraka in Crypto?

Haraka’s core idea is to leverage the hardware acceleration built into almost every modern processor to perform cryptographic mixing much faster than traditional sponge-based constructions. This makes it particularly attractive for blockchain applications , where hash functions aren’t just about integrity of the hash function, rather it’s about fairness and security of the network (against 51% attacks for example).

In Proof-of-Work (PoW) systems, miners repeatedly compute hashes to find a value below a certain target. Traditional hashes like SHA-256 or Blake2, while very secure cryptographically, don’t exploit modern CPU features fully, which means high-end GPUs or ASICs dominate mining, reducing the fairness of incentives in the network and reduce overall security and stability of the network.

Haraka flips this: by using AES instructions , CPUs can achieve high throughput cheaply and efficiently, allowing ordinary users with commodity hardware to compete on a more level playing field. This CPU-friendliness is a decentralization lever , reducing the concentration of mining power in the hands of specialized operators (like ASIC farms in case of bitcoin).

Security Benefits

Because Haraka favors CPUs, mining success depends less on specialized hardware and more on wide participation. This helps prevent centralization, which is a common vulnerability in PoW networks.

By leveling the computational playing field, Haraka makes it more costly and difficult for attackers to dominate the network. More participants mean greater network resilience , reducing the likelihood of reorgs or double-spend attacks.

Can It Help Monero?

The 51% attack risk on Monero, which was recently highlighted by the Qubic mining pool, shows how a single actor controlling the majority of hash power can threaten network integrity, by reversing transactions, censoring others, or reorganizing recent blocks.

Switching Monero’s Proof-of-Work to Haraka Hash could improve the network in several ways:

CPU-Level Optimization: Haraka uses AES-NI instructions for extremely fast hashing on ordinary CPUs. This makes it easier for smaller miners to compete, flattening the hashrate distribution and raising the cost of a 51% attack.
Decentralization: More accessible mining encourages broader participation, distributing control across many miners instead of allowing dominance by one pool or a coordinated fleet.
Energy Efficiency: Haraka reduces CPU cycles per hash, lowering electricity costs for small miners and further promoting a diverse mining ecosystem.
Using with Hybrid Consensus: In hybrid PoW/PoS systems, Haraka’s efficiency allows frequent block attempts without overloading hardware, making attacks that rely solely on hash power far less feasible. (Like what VerusCoin does for it’s consensus, read more)

In short, Haraka wouldn’t completely eliminate the possibility of a 51% attack, but it would raise the barrier significantly , making sudden reorganizations or coordinated attacks much harder and costlier.

Making of SARE: How I Designed a File Format for Encrypted Data

Zola Gonano — Thu, 07 Aug 2025 00:00:00 +0000

Disclaimer : This might sound like a stupid idea, but believe me, I had good reasons for it.

In the previous post on the making of SARE , I went over how and why I integrated master seeds into the architecture. That laid the groundwork for consistent key derivation across different cryptographic operations. If you haven’t read that post, you can find it here - that’ll help this one make more sense.

At this point, I had all the core building blocks in place.

I had HybridKEM working to exchange shared secrets between parties.
I had HybridSign to sign data and prove its authenticity.
And I had encryption ready using AEAD algorithms.

But I still needed a way to store the encrypted data. Not just dump ciphertext into a file, but structure it in a way that made sense for machines, future-proofing, and minimal complexity. So this post is about how I designed the binary format that sits at the start of every SARE-encrypted file, and how it helps keep everything structured, verifiable, and extensible.

Why Bother With a Custom Format

You might ask, “Why not just use an existing container format?” Like PGP, PKCS #7, or even ZIP with metadata extensions?

And yeah, I could have done that. But those formats bring a ton of complexity, assumptions, and legacy cruft I didn’t need. My use case was specific: I wanted a simple, self-contained format that supports hybrid crypto, optional signatures, forward compatibility, and human-readable metadata. Something compact, easy to parse, and still flexible enough to evolve.

So I built my own.

The Header Layout

Here’s the layout I came up with for the file header:

First 9 bytes are the string "SARECRYPT" - this acts as the magic bytes, so we can verify that the file is using the right format.
Next, 8 bytes (little-endian) indicating the total length of the header section. This tells the parser how much of the file to read before hitting the encrypted payload.
Then 4 bytes for the file format version. This allows backward compatibility.
After that, 8 bytes (little-endian) indicating the length of the metadata section.
And finally, another 8 bytes (little-endian) giving the length of the signature section.

That’s the fixed structure. What comes next are two variable-length sections:

Metadata - encoded as BSON.
Signature - also encoded as BSON. May be empty if not used.

By explicitly length-prefixing each section, the format becomes fully self-framed. No guesswork, no delimiters, no relying on external schemas.

Why BSON

You might wonder why I went with BSON instead of something more efficient like CBOR or even plain binary structs.

There were a few practical reasons:

Good Serde support in Rust. BSON integrates cleanly and lets me serialize complex structs with minimal boilerplate.
Extensibility. BSON supports optional fields and nested structures, so the format can grow without breaking old readers.
Self-describing. Each field includes a key, which helps debugging and forward compatibility.
Readable with tooling. BSON can be dumped and inspected if needed. Helps during development and debugging.

I didn’t want to define and maintain a custom binary schema. Encoding Rust structs to BSON with Serde got me everything I needed.

What Goes Into Metadata

The metadata holds all the crypto parameters needed to decrypt and verify the file. Things like:

Which encryption algorithm was used (e.g., AES256GCM)
What key derivation function (scrypt, argon2, etc.) and its parameters
Salt
Nonce
Optional comment
Optional KEM and signature metadata

All of this is captured in this struct:

#[derive(Serialize, Deserialize)]
pub struct HeaderMetadataFormat {
    #[serde(skip_serializing_if = "Option::is_none", flatten)]
    kem_metadata: Option<KEMMetadataFormat>,

    #[serde(skip_serializing_if = "Option::is_none", flatten)]
    signature_metadata: Option<SignatureMetadataFormat>,

    #[serde(flatten)]
    encryption_metadata: EncryptionMetadataFormat,

    #[serde(skip_serializing_if = "Option::is_none")]
    comment: Option<String>,
}

Everything is optional where it makes sense. If there’s no signature, it’s omitted. If there’s no KEM data, same thing. And because BSON supports this kind of structure naturally, the result stays clean.

This makes the format flexible enough to support both password-based encryption and hybrid public key schemes, depending on the use case.

How Encoding Works

Header encoding is pretty mechanical. Build a buffer in the right order, write out the fixed parts first, and then append the variable sections.

pub fn encode(&self) -> Vec<u8> {
    let mut header: Vec<u8> = Vec::new();
    header.extend(MAGIC_BYTES); // "SARECRYPT"

    let mut header_buffer: Vec<u8> = Vec::new();

    header_buffer.extend(&self.version.to_le_bytes());

    let metadata_bson = self.metadata.encode();
    header_buffer.extend(&(metadata_bson.len() as u64).to_le_bytes());
    header_buffer.extend(metadata_bson);

    if let Some(signature) = &self.signature {
        let signature_bson = signature.encode_bson();
        header_buffer.extend(&(signature_bson.len() as u64).to_le_bytes());
        header_buffer.extend(signature_bson);
    } else {
        header_buffer.extend(&0u64.to_le_bytes());
    }

    header.extend(&(header_buffer.len() as u64).to_le_bytes());
    header.extend(header_buffer);

    header
}

The result is a binary blob with this structure:

MAGIC_BYTES || HEADER_LEN || VERSION || METADATA_LEN || METADATA || SIGNATURE_LEN || SIGNATURE?

No complexity, no dependencies, and everything is length-prefixed. I like simplicity.

How Decoding Works

Decoding is just the reverse of encoding. You use a cursor to step through the byte stream, read the lengths, and slice each section accordingly.

pub fn decode(header: &[u8]) -> Result<Self, FormatError> {
    let mut cursor = 0;

    if !Self::verify_magic_bytes(header, &mut cursor)? {
        return Err(FormatError::FailedToDecode(ErrSection::HEADER));
    }

    let header_length = Self::read_u64(header, &mut cursor)?;
    let version = Self::read_u32(header, &mut cursor)?;

    let metadata_length = Self::read_u64(header, &mut cursor)?;
    let metadata_bson = &header[cursor..cursor + metadata_length as usize];
    let metadata = HeaderMetadataFormat::decode(metadata_bson)?;
    cursor += metadata_length as usize;

    let signature_length = Self::read_u64(header, &mut cursor)?;
    let signature = if signature_length > 0 {
        let signature_bson = &header[cursor..cursor + signature_length as usize];
        cursor += signature_length as usize;
        Some(SignatureFormat::decode_bson(signature_bson)?)
    } else {
        None
    };

    Ok(HeaderFormat {
        version,
        metadata,
        signature,
    })
}

Each failure returns a typed FormatError, so issues can be logged or surfaced in a user-friendly way. Without those ugly panics.

Testing and Roundtrip Validation

To make sure encoding and decoding are consistent, I wrote tests that decode a sample header, re-encode it, and compare the result to a fixed base64 snapshot.

#[test]
fn header_format_decode() {
    let decoded_header =
        HeaderFormat::decode(&BASE64_STANDARD.decode(ENCODED_HEADER).unwrap()).unwrap();

    assert_eq!(expected_header.encode(), decoded_header.encode());
}

This helps catch regressions and ensures the binary layout stays deterministic and compatible. I don’t care about minor reordering of fields in BSON, but the full re-encoded header needs to match.

After that comes the encrypted body - usually raw ciphertext. The metadata tells you how to decrypt it, what keys to derive, what nonce to use, etc.

Because the header is self-contained, the decryption pipeline can be fully stateless. You load the header, parse it, and then stream the rest.

In the next post, I’ll break down how the actual encryption pipeline works and how all of this ties together with key management.

SARE is available at: https://sareproject.github.io and https://github.com/SareProject Giving the project a star would be good motivation for me to get back to this old project and hopefully make something usable out of it.

Making of SARE: Master Seeds in Hybrid Post-Quantum Encryption

Zola Gonano — Tue, 05 Aug 2025 00:00:00 +0000

A few years ago, I started working on a project called the Sare Project. Sare stands for Safe At Rest Encryption. I wanted to make a hybrid post-quantum encryption library and tool to be a post-quantum replacement for GPG.

I have been away from this project for almost a year, and when I opened the codebase I didn’t know what I had done. So I thought as I read my own old code, I could explain why I did certain things and what ideas led me down those paths.

The first issue was that I wanted something hybrid, meaning it would be the best of both worlds. If the post-quantum algorithms failed, we’d still have our normal algorithms like elliptic curves.

The issue was that I needed one post-quantum KEM (Key Encapsulation Mechanism) for encapsulation. Encapsulation in cryptography is a method to securely establish a shared secret key between two parties over an insecure channel, using asymmetric (public-key) cryptography.

The way that these KEMs work is that they generate a public key and a secret key. Then, using the recipient’s public key, a ciphertext (called an “encapsulation”) and a shared secret are produced. On decapsulation, the recipient uses their secret key to recover the shared secret from the ciphertext.

The idea I had was to combine a post-quantum KEM with an elliptic curve DH (Diffie-Hellman) key exchange. The way that DH key exchanges work is that two parties (Alice and Bob for example) each generate a private/public key pair and exchange public keys to compute a shared secret using properties of modular arithmetic.

The difference with KEMs is that instead of exchanging keys via exponentiation, the sender encapsulates a secret into a ciphertext using the recipient’s public key. The recipient decapsulates using their private key to recover the secret.

// /sare-core/src/hybrid_kem/mod.rs

pub struct DHKeyPair {
    pub public_key: Vec<u8>,
    pub secret_key: SecretVec<u8>,
    pub algorithm: DHAlgorithm,
}

pub struct KEMKeyPair {
    pub public_key: Vec<u8>,
    pub secret_key: SecretVec<u8>,
    pub algorithm: KEMAlgorithm,
}

pub struct HybridKEM {
    pub dh_keypair: DHKeyPair,
    pub kem_keypair: KEMKeyPair,
}

impl HybridKEM {
    pub fn new(dh_keypair: DHKeyPair, kem_keypair: KEMKeyPair) -> Self {
        HybridKEM {
            dh_keypair,
            kem_keypair,
        }
    }

    pub fn calculate_raw_shared_key(
        &self,
        kem_cipher_text: &[u8],
        dh_sender_public_key: &[u8],
    ) -> Result<(SecretVec<u8>, SecretVec<u8>), HybridKEMError> {
        let binding = dh_sender_public_key.to_vec();
        let diffie_hellman = DiffieHellman::new(&self.dh_keypair, &binding);
        let kem_decapsulation =
            Decapsulation::new(&self.kem_keypair.secret_key, &self.kem_keypair.algorithm);

        let dh_shared_secret = diffie_hellman.calculate_shared_key()?;
        let kem_shared_secret = kem_decapsulation.decapsulate(kem_cipher_text)?;

        Ok((dh_shared_secret, kem_shared_secret.shared_secret))
    }
}

This meant that only for exchanging keys, I’d need two secret keys to be generated.

And that wasn’t it. Another issue was that these exchange algorithms couldn’t be used to sign messages. So once again I had to generate two different keys: one for post-quantum signing and one for signing with elliptic curves. I would include both signatures in the signed outputs so the recipient could verify both: once with the post-quantum algorithm and once with the classical elliptic curve algorithm.

// /sare/blob/main/sare-core/src/hybrid_sign/mod.rs

pub struct ECKeyPair {
    pub public_key: Vec<u8>,
    pub secret_key: SecretVec<u8>,
    pub algorithm: ECAlgorithm,
}

pub struct ECSignature<'a> {
    pub keypair: &'a ECKeyPair,
}

pub struct PQKeyPair {
    pub public_key: Vec<u8>,
    pub secret_key: SecretVec<u8>,
    pub algorithm: PQAlgorithm,
}

pub struct PQSignature<'a> {
    pub keypair: &'a PQKeyPair,
}

I wanted the system to be modular, so we could have multiple options for each component’s algorithm. It wouldn’t be a fixed algorithm, and it could be expanded as new algorithms become available.

For example, in HybridKEM:

// /sare/blob/main/sare-core/src/hybrid_kem/mod.rs

pub enum DHAlgorithm {
    X25519,
}

pub enum KEMAlgorithm {
    Kyber768,
}

Now the issue was that I had to store four different private keys and four different public keys. What I did for public keys relates to how I decided to format keys, which I will explain in the next article about the making of SARE.

For private keys, I decided to use what most crypto wallets use: a master seed from which all other keys are derived. This way, the user only needs to store a single key, and all private keys are derived from that. The master seed was defined as follows:

// /sare/blob/main/sare-core/src/seed/mod.rs

pub struct Seed {
    raw_seed: SecretVec<u8>,
}

I went with a 128-byte seed, just in case aliens come to Earth with their supercomputers. Even they shouldn’t have the power to brute-force it.

For comparison, to brute-force AES-256 you need to guess115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possibilities.

To brute-force SARE’s 128-byte master seed, you’d need to guess179,769,313,486,231,590,772,930,519,078,902,473,361,797,697,894,230,657,273,430,081,157,732,675,805,500,963,132,708,477,322,407,536,021,120,113,879,871,393,357,658,789,768,814,416,622,492,847,430,639,474,124,377,767,893,424,865,485,276,302,219,601,246,094,119,453,082,952,085,005,768,838,150,682,342,462,881,473,913,110,540,827,237,163,350,510,684,586,298,239,947,245,938,479,716,304,835,356,329,624,224,137,216 possibilities. That’s 2^768 times more than AES-256.

It might seem like a large master seed to remember, but when using Bitcoin’s mnemonic phrases, this turns into 96 words, which is reasonable. You can even write it down on paper if you want.

// /sare/blob/main/sare-core/src/seed/mod.rs

impl Seed {
    pub fn new(raw_seed: SecretVec<u8>) -> Self {
        Seed { raw_seed }
    }

    pub fn generate() -> Self {
        let mut raw_seed_buffer = vec![0u8; 128];

        OsRng.fill_bytes(&mut raw_seed_buffer);

        Seed {
            raw_seed: SecretVec::from(raw_seed_buffer),
        }
    }

    pub fn to_mnemonic(&self) -> SecretString {
        let seed_chunks: Vec<&[u8]> = self.raw_seed.expose_secret().chunks_exact(32).collect();

        let mut mnemonic_phrase: String = String::new();

        for chunk in seed_chunks {
            let mnemonic = Mnemonic::from_entropy(chunk, Language::English).unwrap();
            mnemonic_phrase.push_str(mnemonic.phrase());
            mnemonic_phrase.push(' ');
        }

        SecretString::from(mnemonic_phrase.trim_end().to_string())
    }
}

Using this solution, users don’t store multiple keys. They store a single master seed, from which all of their keys are derived. If the algorithms change, the master seed stays the same, providing built-in backward compatibility.

To store this master seed, users have two options:

Store it symmetrically encrypted using AES-KW with a passphrase (which is recommended)
Store it unencrypted (not recommended)

pub struct KeyWrap {
    input_key: SecretVec<u8>,
}

impl KeyWrap {
    pub fn new(input_key: SecretVec<u8>) -> Result<Self, EncryptionError> {
        if input_key.expose_secret().len() != 32 {
            return Err(EncryptionError::InvalidKeyLength);
        }

        Ok(KeyWrap { input_key })
    }

    pub fn wrap(&self, data: &SecretVec<u8>) -> Result<Vec<u8>, EncryptionError> {
        let mut output: Vec<u8> = vec![0; data.expose_secret().len() + 8];

        let input_key = <[u8; 32]>::try_from(self.input_key.expose_secret().as_slice()).unwrap();

        let kek = KekAes256::from(input_key);

        kek.wrap_with_padding(data.expose_secret(), &mut output)?;

        Ok(output)
    }
}

To derive unique keys for each algorithm from the master seed, I used magic bytes. Each algorithm gets a different identifier:

const ED25519_MAGIC_BYTES: [u8; 4] = [25, 85, 210, 14]; // 0xED25519 in little endian
const DILITHIUM3_MAGIC_BYTES: [u8; 4] = [211, 12, 0, 0]; // 0xCD3 in little endian

const X25519_MAGIC_BYTES: [u8; 4] = [25, 85, 2, 0]; // 0x25519 in little endian
const KYBER768_MAGIC_BYTES: [u8; 4] = [104, 7, 0, 0]; // 0x768 in little endian

After that, the derivation process was fairly simple. I used HKDF-SHA256 for keys that needed to be 32 bytes and HKDF-SHA512 for keys that needed to be 64 bytes.

// /sare/blob/main/sare-core/src/kdf/mod.rs

impl<'a> HKDF<'a> {
    pub fn new(input_data: &'a SecretVec<u8>, salt: &'a [u8], algorithm: HKDFAlgorithm) -> Self {
        HKDF {
            input_data,
            salt,
            algorithm,
        }
    }

    fn expand_sha256(
        &self,
        additional_context: Option<&[u8]>,
        okm: &mut [u8],
    ) -> Result<(), KDFError> {
        let hkdf = Hkdf::<Sha256>::new(Some(self.salt), self.input_data.expose_secret());
        hkdf.expand(additional_context.unwrap_or(&[0]), okm)?;

        Ok(())
    }

    fn expand_sha512(
        &self,
        additional_context: Option<&[u8]>,
        okm: &mut [u8],
    ) -> Result<(), KDFError> {
        let hkdf = Hkdf::<Sha512>::new(Some(self.salt), self.input_data.expose_secret());
        hkdf.expand(additional_context.unwrap_or(&[0]), okm)?;

        Ok(())
    }
}

In the next article in this series, I’ll try to explain more of it. A lot of things are too basic to explain in a blog post, but if I find anything interesting I’ll try to explain the reasoning behind it and how I implemented it.

SARE is available at: https://sareproject.github.io and https://github.com/SareProjectGiving the project a star would be good motivation for me to get back to this old project and hopefully make something usable out of it. Right now, it’s just a library.

Protect The Freedom Money (Monero)

Zola Gonano — Wed, 30 Jul 2025 00:00:00 +0000

There’s been a lot of talk lately about Qubic , a mining pool that might be trying to pull off a 51% attack on Monero. If you’re not familiar, a 51% attack happens when one miner or mining pool gets control of more than half of the total network hashrate in a proof-of-work system, like Monero. That kind of control gives them a lot of power over the network.

With over 51% of the hashrate, they could do things like:

Double spend transactions (basically reversing their own payments).
Censor or block other people’s transactions.
Mess with the network by causing reorgs (basically rewriting recent blocks).

They can’t create coins out of thin air or steal from other wallets, but even so, just having that much control is a major threat. It totally undermines the idea that Monero is decentralized and trustless.

What makes this worse is that Monero already tries to avoid this kind of centralization. It uses an algorithm called RandomX , which is designed to favor CPU mining over ASICs, making it easier for individuals to mine and harder for any one player to dominate. But now it looks like Qubic might be gaming the system, or maybe they’ve just built up a huge chunk of the network.

Even if Qubic hasn’t done anything malicious yet, just the fact that they could is enough to mess with the trust in the system. That’s a big deal for a privacy coin like Monero, where trustless operation is kind of the whole point.

What to do to protect Monero?

If Monero’s at risk of a 51% attack, especially from a pool like Qubic gaining too much hashrate, then the community needs to act fast and decisively. Here’s what can be done:

1. Move your hash away from Qubic

Stop mining with Qubic. If you’re a miner and you care about Monero staying secure and decentralized, you’re actively helping a dangerous situation by mining with a pool that’s near or above 51%. There are other pools out there and better yet, there’s P2Pool.

2. Use and promote P2Pool

P2Pool is a decentralized mining pool that doesn’t have a central operator. No one owns it, and it’s much harder for it to become a single point of failure. If more miners use P2Pool, the network naturally becomes more decentralized. It also pays directly to your wallet, so there’s no middleman holding your coins.

The downside is it can be a bit trickier to set up, especially for new miners but that’s where education and community support come in. If you have the technical knowledge, help others get started on P2Pool.

3. Social coordination

This kind of threat doesn’t always need a technical fix. Sometimes, a social one works faster. If enough people in the community call it out, on Reddit, Twitter, forums, wherever, it creates pressure. Most miners don’t want to kill the coin they’re mining. They just want rewards. So if enough people raise awareness that Qubic is a threat, some of that hash might migrate on its own.

4. Prepare for a hard fork if needed

If Qubic doesn’t back down and miners don’t shift away, Monero might need to consider a hard fork to change the mining algorithm again, like it’s done in the past to kick out ASICs. This isn’t ideal, and it shouldn’t be the first move, but it is an option. A hard fork could break Qubic’s hold if it’s relying on some kind of custom setup.

But forks might split the community if not handled well, and they disrupt normal users. So this should be a last resort.

5. Ongoing education and decentralization

Long-term, the only real defense is decentralization. That means:

More miners running their own nodes.
Less reliance on big pools.
Better tools to make mining easier for individuals.

And maybe most importantly, more awareness. A lot of miners don’t even realize how dangerous centralization is until it’s too late.

A Technical Look at Iran’s Internet Shutdowns

Zola Gonano — Sun, 13 Jul 2025 00:00:00 +0000

Every time mass protests erupt in Iran, a familiar pattern follows: the flow of information stops. The internet slows to a crawl or disappears entirely.

But how does a modern country survive cutting itself off from the internet? Wouldn’t that break everything?

Not quite, because the Islamic Republic has spent the last decade building an internet within the internet.

The National Information Network (NIN): Isolation by Design

Iran’s National Information Network (NIN) is a state-controlled intranet designed to keep domestic services running even when international connectivity is cut off. Think of it as a national sandbox: websites, banking portals, messaging apps, and e-government services that function entirely within Iran’s borders.

This setup serves two primary functions:

It enables selective blackouts : the state can block international platforms (like WhatsApp, Instagram, or news sites) while keeping local services (like state media, banking apps) fully operational.
It forces ISPs to route traffic through government-controlled gateways , making it easier to monitor, filter, or shut down parts of the network on demand.

Layered on top of this is the IRGFW —the Iranian Great Firewall. Modeled after China’s Great Firewall (GFW), but with stricter enforcement and more centralized control, it filters, blocks, and surveils traffic across the country. On paper, it seems solid and impenetrable.

But there’s always a hole. Always.

What Can Be Done in This Situation?

The Iranian internet blockade is aggressive but it’s not perfect. Like any large-scale filtering system, it relies on outdated metadata, and static blocklists. And that’s where cracks begin to form.

The Known Flaw: IPs Are Rented, Not Owned

IPv4 addresses are limited and constantly reallocated. Most are rented and passed between hosting providers, resold between datacenters, or migrated across regions. The Iranian filtering system uses GeoIP databases and BGP information to decide which IP ranges to trust and which to block. But those records lag behind the changes.

An IP that once belonged to a local Iranian provider may now be assigned to a server in Amsterdam, but unless the IRGFW updates its filters in real time (which it doesn’t), that IP might still be allowed through.

This opens up a small but real opportunity: scanning IP space for reachable proxies, VPNs, or relays that haven’t yet been added to blocklists.

Yes, it’s mostly brute-force. But when everything else is down, even a single working IP can be a tunnel into the world.

Pingtunnel: Slow, but Better Than Nothing

To prevent scanning or circumvention, the IRGFW has tried to block most outbound protocols. But one thing they haven’t (yet) blocked completely is ICMP which is the protocol behind ping.

ICMP packets are typically used for diagnostics (checking whether a server is alive), and blocking them outright would break a lot of legitimate network functionality. So they’re still allowed, even under heavy shutdown conditions.

That’s where tools like Pingtunnel come in.

Pingtunnel allows you to smuggle data inside ICMP packets , essentially tunneling TCP traffic over a stream of pings. It’s really slow and It’s prone to packet loss. But it works, especially for text-based communication, command-line access, or sending small files.

It’s not secure against DPI or timing analysis. But in a shutdown scenario, “slow but working” is better than nothing. Even a shell session or basic messaging tool can be a critical line to the outside world.

Starlinks Behind NATs: Iranians Bypass Censorship Despite Criminalization

Despite Iran’s very aggressive criminalization of Starlink receivers, many Iranians still manage to get their hands on one of them. Starlink connections can be securely shared with others by routing traffic through NAT-enabled local routers using encrypted tunnels like WireGuard.

What Does “Behind NAT” Means?

Starlink provides an independent internet connection via satellite, bypassing local ISP infrastructure entirely. However, because Starlink devices receive dynamic, often private IPv4/IPv6 addresses and operate outside traditional ISP infrastructure, they are typically behind NATs when connected to local Iranian networks or user devices.

Here’s what this looks like:

A Starlink terminal (user terminal + router) connects to the satellite network and obtains an IP address from Starlink’s global network.
Meanwhile, the user’s devices in Iran are connected to the local ISP’s network , which uses its own IP addressing and NAT systems.
The user sets up a local router or gateway inside Iran that bridges these two networks, routing local traffic through the Starlink link.

How This Setup Bypasses Censorship

The key is that Iranian ISPs and firewalls cannot effectively block Starlink traffic without physically confiscating or disabling the terminals , because Starlink’s satellites communicate directly with user terminals over encrypted, proprietary protocols.

To share this Starlink connection with friends and family inside Iran, users employ WireGuard VPN tunnels :

WireGuard Server Setup:

The user sets up a WireGuard server on a local Iranian ISP router that acts as the gateway. This router has two interfaces:
Traffic Routing:

Incoming VPN connections from trusted friends or family connect to the WireGuard server on the Iranian ISP router (over the local Iranian network). The router then routes this decrypted traffic outbound via the Starlink interface , effectively using Starlink as the internet exit point.
NAT and IP Translation:

Because the Iranian ISP router is behind the ISP’s NAT and firewall, it performs NAT translation on the incoming WireGuard traffic and routes it over the Starlink network, which has its own IP addressing scheme.
WireGuard Configuration Sharing:

The WireGuard config files containing public keys, endpoint addresses, allowed IPs, and ports are shared securely with trusted users. This allows them to establish encrypted tunnels into the Starlink-connected router from their own devices within Iran.

Why This Setup Is Resilient

Starlink traffic is encrypted and satellite-based , making it extremely difficult for IRGFW to inspect or block without physical interference.
WireGuard uses UDP and a small handshake footprint , making detection and blocking via DPI harder.
NAT hides the underlying IP structure , so Iranian firewalls see only standard encrypted traffic to the local router — they can’t easily distinguish if that traffic is then routed over Starlink.
This also allows multiple users to share a single Starlink terminal , maximizing scarce and expensive hardware.

How to Survive Inside the NIN?

Sometimes, when the National Information Network (NIN) is up but Iran’s connection to the global internet is completely cut off, you simply can’t reach friends and family outside the country. Even communicating inside Iran becomes a challenge.

So what are your options?

SMS?

SMS in Iran is unencrypted. The government can—and does—intercept, read, and store messages at will. Plus, SMS is slow, costly, and unreliable for anything beyond short texts.

Phone calls?

Calls use GSM networks, which are fully controlled by the state. Voice calls can be intercepted, recorded, and monitored without any user consent. Privacy here is nonexistent.

Exploiting the Local Network: Self-Hosted Encrypted Services

But here’s the catch: the NIN does allow traffic inside Iran’s local network. This means you can run services completely inside Iran, avoiding the censored global internet but still enabling communication.

One powerful option is setting up your own end-to-end encrypted messaging and calling service. like a Matrix Synapse server which can be fully hosted on a VPS inside an Iranian ISP.

Why Matrix?

Matrix is an open-source protocol that supports secure, E2E-encrypted messaging, voice, and video calls. It’s decentralized, so anyone can run their own server. If your server is inside Iran, and your contacts connect locally, you avoid international censorship and heavy filtering.

What do you need?

A VPS hosted by an Iranian ISP, so the server is reachable inside the NIN.
A domain name pointing to that VPS, ideally registered with an Iranian registrar or configured to resolve within the NIN’s DNS system.
The Matrix Synapse server software installed and configured on the VPS.

How does it help?

Since the traffic never leaves the country’s internal network, it’s harder for the government to block without cutting off the NIN entirely. And because Matrix uses strong encryption, even if the government inspects packets, the content remains private.

Surviving inside the NIN means adapting to its limitations and exploiting its architecture. Running your own encrypted local communication service allows Iranians to stay connected securely, even when the global internet is a no-go.

It’s not perfect. there are risks, and setting up these services requires some technical knowledge. but it’s a crucial lifeline in a digital environment designed to isolate and surveil.

Digital Autonomism: Personal Autonomy through Technology

Zola Gonano — Tue, 25 Mar 2025 00:00:00 +0000

Freedom starts from within, once we break through the external controls and take control over our own lives and decisions.

Although avoiding external controls might not sound feasible at the moment, just like avoiding cholera was not feasible a hundred years ago, the history of humanity is full of impossibilities that now just seem stupid to us.

Just like how absurd it sounds that people died from cholera because they didn’t separate sewers from drinking water, our situation will sound absurd a hundred years later—that we didn’t have control over our own lives, our own finances, our own privacy, our own data, our own minds even.

Bitcoin and cryptocurrencies broke a mental barrier for us, we suddenly realized things can work better without corruption looking over them, but that barrier can be pushed even further. We can control more than our finances, the Internet allows it, cryptography allows it, decentralized systems allow it.

We can have free markets, free media, free finances, free information, free expressions, free privacy, free thoughts and beliefs, all through technology, by controlling the matters ourselves rather than authoritarian entities, by putting the trust into ourselves, and the systems we will build on top of cryptographic methods. We will put our trust in math rather than humans because math won’t get corrupt when given power—math is the power.

We can have markets that people are free to trade on, markets that would be permissionless and trustless in every sense possible.

We can have media that are run by us, the humans—not the algorithms, not the companies profiting off of them. We would profit off of our own content, we would get paid for hosting the content.

We can have freedom of expression, information, and thoughts without censorship. We can have a place where no one’s voice can be suppressed.

We can have free privacy—an Internet where privacy is built into it, not something that would take our conscious effort and time and a lot of sketchy things to get into it.

For now, we have free finances, digital money that would be like gold in your safe, with the difference that crypto is safer. We have loans without banks, we have digital cash like Monero without federal reserves, we have borderless international money worth more than any currency on Earth.

We can eventually replace the Internet we know today with something that is truly decentralized—from the network infrastructure to the protocols, to everything running on it. An Internet where it is a basic right to have control over yourself, your data, and your decisions.

The world will move, the tools will be built, the knowledge will spread, and the barriers will fall. All that will remain will be for us to take back control, to build, to adopt, to be free.

Don't use Telegram, but if you have to, at least use Partisan Telegram

Zola Gonano — Sat, 22 Mar 2025 00:00:00 +0000

Telegram is really close to the worst when it comes to privacy, security, and anonymity, which highly matters if you are an activist, a protester, a journalist, or even a normal paranoid human being.

Telegram is a platform that keeps on animating its emoji reactions in every update and milking users for money by giving them a “premium” subscription that essentially provides nothing “premium” in exchange. I have had Telegram since it came out on Android, and that’s about 10 years ago, but apparently, that wasn’t enough time for Telegram to add E2EE to their platform.

Of course, it provides so-called “Secret Chats,” but what is the use of it if it is only available on mobile clients and its encryption is self-rolled, provoking one of the most important laws in cryptography, which states explicitly: “DO NOT ROLL YOUR OWN CRYPTO.”

But besides its lack of proper E2EE, you might have to use it. I have to use it. Just because everyone I know uses it. And that’s a huge reason, believe it or not—you cannot go live on your own island forever. I have tried, and I have failed.

With all this hate speech I did on Telegram, it is time to introduce a client called “Partisan Telegram” that not only fixes the issues with E2EE but also provides some other kind of security to it.

Partisan Telegram brings operational security to Telegram, and by using it, you are still trusting Telegram with your data, which is not something you should do, honestly. Do not trust anyone with your data, especially if they can profit off your data or be pressured to hand out your data (be realistic—no one would shut down their platform in a country for you, let alone go to jail for you).

Partisan Telegram adds some privacy and security features that can be life-saving for protesters and activists in some parts of the world where freedom is far from a luxury, in places where expressing it is considered a crime and punished severely.

I like to keep this post short, so I will just explain how it works and what it offers.

How It Works

Partisan Telegram tries its best to obfuscate its existence so it wouldn’t put you into more trouble if you’re caught with it. So everything feels and looks like vanilla Telegram.

It uses the lock feature of Telegram, where you put a 4-digit passcode to access your Telegram. By using Partisan Telegram, you can set multiple passcodes, which can then be programmed to do certain things when entered. This is its main functionality.

For example, you can set the passcode “1234” to show only one account that you have nothing on. Or you can program it to send an alert message to your contacts when activated or to log off your accounts on all devices. And you will have a main passcode that will give you full access to your Telegram.

But how would this be useful? Imagine you’re caught mid-protest and someone is investigating your phone. You can just give them the fake passcode that you have programmed to log out your accounts and remove any evidence from the device without them noticing while alerting your friends who might have been involved. The scenarios can be endless.

What It Offers

Partisan Telegram’s main focus is your OPSEC, as it cannot add E2EE to Telegram without breaking its backward compatibility with other versions of Telegram. And it is relatively good at it.

Configurability

Partisan Telegram has great configurability. You can set endless fake passcodes and configure each to do a certain thing for a specific situation.

You can set a timer to go off or set a number of failed attempts to trigger a fake passcode, which will then trigger other events you have programmed it to do.

It can also take pictures when entering a wrong or fake passcode, which you can later check to see if someone has attempted to unlock your Telegram or not.

Triggering Killswitch by Receiving a Message

One main feature it provides is that the fake passcode actions or killswitch can be triggered if you receive a specific message.

This can be very useful if you lost your phone, or it got stolen or taken from you. You can remotely delete all your accounts from that phone and send an SOS message to your key contacts.

Providing Additional Security Measures

It also provides some other security measures, like brute-force protection for the passcodes, which Telegram itself doesn’t. With brute-force protection, the time between login attempts will increase every time.

It can also be set to delete cache and drafts on exit, which the original Telegram doesn’t offer.

It can prevent accidental clicks by double-checking with you when you accidentally touch the subscribe button or send a reaction to a message.

Delete After Read

It provides automatic delete-after-read for specific messages. You can send a message with a timer, and it will be deleted after the timer has passed. It is not like Telegram’s auto-delete, which deletes all messages from both sides after a period of time and is also visible when enabled or disabled, which can be more suspicious in some cases.

Other than that, Partisan Telegram also provides auto-delete to delete all of your messages in a group chat automatically. This can come in handy if you need to delete your messages and leave. Although all group chat events, like deleting or editing messages, will be visible to the admins of the group chat for 72 hours.

File Protection

Partisan Telegram can prevent information extraction from your phone by encrypting the data stored on the phone, including messages.

Encrypted Group Chats

Partisan Telegram recently introduced an experimental feature for having an encrypted chat with a group of people, which can be useful for organizing.

Other Perks

It can also bypass some of the annoying paywalls that Telegram has recently put up. For example, it will allow you to add more than three accounts without subscribing to Telegram Premium.

It can provide additional badges to certain accounts, helping you detect suspicious accounts and scammers before you interact with them.

Security Precautions

You should research before using anything, especially when it doesn’t have audits and a well-known, reputed developer team. But Partisan Telegram is fully open-source and can be compared against the original Telegram codebase to see exactly what has been modified. You can compile your own version instead of trusting their binaries.

You can find Partisan Telegram at https://github.com/wrwrabbit/Partisan-Telegram-Android.

It is a good project for a good purpose, but if you can avoid Telegram and use something like Signal (which includes E2EE and is built with privacy in mind), do it.

How Monero Fulfilled Satoshi's Promise

Zola Gonano — Fri, 07 Mar 2025 00:00:00 +0000

Since Trump’s election and even before that, news kept coming out about how crypto was going to change the world, how the US was going to become the crypto capital of the world, and how they wanted to build strategic reserves of Bitcoin, Ethereum, Solana, Ripple, and others. At the same time, however, they de-listed Monero from major exchanges like Binance and even criminalized this cryptocurrency.

But if we take a closer look at Monero, we can see that it was the true crypto—it was what Satoshi wanted to build.

But why is it hated so much by the authorities?

Governments first thought Bitcoin and early cryptocurrencies were anonymous too, as we did. But soon it became obvious that this anonymity shatters as soon as you spend your money in the real world.

Imagine you get some Bitcoin somehow, and you try to buy a car with it. Everyone can trace that transaction, get to the person who sold you the car, and identify you. With the help of AI, this can be further simplified and made easier to track.

But Monero is different. Monero is untraceable, meaning they don’t know who spends money. They cannot collect taxes, and they hate it when they cannot figure out what everyone in society is doing.

But despite all the efforts to criminalize Monero and delist it from exchanges, it has kept its value, continuing to increase over time because, like cash, it is actually used in transactions.

What is cash and what was Satoshi’s promise?

Satoshi’s whitepaper introduced Bitcoin as “Bitcoin: A Peer-to-Peer Electronic Cash System” , but Bitcoin never became electronic cash. Not even Bitcoin Cash managed to be electronic cash.

But what is cash? Cash is a form of money that allows for direct peer-to-peer transactions without intermediaries. When you pay for something with cash, you don’t know where the cash originally came from. You just know you got it, and you will give it to someone else in exchange. No matter how many times these green papers circulate among people, they won’t be linked to anyone. When you hand over cash, the transaction is irreversible and requires no third-party verification.

Cash is Permissionless , meaning no approval is needed to use it. Bitcoin and other public ledger cryptos are that to some extent.

Cash is Censorship-Resistant , meaning it cannot be blocked by banks or governments. Bitcoin is that as well to some extent, but there can be censorship when exchanging on centralized exchanges (CEX).

Cash is Untraceable , meaning transactions are not publicly recorded. Bitcoin and most cryptos are not that; they’re exactly the opposite.

Cash has No Counterparty Risk , meaning unlike digital bank balances, which depend on a central authority, cash does not. Neither Bitcoin nor most cryptos do.

Self-Custodial: When you have cash, it’s in your wallet. You’re holding it. Bitcoin and other cryptos are like that as well.

Based on all these points, Bitcoin and other public ledger cryptocurrencies have most of the characteristics of cash except one thing: Untraceability.

Monero found the missing piece of the puzzle

Monero introduced a new way that fixed the only missing piece of the “Electronic Cash” system that Satoshi wanted to build. Monero made a untraceable cryptocurrency while keeping all of cash’s characteristics.

To achieve this, Monero introduced a few new technologies to the crypto space:

1. Ring Signatures: Sender Anonymity

Monero transactions do not directly reveal the sender. Instead, they use ring signatures , which mix a real transaction input with decoys.

A ring signature allows a signer to create a signature that proves ownership of a private key without revealing which key in the set was used.

In a ring signature, the user is given a set of public keys $P1, P2, …, Pn$. The signer has the private key $sk$ corresponding to one of these.

The signature is constructed so that an observer cannot determine which private key was used, only that one of the keys in the ring signed the message.

Monero used to use Linkable Spontaneous Anonymous Group (LSAG) Signatures for ring signatures, in which:

Each participant’s public key contributes to a key image $I$, which is derived as: I=xH(P)I=xH(P) where $x$ is the private key, and $H(P)$ is a cryptographic hash of the public key.

Then, the signer constructs a ring $(P1, P2, …, Pn)$ such that: $σ=(I,c1,r1,…,rn)σ=(I,c1, r1, …, rn)$

where $c1$ is a random challenge, and $r_i$ are random values that make the signature verifiable without revealing the real signer.

A verifier can check that the key image $I$ hasn’t been used before, preventing double spending.

In 2020, Monero introduced Concise Linkable Spontaneous Anonymous Group Signatures (CLSAG), which does this much more efficiently.

With CLSAG, users see a 20% improvement in signature verification, and at least a 10% overall improvement for typical transactions. For example, a typical Monero transaction (2 inputs and 2 outputs) that usually weighs 2.5kB now takes only 1.9kB of blockchain space with CLSAG, a ~25% improvement.

2. RingCT: Amount Privacy

Bitcoin transactions openly show input and output amounts. Monero hides these with RingCT (Ring Confidential Transactions).

RingCT is based on Pedersen Commitments , which allow a sender to commit to a value without revealing it.

A commitment to a value $v$ is:

$C=vG+rHC=vG+rH$

where:

$G, H$ are generator points on an elliptic curve.
$r$ is a random blinding factor.

Each input and output amount is committed using Pedersen Commitments. Bulletproofs are used to prove that the committed values sum to zero (to ensure no coins are created out of thin air) without revealing them. Decoy amounts are included to make it impossible to determine the real transaction amounts.

Additionally, a Bulletproofs+ upgrade in 2022 reduced transaction size by 5-7x compared to original Bulletproofs, making Monero even faster.

Later on, cryptos like ZCash came along that use Zero-Knowledge Proofs (ZKPs) like ZK-Snarks to do this exact thing, and they are superior. But the problem with ZCash is that it is not the default; in Monero, all transactions are private, whereas in ZCash, some transactions can be private.

In ZKPs, someone can prove that they possess information (in the case of crypto, the amount of money they want to transfer) without revealing anything about the information itself.

3. Stealth Addresses: Receiver Privacy

Bitcoin addresses are static, meaning you can see all transactions going to a given address. Monero uses one-time stealth addresses that unlink the receiver from the transaction.

Each Monero wallet has a public view key $v$ and a public spend key $s$. When sending a transaction, the sender generates a one-time public key $P$ as follows:

$P=H(rV)G+SP=H(rV)G+S$

where:

$r$ is a random scalar chosen by the sender.
$V$ is the recipient’s public view key.
$S$ is the recipient’s public spend key.
$G$ is the elliptic curve generator.

The recipient can compute the corresponding private key to spend the funds:

$P′=H(rv)G+sP′=H(rv)G+s$

This ensures that only the recipient can identify and spend the transaction , but an outsider cannot link it to a wallet.

4. Dandelion++: Network-Level Privacy

Even if transactions are private on-chain, Bitcoin and other cryptocurrencies leak metadata through the P2P network when broadcasting transactions. Monero mitigates this with Dandelion++ , which obfuscates transaction propagation.

In Dandelion++, a node first selects a “stem” path (a small subset of nodes) to pass the transaction privately. Then, at a random step, the transaction “fluffs” (broadcasts) to the entire network. This makes it difficult to determine the original source of the transaction.

Monero makes a more decentralized cryptocurrency than Bitcoin

As mining becomes more competitive, larger entities with access to specialized hardware (ASICs) and cheap electricity can dominate the mining process. This leads to centralization, where a few large mining pools control the majority of the network’s hash power, potentially threatening decentralization and security.

Monero introduces a new PoW algorithm called RandomX to be ASIC-resistant by making the PoW memory-hard, meaning it requires RAM to compute hashes, which cannot be specialized like SHA hashes. RAM is expensive to obtain.

Also, unlike Bitcoin’s 1 MB limit , Monero has an adaptive block size to prevent congestion. And unlike Ethereum and Solana, Monero has no pre-mined coins, no corporate backing, and no central leadership.

With all that being said, we all love Bitcoin, Ethereum, and Solana. They’re great technologies, and even the worst of them is still superior to the best of banking systems.

A Very Technical Look at BitMessage: Learning From a Dead Project

Zola Gonano — Sun, 25 Aug 2024 00:00:00 +0000

There are a lot of cool projects that unfortunately have been abandoned or unmaintained for years, but that doesn’t mean they added no value. Studying what they’ve done, taking their unique ways of doing certain things and their problems can lead us to build something better. Bitmessage is one of those projects; it is an email-like service but fully peer-to-peer and decentralized, built upon the same principles. It used innovations of other projects like Bitcoin to build a new thing.

But sadly, Bitmessage didn’t seem to make it. Though it was a cool project, it never got independently audited and its latest release was in 2018. There aren’t many peers left on the network and its client has some known and critical vulnerabilities like remote code execution, but none of this means it served no good. There have been freedom-loving and privacy-caring people behind it, dedicating their time, money, and energy to build something valuable.

In this post, I wanted to take a technical look at this network, on how it worked in depth (like the post I did on Zeronet) in a very simple and easy-to-understand way.

What did Bitmessage do

Bitmessage was supposed to be like a truly P2P email system. You would send a message on the network, it would have been encrypted for the receiver and spread across the peers until the receiver got it. Everyone would get the message, but only the receiver would open it. That causes some issues, though. We’re relying too much on the encryption scheme and its implementation. If a flaw in the scheme was found, the whole network would become insecure until a new version was released, and then it would break compatibility with older versions. Here, a bad actor could log all messages flowing on the network and wait for the day that a vulnerability in encryption was found, then they would open all messages. Networks like Jami and Tox do this differently; they find the receiver and then directly communicate with them, which fixes that problem.

Mailing Lists

One of the interesting features of Bitmessage was its mailing list feature, which is a broadcast address that, when someone sends a message to it, a copy of the message gets sent to everyone in the subscription list of this address.

But the downside is that everyone can send a message to a mailing list in Bitmessage without even being a member of it, and that is the recipe for spam.

Subscriptions

Subscriptions in Bitmessage allow users to receive encrypted broadcasts from a subscribed address. The way that this encryption happens is not very secure. A broadcast message is encrypted with a key, which can be derived from the sender’s address. Once a broadcast is decrypted, the sender’s address is known, and after that, every broadcast ever sent and every broadcast that will be sent in the future can be decrypted.

Private Messages

Private messages in Bitmessage are those messages that have only one recipient. All private messages are encrypted using the receiver’s public key (and the receiver’s public key is the receiver’s address), and when the receiver successfully decrypts the sender’s message, they send an ACK message telling the sender that the message has been successfully received and decrypted. If the ACK message isn’t received within 2.5 days, the message expires and the sender will have to do the Proof-of-Work again.

Note: Explain the Proof of Work and how it works in Bitmessage here

BitMessage’s Encryption

Bitmessage used an ECIES (Elliptic Curve Integrated Encryption Scheme) to encrypt the payloads of the messages and broadcast objects.

This scheme uses ECDH (Elliptic Curve Diffie-Hellman) to generate a shared secret, which is then used to encrypt the data using AES-256 (Advanced Encryption Standard) in CBC mode.

This scheme, by today’s standards, isn’t that secure. The CBC mode adds a lot of complications and insecurities because it doesn’t have authentication of messages, and self-implementation of them leaves room for many errors and mistakes. A better scheme by today’s standards would use X25519 to exchange the keys and generate the shared secrets. X25519 is based on Curve25519, which is faster and more secure than ECDH.

Also, there are other new methods for exchanging keys besides elliptic curves and RSA, like Key Encapsulation Mechanisms (KEMs), which are supposed to reduce the complexity of the key exchange methods.

The encryption process in Bitmessage is as follows (taken from Bitmessage’s wiki):

The destination public key is called K.

Generate 16 random bytes using a secure random number generator. Call them IV.

Generate a new random EC key pair with the private key called r and the public key called R.

Do an EC point multiply with public key K and private key r. This gives you public key P.

Use the X component of public key P and calculate the SHA512 hash H.

The first 32 bytes of H are called key_e and the last 32 bytes are called key_m.

Pad the input text to a multiple of 16 bytes, in accordance with PKCS7.

Encrypt the data with AES-256-CBC, using IV as the initialization vector, key_e as the encryption key, and the padded input text as the payload. Call the output ciphertext.

Calculate a 32-byte MAC with HMAC-SHA256, using key_m as salt and IV + R + ciphertext as data. Call the output MAC.

The resulting data is: IV + R + ciphertext + MAC

This could be improved in many ways, for example:

Using a safe KDF like HKDF to derive the keys instead of using a hash like SHA512.
Using an AEAD to ensure the integrity of the encrypted message instead of calculating the MAC separately and increasing the risk of implementation errors.
Using a KEM to exchange the keys would simplify the exchange process while increasing security by reducing the risk of key interception or leakage.

Plausible Deniability

Plausible deniability is when someone can say they didn’t know about something bad that happened, and there is no clear proof to show they did.

Plausible deniability is a big part of Bitmessage. In Bitmessage, the messages are not only encrypted but also signed with the sender’s address to prevent strangers from claiming to be a specific person. However, this also causes problems: if a message is decrypted and the signature is verified, the content of the message can be used against the sender. But these actions can be taken for plausible deniability in Bitmessage:

Deleting: Address blocks can be deleted from keys.dat so they are no longer used to send or receive messages.
Publication: Another thing that can be done is to publicly share the address block in a crowded mailing list. This way, users can pretend that they never used that address at all, and there will be no proof that they actually did, or someone else who had access to that address block. But this comes with some consequences:
1. Everyone can claim that they’re the true owner of the address, impersonating the address.
2. Every message that was sent using or to the public address can be decrypted by everyone. While the messages delete after 2.5 days, there might always be a backup copy of the messages.

BitMessage’s Proof of Work

To prevent or at least reduce the spam on the network, Bitmessage used proof of work to address this problem.

Proof of work is a costly task for a computer to perform, for example, a calculation that requires time and effort (for a computer) to do, and it is verifiable by other people that this calculation or work is done correctly and there is no cheating involved.

Bitmessage uses a double round of SHA-512 for its proof of work, meaning it hashes a message twice with SHA-512. It is not very costly by modern standards, and in my opinion, it doesn’t prevent spam that much. It could have been improved by using a hash algorithm that requires memory to perform the hashing, usually a key derivation function (KDF) like Argon2id or scrypt. These algorithms not only require CPU/GPU power but also take up RAM, and RAM is much more expensive than CPU power.

hello
9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043 (first round of SHA-512)
0592a10584ffabf96539f3d780d776828c67da1ab5b169e9e8aed838aaecc9ed36d49ff1423c55f019e050c66c6324f53588be88894fef4dcffdb74b98e2b200 (second round of SHA-512)

BitMessage’s Addresses

In Bitmessage, all addresses are Base58 encoded hashes of the public key. The hash algorithm for address generation is different from its PoW algorithm; for addresses, Bitmessage uses RIPEMD-160 instead.

For example, a Bitmessage address looks like this:

BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash

All Bitmessage addresses start with the characters “BM-“ to indicate they are part of the protocol. This is a good idea because when a network applies such a separator in the addresses, it becomes easier to identify newer versions of addresses. For example, if in a new version of Bitmessage they wanted to use a different hash or public key algorithm, they could have changed the address prefix to BMV2-, indicating it is version 2 of the address. This would let users know if they need a newer client and would prevent sending messages from unsupported clients to newer versions.

BitMessage’s Protocol

BitMessage’s Message Encoding

BitMessage’s protocol uses a custom encoding system for its messages that are sent over the network. It consists of several parts:

1. Message Header

Magic (4 bytes): Identifies the network. It helps the protocol to recognize the beginning of a message. Known magic values include 0xE9BEB4D9.
Command (12 bytes): ASCII string identifying the type of message. It’s padded with NULL bytes (\x00) to ensure a length of 12 bytes.
Length (4 bytes): Specifies the length of the payload. It’s an unsigned 32-bit integer, meaning it can describe a payload up to 4,294,967,295 bytes, though restrictions limit it to 1,600,003 bytes.
Checksum (4 bytes): First 4 bytes of the SHA-512 hash of the payload to ensure data integrity.
Message Payload (variable): The actual data being transmitted, which could vary based on the message type.

2. Variable Length Integer (VarInt)

1 byte : For values less than 0xFD.
3 bytes : Starts with 0xFD followed by a uint16_t value.
5 bytes : Starts with 0xFE followed by a uint32_t value.
9 bytes : Starts with 0xFF followed by a uint64_t value.

3. Variable Length String

Prefixed with a VarInt indicating the length of the string, followed by the string itself.

4. Variable Length List of Integers

Starts with a VarInt specifying the number of integers, followed by the integers themselves, each encoded as VarInts.

5. Network Address Structure

Time (8 bytes): Timestamp.
Stream (4 bytes): Stream number for the node.
Services (8 bytes): Node services bitfield.
IPv6/4 (16 bytes): IPv6 address (or IPv4 mapped into IPv6).
Port (2 bytes): Network port.

6. Inventory Vectors

Used to announce or request objects within the network. Each entry includes a 32-byte hash representing the object.

7. Encrypted Payload

IV (16 bytes): Initialization vector for AES-256-CBC encryption.
Curve Type (2 bytes): Identifies the elliptic curve used (e.g., 0x02CA for secp256k1).
Public Key Components (X and Y): Lengths and values of the X and Y coordinates of the elliptic curve public key.
Ciphertext : The actual encrypted data.
MAC (32 bytes): Message Authentication Code using HMAC-SHA256.

8. Unencrypted Message Data

Various fields including version, address version, stream number, public keys, and a bitfield indicating node behavior.
Nonce Trials per Byte and Extra Bytes : Difficulty settings for Proof of Work.
RIPE Hash (20 bytes): Represents the receiver’s public key.
Message Encoding : Specifies how the message is formatted (e.g., UTF-8).
Signature : ECDSA signature covering specific parts of the message.

9. Message Types

Version Message : Announces a node’s protocol version and capabilities.
Verack Message : Acknowledges the reception of a version message.
Addr Message : Provides information about known nodes.
Inv and Getdata Messages : Handle the exchange of object information and requests.
Object Message : Carries content that propagates across the network, such as public keys, messages, or broadcasts.

10. Pubkey and Broadcast Structures

Pubkey : Contains public keys for signing and encryption, behavior bitfields, and optionally encrypted data (in version 4 and above).
Broadcast : Used for sending messages to subscribers, with version 4 and 5 utilizing tags and encryption for additional security.

There could be some improvement to this encoding format. For example:

The protocol uses a variable-length encoding that allows smaller numbers to be represented with fewer bytes. However, the current scheme (e.g., using 0xFD, 0xFE, and 0xFF prefixes) might be wasteful for certain number ranges. A more efficient variable-length encoding scheme, such as LEB128 (Little Endian Base 128), which is widely used in formats like WebAssembly, encodes integers using a variable number of bytes, with no need for extra prefix bytes, making it more space-efficient for both small and large numbers.
The protocol stores full 128-bit IPv6 addresses, which can be wasteful, especially for addresses with long sequences of zeros. It could use address compression techniques, similar to how IPv6 addresses are represented textually (e.g., using :: to replace sequences of zeros). Alternatively, apply prefix compression if many addresses share a common prefix.
Commands are encoded as fixed-length, 12-byte ASCII strings, which is simple but inefficient and inflexible. Using a variable-length encoding for commands, storing the command length as a prefix, followed by the command string, would reduce the size of the message when the command is shorter than 12 bytes.

BitMessage’s Message Types

Message types refer to the different kinds of messages that nodes (computers) can send and receive in a peer-to-peer network. These messages are used for various purposes, including establishing connections, sharing information about nodes, requesting and receiving data, and managing the objects (like messages or keys) in the network.

1. Version

What It Is : When two nodes first connect, they need to agree on the version of the protocol they are using.
What It Contains :
- Version : Tells which version of the protocol the node is using (should be version 3).
- Services : Lists the features the node supports (like network connectivity or security options).
- Timestamp : The current time.
- Addresses : The network addresses of the node sending and receiving the message.
- Nonce : A random number used to check if the connection is with itself.
- User Agent : Information about the software being used.
- Stream Numbers : The streams of messages the node is interested in.

2. Verack

What It Is : A simple acknowledgment message sent in reply to the version message.
What It Contains : Just a header with the command “verack” (short for “version acknowledgment”).
Purpose : Signals that the connection setup is complete and both nodes are ready to communicate. After this, they can start a secure connection if both support SSL/TLS.

3. Addr

What It Is : A message that provides information about other nodes in the network.
What It Contains :
- Count : The number of addresses being shared.
- Address List : The addresses of other nodes.

4. Inv

What It Is : A message used to announce that a node knows about certain objects (like messages or public keys).
What It Contains :
- Count : The number of objects being announced.
- Inventory : Details of each object.

5. Getdata

What It Is : A request to get the actual data of specific objects after they have been announced by inv.
What It Contains :
- Count : The number of objects being requested.
- Inventory : Details of each object requested.

6. Object

What It Is : This is the actual data message that gets shared across the network. It’s the primary way to send information.
What It Contains :
- Nonce : A random number used to ensure the message has been properly processed.
- Expires Time : When the object will no longer be valid.
- Object Type : Tells what kind of message it is (like a request for a public key, a public key, a message, or a broadcast).
- Version : The version of the object format.
- Stream Number : The stream the object is related to.
- Object Payload : The actual content of the message, which varies depending on the type of object.

The message types could have been improved by implementing these methods:

A more detailed protocol negotiation mechanism to handle different versions and backward compatibility better.
Including additional metadata about the node’s capabilities or preferences (e.g., supported encryption algorithms or message types) to optimize the interactions.
Ensuring SSL/TLS handshakes are mandatory and verified before proceeding with further messages.
Implementing mechanisms to dynamically update and validate node addresses to ensure that outdated or invalid addresses are removed from the list.
Using methods to anonymize node addresses or using temporary addresses that change periodically to increase privacy.
Supporting batch requests to retrieve multiple objects in a single getdata message, reducing overhead and improving efficiency.
Implementing priority mechanisms to request the most critical data first and supporting caching to avoid redundant requests for the same data.
Using compression algorithms to reduce the size of object

messages, especially for large payloads.

Implementing version control within object messages to handle changes in the object structure or content format over time.

BitMessage’s Object Types

Object types are specific data structures used to perform various operations within the network. Each object type serves a particular purpose, such as requesting a public key, sending messages, broadcasting information to multiple recipients, or transmitting a public key. These objects are the building blocks of the protocol, enabling nodes (participants in the network) to communicate, authenticate, and exchange information securely and efficiently.

1. `getpubkey` Object

Purpose : This object is used by a node to request a public key from another node when it has the hash of the public key (from an address) but not the key itself.
Fields :
- ripe (20 bytes): This is the RIPEMD-160 hash of the public key. It is included only when the address version is 3 or below.
- tag (32 bytes): This is derived from the address version, stream number, and ripe hash. It’s included when the address version is 4 or above, ensuring that the requesting node can correctly identify the public key.

2. `pubkey` Object

Purpose : The pubkey object contains the public key information used for cryptographic operations like signing and encryption. The format of this object evolves across different protocol versions.
Version 2 :
- behavior bitfield (4 bytes): Indicates the behaviors and features supported by the node. This is a set of flags that tell other nodes what to expect.
- public signing key (64 bytes): The ECC public key used for signing messages, provided in an uncompressed format.
- public encryption key (64 bytes): The ECC public key used for encrypting messages, also in an uncompressed format.
Version 3 : Builds upon version 2 by adding:
- nonce_trials_per_byte (variable length): Defines how hard the Proof of Work (PoW) needs to be for messages accepted by the node. A higher value increases the difficulty.
- extra_bytes (variable length): Adds to the message length to increase the difficulty of sending small messages.
- sig_length (variable length): Length of the signature.
- signature (variable length): The ECDSA signature that covers the object header and data.
Version 4 : In version 4, most of the pubkey data is encrypted:
- tag (32 bytes): Helps in identifying the correct pubkey for decryption.
- encrypted (variable length): Contains encrypted data, which includes fields like the behavior bitfield, public signing key, and public encryption key. This encryption is intended to prevent spam or abuse of the public key.

3. `msg` Object

Purpose : The msg object is used for sending person-to-person messages within the network.
Fields :
- encrypted (variable length): The message data is encrypted to ensure confidentiality. The details of this encryption are handled similarly to how pubkeys are encrypted, ensuring only the intended recipient can read the message.

4. `broadcast` Object

Purpose : The broadcast object allows a user to send messages to all subscribers of an address. This is typically used for announcements or public messages.
Fields :
- tag (32 bytes): Similar to the pubkey object, it helps identify the broadcast messages that are relevant to a particular address.
- encrypted (variable length): Contains the encrypted broadcast data. Like in the msg object, the encryption ensures that only the intended recipients can decrypt and view the broadcast.

Encryption Mechanism

For Version 4+ Objects :
- The encryption is done using a key derived from the double SHA-512 hash of the address version, stream number, and the ripe hash of the address. This ensures that only nodes that know the address can decrypt the pubkey or broadcast message, adding a layer of privacy and security.
- The process involves creating a public and private key pair from the first 32 bytes of the hash, which is then used for encrypting the pubkey data.

Understanding Specific Fields :

behavior bitfield : This is a bitmask that specifies what behaviors the node supports. Each bit in the 32-bit field might represent a different capability or feature.
public signing key and public encryption key : These are standard ECC (Elliptic Curve Cryptography) keys used in the cryptographic processes of signing messages to verify authenticity and encrypting messages to ensure privacy.
nonce_trials_per_byte and extra_bytes : These are parameters related to the Proof of Work mechanism, which is used to prevent spam by making it computationally expensive to send messages.
tag : This is a unique identifier derived from the address data, allowing nodes to quickly determine whether a particular piece of data is relevant to them.

Object types also have some issues that could have been addressed and improved:

Instead of requesting public keys using a hash, using a more direct method to find and retrieve keys quickly.
Allowing the behavior bitfield and other metadata to be dynamically updated rather than fixed, so nodes can negotiate features dynamically.
Implementing data compression to reduce the size of encrypted messages and improve transmission efficiency.
Improving the tagging mechanism to handle larger and more complex broadcasts efficiently. For instance, using hierarchical tagging to manage different types of broadcasts.

BitMessage’s Files

BitMessage uses several .dat files to store crucial data for the client to work:

Knownnodes.dat

BitMessage uses a file named knownnodes.dat to store the IP addresses and ports of the nodes that run BitMessage. These nodes help bootstrap the connection to the network.

Keys.dat

keys.dat is a file used by BitMessage to store important settings and address information.

This file is the most important file in BitMessage as it contains all your keys; if you lose this file, you lose your BitMessage identity (which is your private/public keys).

Configuration Sections

[DEFAULT] and [bitmessagesettings]
Address Sections

messages.dat

All messages in BitMessage are stored in a SQLite database named messages.dat, along with keys.dat and knownnodes.dat in the same directory.

This database uses different tables for different messages, for example, messages that were retrieved and decrypted, sent messages, and also some app configurations:

`inbox` Table:

This table contains messages that were retrieved and were successfully decrypted. It also stores trash messages as well.

CREATE TABLE inbox (
    msgid blob,
    toaddress text,
    fromaddress text,
    subject text,
    received text,
    message text,
    folder text,
    encodingtype int,
    read bool,
UNIQUE(msgid) ON CONFLICT REPLACE)

`sent` Table:

Similar to the inbox table, it contains only the sent messages, including the trashed sent messages:

CREATE TABLE sent (
    msgid blob,
    toaddress text,
    toripe blob,
    fromaddress text,
    subject text,
    message text,
    ackdata blob,
    lastactiontime integer,
    status text,
    pubkeyretrynumber integer,
    msgretrynumber integer,
    folder text,
    encodingtype int
)

`subscription` Table:

This table contains all the addresses that the user has subscribed to:

CREATE TABLE subscriptions (
    label text,
    address text,
    enabled bool
)

`addressbook` Table:

This table contains all of the addresses that a user has communicated with in the past, like a phonebook:

CREATE TABLE addressbook (
    label text,
    address text
)

`blacklist` Table:

As the name suggests, any address that a user blocks will be stored in this table to prevent future communications with these addresses:

CREATE TABLE blacklist (
    label text,
    address text,
    enabled bool
)

`whitelist` Table:

This table, similar to the blacklist table, contains addresses that are whitelisted. If the field enabled is set to true, the user can only communicate with the addresses in this table.

CREATE TABLE whitelist (
    label text,
    address text,
    enabled bool
)

`knownnodes` Table:

This table was created for future use and to replace the knownnodes.dat file, which never happened as the project’s development halted.

CREATE TABLE knownnodes (
    timelastseen int,
    stream int,
    services blob,
    host blob,
    port blob,
UNIQUE(host, stream, port) ON CONFLICT REPLACE)

`settings` Table:

This table, like the knownnodes table, is not implemented and was set to replace the keys.dat file configurations.

CREATE TABLE settings (
    key blob,
    value blob,
UNIQUE(key) ON CONFLICT REPLACE)

`pubkeys` Table:

This table contains public keys created by the user and the time they were last transmitted.

CREATE TABLE pubkeys (
    hash blob,
    transmitdata blob,
    time int,
    usedpersonally text,
UNIQUE(hash) ON CONFLICT REPLACE)

This approach has some obvious flaws that could have been addressed relatively easily:

There is no need for storing sent and retrieved messages in separate tables; it could have been done by adding a field to a table called messages to determine whether it is sent or received. This would reduce a table in the database, making it smaller, especially as it is a file-based database.
Whitelists and blacklists could have been implemented into the addressbook table by adding a field to determine whether the address is whitelisted or blacklisted.
Using a file-based database for storing messages is not a good idea as they will get huge and will slow down as they grow more and more with usage.
Configurations such as knownnodes aren’t related to the messages and should have a separate database, perhaps named configs.dat, to store all configurations and settings.

BitMessage’s Stream

In BitMessage, a stream is like a separate channel or group where nodes can communicate. Streams in BitMessage help organize and manage communication between nodes. They allow for more efficient data handling and keep the network organized.

This feature was never fully implemented to have multiple streams, and all addresses use stream 1 in BitMessage. When you create a new address, you usually set it up with a stream number, which is stream 1.

Stream 1 is the main or “master” stream. It’s the primary stream and, at the moment, the only one.

If you have addresses in different streams, your BitMessage client will connect to other clients in those specific streams only. This helps manage and reduce the amount of data your client handles. Your client will also connect to streams of addresses you are subscribed to.

Clients occasionally connect to Stream 1 to let other clients know that they exist. This helps clients find out which stream a particular address is using.

If there are too many messages in a stream, clients can create new streams (child streams) to manage the load. This helps keep the traffic and messages more manageable.

When someone wants to send you a private message, they need to find your stream and send it there. You then need to connect back to their stream to acknowledge receipt of the message.

Broadcasts are sent to the stream associated with the sending address. If you want to receive broadcasts from another stream, you have to connect to that stream and check for messages manually. For example, if you’re in Stream 5 and want updates from Stream 1, you need to connect to Stream 1 to get those updates.

This feature, if implemented fully, could benefit a searching system where users could look up different stream numbers and connect to those. It could also allow users to prioritize streams based on their preferences. This way, important streams receive more attention and resources, while less critical ones are managed with lower priority.

Good BitMessage’s Proposals

BitMessage had some good proposals to implement. If development had continued, it could have made a solid network.

Scalability through Prefix Filtering

This proposal was to make BitMessage more scalable. The proposal is still a work in progress, and some details are yet to be finalized. It suggests a new system to handle how messages are routed through the network to manage increasing traffic efficiently.

In this proposal, every BitMessage address and network node will have a ‘prefix’ and a ‘prefix length.’ These determine how messages are routed and how much traffic each node handles.

Nodes will be grouped into overlapping ‘streams’ based on these prefixes. As the network grows or shrinks, both addresses and nodes will move between streams to balance traffic and privacy.

Each message or object has a ‘prefix nonce’ that determines which streams it will travel through. Objects are processed in their stream and all higher streams in the same branch.

Stream Structure

The diagram below shows the proposed structure of streams in BitMessage:

In the diagram above, the small, light blue circles represent groups of nodes, and the large colored circles represent streams.

Node Connections

The diagram below shows the connections between nodes and clients under the proposed system:

Nodes and clients are labeled with a stream number, which corresponds to the stream numbers in the stream structure diagram above.

Proposed Changes

Prefixes:
- Purpose: Prefixes route messages through the network. Instead of creating or deleting streams, this proposal uses a vast number of possible prefix values to manage traffic and privacy.
- Node and Address Management: Nodes and addresses are assigned a prefix and prefix length to control their traffic handling and balance anonymity with efficiency.
Address and Object Structure:
- Address Prefix: The prefix is part of the address and does not change.
- Prefix Length: Determines the address’s stream. Changing the prefix length adjusts the stream assignment.
- Object Structure: Messages (objects) include a ‘prefix nonce’ to dictate their propagation path.
Stream Hierarchy:
- The proposed system involves a multi-level hierarchy of streams. Each stream level handles different traffic volumes and maintains connections accordingly.

How Objects Travel and Nodes Connect

Node Connections:
- Nodes connect to multiple nodes in their stream and nearby streams. They also connect directly to other streams as needed.
- Higher-capacity nodes maintain more connections.
Message Propagation:
- Nodes process messages in their stream and all higher streams within the same branch.

Client Procedures

Creating an Address:
- The client requests information on current traffic levels, sets a prefix length for the address, and generates a pubkey with this prefix length.
- The client then sends the pubkey to the appropriate nodes based on the stream.
Retrieving a Pubkey:
- The client queries nodes in the stream to get the pubkey for an address, matching the address’s prefix value.
Sending a Message:
- The client sets the prefix nonce of the message to match the destination address’s prefix and sends it to the relevant stream.
Retrieving Messages:
- The client connects to nodes in the address’s stream or higher streams to request and process messages.
Broadcasts:
- Broadcasts are sent to all nodes in the destination address’s stream. Clients need to periodically check these streams for new broadcasts from subscribed addresses.

Argothas Architecture

The goal of this proposal is to make it more scalable and user-friendly while preserving privacy. It is worth mentioning that this system sacrifices some aspects of complete anonymity and the ability to check for new messages instantly.

The new system involves several types of servers:

Data Server (DS): Stores actual messages.
Introduction Server (IS): Handles notification messages that inform users about new messages.
Directory Server (DIR): Keeps track of all available servers so clients can find them.

New Address Process

Create Address: The user creates a new BitMessage address.
Find Servers: The user connects to a DIR to get a list of available ISs.
Select ISs: The user chooses some ISs to use.
Request Access: The user contacts the chosen ISs to request access.
Store Details: If accepted, the IS’s details are stored with the user’s address.

Why Multiple ISs?

Redundancy: If one IS is down, the user can still receive messages through others.
Privacy: Using multiple ISs prevents any single IS from seeing all messages.

New Message Process

Create Message: The sender prepares the message.
Choose DS: The sender picks a Data Server to store the message.
Store Message: The DS responds with a minimum proof-of-work value (security measure).
Send Message: The sender uploads the message to the DS.
Prepare Notification: The sender creates a notification message (NMESSAGE) with instructions for the recipient.
Send Notification: The sender sends the NMESSAGE to the chosen ISs.

Receiving Messages

Check ISs: The recipient periodically connects to their ISs to check for new notifications.
Retrieve Messages: The recipient decrypts the notification and then fetches the actual messages from the Data Servers.

Onion Routing

Purpose: Onion routing (like TOR) hides users’ IP addresses to prevent tracking and linking of messages.
Question: Should BitMessage clients use TOR, or should the BitMessage network create its own onion routing system?

This proposal suggests a more scalable and private architecture for BitMessage. It involves using multiple servers to handle different types of data, distributing trust among them, and incorporating onion routing for enhanced privacy.

Bitmessage was a great project aiming to create a fully decentralized and private messaging system. Even though it’s no longer maintained and has some serious issues, it was an appreciable effort in its time.

By studying Bitmessage and other similar projects, we can learn valuable lessons from their innovations and challenges. These lessons help us understand what worked, what didn’t, and how we can build even better systems in the future.

The dedication of the people behind Bitmessage, who worked hard to create something meaningful, is a testament to their commitment to privacy and freedom. Their work, despite its limitations, has paved the way for new ideas and improvements in the world of decentralized communication.

While Bitmessage may be a project of the past, its impact continues to guide future developments in privacy-focused and decentralized technologies.

As always, this post is freely available on my GitHub. If you see any problems or have any suggestions, please make a pull request or open an issue.