Run Fractum on a dedicated offline machine

Fractum writes key material to disk and cannot reliably erase it from memory afterwards. Neither limit is a bug that a future release removes: the first is inherent to producing share files that you then have to keep, and the second is inherent to Python. The practical answer is to run the operation on a machine that never goes online and that you can wipe or discard afterwards.

This page states that requirement, explains what it does and does not protect against, and lists hardware that works.

Why this is required, not advised

Two properties of the current implementation drive it.

Key material reaches the disk. Each share is written as a plaintext JSON file before being archived into its ZIP. If anything interrupts the run between those two steps, those files stay on disk. Reproduced on v1.4.2 by making the archiving step fail on the second share:

Error: disque plein simule
plaintext share files left: 2
   share_2.txt mode=0o644 share_key_present=True
   share_3.txt mode=0o644 share_key_present=True

Two of three shares, readable by every user on the machine. The threshold for that setup was two.

Memory cannot be scrubbed. SecureMemory.secure_clear overwrites mutable buffers, and that part works. It cannot work on Python's immutable types: a str or bytes object is copied into a new buffer, the copy is overwritten, and the original stays in memory untouched. The pyca/cryptography limitations page states the same constraint for any Python program: there is no way to clear immutable structures such as bytes.

Running as a normal user on a normal workstation, those two facts mean the secret can persist in the filesystem, in swap, in a hibernation image, and in free memory, with no reliable way to remove it.

What a dedicated machine actually fixes

Being precise here matters, because the wrong expectation is worse than none.

Fixed. Network exfiltration, since there is no network. Disk residue on your everyday machine, since the material never touches it. The plaintext share window described above, provided the working directory is a ramdisk.

Not fixed. The Python memory problem. A live system that runs from RAM does not make Python erase anything; it only guarantees that RAM is discarded when the machine powers off. That is a weaker and different property, and it holds only if the machine has no swap and never hibernates.

Not fixed. A compromised image or compromised packages. Verify what you intend to run before going offline, as described in the security practices.

Cold boot attacks, where RAM contents are recovered shortly after power-off, are real but require physical access within a narrow window. Tails, which documents the attack, notes it is not a common data recovery procedure. Power the machine off and let it sit rather than suspending it; that is the proportionate response.

Hardware options

A live system on an x86-64 machine, disk disconnected

The strongest option that most people can actually carry out. Boot Tails from a USB stick on a computer whose internal drive is physically disconnected or removed. Tails runs from RAM and leaves nothing behind by design.

Coldcard's paranoid guide recommends the same arrangement in the same terms: a computer running Tails, "preferable without any network connection and no hard drives".

Tails requires a 64-bit x86-64 processor and around 3 GB of RAM, per its hardware requirements. An old laptop is usually sufficient.

A second-hand laptop, permanently quarantined

The Glacier Protocol describes the most thorough published procedure. The instructions are physical and worth following literally: "Unbox laptop. Do not power it on", then "Physically remove the wireless card", then "After removing the wireless card, cover the ends of the internal wi-fi antennae with electrical tape". If WiFi and Bluetooth are separate cards, both come out. A tamper-resistant seal goes over the Ethernet port.

Glacier goes further than most situations require, using two parallel sets of hardware from different manufacturers so that a defect or backdoor in one vendor's equipment does not affect both. Adopt that if the secret warrants it.

Raspberry Pi

Usable, with one correction to the obvious plan: Tails does not run on a Raspberry Pi. Its requirements page lists Raspberry Pi as unsupported, and Tails does not run on ARM processors at all. A Pi therefore means Raspberry Pi OS on an SD card, which is persistent by default, which is the opposite of what this page asks for.

A Pi is still a reasonable choice if you treat the SD card as the thing to destroy afterwards, and if you pick a model without radios. SeedSigner selects the Pi Zero v1.3 precisely because it has no WiFi or Bluetooth capability. On a model that has them, they must be disabled in firmware, which is a weaker guarantee than absent hardware.

Qubes OS

If you already run Qubes, a network-isolated vault qube is a legitimate place for this work; that is the pattern Qubes documents for split GPG, where the master secret key never leaves the isolated VM. It is not worth installing Qubes solely for Fractum.

Keep the working directory in RAM

Fractum writes the plaintext share files into its working directory before archiving them. On Linux, point that directory at a tmpfs mount so the intermediate files never reach persistent storage:

sudo mount -t tmpfs -o size=256m,mode=0700 tmpfs /mnt/fractum
mkdir -p /mnt/fractum/data /mnt/fractum/shares

Two things defeat this if you overlook them.

Swap must be off, or a page holding key material can be written to disk anyway:

sudo swapoff -a

Docker's own storage is on the persistent disk. docker info reports the location under Docker Root Dir, normally /var/lib/docker. The container's writable layer lives there, so a run that leaves files inside the container rather than in your mounted volume leaves them on the disk. Use --rm so the layer is discarded when the container exits.

Always pass --network=none. Without it, Docker places the container on a network with outbound access; whether anything can actually leave then depends on the host firewall rather than on Docker.

docker run --rm -it --network=none \
  -v /mnt/fractum/data:/data \
  -v /mnt/fractum/shares:/app/shares \
  fractum-secure encrypt /data/secret.txt -t 3 -n 5 -l mysecret

Persist the shares, discard everything else

Running from RAM and needing to keep the output are only in tension if the outputs are treated as one thing. They are not.

The .enc file is ciphertext. It is useless without the shares, so it can be copied to ordinary storage, backed up, and kept online.

The share archives are the secret. They go to the media you intend to distribute, written directly from the ramdisk, and nowhere else.

Once the shares are written and verified, power the machine off rather than suspending it.

Disposing of the media

If a secret was written to a disk or card in plaintext, overwriting it is not a reliable erase. NIST's SP 800-88r2 (September 2025, superseding the widely cited 2014 revision) states that flash devices containing spare cells and performing wear levelling make it infeasible for a user to sanitize all previous data by overwriting, and that multi-pass overwriting of drives with overprovisioning achieves very little confidentiality protection. Degaussing does nothing to flash media.

What that leaves:

  • Cryptographic erase, where the media was encrypted from the start and only the key is destroyed. It only works if plaintext was never written to the device, so it has to be decided before the ceremony, not after.
  • Physical destruction. Note that r2 advises that pulverizing and shredding be reserved as the method for all but the lowest data categories, so a card put through a shredder is a weaker measure than it is usually assumed to be.
  • Not reusing the media. For an SD card, retaining it in the same custody as the shares is often more practical than attempting to sanitize it.

The simplest arrangement that avoids the question: keep the plaintext off persistent media in the first place, by using the ramdisk above.

Checklist

  1. Machine with no working network path, ideally with the radios physically removed.
  2. Internal disk disconnected, or a live system running from RAM.
  3. Swap disabled.
  4. Working directory on tmpfs.
  5. Image built and verified before going offline.
  6. --network=none and --rm on every run.
  7. Shares written to their destination media directly from the ramdisk.
  8. Machine powered off, not suspended.