DEV Community: Zola Gonano

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.

Creating a Muti-Algorithm simple Proof-Of-Work library in Rust

Zola Gonano — Thu, 09 May 2024 00:00:00 +0000

I had an idea for a project that required Proof of Work as a part of it, but I couldn’t find any Rust libraries that would have Argon2id or Scrypt algorithms and were meant to provide proof of work functionality without being tied to a specific blockchain. So, I decided to develop my own. When I was doing so, I wanted to show how Rust’s data types can make such things easy and clean.

Okay, but what is PoW? Proof of Work is like solving a puzzle – an expensive task for a computer. It’s proof that your computer has done something difficult. It’s mostly used in cryptocurrency blockchains during mining, proving that the miner has completed the puzzle (equivalent to going to a mine and digging with a pickaxe for gold and silver). However, it’s not necessarily meant only for mining. Another common example of its use is for preventing spam on a network, which was the reason I needed to use it. For example, Bitmessage, which was an old (now defunct) P2P email network, used it to prevent spam on the network.

The idea is pretty straightforward. I wanted a library that is expandable, meaning multiple algorithms can be added to it without breaking everything. Secondly, I needed it to be general-purpose. I didn’t want it to be meant for one specific blockchain; I wanted it to handle any data and verify any data using it.

To start, I created a PoWAlgorithm enum, which would be expanded to include algorithms that the library is going to support. For now, I’ve used SHA2_256 for testing.

pub enum PoWAlgorithm {
    Sha2_256,
}

Next, I implemented calculate functions for it, which compute the hash of given data:

impl PoWAlgorithm {
    pub fn calculate_sha2_256(data: &[u8], nonce: usize) -> Vec<u8> {
        let mut hasher = Sha256::new();
        hasher.update(data);

        hasher.update(nonce.to_le_bytes());

        let final_hash = hasher.finalize();

        final_hash.to_vec()
    }

    pub fn calculate(&self, data: &[u8], nonce: usize) -> Vec<u8> {
        match self {
            Self::Sha2_256 => Self::calculate_sha2_256(data, nonce),
        }
    }
}

This kind of structure also allows using a trait for algorithms later, reducing some of the code and making the project cleaner as it grows.

Then I created the PoW library, meant to calculate and verify the proof of work based on the given data, difficulty, and the algorithm.

pub struct PoW {
    data: Vec<u8>,
    difficulty: usize,
    algorithm: PoWAlgorithm,
}

For the data, I decided to accept all types that implement serde’s Serialize trait and convert the data to JSON. This way, anyone could provide their own structs and data types to the PoW.

impl PoW {
    pub fn new(
        data: impl Serialize,
        difficulty: usize,
        algorithm: PoWAlgorithm,
    ) -> Result<Self, String> {
        Ok(PoW {
            data: serde_json::to_vec(&data).unwrap(),
            difficulty,
            algorithm,
        })
    }

    pub fn calculate_pow(&self, target: &[u8]) -> (Vec<u8>, usize) {
        let mut nonce = 0;

        loop {
            let hash = self.algorithm.calculate(&self.data, nonce);

            if &hash[..target.len()] == target {
                return (hash, nonce);
            }
            nonce += 1;
        }
    }

    pub fn verify_pow(&self, target: &[u8], pow_result: (Vec<u8>, usize)) -> bool {
        let (hash, nonce) = pow_result;

        let calculated_hash = self.algorithm.calculate(&self.data, nonce);

        if &calculated_hash[..target.len()] == target && calculated_hash == hash {
            return true;
        }
        false
    }
}

For the actual proof of work calculation, I followed what most cryptocurrencies do. I defined target bytes, which are the bytes that the hash should match with at the beginning. The nonce is then incremented until the hash meets this target.

My blog and all of its content are available under the CC by SA 4.0 License on my GitHub. If you notice any problems or have any improvements for the blog or its content, you’re always welcome to open a pull request.

Hosting Multiple Censorship Circumvention Tools on a VPS

Zola Gonano — Wed, 01 May 2024 00:00:00 +0000

This is a guide for those who live under heavy internet censorship and restrictions and want to host their own censorship circumvention tools and services to bypass the firewalls and access the free internet. To understand how these censorship systems and firewalls work, you can check out my previous post by clicking here.

To host your own VPN and Proxy services, you will need a VPS with unrestricted internet access (and in some extreme cases a VPS inside your country to communicate with that VPS with unrestricted access, which I’ll explain why and how later in this post).

Using Sing-box to create our proxy servers

Sing-box is a fast universal proxy platform with straightforward configuration. It can be used to run many services like Trojan, VMess, VLess, Shadowsocks, Hysteria, TUIC, and other censorship circumvention tools.

For this post, I’ll be creating a Shadowsocks server and a Trojan server using Sing-box. However, you can check Sing-box’s configuration guide and choose the protocol that works best for you.

For the Trojan server, we will need a domain name with a certificate. If the domain name is not available, we can generate a self-signed certificate instead.

To create the self-signed certificates, run these openssl commands:

openssl genrsa -out privkey.pem 2048
openssl req -new -key privkey.pem -out csr.pem
openssl x509 -req -days 365 -in csr.pem -signkey privkey.pem -out fullchain.pem

This should generate two files, privkey.pem and fullchain.pem, which we will use for TLS encryption in Sing-box.

Now, let’s create the Sing-box config file:

