Operating systems on ARPOKRAT

Cold wallet: the complete guide, from a scrap of paper to multisig on Qubes OS

Mon, 10 Aug 2026 00:00:00 +0000

In 2023, researchers at Kaspersky took apart a Trezor hardware wallet bought from a respectable-looking online marketplace. The device was visually identical to the original, packaging included, and worked normally. It displayed a list of words to copy down, exactly like a genuine one. Except that the list had not been drawn at random by the device: it had been chosen in advance by the attacker, who then only had to wait for the victim to deposit funds. The full analysis is published on Kaspersky’s blog.

That story sums up the whole subject. The victim had bought the right product, from the right brand, with the right intentions. What failed was not the hardware, it was the procedure around it.

A cold wallet is not an object you buy. It is a procedure you apply, and the hardware is only one part of it.

Here are five levels of security, from the simplest to the most demanding. Each one is usable as it stands. At every step, the same question: what did the previous level fail to protect against, and does that risk really apply to you?

What a cold wallet is, without the jargon

A cryptocurrency is stored neither in your phone nor in your computer. It is recorded in a public ledger, the blockchain, duplicated across thousands of machines. That ledger links an amount of funds to an address, a long string of characters that acts as a public account number.

To move those funds, you have to prove you own them. That proof comes from a secret only you hold: the private key. It is never sent anywhere. It is used to place a cryptographic signature on the payment instruction, and the network checks that the signature does indeed match the address concerned.

All the security therefore comes down to a single point: who has seen the private key.

On an exchange, that is not you. The platform holds the keys, you hold a row in its database. If it goes bankrupt, if it is hacked, if a regulator freezes accounts, that row is not worth much any more. That is the meaning of the phrase that has been going around for ten years: not your keys, not your coins.

On a mobile wallet app, you do hold the key, but it was generated on an internet-connected device and it lives on that device. A modern phone runs tens of thousands of lines of code that nobody has audited, and it remains exposed to flaws unknown even to its own manufacturer. The key is safe there as long as nothing goes wrong.

A cold wallet turns the logic around. The private key is generated on a device that is not connected to the internet, and it never leaves that device. What moves in and out is only transactions to be signed, going in, and signed transactions, coming out. An attacker with complete control of your connected computer would see transactions go past, but never the key that signs them.

That is the only distinction that matters. Everything else consists of making it harder and harder to get around.

Hot wallet or cold wallet, the difference

A hot wallet is a wallet whose private key is generated or kept on an internet-connected device, which permanently exposes it to remote attack. A cold wallet generates the key offline and signs offline, so the private key never touches a connected device. The most common confusion concerns the role of the operating system: a phone running an app such as MetaMask is still a hot wallet, even on a hardened and perfectly up-to-date system. What matters is not the general security of the device, it is the presence of a network connection at the precise moment the key is used to sign. Hardening a connected device reduces the probability of a compromise, but it does not change the category the wallet belongs to.

What the 2026 Coldcard affair teaches us

One clarification is needed before we get to the levels, and recent events make it impossible to skip.

At the end of July 2026, manufacturer Coinkite revealed that a defect introduced into the firmware of its Coldcards in March 2021 had affected the generation of certain seeds. This was not a deliberate fallback mechanism: an integration error when moving to a new cryptographic library meant that a macro supposed to disable the software backup generator did not have the expected effect, so the intended hardware generator was in fact bypassed in favour of the platform’s generic software generator, which is predictable. The resulting phrases looked perfectly random, but their actual entropy dropped, according to the preliminary estimates published by Coinkite, to around 40 bits on the Mk2 and Mk3 models and around 72 bits on the Mk4, Mk5 and Q, instead of the intended 128 bits. The technical backgrounder published by Coinkite sets out the mechanism precisely.

From 30 July 2026, in four waves, attackers drained around 1,816 bitcoins spread across more than 5,200 addresses, according to TRM Labs’ analysis. At no point did they need to access the victims’ devices, either physically or remotely. They simply recomputed private keys that had become weak enough to be found by brute force.

That is the point to hold on to. Those victims had made no mistake. Seed never shared, device never connected, physical backup beyond reproach. None of it helped, because the flaw sat at the moment the key was created, before there was anything to protect at all.

This affair disqualifies neither Coldcard hardware nor hardware wallets as a category. It was a specific bug, fixed by firmware released the day after the first wave, and migrating to a new seed remains necessary since an update does not repair a key that has already been generated. But it highlights a limit that applies to everything that follows: the five levels in this article explain how to protect a key once it exists, and none of them on its own guarantees that it was correctly generated in the first place. That is precisely the value of open solutions such as SeedSigner, described further down, whose generation code is public and verifiable by anyone, where closed firmware can hide a defect for five years.

Level 1: the seed phrase on paper

Memorising a private key is impossible for a human. The BIP39 standard, adopted by almost every wallet, works around the problem.

The wallet draws a very large random number, then translates it into a list of ordinary words taken from a fixed dictionary of 2,048 words: the seed phrase, or recovery phrase. Twelve words correspond to 128 bits of randomness, twenty-four words to 256 bits. From that phrase, the wallet mathematically re-derives all your private keys and all your addresses.