{
  "inbounds": [
    {
      "type": "trojan",
      "listen": "127.0.0.1",
      "listen_port": 4431,
      "users": [
        {
          "name": "example",
          "password": "password"
        }
      ],
      "tls": {
        "enabled": true,
        "server_name": "example.org",
        "key_path": "privkey.pem",
        "certificate_path": "fullchain.pem"
      }
    },
    {
      "type": "shadowsocks",
      "listen": "127.0.0.1",
      "listen_port": 4432,
      "network": "tcp",
      "method": "2022-blake3-aes-128-gcm",
      "password": "<server_password>",
      "users": [
        {
          "name": "username",
          "password": "<user_password>"
        }
      ]
    }
  ]
}

Now, our config file is ready. It will run a Shadowsocks server for us on 127.0.0.1:4432 and a Trojan server on 127.0.0.1:4431, which we will redirect traffic to using HAProxy.

To run our Sing-box server, we need to execute the Sing-box command:

sing-box run -c config.json

Optionally, you can create a systemd service for it as well to make it automatically run on boot:

To set up the systemd service, create and open a file at /etc/systemd/system/sing-box.service and add the following configuration (change the paths according to where your config file and Sing-box executable are located):

[Unit]
Description=Sing-box Service
After=network.target

[Service]
Type=simple
ExecStart=/path/to/sing-box run -c /path/to/config.json
WorkingDirectory=/path/to/sing-box
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Then, reload the systemd services and enable and start the Sing-box service:

sudo systemctl daemon-reload
sudo systemctl enable sing-box.service --now

Setting-Up HAProxy to host multiple services on one Port

Most of the time, you can only use common ports like 443 (which is for TLS and it’s not suspicious to have encrypted communications over this port). So, we might need to run all of our services on this port. HAProxy can help us achieve that.

HAProxy is a high-performance TCP/HTTP load balancer. It can spread requests across multiple servers and separate requests based on things like SNI and headers.

Here is the config file for HAProxy, which takes requests from port 443 and reroutes them based on the SNI of the request to our Trojan or Shadowsocks server:

frontend https
    bind <server_ip>:443
    mode tcp
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }

    use_backend trojan_server if { req_ssl_sni -i example.org }
    default_backend shadowsocks_server

backend trojan_server
    mode tcp
    server trojan_server 127.0.0.1:4431

backend shadowsocks_server
    mode tcp
    server shadowsocks_server 127.0.0.1:4432

You need to add this to the end of your HAProxy config file located at /etc/haproxy/haproxy.cfg.

Then, you can start and enable HAProxy:

systemctl enable --now haproxy

Now your proxies should be ready to use

After setting up Sing-box and HAProxy, you can now access your proxies on the same port and hopefully bypass censorship. Additionally, you can add more services like obfs4 and OpenVPN (to be used with Stunnel or obfs4 if it’s blocked) and other stuff on the same port and the same VPS using HAProxy.

How Governments Detect and Block your Internet traffic

Zola Gonano — Thu, 25 Apr 2024 00:00:00 +0000

If you have ever lived in a country with advanced internet censorship, such as China or Iran, you would know how challenging it is to bypass these restrictions. In this post, I want to discuss the methods by which these firewalls block and detect your traffic, as well as the circumvention tools and methods available for each of them.

An advanced censorship system can employ a combination of these methods based on multiple factors, such as the geolocation of the destination server or its data center, as well as packet fingerprinting and throttling of suspicious traffic, among others.

IP Blocking

Ip blocking is the simplest and easiest method for firewalls to implement. It involves checking the destination address of traffic, and if it matches a certain IP or IP range, the firewall will either block the traffic or route it to another IP.

Because of its simplicity, it’s quite easy to bypass as well. All you have to do is route the traffic through another server whose IP is not on a block list using a proxy server.

DNS Spoofing

Most of the time, an IP can be used for multiple services. For example, YouTube and other Google services might share the same IP addresses. This would make IP blocking quite expensive for a government because they might inadvertently block some services they didn’t intend to block.

In this situation, the easiest thing that can be done to block specific websites and services would be spoofing the user’s DNS traffic (as DNS lacks encryption and can be read along the way). If the destination domain matches a specific domain, it would return an invalid address or not respond to the user at all.

The fix for this would be relatively straightforward as well. All we have to do is encrypt the DNS traffic using protocols such as DNS-Over-TLS or DNS-Over-HTTPS, DNSSEC, or DNSCrypt. Because the firewall wouldn’t see what domain name we’re asking for, it can’t determine whether we’re trying to access a blocked website or not.

Protocol Blocking

In some extreme cases, a firewall might fully block a protocol, mostly those used for VPNs such as PPTP and L2TP.

This method is usually applied to protocols that wouldn’t incur significant costs. For example, if they were to block HTTPS or TLS, it would disrupt most websites regardless of whether they are blocked or not, and that can be quite expensive.

To overcome this type of blocking, some protocols have been created to make proxied traffic appear as normal web or TLS traffic as much as possible. Protocols such as REALITY and Trojan are designed for this purpose.

Packet Filtering

A firewall might filter packets and block or throttle them based on factors such as their protocol (whether they’re TCP or UDP), size and length, destination port, and headers.

For example, in extreme cases, they might fully block UDP traffic and only allow TCP connections to certain ports, such as 443 and 22, which are common ports for TLS and SSH.

Bypassing this type of restriction is not difficult, but it will come with speed and bandwidth sacrifices, as you might be limited to using TCP connections, which are typically slower than UDP ones, especially for streaming.

Deep Packet Inseption (DPI)

DPI (Deep Packet Inspection) is a method used to inspect and filter traffic in real-time, meaning that the firewall will open your packets, analyze their content, and decide whether to block them or allow them to pass through.

DPI can even detect and block fully encrypted traffic through methods like fingerprinting, allowing it to determine whether the traffic is VPN or proxy traffic or normal traffic.

Bypassing DPI is actually challenging, as DPI systems are constantly evolving and becoming more advanced at detecting encrypted traffic. However, so are the protocols for bypassing them.

The most promising and well-tested protocol for bypassing DPI is obfuscating protocols, such as obfs4, which are designed to make the traffic appear as noise or normal traffic.

Active Probing

Active probing, unlike other methods of censorship, isn’t passive; it involves automated servers sending requests to other servers to check if they’re being used for bypassing censorship or not.

These servers might act as obfs4 clients and send requests to your server to examine its response.

Preventing these probes is a challenging task, but there are measures that can be taken, such as only allowing connections from specific IP addresses or blocking any suspicious attempts on the server.”

Creating an Encrypted Portable Container for ZeroNet

Zola Gonano — Wed, 17 Apr 2024 00:00:00 +0000

I have two Linux machines that I constantly switch between, and I had a problem syncing my ZeroNet¹ data between my machines. Additionally, I didn’t want to share my data with a third-party server. So, I decided to make a portable USB stick for my ZeroNet that could not only be used with my devices but also with any other device running Linux. This approach also solved another problem I had with ZeroNet, which was its lack of encryption. Now, I could encrypt my USB stick and my ZeroNet data inside it without any complications.

And I thought that sharing the process of doing so would save a lot of time for someone experiencing the same problem. So here’s how I set up my portable container:

1. Wiping the USB Stick

Always before encrypting any devices, you should securely wipe the device so that the previous data on it becomes unrecoverable in case you lose the device or it gets stolen. To wipe this USB stick, all I did was fill it with zeros until there was no space left on it:

To do so, you first need to identify the device that you want to wipe:

For that, you can run the lsblk command which will show all your devices and their names:

$ lsblk -p
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
...
/dev/sdc 8:32 1 29.3G 0 disk

The output shows me that the USB stick that I’m going to use is located at /dev/sdc.

Then, use the dd command to read from /dev/zero or /dev/urandom into it until it’s filled with zeros:

sudo dd if=/dev/zero of=/dev/sdc status=progress bs=128M

Note: You should replace /dev/sdc with your own device.

I recommend reading from /dev/urandom as most modern Flash Memory devices use compression features, which can compress a pattern of zeros and prevent the device from getting fully and securely wiped. However, with /dev/urandom, you’ll get fairly fast-generated pseudo-random data that cannot be compressed, making it the safer approach.

You should wait until you get the “No space left on device” message from the dd command. Then, you can proceed to encrypt the device.

2. Encrypting the USB Stick

To encrypt the device, I used LUKS² as I only have Linux machines and I don’t need my USB stick to be readable on Windows machines. However, if you want to make it cross-platform, you can use VeraCrypt instead.

**Note: ** To encrypt the device using the LUKS format, you’ll need to install the cryptsetup package (usually it is already installed in most Linux distributions).

sudo cryptsetup -y -v --type luks2 luksFormat /dev/sdc

By running the command above, you’ll be prompted to accept the risks of overwriting data on your device. Then, you’ll be asked for a passphrase, which will be used to decrypt and unlock the USB stick.

After you set up encryption, you need to open the device using luksOpen and create a file system on it. For the file system, I’ve used BTRFS, which is a modern and stable enough filesystem for my purpose. You can use EXT4 as well if you want something older and more stable, but the journaling of EXT4 can cause some additional wear and tear on your device.

sudo cryptsetup luksOpen /dev/sdc DeviceName

After you open and decrypt the device, it will be available at /dev/mapper/DeviceName, and you can use this path to create a file system on the device:

sudo mkfs.btrfs /dev/mapper/DeviceName -L WhateverLabelYouWant -f

Now you can mount your encrypted device and put the ZeroNet on it (it will mount your device on /mnt/zeronet_container):

sudo mkdir /mnt/zeronet_container
sudo mount /dev/mapper/DeviceName /mnt/zeronet_container

3. Setting-Up ZeroNet Bundle

Next, you want to download the ZeroNet Bundle, which includes all the executables inside it and doesn’t need any additional packages to work. For that, I’ve downloaded the ZeroNetX Bundle, which is an actively maintained fork of ZeroNet:

cd /mnt/zeronet_container
wget https://github.com/ZeroNetX/ZeroNet/releases/latest/download/ZeroNet-linux.zip
unzip ZeroNet-linux.zip
cd ZeroNet-linux

Then, create a zeronet.conf file in the Zeronet-linux directory to enable TOR support:

force_encryption = True
tor_proxy = 127.0.0.1:9150
tor_controller = 127.0.0.1:9151
tor = always

Note: The ports 9150 and 9151 are default ports for the TOR Browser, which we will include in our container. This way, when you open your Tor Browser to access the ZeroNet, the ZeroNet will use the browser’s controller port to communicate with Tor, minimizing the need for setting up Tor and granting access to ZeroNet to use its controller port.

4. Setting-Up a Portable TOR Browser

Making a portable Tor Browser is fairly easy. You only need to download the Tor Browser onto your USB stick and extract it there. Every time you want to use it, run it from there.

To download the Tor Browser for Linux, you should go to https://www.torproject.org/download/ and after downloading it, extract it into your USB stick.

5. Now your Portable ZeroNet is Ready to Use

After you set everything up, you can just plug your USB stick into your machine, open it up, and run the Tor Browser and ZeroNet from there.

Additionally, you can run your ZeroNet with FireJail to isolate it from the rest of your system and provide some sandboxing for it.