The central consequence: the phrase is the wallet. If your device burns, you type the words into any other compatible wallet and you get your funds back exactly as they were. If someone reads those words, they need nothing else. Not your device, not your PIN.

What makes the phrase impossible to guess is the amount of randomness it contains, not its apparent length. Same reasoning as for a password, set out in detail in our article on entropy and the science behind your security.

In practice, you write the words down by hand, in order and numbered, on a medium that passes through no device at all. Never a photo, a screenshot, a text file, a synchronised password manager, or an email to yourself. Anything that touches an online service takes the phrase out of the offline domain, and the cold wallet no longer exists.

What this level does not protect against. Paper burns, does not survive water damage, fades, gets lost. It can be read in seconds by whoever opens the wrong drawer. Above all, it constitutes a single point of failure, an expression that will come back throughout this article: a single element whose loss or compromise is enough to carry everything away.

The immediate improvement is inexpensive: engrave the phrase on a metal backup, a stainless steel plate with stamped letters or inserted tiles, of which Cryptosteel and Billfodl are the best known examples. Steel survives a house fire and a flood. That settles accidental destruction, not theft.

Level 2: the off-the-shelf hardware wallet

Level 1 assumes you generated the seed phrase somewhere. If you did it in a mobile app before copying it down, your phrase existed on a connected device, and the paper merely backed up a secret that was already exposed.

The hardware wallet fixes that problem at the root. It is a small dedicated device, with no browser and no third-party apps, whose only job is to generate the seed phrase, keep it in a secure chip and sign transactions. It plugs into your computer, but the key never leaves the chip. The computer sends a transaction to be signed, the device displays the amount and the destination address on its own screen, you confirm with a button, it returns a signature.

That screen is the essential point, and it is often misunderstood. If malware on your PC swaps the destination address at the moment of sending, the device’s screen will display the real destination, the attacker’s. It is your last independent point of verification. You have to read it, every single time.

The reference devices are Ledger, Trezor and Coldcard, the last of which specialises in Bitcoin.

Vigilance about provenance

Here we are back at the counterfeit wallet from the start of this article.

Buy only directly from the manufacturer’s website, or from a reseller officially listed by them. Never on a general marketplace, never second-hand, never a device received as a gift. Between the factory and your hands, an intermediary can open a device, replace its contents and close it up neatly. On delivery, check the seal and the absence of any signs of opening, following the authentication procedure published by the manufacturer.

Above all, remember the rule that on its own neutralises the most common attack: a new hardware wallet must make you generate a seed phrase, it must never supply you with a ready-made one. A device that arrives with a phrase already written in the box, or that asks you to enter a phrase provided to you, is compromised. No exceptions.

What this level does not protect against. You are now trusting a manufacturer on the quality of its randomness generator and on the integrity of its firmware, the software embedded in the device. That firmware is generally proprietary, at least in part, and therefore unverifiable on your side. Reasonable trust, justified for the vast majority of people, but trust nonetheless. And the seed phrase remains a single point of failure.

Level 3: the dedicated air-gapped computer

If you do not want to trust any manufacturer, there is still the option of doing everything yourself on generic hardware, with open, audited software. That is the principle of the air-gapped machine, literally separated by a gap of air: a computer that has never been and never will be connected to a network.

Take a machine dedicated to this single purpose. An old laptop will do, and a model with no built-in wireless chip is ideal.
Reinstall a clean system, a mainstream Linux distribution for instance, from an image whose cryptographic fingerprint you have verified.
Neutralise networking at the lowest possible level. Physically removing the Wi-Fi card, often a small card slotted in under a hatch, is better than disabling it in the settings. Never plug in an Ethernet cable. A software switch can be undone by software, a missing component can undo nothing.
Install a reference software wallet, Sparrow or Electrum, transferring the installer by USB stick and verifying its signature.
Generate the seed phrase on that machine, offline, and back it up as in level 1.

To spend, the flow goes through a standard format, the PSBT (Partially Signed Bitcoin Transaction). It is a file containing every detail of a transaction, apart from the signature. On the connected computer, you prepare the transaction and export that file. You carry it to the offline machine by USB stick or by QR code displayed on screen and read by a camera. The offline machine signs it, you bring the signed file back by the same route, and the connected computer broadcasts it to the network.

The only channel between the two worlds is a file you carry by hand. It is slow, and that is precisely the point.

What this level does not protect against. The USB stick becomes your weak point: it is an active medium, capable of introducing code. The offline system is also still a general-purpose operating system, large and hard to audit. Discipline matters too: the temptation to plug in that network cable just once for an update wipes out the whole arrangement in one go.

Level 4: the open source DIY signer, SeedSigner

SeedSigner pushes the logic of level 3 to its conclusion: a minimal device, built by you, whose behaviour is verifiable, and which keeps nothing.