Another method, if you want to use your ZeroNet on untrusted machines portably, is through using Tails OS. You can download and boot the Tails OS on your USB stick and enable Persisted Encrypted Storage on it. Then, put your ZeroNet Bundle on the Persisted storage inside Tails and boot the device on any machine to use your ZeroNet without leaving any trace on the machine or having to trust the machine (to some extent).

ZeroNet is a peer-to-peer web-like network, which I have covered in detail in my blog. ↩
LUKS (Linux Unified Key Setup) is a disk encryption specification that provides an easy-to-use, platform-independent method for securing data on storage devices. It allows users to encrypt entire partitions or storage devices, ensuring that data remains protected even if the device is lost or stolen ↩

Hacking a CTF: Do not use ECB mode for encryption

Zola Gonano — Wed, 03 Jan 2024 00:00:00 +0000

I recently started doing CTF challenges. A few days ago, I was working on a challenge from 247CTF.com. I found a challenge that, in my opinion, shows why using ECB(Electronic Codebook) mode for encrypting with block ciphers like AES or Twofish isn’t a good idea. So, I decided to write a series of blog posts where I solve these challenges and explain how to prevent these kinds of attacks.

The challenge was quite simple. It was a website with two parts: /encrypt and /get_flag. Both parts needed a hex-encoded message called user.

Understanding the Source Code

This challenge provided the source code for us, making it quite easy to reverse engineer and understand how it works:

from Crypto.Cipher import AES
from flask import Flask, request
from secret import flag, aes_key, secret_key

app = Flask( __name__ )
app.config['SECRET_KEY'] = secret_key
app.config['DEBUG'] = False
flag_user = 'impossible_flag_user'

class AESCipher():
    def __init__ (self):
        self.key = aes_key
        self.cipher = AES.new(self.key, AES.MODE_ECB)
        self.pad = lambda s: s + (AES.block_size - len(s) % AES.block_size) * chr(AES.block_size - len(s) % AES.block_size)
        self.unpad = lambda s: s[:-ord(s[len(s) - 1:])]

    def encrypt(self, plaintext):
        return self.cipher.encrypt(self.pad(plaintext)).encode('hex')

    def decrypt(self, encrypted):
        return self.unpad(self.cipher.decrypt(encrypted.decode('hex')))

@app.route("/")
def main():
    return "

%s

" % open( __file__ ).read()

@app.route("/encrypt")
def encrypt():
    try:
        user = request.args.get('user').decode('hex')
        if user == flag_user:
            return 'No cheating!'
        return AESCipher().encrypt(user)
    except:
        return 'Something went wrong!'

@app.route("/get_flag")
def get_flag():
    try:
        if AESCipher().decrypt(request.args.get('user')) == flag_user:
            return flag
        else:
            return 'Invalid user!'
    except:
        return 'Something went wrong!'

if __name__ == " __main__":
  app.run()

Just by looking at the code, it’s obvious that we need to encrypt the impossible_flag_user using the AESCipher class defined in the code. The class employs a straightforward algorithm for padding and utilizes AES with ECB mode for encryption. The secret key is imported from another Python file, which we don’t have access to. This means we can’t simply rewrite the AESCipher class and encrypt whatever we want.

On the other hand, the /encrypt route takes a hex-encoded payload named user and decodes it. If the decoded value is equal to impossible_flag_user, it returns a ‘No cheating!’ message. However, to obtain the flag, we need to provide the /get_flag route with a hex-encoded payload named user that, when decrypted, equals impossible_flag_user.

@app.route("/encrypt")
def encrypt():
    try:
        user = request.args.get('user').decode('hex')
        if user == flag_user:
            return 'No cheating!'
        return AESCipher().encrypt(user)
    except:
        return 'Something went wrong!'

So, what we can do is attack the implementation of the encryption scheme, which is the AESCipher class. The two main issues that come to mind when looking at it are the self-rolled padding algorithm and the use of ECB mode.

But what is ECB mode and how can it help us bypass that restriction? Well, ECB mode is the simplest way of encrypting blocks in block cipher algorithms. It works by breaking down the plaintext data into blocks of a fixed size and encrypting each block with the key. This process is repeated for each chunk until it reaches the last block. The final block is then padded to match the block size of the block cipher, and all the blocks are arranged in series to form the ciphertext:

But what’s the problem? ECB mode lacks diffusion, meaning it doesn’t obscure the correlation between the plaintext and the ciphertext. This weakness is what we will leverage to our advantage when encrypting the impossible_flag_user with it.

Performing the Attack

The first thing that came to my mind was that I could encrypt the impossible_flag_user partially to obtain some encrypted segments. To achieve this, I replaced the user in the plaintext with 0000 to maintain the same length. Here are the results:

939454b054b7379b0709a270b894025c1c3b822d1217b7af1516eccddb9349fc

Next, I encrypted only the user and obtained the following result:

707ece4f0913868ec5df07d131b0822d

Now, all I had to do was replace one block size length (16 bytes in this case) from the first encrypted plaintext with the corresponding portion from the second encrypted plaintext:

939454b054b7379b0709a270b894025c707ece4f0913868ec5df07d131b0822d

Now, by sending this modified ciphertext to the /get_flag route, we obtain the flag:

247CTF{ddd01e396dc1965c3fcf943f3968aa39}

The reason this happened is that the user was our last chunk, and because there was no random initializing vector, no matter how many times we encrypt that last chunk, we’d get the same result. Essentially, we encrypted the initial chunks and then appended the last chunk to bypass the restriction and obtain the flag.

This attack could have been easily prevented by using a cipher mode that provides diffusion and authentication, such as GCM_SIV. This mode eliminates the need for padding, and the ciphertext can be authenticated later.

This blog is available on my GitHub, and if you find the content interesting, you can give it a star or consider making a donation here.

A Guide to Security, Privacy, and Anonymity on ZeroNet

Zola Gonano — Tue, 08 Aug 2023 00:00:00 +0000

In my previous post, I took a technical look at ZeroNet, explaining how it works and the technologies it uses to create a peer-to-peer web-like network. In this post, I want to discuss how you can maintain privacy and security in this network, explore the potential threats, and provide some techniques to enhance your privacy and security.

I will divide this guide into three main sections: “Security,” “Privacy,” and “Anonymity.” In each section, I will explain what you can do to enhance each aspect.

These sections are interconnected, and as a result, there will be a lot of overlap. For example, you will need security to ensure your privacy, and you will need privacy to stay anonymous.

Security

This section covers what is needed to protect assets, information, or prevent harm, damage, unauthorized access, or exploitation.

Ensure Browser Security

In the ZeroNet network, no servers are hosting the sites, which means everything is executed on the client-side. Every site you visit will run JavaScript or WASM code in your browser. This makes browser sandboxing critically important because you cannot simply block every script and expect things to function properly. Therefore, the most important thing to stay secure in such a network is the browser.

Use a well-known browser

Use a browser that has been around for a while, as it will have had the chance to be audited and tested, and most of its vulnerabilities are likely to be fixed. Browsers like Firefox or Chromium are good options, as they have sandboxing features and vulnerabilities are detected and fixed quickly. However, the best choice would be the Tor Browser, which is a modified version of Firefox provided by the Tor Project. It is designed to reduce fingerprinting and enhances security by enabling some sandboxing features of Firefox that are not enabled by default.

Keep your browser up-to-date

Usually, most attacks come from already known and fixed vulnerabilities, and it is very unlikely to be attacked by a zero-day vulnerability. That’s why you should always keep your browser and all your software up-to-date. It prevents attacks through known and fixed vulnerabilities and reduces your attack surface area significantly.

Encrypt All ZeroNet Traffic

By default, traffic encryption is not enforced for all requests and clients in ZeroNet. However, you can enforce it by adding force_encryption = True to the [global] section in the zeronet.conf file. Alternatively, you can run your ZeroNet with the --force_encryption flag, but you may accidentally forget to do so, so it’s safer to put it in the config file.

By doing so, all your traffic will be secured using TLS.

Add an Additional Layer of Encryption

You can also provide an additional layer of encryption by using a VPN(Virtual Private Network) or by tunneling your whole system through TOR. This will prevent your ISP(Internet Service Provider) from knowing you’re connecting to ZeroNet nodes.

But note that using a VPN means you’re putting your trust in your VPN provider instead of your Internet Service Provider.

Encrypt Your ZeroNet Data

ZeroNet data, such as site files, even your private keys, etc., are stored in plain text inside a directory named data, and ZeroNet itself doesn’t provide encryption for those files yet. However, there are several tricks to implement encryption for these files.

Use ZeroNet inside an encrypted virtual machine

If you want to take it to the next level and increase the security and privacy of your ZeroNet client at the same time, you can install a fully encrypted OS inside a virtual machine and run your ZeroNet inside it. This approach provides strong sandboxing and security for your ZeroNet data. An OS recommended for such purposes is Whonix OS, and they have a guide on how to use ZeroNet inside Whonix.

Store your ZeroNet files in an encrypted container

This method is simpler and offers added benefits, such as portability. You can encrypt a USB stick and store your entire ZeroNet bundle there, enabling you to use it on any machine you desire.

For enhanced portability, I highly recommend using Tails OS, which routes all traffic through Tor and includes an Encrypted Persistent Storage feature. This allows you to store files like your ZeroNet bundle securely without having them deleted when you restart the Tails Os.

Do not log in when using a ZeroNet instance (public proxy)

Everyone who runs a ZeroNet public proxy can see your private key and potentially steal your identity. Therefore, never use your identity or perform actions like creating an ID or site using a public proxy, as the proxy manager will have access to that site and ID just as you do.

Privacy

This section covers what you can do to control what information about you is shared or accessed when using ZeroNet.

Always use Tor

Setting Tor mode to Always will ensure that your IP address is not exposed when connecting and seeding a site in ZeroNet. Instead of IP addresses, other ZeroNet nodes will communicate with you through your onion address, and you have multiple of them (10 by default) to reduce the fingerprinting of an onion address.

To do so, you need to open a Tor controller port and allow ZeroNet to have access to the cookie authentication file.

Here are the changes you will need to make in the torrc file to achieve this:

Uncomment or add this line to open the controller port:

ControlPort 9151

Add these lines to make the cookie authentication file readable for ZeroNet:

CookieAuthFile /var/lib/tor/control_auth_cookie
DataDirectoryGroupReadable 1
CacheDirectoryGroupReadable 1
CookieAuthentication 1

Add your user or the user that runs ZeroNet to the Tor group:

sudo chown -R your_user:tor /var/lib/tor/control_auth_cookie

Once you’ve made these changes, you can add the following lines to the [global] section in your zeronet.conf file to enforce ZeroNet to use Tor:

tor_proxy = 127.0.0.1:9050
tor_controller = 127.0.0.1:9151
tor = always

With these configurations, your ZeroNet instance will route its traffic through Tor, providing increased privacy and anonymity.

Use Tor Browser or Disconnect Your Browser from the Internet