The central component is a Raspberry Pi Zero version 1.3. That detail is not incidental, it is the heart of the arrangement. The Pi Zero 1.3 has neither Wi-Fi nor Bluetooth at the hardware level: the radio chips are not present on the board. This is not a Raspberry Pi 5, nor a Pi Zero W, nor a Pi Zero 2, all of which carry wireless connectivity. The official documentation is explicit, version 1.3 is the one that offers the best guarantee of network isolation.

The difference from a software switch is fundamental. Wi-Fi disabled in a setting rests on the promise of one piece of software that another piece of software can break. A chip that was never soldered onto the board cannot be reactivated by any code, any flaw, any booby-trapped update. You are no longer trusting a configuration, you are observing a physical absence.

The rest comes down to three parts: a 1.3 inch WaveShare screen at 240 by 240 pixels with its buttons, a camera module compatible with the Pi Zero, and a microSD card. Less than 50 dollars of components, with no soldering at all.

All communication goes through QR codes, in both directions. The connected wallet, Sparrow for example, displays the PSBT as a QR code, animated if the transaction is large. The SeedSigner’s camera reads it. The device displays the transaction details on its screen, you confirm, it signs, then displays the signed transaction as a QR code in turn, which you capture with the connected computer’s webcam. No data cable, no USB stick, no network. Light is the only channel.

The device is also stateless. It never stores the key permanently: the seed phrase is entered at the start of each session, lives only in RAM while in use, and disappears when the power goes off. The microSD card contains nothing but the software. An attacker who steals your switched-off SeedSigner steals nothing but a fifteen-euro Raspberry Pi.

The flip side of openness. There is no longer a manufacturer to trust, but there is no longer one to guarantee anything either. Before writing the software to the microSD card, you have to verify its authenticity yourself. The project publishes on its GitHub releases page the image file together with a manifest and the signature of that manifest. Verification combines a GPG signature, which proves the release really comes from the developers, and a SHA256 fingerprint check, which proves the file has not been altered since. It has to be done before you even mount the image, because some systems modify it on opening and cause the check to fail. If it fails, you do not flash.

One functional limitation to note: SeedSigner is a Bitcoin project, it does not cover other chains.

Level 5: the Vault VM on Qubes OS

Level 3 separates two worlds by an unplugged cable. That is a guarantee you maintain manually, day after day, and it rests on your discipline.

Qubes OS offers something else: a separation imposed by the architecture of the system. Qubes compartmentalises your activities into distinct virtual machines, called qubes, isolated by a hypervisor. We placed it alongside the other systems in our comparison of security-focused operating systems.

A Vault VM is created with no network interface at all. This is not a cosmetic setting: the virtual machine has no virtual network card whatsoever, no driver, no stack, nothing to enable. It has physically no way of emitting a packet, whatever code runs inside it. That is the VM that holds the seed phrase and runs Sparrow offline.

A second VM, connected this time, runs Sparrow in watch-only mode, with the public keys alone. It sees the balance and the history, knows how to build transactions, but is incapable of signing one.

The transfer happens exclusively by file, using the internal qvm-copy tool. The unsigned PSBT goes from the connected VM to the Vault, the Vault signs it, the signed file comes back by the same mechanism. No shared network, no common folder, no automatic clipboard.

Two things make this superior to a simple isolated PC. First, the isolation no longer depends on you: on a classic air-gapped machine, the air gap is a property of your behaviour, it holds as long as nobody plugs in a cable. Under Qubes, the isolation is enforced by the hypervisor, below the VM, out of reach of whatever runs inside. Malware that gained full powers inside the Vault would still have no network hardware to drive. Second, reversibility: qubes are based on templates, and if you suspect a compromise, you destroy the VM and recreate it clean in a few minutes. On a dedicated computer, the same doubt requires a full reinstall.

What this level does not protect against. It is the most solid arrangement on this list, and it retains exactly the weakness of the first: there is still only one seed phrase. A fire that destroys your backup, physical coercion applied to you, a handling mistake, and everything is lost or everything is taken. Software isolation, however perfect, changes none of that.

Multisig: changing the nature of the problem

The five previous levels all improve the same thing, the protection of a single secret. Multisig, or multiple signature, asks a different question: what if we stopped having a single secret?

The principle is written into the rules of the network. Instead of tying the funds to a single key, you tie them to a group of keys, with a threshold. In 2 of 3, three keys exist and two are needed to spend. In 3 of 5, five keys exist, three are needed. Each key is generated independently, on a different device, ideally of a different kind, and kept in a different place: a Coldcard at home, a SeedSigner with someone you trust, a key in a bank vault.

What that changes is clear-cut. A burglar who finds one backup gets nothing. A fire that destroys one location does not destroy your funds, you reconstitute with the remaining keys. A defect discovered at one manufacturer is not enough, since your other keys come from elsewhere. Someone threatening you physically runs into the fact that you cannot, alone and on the spot, produce what they are asking for.

The single point of failure disappears in both directions at once, against loss and against theft. None of the previous levels achieves that result, including the Qubes arrangement.