Even if you have set Tor to ‘Always’ mode, the sites can still send a request from your browser to the clearnet and expose your real IP address. The best practice here would be to always use ZeroNet inside the Tor browser to ensure that your real IP address never leaks to the clearnet through your browser. Optionally, you can set a non-working proxy or use your browser in offline mode when using ZeroNet, as ZeroNet doesn’t require your browser to have access to the internet.

Protect your Identity

In ZeroNet, all identities are represented by private keys and certificates, which are stored in the users.json file. Therefore, it is essential to regularly back up this file if you want to ensure you don’t lose your identity on ZeroNet.

Use ZeroID if possible

ID providers like CryptoID or KaffieID are considered “decentralized,” but this decentralization comes at the cost of lacking uniqueness and regulation on IDs. As a result, anyone could generate the same ID that you have and potentially use your identity. On the other hand, ZeroID follows a different approach with a centralized server that ensures usernames and IDs are unique. However, it is worth noting that using ZeroID inside the Tor Browser should help maintain privacy despite the data being sent to the clearnet.

Anonymity

This section covers what you can do to seperate your real identity from the identity that you have on ZeroNet.

You need almost everything from the Security and Privacy sections

There’s a lot of overlap between security, privacy, and anonymity, and you should have those to achieve anonymity.

You need good OPSEC

“OPSEC” stands for Operational Security. It involves using specific practices and strategies to protect sensitive information. When you have applied most of the security and privacy practices, it’s mostly about OPSEC. You are the one who chooses what to share, where to share, and with whom.

Privacy is a human right, and digital privacy is necessary for people living in dictatorships, journalists, or activists to stay safe in the real world. If there’s anything else that can be added, I’d be more than happy to know. This entire blog is available on GitHub, and you can contribute to it or simply give it a star.

A Very Technical Look at ZeroNet

Zola Gonano — Mon, 17 Jul 2023 00:00:00 +0000

ZeroNet has always been a project that I’m very passionate about, and I enjoy contributing to it. It is a Peer-to-Peer Web-Like Network that cannot be censored or taken down, thanks to its decentralized nature. When I first started exploring ZeroNet, I struggled to find comprehensive documents or blog posts that provided a clear understanding of the network. Therefore, I decided to write this blog post to make it easier for newcomers to learn more about the network and contribute to it.

Introduction

ZeroNet was created in 2015 by Tamas Kocsis as a decentralized and peer-to-peer network. It utilizes technologies such as Bitcoin’s cryptography, BitTorrent trackers, and NameCoin’s domain name system. These technologies enable ZeroNet to function as a fully dynamic web-like network, in contrast to IPFS which is limited to serving static files and websites. One of the key strengths of ZeroNet is its high resistance to censorship, as it operates without relying on a single central server. It also provides anonymity for users by enabling them to use the TOR network and hide their IP address while using ZeroNet. In ZeroNet, every site has an address that is represented by a Bitcoin public key. Peers for the sites are discovered through various methods, including the use of BitTorrent trackers. However, it’s worth noting that this is the only instance where a central server comes into play. To eliminate the reliance on a central server, ZeroNet provides an internal plugin called BootStrapper, which allows peers to function as trackers.

How exactly do we find other peers?

As mentioned before the main method for finding the peers that are hosting the site on the ZeroNet is BitTorrent Trackers, BitTorrent trackers are an essential part of the BitTorrent protocol as they hold the information that what peer holds what piece of data, and ZeroNet uses them for the same purpose. When your ZeroNet client tries to access a site it asks the trackers for the peers that are hosting the website and when your client gets the peers list it starts downloading the site’s content and it becomes a peer itself and the next time someone comes to that site they might download a piece of it from you.

But BitTorrent trackers are not the only option for discovering peers of a site. ZeroNet offers a plugin called AnnounceZero that utilizes the ZeroNet Protocol to find peers. This plugin is particularly useful for locating peers on the TOR network, as BitTorrent trackers are not capable of performing this function.

The BitTorrent Tracker works through a plugin named AnnounceBitTorrent which operates as follows: It collects all the trackers that start with http://, https://, and udp://, and sends them a request with the following parameters:

{
  "info_hash": "SHA1_HASH_OF_SITE_ADDRESS",
  "peer_id": "YOUR_PEER_ID",
  "port": "YOUR_FILESERVER_PORT",
  "uploaded": 0,
  "downloaded": 0,
  "left": 431102370,
  "compact": 1,
  "numwant": NUMBER_OF_PEERS_NEEDED,
  "event": "started"
}

If the tracker has any peers associated with that info_hash, it will return them in a BenCode, which is a binary serialization format commonly used in BitTorrent. Here’s a Python code snippet that demonstrates the process behind the scenes:

import hashlib, bencode, requests, urllib

tracker_url = "https://some_tracker:443/announce"
peer_id = "-UT3530-some_id"
peer_port = 15441
number_wanted = 2
site_sha1 = hashlib.sha1(b"1HELLoE3sFD9569CLCbHEAVqvqV7U2Ri9d").digest()

params = {
 "info_hash": site_sha1,
 "peer_id": peer_id,
 "port": peer_port,
 "uploaded": 0, "downloaded": 0, "left": 431102370,
 "compact": 1,
 "numwant": number_wanted,
 "event": "started"
 }

response = requests.get(tracker_url+"?"+urllib.parse.urlencode(params)).content
print(bencode.decode(response))

Now, if we execute this code, we would obtain our peers. However, please note that the peer information would be in binary encoding and would need to be decoded in order to establish connections with them. In this blog post, we won’t cover the decoding process.

{
 b'complete': 0,
 b'incomplete': 15,
 b'interval': 1800,
 b'min interval': 300,
 b'peers': b'\xbc\xe2D\xf3\x00\x01PuW\xb3\x00\x01'
}

The AnnounceZero plugin functions in a similar manner, but the request it sends to trackers starting with zero:// has slightly different parameters. Here is an example of the request:

{
  "hashes": ["SITE_ADDRESS_HASHES"],
  "onions": ["YOUR_ONION_ADDRESSES"],
  "port": YOUR_FILESERVER_PORT,
  "need_types": ["PEERS_TYPES"],
  "need_num": NUMBER_OF_PEERS_NEEDED,
  "add": ["TYPE_OF_ADDRESSES_TO_REACH_YOU"]
}

In this request, the need_types parameter specifies the type of peers you want to receive, which can be either onion or ipv4. The onions field contains your own onion addresses for communication, and the add field indicates the type of addresses (ipv4 or onion) through which others can reach you. If you have set Tor mode to Always, the value for add will always be onion.

There are several other plugins designed for the same purpose. For example, the AnnounceLocal plugin enables peer discovery on a Local Area Network (LAN) through UDP broadcasting. The AnnounceShare plugin allows peers to share discovered trackers with each other. Additionally, there is a plugin called Bootstrapper that is disabled by default to prioritize user privacy. The Bootstrapper plugin functions as a BitTorrent Tracker server running on the user’s client, facilitating peer discovery within the ZeroNet network.

How do we validate the content?

In ZeroNet, the data and content of a site are hosted by its visitors. However, to prevent corruption of the data, ZeroNet utilizes hash functions, checksums, and cryptographic signatures. As mentioned earlier, ZeroNet site addresses are Bitcoin public keys, and the user creating the site possesses the private key.

When downloading a ZeroNet site, the first file retrieved is the content.json file. This file contains the SHA512 checksum for each available file within the site. Additionally, it includes a sign field that ensures the integrity of the content.json file itself. By verifying the signature, we can confirm that the content.json file is valid and has been signed by the owner of the site.

Here is the content.json file for an empty site that I just created:

{
 "address": "17u6wJX7fCd9BZwLX8JyhVKTwxb1uEhzcH",
 "address_index": 5655359,
 "background-color": "#FFF",
 "clone_root": "template-new",
 "cloned_from": "1HELLoE3sFD9569CLCbHEAVqvqV7U2Ri9d",
 "description": "",
 "files": {
  "index.html": {
   "sha512": "542f7724432a22ceb8821b4241af4d36cfd81e101b72d425c6c59e148856537e",
   "size": 1114
  },
  "js/ZeroFrame.js": {
   "sha512": "76a24d167e8a4c45f7d1b315efe31e4b4ccb19efef011c080994c94045ff4c93",
   "size": 5088
  }
 },
 "ignore": "",
 "inner_path": "content.json",
 "modified": 1689603718,
 "postmessage_nonce_security": true,
 "signers_sign": "HMGXIah7OTimruksGGqAhzC821bWemxkmS9MG6DlrIJDGpHuIb2MYGO0UpAzxd0nfUzF4x0xxSal1rfbBD0sok4=",
 "signs": {"17u6wJX7fCd9BZwLX8JyhVKTwxb1uEhzcH": "G3jkxsTv+acg0Bzm7+EJZxBznaXdMhrKD3YKSdlMRGsNYUSCzbZ0cSag+VUIkMuPhH2ApveJOglAZcytJik59Lc="},
 "signs_required": 1,
 "title": "my new site",
 "translate": ["js/all.js"],
 "zeronet_version": "0.7.6-internal 2"
}

When the content.json file is retrieved, ZeroNet looks for the files field and downloads the files listed in it. It verifies the integrity of each file by comparing the hash in the content.json file with the hash of the downloaded file. If the hashes match, it means that the file has not been changed or lost during the downloading process.

The signatures in ZeroNet are based on the same cryptographic techniques used in Bitcoin’s signatures, which have undergone audits and have been established as secure over a long period of time.

How sites are created?

ZeroNet’s data and settings are stored in the data directory. Within this directory, there is a file called users.json that contains the private keys for sites, certificates for ID systems, and a master_seed field from which site keys are derived.

Here is an example of the users.json file:

{
  "1NupA7xwj4qiQzh58Zu4oKn6c3zQUYGdbt": {
    "certs": {},
    "master_seed": "14cacb9f9321b<CENSORED>70a61a9dda362",
    "settings": {
      "theme": "light",
      "use_system_theme": true
    },
    "sites": {
      "17u6wJX7fCd9BZwLX8JyhVKTwxb1uEhzcH": {
        "auth_address": "18Vijw97tkMp7sYYiuX5pvoewpKybCfxZ2",
        "auth_privatekey": "5JgiXeSAPJ1tF<CENSORED>cx6QSSdXhuxtS",
        "privatekey": "5KNmLu2S6<CENSORED>T1hu1Lthdp2SRr"
      }
    }
  }
}

When you create a site in ZeroNet, a random HD Keypair (hierarchical deterministic keys) will be derived from your BIP32 encoded master_seed, and it will be written to your users.json file. This allows you to restore all your site’s private keys by having your master seed.

The process involves generating an index, which is a random number between 0 and 29639936. This index is used to derive the private key from your master seed:

index = (a random index between 0 and 29639936)
private_key = HDPrivateKey(master_seed, index)

However, it’s also possible to use normal Bitcoin keypairs that are not associated with your master seed. In fact, you can even generate a custom public key using tools like VanityGen.

You might notice that there is another keypair named auth_address and auth_privatekey in the users.json file. These two addresses act as your identity on the site, and their primary use case is for identity systems like ZeroID. These keypairs are separate from the site’s private keys and serve to authenticate and identify you on the platform.