The flip side is operational complexity. You have to back up not only the seeds, but also the wallet descriptor, a file describing the structure of the arrangement and the public keys that make it up. Without it, recovering your funds becomes very difficult even with the required number of seeds. A badly documented multisig is more dangerous than a simple hardware wallet properly mastered.

The rules that apply at every level

Hardware takes up most of the discussion, whereas real losses most often come from elsewhere.

Spread your backups geographically. Two copies of the same seed in two drawers of the same house amount to one copy in the face of a fire or water damage. The risk is not only theft. Separate the locations, bearing in mind that every additional copy improves your resistance to loss and degrades your resistance to theft. It is a trade-off, not an optimal setting.

Test with a small amount. Send the equivalent of a few euros, check it arrives, then wipe the wallet and restore it entirely from your backup. A working receipt proves nothing about restoration, and it is restoration that will save you one day. A word copied wrong, a reversed order, an incomplete backup: all things that only come to light at that moment, and it is better to find out with ten euros at stake.

Stay discreet. Technical security has no effect on social engineering or on targeted physical theft. Do not mention publicly that you hold cryptocurrencies, not on social media, not at the restaurant, not to distant acquaintances. The best arrangement in the world does not protect someone who is known to have something worth taking.

Plan for inheritance. This is the most neglected point, and it is irreversible. A well-secured cold wallet is designed so that nobody but you can get into it. In the event of death or incapacity, that property turns against your heirs and the funds are lost for good. Several approaches exist: encrypted documentation entrusted to a trusted third party or lodged with a notary, a multisig arrangement including a key held by an heir, or a dead man’s switch mechanism that releases information in the absence of any sign of life. Each carries legal and tax implications that vary from country to country. Document the technical intent, and have the implementation framed by a legal professional.

What this says about Arpokrat’s approach

The thread running through these five levels is not increasing sophistication. It is the progressive reduction in the number of actors you have to trust without being able to verify. The exchange demands total trust. The hardware wallet reduces it to one manufacturer. The SeedSigner replaces it with a verification you carry out yourself. The Qubes arrangement shifts the guarantee from behaviour to architecture. Multisig removes it from every element taken in isolation.

That is the logic governing the design of our products. A guarantee that rests on a promise is not a guarantee, it is a commitment. A structural guarantee holds even when whoever built it changes their mind or receives a court order. A service that does not hold your keys cannot hand them over, whatever pressure is applied: that is the principle underlying Arpokrat Swap. The question becomes more concrete as the regulatory framework evolves, as shown by our analysis of the European restrictions on Monero and Zcash planned for 2027.

Conclusion

There is no such thing as a good level of security in general. There is a level proportionate to what you hold and to who could reasonably target you.

A few hundred euros on a hardware wallet bought from the manufacturer, with a seed engraved on metal and stored away from your home, is a perfectly serious configuration. It already puts you above the overwhelming majority of cryptocurrency holders and protects you from the scenarios that actually cause losses. Nobody needs a multisig on Qubes for that. The complex arrangement is justified when the sum would make a targeted attack worthwhile, or when your situation attracts particular attention.

The right question is therefore not how far up to go, but which of your current assumptions is the most fragile. For most people it is not the hardware: it is a single backup stored in a single place, a restoration never tested, or an inheritance never considered. Those three points cost nothing to fix, and they matter more than moving from one level to the next.

Which operating system for your security and privacy? Windows, macOS, Linux, Tails, Whonix and Qubes OS compared

Mon, 22 Jun 2026 00:00:00 +0000

Choosing an operating system is not merely a matter of interface preference or software compatibility. It is also — and increasingly so — a security and privacy decision. Each OS collects data differently, exposes different attack surfaces, and offers a highly variable level of control to the user. This comparison analyzes the main systems on the market exclusively through this lens, from the most widely used to the most specialized.

The central criterion: who controls your system?

Before diving into the details of each OS, one structuring principle: the security of an operating system fundamentally depends on who holds the code and what architectural decisions were made at design time. A proprietary closed-source OS (Windows, macOS) delegates that trust to its publisher. An open-source OS delegates that trust to the community auditing the code. An OS designed for compartmentalized security (Qubes OS) starts from the assumption that no component of the system should be entirely trusted.

Windows 11

Data collection and telemetry

Windows 11 is the most widely used desktop OS in the world, and also one of those that collects the most data by default. Microsoft divides its telemetry into two official categories:

Required data (cannot be disabled on Home and Pro editions): hardware configuration, device identifiers, error and stability reports, update and driver data. This data is transmitted to Microsoft regardless of user preferences.

Optional data: usage behavior, application interactions, personalization data. Can be disabled in settings, but is automatically re-enabled during certain major updates.

Windows 11 24H2 introduced several new collection layers tied to AI:

Windows Recall: takes a screenshot every five seconds to create a searchable timeline of everything you have done on your machine. Can be disabled, but is enabled by default and linked to access rights that can be extended by other applications
Copilot: every query is transmitted to Microsoft servers, including screenshots, selected text, and the context of open applications
Defender Cloud Protection: sends hashes of suspicious files and behavioral data to the Microsoft cloud for analysis

The conclusion documented by numerous independent technical sources is unequivocal: it is impossible to fully disable Windows 11 telemetry on Home and Pro editions. The only way to achieve this is to use an Enterprise or Education edition, apply specific group policies, or resort to third-party tools such as O&O ShutUp10++ or WPD, with the stability risks that may entail.

Attack surface and security

Windows 11 is the target of the vast majority of malware, ransomware, and exploits available worldwide, proportional to its market share. Microsoft has introduced significant security mechanisms (mandatory TPM 2.0, Secure Boot, VBS, Credential Guard), but these operate within a monolithic model: a compromise of the kernel or a privileged system service affects the entire environment.

Security/privacy verdict: the most exposed system in this comparison, telemetry that cannot be fully disabled, trust model entirely delegated to Microsoft and US jurisdiction.

macOS

Data collection and telemetry

Apple has built part of its marketing image on privacy. The technical reality is more nuanced.

macOS collects significantly less data than Windows by default, but collection remains real and partially non-disableable:

Gatekeeper and OCSP verification: every time an application is opened, macOS performs an online check with Apple servers to confirm the application has not been revoked. This request transmits information about the opened application and the device’s IP address. No native setting allows disabling these checks without breaking the security chain
macOS Analytics: collects data on system usage, disableable in System Preferences > Privacy > Analytics
Apple application telemetry: Maps, Siri, App Store, and other built-in Apple applications each maintain their own collection with rotating identifiers, independently of the system analytics setting

For users who want to go further, security experts recommend using an application firewall (Little Snitch or LuLu, which is open source and free) to monitor and block outgoing connections on a per-application basis.

Attack surface and security

macOS benefits from several robust security mechanisms: System Integrity Protection (SIP), which protects system files as read-only; Kernel Integrity Protection at the hardware level on Apple Silicon chips; sandboxing of App Store applications; and the Secure Enclave on recent machines. The relationship with an Apple ID is the primary vector for personal data collection.

Security/privacy verdict: better than Windows on default telemetry, but still subject to non-disableable OCSP checks, US jurisdiction, and Apple’s closed model. Difficult to audit independently.

Linux (general-purpose distributions)

Linux is not a single operating system but a kernel upon which very different distributions are built. From a security and privacy standpoint, they share a common foundation but diverge on several points.

Ubuntu is the most popular distribution for beginners. It sparked controversy in 2012 by sending local search queries to Amazon servers — behavior that has since been removed. Ubuntu maintains its own usage data collection (whoopsie, ubuntu-report), which is disableable, and tightly integrates Snap repositories controlled by Canonical Ltd.

Debian is the base upon which Ubuntu is built, without the layers added by Canonical. Governed by a non-profit community project with a strict commitment to free software, it collects no telemetry by default. Its conservative update policy is generally preferable in terms of attack surface.

Fedora, sponsored by Red Hat (an IBM subsidiary), is technically modern with a fast update cycle. No telemetry by default, but the relationship with Red Hat/IBM introduces a corporate dependency worth noting.

Linux Mint, derived from Ubuntu, is designed for users coming from Windows. It has removed the most controversial Ubuntu components (Snap is absent by default) and introduces no telemetry of its own.

Arch Linux targets advanced users with a minimalist philosophy: the user installs only what they need. No telemetry, rolling release updates, and total freedom of customization.

What Linux fundamentally offers

Open and auditable source code: any security researcher can inspect the kernel and main component code
No imposed telemetry: no major distribution forces non-disableable data collection
Stricter permissions model by default: use of a root account separate from daily actions
Reduced attack surface: Linux is less targeted by mass malware

Security/privacy verdict: clearly superior to Windows and macOS on data collection. No general-purpose distribution protects against a compromised application spreading across the entire system.

Tails OS

Philosophy: amnesia as protection

Tails, an acronym for The Amnesic Incognito Live System, is a Debian-based operating system that merged with the Tor Project in 2024. Its philosophy is radically different from all other OSes: rather than attempting to secure a persistent environment, it eliminates all persistence by default. Tails exists only for the duration of a session.

Technical architecture

Tails runs entirely from a USB drive (8 GB minimum) and operates entirely in RAM. When you shut it down, no trace remains on the host machine: no temporary files, no history, no credentials, no forensic artifacts on the PC’s hard drive. It does not matter if that PC is compromised at the software level: Tails never writes to its disk.

Tor by default and without exception

All network traffic in Tails is systematically routed through the Tor network. If an application attempts to establish a direct connection bypassing Tor, Tails blocks it. It is not possible to use Tails to browse without Tor, even by mistake.

Encrypted persistent storage (optional)

By default, Tails forgets everything on each shutdown. For users who need to retain certain data between sessions, Tails offers a Persistent Storage: an encrypted volume (LUKS) created on the USB drive itself, protected by a passphrase. The user chooses precisely what is stored there: certain files, application configurations, PGP keys, etc. This persistent storage does not change the amnesic nature of Tails with respect to the host machine — it only affects what is retained on the USB drive between sessions.

Pre-installed tools

Tails comes with a set of pre-configured tools: Tor Browser, an encrypted email client, a file encryption tool (Kleopatra/GnuPG), secure messaging clients, and LibreOffice for office tasks. No additional software needs to be installed for common high-security use.

2026 technical note: Tails 7.7 added a notification for outdated Secure Boot certificates, as Microsoft’s 2011 keys are beginning to expire in June 2026. Users whose UEFI firmware has not been updated may no longer be able to boot Tails on certain machines.

What Tails protects against and what it does not

Threat	Tails Protection
Forensic analysis of the host disk after seizure	Total: the host disk is never touched
Network surveillance (IP, sites visited)	Strong via Tor, but depends on Tor’s robustness
Persistent malware on the host machine	Bypassed: Tails does not use the installed system
BIOS/UEFI malware (compromised firmware)	None: Tails cannot protect against the firmware of the machine being used
Human error (logging into a personal account)	None: if you log into Gmail under Tails, you de-anonymize the session
Compromise of software during the session	Limited to the current session, destroyed on shutdown

Honest limitations

Tails is not suitable for everyday use: the lack of persistence means reconfiguring the environment on every boot
A BIOS or firmware-level malware (such as a UEFI-level implant) can potentially compromise a Tails session, because Tails does not control the firmware layer of the machine it runs on
Logging into a personal account (email, social network) cancels the anonymity of the session, regardless of Tor

Who is it for?

Journalists working with sources via SecureDrop, activists under surveillance in repressive regimes, and anyone needing a one-off high-sensitivity session on hardware they do not control. Used by Glenn Greenwald and Laura Poitras to process the Snowden documents, recommended by the EFF, the Freedom of the Press Foundation, and the Tor Project.

Verdict: a first-choice tool for one-off high-sensitivity sessions. Not a primary everyday OS.

Whonix

Philosophy: structural anonymity through network isolation

Whonix addresses a different question than Tails: rather than erasing all traces after the session, it ensures that malware running in the work environment structurally cannot know the user’s real IP address, even if it has root privileges on the work virtual machine.

Whonix is based on Debian (via KickSecure, a hardened version of Debian developed by the same team) and runs inside a Type 2 hypervisor (VirtualBox, KVM) on any host OS, or natively in Qubes OS as a Type 1.

The two-VM architecture

The central principle of Whonix is a strict separation between the network layer and the application layer, implemented via two distinct virtual machines:

Whonix-Gateway is the first VM. It runs the Tor daemon and serves exclusively as a network gateway. It is the only VM with Internet access. It contains no user applications. Its sole role is to intercept all incoming and outgoing network traffic and force it through Tor.

Whonix-Workstation is the second VM. It is the working environment: browser, messaging, file processing, development. It is connected to the Internet only through the internal virtual network pointing to the Whonix-Gateway. It has no direct Internet access, no ability to connect in a way that would bypass the Gateway.

Here is what happens when a network request is made from the Workstation:

The application issues a network request
The Workstation sends it via its internal network interface to the Gateway
The Gateway intercepts the request and reroutes it through Tor (three successive relays)
The response returns by the same path in reverse
The Workstation receives the response without ever having knowledge of the real exit IP address

The fundamental guarantee: even if malware compromises the Workstation with root privileges, it cannot know the user’s real IP address, because the Workstation itself never has access to it. The Workstation only sees the internal IP address of the Gateway.

Additional security mechanisms

Stream isolation: Whonix uses separate Tor circuits for different applications (the browser does not use the same circuit as the email client, etc.), which prevents traffic correlation between different activities.

Boot clock randomization: the Workstation’s system clock is slightly and randomly offset on each boot to prevent timing attacks based on the exact system time.

sdwdate: Whonix uses its own time synchronization daemon (sdwdate) that retrieves the time via Tor from onion servers, instead of classic NTP which could leak the IP address.

AppArmor: AppArmor profiles harden the sandboxing of critical applications such as Tor Browser at the system level.

Disposable VMs: Whonix supports disposable Workstations (Whonix-Workstation DispVM in Qubes-Whonix) for one-off tasks without persistence, similar to the Tails approach but within an otherwise persistent environment.

The three deployment modes

Whonix on VirtualBox or KVM (Type 2): the most accessible mode. Both VMs run on an existing host OS (Windows, Linux, macOS). Convenient, but introduces an additional trust layer in the host OS: if the host is compromised, Whonix’s protection can be bypassed.

Qubes-Whonix (Type 1, recommended): Whonix is natively integrated into Qubes OS as templates. The Gateway becomes a ProxyVM (sys-whonix) and the Workstation an AppQube (anon-whonix). This is the most robust configuration because the isolation relies on the bare-metal Xen hypervisor rather than a Type 2 hypervisor running on a potentially vulnerable host OS. This is the configuration recommended by both projects.

Physical isolation (advanced mode): the Gateway and the Workstation run on two separate physical machines connected by an Ethernet cable. The Workstation has no network card except the one connected to the Gateway. This mode drastically reduces the trust base but requires two dedicated machines.

What Whonix protects against and what it does not

Threat	Whonix Protection
IP address leak from the Workstation	Structurally impossible by architecture
DNS leaks	Impossible: all DNS goes through Tor via the Gateway
Root malware on the Workstation seeking the real IP	None: it will not find it
Compromise of the Gateway itself	Partial: if the Gateway is compromised, the IP can leak
Host OS compromise (in Type 2 mode)	None: a compromised host can observe both VMs
De-anonymization through user behavior	None: Whonix does not protect against human error
Forensic analysis of the disk after seizure	Partial: Whonix is persistent by default, except for disposable VMs

Honest limitations

Whonix does not erase disk traces: it is persistent by default (unlike Tails). If your machine is seized and host disk encryption is absent or weak, VM data can be recovered
In Type 2 mode (VirtualBox/KVM on a host OS), Whonix’s security is limited by the security of the host OS. A compromised host can potentially observe traffic between the two VMs
Performance is impacted by double virtualization and routing through Tor: connections are slow, and large downloads are difficult on a daily basis

Who is it for?

Anyone needing a persistent working environment with structural network anonymity: development of sensitive software, extended pseudonymous research, management of multiple distinct digital identities, onion servers. The Qubes-Whonix combination is considered by many security experts to be the most robust anonymous working environment currently available for everyday use.

Verdict: the reference OS for structural network anonymity in a persistent environment. Complementary to Tails (which handles one-off sessions), not a competitor.

Qubes OS

Philosophy: security through compartmentalization

Qubes OS represents a fundamentally different approach from all the preceding systems. Whereas other OSes attempt to prevent compromises, Qubes starts from a radically different postulate: the compromise of certain components is inevitable. The objective is to ensure it cannot spread.

Created in 2012 by security researcher Joanna Rutkowska, Qubes OS is publicly recommended by Edward Snowden, among other security professionals.

Technical architecture

The Xen hypervisor as the base layer

Qubes is not a Linux distribution in the classical sense. It uses the Xen hypervisor, bare-metal virtualization software that runs directly on the hardware without an intermediate host OS, to create lightweight virtual machines called qubes. Isolation between qubes is enforced at the hardware level via Intel VT-x/VT-d and AMD-Vi (IOMMU) technologies, which prevent VMs from accessing the memory or devices of other VMs without explicit permission.

dom0: the maximum-trust domain

At the top of the hierarchy sits dom0, a privileged domain from which the desktop manager is run. dom0 manages the display of all windows from other qubes. For security reasons, dom0 has no network connection and runs no user applications. It serves only to orchestrate display and domain management.

Qubes: airtight compartments

The user defines as many qubes as needed, each corresponding to a trust context:

A “work” qube for professional applications
A “personal” qube for emails and social networks
A “banking” qube dedicated solely to financial transactions
An “untrusted” qube for opening suspicious attachments
Disposable qubes that disappear entirely on closure

Each qube has its own network stack, its own memory space, and its own processes. Malware that compromises the “untrusted” qube is confined to that qube. It cannot access files in the “work” qube, nor traverse to other domains.

Visual color coding

Each window displays a colored border corresponding to the trust level of its qube: red for untrusted domains, green for high-security isolated domains, yellow for semi-trusted domains. This simple visual system allows users to know at all times in which context each action is taking place.

Templates and centralized management

Qubes do not contain their own full OS installation: they share templates (Fedora, Debian, and Whonix by default). Security updates are applied to the template, and all qubes based on that template benefit from them automatically.

PCI passthrough and hardware isolation

Whereas classic OSes run hardware drivers in the same space as user applications, Qubes assigns each physical device (network card, USB controller) to a dedicated qube via PCI passthrough. A compromised network driver cannot access data from other qubes.

Whonix integration

Qubes natively integrates Whonix as templates, allowing the traffic of any qube to be routed through Tor transparently. This is the Qubes-Whonix configuration described in the previous section.

What Qubes actually protects against

Attack scenario	Classic OS	Qubes OS
Malware in a PDF attachment	Potential access to the entire system	Confined to the “untrusted” qube, destroyed on closure
Web browser exploit	Access to user profile, files	Confined to the browser qube
Network driver compromise	Access to system memory	Confined to the network qube via PCI passthrough
Stolen PGP key	Yes, if the signing software is compromised	No, if the key is in a dedicated qube with no network
Leakage between applications	Possible via IPC, shared memory	Impossible between distinct qubes

Honest limitations

Qubes does not protect against a dom0 compromise: if the Xen hypervisor itself is compromised, isolation can be broken (bulletin QSB-115 dated June 9, 2026, regarding vulnerability XSA-491)
No isolation within a single qube: two applications in the same qube are not isolated from each other
Significant hardware requirements: processor supporting VT-x/VT-d, minimum 16 GB RAM (32 GB recommended), 32 GB storage. Apple Silicon machines are not supported
Real learning curve: copy-pasting between qubes requires a conscious action, and installing software goes through templates

Who is it for?

Qubes OS is designed for profiles whose threat model includes serious adversaries: journalists working with sensitive sources, lawyers managing confidential files, security researchers, professionals handling industrial or diplomatic secrets.

Verdict: the reference standard for personal workstation security against capable adversaries. The Qubes + Whonix combination is considered the most robust environment currently available.

How these systems combine

It is important to understand that these OSes are not exclusively alternatives to one another: they address different needs and are often combined.

Qubes + Whonix: the most robust combination for high-security everyday use. Qubes handles compartmentalization, Whonix handles network anonymity within certain qubes
Qubes + Tails: some advanced users use Qubes as their primary OS and boot Tails from a dedicated qube for particularly sensitive one-off sessions
Linux + Whonix in VMs: an accessible entry point into structural network anonymity without the full complexity of Qubes

Summary table

Criterion	Windows 11	macOS	Linux (Debian)	Tails	Whonix	Qubes OS
Default telemetry	Significant, cannot be fully disabled	Moderate, partially non-disableable	None	None	None	None
Auditable source code	No	No	Yes	Yes	Yes	Yes
Data persistence	Permanent	Permanent	Permanent	None by default	Permanent (VMs)	Permanent per qube
Network anonymity	None	None	None	Strong (Tor enforced)	Structural (Tor enforced)	Via Whonix integration
Isolation between applications	Weak	Moderate	Weak	Moderate	Moderate	Strong (hypervisor)
Resistance to compromise	Weak	Moderate	Moderate	High (amnesic)	High (network isolation)	High (compartmentalization)
Ease of use	High	High	Moderate	Moderate	Low to moderate	Low
Required hardware	Standard	Mac only	Standard	Standard + USB	Standard + RAM	x86-64 with VT-d, 16+ GB RAM
Suitable profile	General use	General use	Intermediate profile	One-off sensitive sessions	Persistent network anonymity	High-security daily use

Choosing an OS based on security is not a binary decision. It is an alignment between a real threat model and acceptable trade-offs in terms of compatibility and ease of use. For the vast majority of users, a well-configured Linux distribution already offers a level of protection radically superior to Windows 11 or macOS. For high-sensitivity profiles, Tails, Whonix, and Qubes OS represent three complementary approaches, each optimized for a distinct threat model.

The Time Bomb: Harvest Now, Decrypt Later and the Zero-Knowledge Imperative

Tue, 26 May 2026 00:00:00 +0000

The dependence of European governments on American cloud infrastructure poses more than just an immediate interception problem. The great revelation, the most devastating threat for decades to come, is what intelligence specialists call the HNDL: “Harvest Now, Decrypt Later” strategy.

This is not a frontal intrusion, but a silent theft. Intelligence agencies and state adversaries are intercepting and storing immense amounts of encrypted data today, simply because the cost of storage has become negligible.

They wait patiently for the moment when technological leaps and the unpredictable evolution of computing power will render current cryptographic keys obsolete. What constitutes a protected state secret in 2026 could become an open book in fifteen or twenty years.

Retroactive Liability and Temporal Risk

The HNDL model introduces a novel concept: delayed legal harm. Traditionally, a breach of secrecy is a static event. With the massive collection of data for future decryption, confidentiality becomes a time-dependent variable.

To quantify this risk, the HNDL scientific model defines that confidentiality inevitably fails when the required lifespan of the secret exceeds the adversary’s decryption horizon. Sectors of critical exposure are currently in a state of latent vulnerability.

If a state or an organization does not guarantee the absolute sovereignty of its hardware infrastructure, it is practically signing a waiver of long-term confidentiality for its citizens and institutions.

Today’s interception is tomorrow’s compromise. Turning cloud dependence into a national security debt is a gamble impossible to repay.

The Arpokrat Antithesis: Legal Impossibility by Code

Faced with this vulnerability, the industry is responding by creating radical digital sovereignty ecosystems. The Arpokrat model emerges as the perfect antithesis to centralized messaging: this architecture operates on a decentralized network, protected by the very strict Federal Act on Data Protection (FADP) in Switzerland.

The core logic is one of absolute Privacy by Design. By removing the need to provide a phone number, the user becomes a simple cryptographic key, devoid of physical identity.

Legally, this drastically changes the rules of the game. If the architecture is fundamentally Zero-Knowledge and non-custodial, the company faces a technical impossibility to comply with foreign warrants.

This is not civil disobedience against extraterritorial laws, but an unstoppable mathematical and legal safeguard: what you do not hold cannot be disclosed.

Beyond Encryption: Devaluing the Target Data

The true response, natively integrated into the Arpokrat messaging app, is not to bet on eternal mathematics, but to devalue the data itself.

Without central metadata, without phone numbers, and without IP logs to link a message to a physical individual, the encrypted content loses its strategic value because it becomes unattributable.

However, software alone can do nothing if the hardware betrays it upstream.

Ultimately, security in the 21st century requires the independence of the machine itself. Deploying a sovereign de-Googled OS has become an absolute survival requirement for anyone handling state secrets.