How Identities work in ZeroNet?

Identities in ZeroNet are provided by an ID provider such as ZeroID, (which acts as a centralized system to ensure uniqueness of the IDs). When a user requests an ID, the provider signs them a Certificate, which is a cryptographic signature of their public address and the username they requested. The validity of this Certificate is later verified by matching it with the provider’s public key, ensuring the authenticity and integrity of the identity.

The Cert is generated using the following process:

cert = Base64(BitcoinSign(PROVIDER_PRIVATE_KEY, (USER_AUTH_ADDRESS + "#METHOD_OF_CREATION/") + USERNAME))

For example, if a user with the address 18Vijw97tkMp7sYYiuX5pvoewpKybCfxZ2 wants the username zeronet_user and uses the web interface, the message that would be signed is constructed as follows:

cert = Base64(BitcoinSign(PROVIDER_PRIVATE_KEY, "18Vijw97tkMp7sYYiuX5pvoewpKybCfxZ2#web/zeronet_user"))

Here’s an example of accepted ID providers in a site’s data/users/content.json:

"cert_signers": {
  "cryptoid.bit": ["18143WPue3rQykNaopx5KJKzYmaYhCjqhv"],
  "zeroid.bit": ["1iD5ZQJMNXu43w1qLB8sfdHVKppVMduGz"]
}

Domain Name System in ZeroNet

Domain names are provided using NameCoin’s IDs to help users remember the site’s addresses. The way it works is that a server transfers all the NameCoin domains that have the zeronet key in them to a ZeroNet site named ZeroName.

Example domain registered for ZeroNet in NameCoin’s blockchain:

{
  "name": {
    "formatted": "ZeroNet project"
  },
  "bitcoin": {
    "address": "1QDhxQ6PraUZa21ET5fYUCPgdrwBomnFgX"
  },
  "zeronet": {
    "": "1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr",
    "blog": "1BLogC9LN4oPDcruNz3qo1ysa133E9AGg8",
    "talk": "1TaLk3zM7ZRskJvrh3ZNCDVGXvkJusPKQ"
  },
  "ns": [
    "ns1.domaincoin.net",
    "ns2.domaincoin.net"
  ]
}

And when a user looks for a site with the domain name zeronetwork.bit, it looks it up from the ZeroName site and redirects the user to the public key associated with that domain name.

How Databases work in ZeroNet?

ZeroNet also provides decentralized databases, making it a dynamic network. The structure of the database is defined in a file named dbschema.json, where tables, fields, and types are specified. ZeroNet offers APIs for site developers to interact with the database and modify the data. The data is stored in the site’s data directory, and when it changes, it is automatically updated for other peers, ensuring synchronization.

Here’s a simplified example of a dbschema for a forum-like site:

{
  "database": "ZeroTalk",
  "tables": {
    "topic": {
      "cols": [
        ["topic_id", "INTEGER"],
        ["title", "TEXT"],
        ["body", "TEXT"],
        ["added", "DATETIME"]
      ]
    },
    "comment": {
      "cols": [
        ["comment_id", "INTEGER"],
        ["body", "TEXT"],
        ["added", "DATETIME"],
        ["topic_id", "INTEGER REFERENCES topic (topic_id)"]
      ]
    }
  }
}

And the corresponding data.json would look like this:

{
  "topics": [
    {
      "topic_id": 1,
      "title": "First Topic",
      "body": "This is the first topic.",
      "added": "2022-01-01 10:00:00"
    },
    {
      "topic_id": 2,
      "title": "Second Topic",
      "body": "This is the second topic.",
      "added": "2022-02-01 12:00:00"
    }
  ],
  "comments": [
    {
      "comment_id": 1,
      "body": "Comment 1",
      "added": "2022-01-01 11:00:00",
      "topic_id": 1
    },
    {
      "comment_id": 2,
      "body": "Comment 2",
      "added": "2022-02-01 13:00:00",
      "topic_id": 2
    }
  ]
}

This example showcases a simple database structure for a forum-like site with two tables: topic and comment. The topic table contains columns for the topic ID, title, body, and timestamp. Similarly, the comment table includes columns for the comment ID, body, timestamp, and a foreign key referencing the topic ID in the topic table. The accompanying data.json file presents sample data entries for topics and comments.

How to get started with ZeroNet?

While the official development of ZeroNet has not been active since 2020, there are several forks that continue to work on the project. Some of these forks are even reimplementing ZeroNet in other languages such as Rust, which would eventually increase its security and performance. Here are some links to these forks:

ZeroNetX - https://github.com/ZeroNetX/ZeroNet
ZeroNet-rs (Rust Implementation) - https://github.com/ZeroNetX/zeronet-rs
zeronet-conservancy - https://github.com/zeronet-conservancy/zeronet-conservancy

Additionally, if you’re interested in using ZeroNet but don’t know where to start, I have created a curated list on my GitHub called “awesome-zeronet”. This list provides resources and links to new sites on ZeroNet, and you can also contribute by adding sites that are not yet listed. You can find the list at https://github.com/zolagonano/awesome-zeronet.

Final Thoughts on ZeroNet

ZeroNet might be a great approach towards achieving a decentralized web, but it is far from perfect. It lacks encryption for data and still depends on central servers to operate properly, such as BitTorrent Trackers and ZeroID. However, it can be improved. If you are interested, you can start contributing to make it better.

As always, the entire blog is available on my GitHub, and I would greatly appreciate it if you could point out any inaccuracies, grammatical errors, technical mistakes, or simply give it a star. Your contributions means a lot to me.

Here are some of the resources used in this post: