Skip to content

secinthenet/crypto-guide

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

75 Commits
README.md
README.md
 
 

Repository files navigation

Cryptocoins management guide

⚠️ NOTE: WIP, no guarantees.

Table of Contents

Goals

  • Serve as a guide for secure storage and transacting of cryptocoins.
  • Avoid any novelty. It's basically bits and pieces from the web, organized in a way that I personally find clear.
  • Use simple, clear, and succinct language.
  • Be comprehensive but succinct: cover many aspects but link to other sources wherever possible.
  • Use methods that support multiple currencies where possible, but focus on Bitcoin and Ethereum (including ERC-20 tokens).

Non-Goals

  • Cover the purchase of cryptocoins. Only secure storage and transacting are in scope.
  • Be friendly to novices. This guide aims to be succinct and assumes familiarly with concepts such as HD wallets (BIP32), mnemonic seed phrases (BIP39), multi-account hierarchy for deterministic wallets (BIP44, BIP49, BIP84), Segwit (BIP141), Bech32 (BIP173), and multisig wallets. If those don't mean much to you, this guide is probably not for you.

Disclaimer

I wrote this guide for my own needs. I decided to share it with the community to collect feedback and help others in a similar position, but I take no responsibility whatsoever for any of the written content. Specifically, I am not responsible for any loss of funds incurred by following this guide or using any referenced software. You should always do your own research, and don't ever trust strangers on the internet with anything important.

Principles

  • Minimize trust in external entities, hardware, firmware, and software.
  • Maximize simplicity.
  • Follow established protocols and stick to adopted standards that have multiple independent implementations.
  • Avoid single points of failure.
  • Defense in depth.
  • Least privilege.
  • Compartmentalization.

Threat model

  • Malware and attacks originating from the Internet have a very high risk. Any malware infection in a device that handles secrets can compromise all the secrets the device holds.
  • Human errors in executing protocols are highly likely.
  • Any physical location can be compromised, whether by theft or physical damage.
  • Physical attacks have a low risk, but defending against simple ones (burglars and thieves) is in scope.
  • Physical attacks by a sophisticated adversary are out of scope.
  • Social engineering is out of scope.

Terminology

BIP32 master seed

The pseudo-random byte sequence of length 128-512 bits used in the first step of BIP32's master key derivation. Typically, backed up via BIP39 mnemonics.

BIP32 master key

The extended private key at the top of the BIP32 hierarchy. Denoted as m in BIP32 derivations.

BIP39 entropy

An initial entropy of 128-512 bits used in BIP39's mnemonic generation. Derives the mnemonic phrase by adding a checksum to the initial entropy and then decoding the result using a word list.

BIP39 mnemonic

The mnemonic phrase computed in BIP39 from the BIP39 entropy. This mnemonic is later hashed with an optional password to derive the BIP32 master seed.

Individual private keys

Private keys which are generated independently (in contrast to keys that are generated using a scheme such as BIP32). Less flexible than BIP32 seeds since they are only associated to a single "account", but may have security advantages if BIP32 turns out to have weaknesses.

Secrets

Any information that can help an attacker to spend funds. This includes:

  • BIP32 seeds
  • Individual private keys
  • Any passphrases for the above, for example a passphrase for BIP39 or a passphrase for BIP38 encrypted private keys.
  • Public keys: knowing them makes it easier to retrieve the corresponding private key by exploiting a weakness in ECDSA, whereas knowing only the address adds another security layer: inverting a cryptographic hash.

Seeds

A general term for anything that can be used to derive private keys, including BIP32 seeds, BIP39 mnemonics, and individual private keys.

Online Read-Only Wallet

A wallet that only knows addresses (and possibly public keys), but not any seed. This wallet is only used for tracking funds in existing addresses and generating addresses for receiving new coins. It must be online because tracking funds requires access to the blockchain (in contrast, generating addresses can be done offline).

Offline Signing Wallet

A device that is completely offline (not connected to the internet, nor any device that can be connected to the internet) that is used to sign transactions. Can be either a hardware wallet or a general purpose computer.

When using multisig, multiple separate offline signing wallets are required for securely sending funds, each providing a single signature.

PSBT

A transaction format standard for partially signed Bitcoin transactions defined in BIP174. Prior to the adoption of PSBT, every wallet implemented its own format for partially signed transactions used in multisig. This meant that it was not always possible to use different wallets to process multisig transactions.

Overview

Creating a wallet

  • Prepare secure quarantined devices (AKA eternally air gapped).
  • Generate seeds and auxiliary secrets using one or more quarantined devices.
  • Verify the seeds derive the same master public keys (xpub/ypub/zpub) with at least two implementations that are as independent as possible (different authors, different programming languages, different libraries used by the code).
  • Transfer a set of addresses to the online read-only wallet.
  • Verify that the new wallet can receive and spend funds (see subsection below).
  • Back up and distribute both the secrets and master public keys to paper in multiple locations.

Verify that the wallet is spendable

  • Send a small amount of funds from your old wallet (can be an exchange) to the first address in the new wallet, address1.
  • Verify that the online read-only wallet can detect that address1 received funds.
  • Select a new address address2 in the online read-only wallet.
  • Send the funds from address1 to address2.
  • Verify that the online read-only wallet can detect that address1 moved funds to address2.

Sending funds

  • Generate an unsigned transaction in the online read-only wallet.
  • For each offline signing wallet (multiple wallets are used only in multisig):
    • Transfer the unsigned transaction to the offline signing wallet.
    • Sign the transaction in the offline signing wallets (can be multiple wallets if using multisig)
    • Transfer the (partially) signed transaction to the online read-only wallet.
  • (Multisig only): Combine and finalize the partially signed transactions in the online read-only wallet.
  • Broadcast the transaction from the online read-only wallet.

Receiving funds

  • Select the first unused address in the online read-only wallet and provide it to the sender.

Testing backups

Preparing a quarantined laptop

TODO: Write guidelines for buying laptop (see Glacier for reference). Preferably use a laptop with a camera for communicating with QR codes, or connect an external webcam, alternatively use audio codes via amodem.

A laptop that can boot from a DVD or SD card (with built-in support and not via an external USB device) is also preferable.

Creating boot USB

  • Update BIOS to latest version from manufacturer

  • Physically remove risky components (not all of them may be easily removable):

    • Wifi
    • Bluetooth
    • Hard drives
    • Sound (microphone, speakers)

  • Install Linux Tails to a USB/DVD using the installation instructions

    • Download the latest image and signature

    • import the Tails developers PGP key

    • Verify the Tails image signature

    • Burn Tails image to USB/DVD (replace ${VERSION}):

      sudo dd if=tails-${VERSION}.img of=/dev/sdb bs=16M conv=fsync oflag=direct status=progress

    • If the laptop only supports BIOS/MBR (usually old laptops manufactured before 2012 or so), see the next subsection

  • Generate a strong password and store it.

  • Use Gnome Disks or GParted to create a separate encrypted partition (either in the boot device or another external storage device) and use the password from the previous step. This can be done either from inside Tails after booting it, or in another Linux machine. Note that Tails has a built-in GUI for that, but it only works in EFI/GPT mode, and it's easier to do it before booting Tails.

  • Decrypt and mount the encrypted partition in the setup computer.

  • Copy the setup_tails.sh script and other tools to the encrypted partition.

Booting quarantined laptop

  • Boot Tails.
  • In the Tails greeter, select Additional Settings:
    • Disable all networking
    • Create an admin password (you can reuse the previous password used for disk encryption).
  • Open the file manager and click on the encrypted partition to decrypt and mount it.
  • Open a terminal in the mount point of the encrypted partition (can be accessed by right clicking in the file manager).
  • Run the setup_tails.sh script.

Making Tails work in BIOS/MBR mode

The Linux Tails image uses GPT partitioning and contains the Syslinux MBR boot code for GPT. However, some laptops have BIOS firmwares that won't boot because without a proper MBR partition table. Therefore, we need to do some modifications to the boot device (USB/DVD) to support BIOS/MBR boot.

The first step is to download the archive of the latest stable version of Syslinux and extract it to a directory which we reference as ${SYSLINUX_DIR} in the shell code below. Then, run the following shell commands in a Linux terminal, where ${DEV} is the Tails boot device.

# Convert the partition table to MBR/msdos
sudo sgdisk --gpttombr "${DEV}"
if ! sudo parted --script "${DEV}" print | \grep -qi 'partition table: msdos'; then
  # NOTE: sgdisk sometimes failed to do this and I needed to use gdisk (the
  # interactive version).
  # TODO: maybe use expect/autoexpect to automate this.
  echo 'GPT to MBR conversion failed, falling back to gdisk'
  echo 'Type "r", then "g", then "w"'
  sudo gdisk "${DEV}"
fi
# Make the Tails OS partition bootable
sudo parted --script "${DEV}" set 1 boot on
# Write the MBR code for msdos partitions to the device
sudo dd bs=440 count=1 conv=notrunc,fdatasync if="${SYSLINUX_DIR}/bios/mbr/mbr.bin" of="${DEV}"

Changes considered:

  • Hybrid Hybrid UEFI GPT + BIOS GPT/MBR: not recommended by gdisk. Rejected because there's no reason to support it if the boot device is only used by a single laptop, which is the best practice for security.
  • Using /utils/mbr/mbr.bin from the Tails boot partition. For some reason, the boot failed when I tried that.
  • Running the syslinux/extlinux tools from Syslinux to install the bootloader into the filesystem. Tails already uses Syslinux so the MBR code is able to find it, but it may be safer to install it in case Tails switches to another boot loader.

References:

Generating secrets

Highly unpredictable secret generation is critical for the security of cryptographic algorithms. The following methods should provide a sufficient level of security:

  • Software generation on an air-gapped computer. Additional requirements:
    • The software generating the entropy for the secrets must be verified to use only secure sources of entropy (for example getrandom on Linux).
    • The OS must be loaded from live media (USB drive etc), be in pristine condition (no modifications to the upstream version), include minimal software other than what's required, be verified against signatures provided from the developers, and leave no traces (no persistence by default, i.e. be "amnesic").
    • Ideally, the OS will be booted from a read only storage medium in order to prevent malicious modifications. To this end, DVDs (which are read only after burning them) or USB flash drives with write protection can be used.
    • Ideally, the computer will never be connected to the internet after it was used to generate the secrets. This eliminates the risk that the generated secret was stored in persistent memory (probably due to already being compromised), and then transmitted to the attacker when connected to the internet.
  • Firmware/hardware generation on a special purpose security device such as a hardware wallet or an HSM.
  • Casino grade dice. Pro: simple, malware resistant, easy to verify. Con: requires manual input to a computer. Also, note that some secrets require additional computation that can't be easily done on paper (for example, the checksum for a BIP39 mnemonic), which reduces the malware resistance advantage.

It is possible to combine multiple independent sources of randomness to derive secrets that are at least as random as the most random source (for example, by XORing them).

Storing seeds

  • Store the seeds in multiple physical locations in a non-electronic form with redundancy, for example using identical paper copies with the seed, or multisig seeds (see below).
    • This should prevent most attacks, since physical access will be required to compromise the secrets.
    • Redundant storage ensures that it's possible to restore the funds in case a subset of the storage locations are compromised (for example due to loss, theft, fire, etc.).
  • Use durable materials, such as the durable paper Glacier recommends, or a Cryptosteel.
  • Store the seeds in a safe place, for example a vault.
  • Consider using tamper-resistant seals to be able to detect compromises.

Encrypting seeds at rest

If you store seeds unencrypted, an attacker can steal funds by a simple physical theft. The following subsections discuss additional layers of defense that can be used to prevent such attacks.

Passphrase

You can use a passphrase to protect the seeds (both for BIP39 mnemonics and for private keys). This means that you need to store the passphrase securely as well (don't forget about backups!). Options include:

  • On paper or other non-electronic form, in a disjoint set of physical locations.
  • In secure hardware devices such as Yubikeys or HSMs.
  • In a password manager. The con of this method is that it may be impossible for your heirs to access the password.

For any of these methods, backups can be made by adding redundancy, for example storing multiple paper backups, using multiple hardware devices, or storing the password manager database in multiple devices.

Split seeds

Instead of directly storing the seeds, you can split them to N shares using Shamir's Secret Sharing (from now on SSS) and store the shares. Using SSS you can choose a parameter M so that the secret can be restored by any M shares. This means an attacker needs to compromise at least M different physical locations to steal the funds. Moreover, you can loss up to N-M+1 shares and still be able to restore the seed.

A similar option is to use SSS to split a passphrase to the seed, instead of the seed itself. The advantage of doing this is that the passphrase is usually smaller, so the SSS shares will also be smaller and easier to store. That said, some SSS standards such as SLIP39 have length limits (minimum 128 bits for SLIP39), so in this case splitting the passphrase may not have an advantage.

See SLIP39 for more details on this approach.

Multisig seeds

Using a method like BIP45, it's possible to generate N seeds so that each transaction requires signatures from private keys derived from M of the seeds. The equivalents for private keys are BIP11 and the newer BIP16.

Discussion: split vs multisig seeds

  • Multisig seeds are partially standardized (via the unofficial "BIP48" used by multiple wallets). In Bitcoin, multisig transactions are also supported at the protocol level (BIP11). In contrast, split seeds require more custom software. This means that multisig seeds are likely to have better software support over time. For example, they are already supported by some wallets.
  • When the secrets are stored in cold storage, both split and multisig require M/N shares to spend funds. In both cases, the user can choose M and N to fit their specific security requirements.
  • Multisig enables you to maintain the property that at no point in time there is sufficient information to spend funds in a single wallet/place, even when spending funds. When you want to spend funds, you generate a transaction, pass it to each of the wallets for signing, and then broadcast it to the network. Importantly, no single wallet will have sufficient information to spend funds during the whole process. The upshot is that multisig seeds enable you to distribute trust among multiple wallets. For example, you can use both a Trezor and a Ledger, each having one multisig seed in a 1-of-2 setup, and require signatures from both seeds to sign a transaction. Even if a severe vulnerability is discovered in one of them, it should not affect you. Contrast this with split seeds, where there will necessarily be some time period where a single wallet has enough information to spend funds.
  • Multisig seeds require M signatures for every transaction. Using split seeds requires M shares to reconstruct the seed, but from that point the reconstructed seed can be used to sign any number of transactions.
  • Multisig seeds do not yet support multiple coins in a standardized way. Note that BIP45 specifies derivation paths that are specific to a single coin, and as of 2020-12-27 it doesn't seem to be used by any popular wallet.

Secure air-gapped communication

Signing transactions requires moving data between the offline signing wallets and an online read-only wallet. Using USB for such a task is risky, as the USB stack is complex and has been exploited in the past to infect computers with malware (Stuxnet, BadUSB, etc.). There are two alternative mechanisms for communication that avoid the complexity of USB and other electronic connections:

  • Visual codes (such as QR codes)
    • Pro: QR codes are standardized and have a large software ecosystem.
    • Con: Large transactions may not fit in a single QR code. Multiple QR codes can be used to transfer an arbitrary amount of data, but that increases manual work and there's no standards for that.
  • Audible codes
    • Pro: Supports large transactions more seamlessly than QR codes.
    • Con: No standards and limited software selection.
    • Con: It's harder to defend against wiretapping/eavesdropping than a camera (microphones are smaller and harder to block).

Another consideration is hardware requirements. QR codes require a camera/scanner, while audible codes require a microphone and speakers.

See references below for implementation options.

Hardware wallets

An issue common to most hardware wallets, including Trezor and Ledger, is that they are not truly air gapped: they use SD cards or USB to communicate with an internet connected host. Cobo Vault is one device which does this right, and uses QR codes to communicate with the host.

Using a PIN and/or passphrase in hardware wallets

Using a PIN should be sufficiently secure provided that:

  • The hardware wallet throttles PIN attempts and has a self destruct mechanism after many wrong attempts
  • The hardware wallet stores the secrets (like xprv or seed phrase) in a secure element

TODO: document which wallets have these features.

When using either a PIN or passphrase with this security protocol, it can be stored in a password manager (ideally in a dedicated virtual vault and more protection than a regular password). This way, you don't have to do the restore process (which is risky) to be able to restore the PIN/passphrase.

Trezor vs Ledger

The most popular wallet vendors are Trezor and Ledger, and both support a large number of currencies.

Trezor seems better to me since it's fully OSS (hardware, firmware, and software), and both of the founders have been active in the Bitcoin community for a long time and seem to have a good reputation. That said, Trezor had at least one critical issue in the past — it stored the device PIN in plaintext. To their defense, they quickly fix reported security issues, and are responsive in general.

Ledger also had serious security issues in the past, and their response wasn't great — according to the linked article, their CEO "made some comments on Reddit which were fraught with technical inaccuracy". See the Interaction with Ledger section for more details.

Ideas that need more research

Building from source

Bitcoin Core and other used software can be built from source, ideally using a reproducible build process that can be done on multiple computers to verify the binaries match bit-for-bit.

Using a virtual keyboard to type secrets

Using a virtual keyboard significantly reduces the risk of hardware keyloggers, most software keyloggers, and some audio side channel attacks.

Disabling risky drivers (Wifi, Bluetooth, etc.)

On Linux, it's possible to blacklist the kernel modules for these devices.

Removing USB flash drive after boot

It seems there may be an issue doing this in Tails, but it should be possible to load everything to RAM and then remove the USB. AirGap Vault Distro documents that this is possible with their setup.

Avoiding installation of OS packages

Installing OS packages such as qrencode requires root permissions, which is risky, because a compromised package could write data to persistent storage such as the EFI NVRAM, while regular users don't have this permission.

Methods that can be used to avoid this:

  • Building the package manually with all its dependencies without installing it. This can be done from an online computer (booting a live CD)
  • Installing the package in a container

Stripping down OS installation to bare minimum

By default, most distributions contain a lot of software packages that are not required for this protocol, which introduces more risk. It's possible to build a bootable Linux ISO purpose-built to run the software of the offline signing wallet (similar to BitKey). However, this also introduces security risks in the ISO build process, and makes it harder to correctly verify the ISO, in contrast to popular distros where it's easy to verify the hashes/signatures of the ISO in multiple sources.

Avoiding X11

X11 is very old and has many security issues, the most notorious one being that every window can log keys from any other window. Wayland has better security in theory, though it's less battle tested.

It should also be possible to do everything from a terminal, with the possible exception of scanning a QR code, or at least seeing what is being scanned. It can be overcome in theory by rendering the video to the terminal.

Diversifying the operating system

Using another operating system like OpenBSD in the offline signing wallet.

Using eternally quarantined printers

Buying eternally quarantined printers that will be used by the offline signing wallet to print the (partially) signed transaction. This will make it possible to use the offline signing wallet in a room with no other electronic devices, reducing the risk of malware being able to communicate with it to steal secrets.

Misc notes

References

Cold storage protocols

  • Glacier protocol: I reviewed the design document and it looked good. The main issues with it are that it doesn't use HD wallets (didn't have time to review it before the release), and doesn't look maintained since early 2018.
    • BitcoinHodler's fork of Glacier improves many things in Glacier and seems well maintained as of 2020-11-28.
    • Proof Wallet is another Glacier fork which adds support for HD wallets and sequential signing. Seems maintained as of 2020-11-28.
  • Yeti Cold (github repo): HD 3-7 multisig wallet.
  • 10x Security Bitcoin Guide: Bitcoin security guide by Michael Flaxman advocating for multisig seeds managed by hardware wallets from different vendors.
  • Tordl Wallet Protocols: modular guides for securely storing Bitcoin.
  • Subzero: Square's cold storage solution using HSMs for storage, QR codes for hot/cold storage communication, with multiple signatures required. Applied specifically to Square's hardware setup, but the ideas are general and the documentation is clear.
  • Pro-Tips for Ethereum Wallet Management: Ethereum guide from February 2018.
  • SmartCustody: Book by Blockchain Commons.
  • https://github.com/BlockchainCommons/Gordian
  • Advanced: Creating a Secure Wallet by Tomshwom: good guide for generating keys on an air gapped computer booting Tails. The guide agrees that hardware wallets are a very good option, but tries to avoid them due to their cost.
  • grayolson's guide for cryptocoins cold storage: advocates storing encrypted private keys in the cloud (Dropbox etc), encrypted with a strong Diceware password. Uses Tails on an air gapped computer to generate the keys. Most of the content is pretty good but I don't like the general strategy of storing the sensitive data online.
  • Coinbase Vault: managed wallet that requires multiple approvals for withdrawing funds and a time delay. Claims that 98% of the funds are stored offline.

Passphrase generation

Seed generation

  • github.com/iancoleman/bip39: web tool for generating BIP39 mnemonics or generating the private keys from an existing mnemonic or external entropy. Can be used offline.

  • bc-seedtool-cli: CLI tool for generating entropy and converting external entropy to different formats (hex, BIP39, binary, etc.). See also the comprehensive manual.

    Failed building a static binary (complained about missing libgcc_s.a), need to retry in a Docker container to see if it has anything to do with my specific setup.

  • github.com/trezor/python-mnemonic: reference implementation of BIP39 by Trezor.

  • github.com/tyler-smith/go-bip39: golang implementation of BIP39.

  • github.com/taelfrinn/Bip39-diceware: mapping from a coin flip and 4 dice rolls to BIP39 words. Can be used to generate the first N-1 words in a BIP39 mnemonic, similar to the Diceware method for generating passwords. Note that the last word in a BIP39 mnemonic is a checksum and therefore cannot be randomly generated. To get the last word, you will have to use something like seedpicker's last word calculator, or a script that tries all the words, similar to this script by Jonathan Cross.

  • github.com/bip32JP/bip32JP.github.io

HD wallets address derivation (BIP32)

BIP85 implementations

Air-gapped communication

Audible

  • amodem: a tool for sending data between computers using audio. The codebase looks high quality (well structured and readable code, tests, documentation, etc.) and the author is responsive.
  • Audio MODEM- Android implementation of amodem by the same author.

Visual

  • qrencode can be used to generate QR codes
  • zbar can be used to decode QR codes from images or a webcam
  • https://github.com/divan/txqr: golang library for communication via animated QR codes
    • Issue with reference to more projects
  • AirGap: OSS mobile apps for managing the secrets in a dedicated offline device, and then broadcasting transactions with another "regular" internet connected device. Communication is done with QR codes.
  • Guide on using Electrum and QR codes for air-gapped transactions.
  • Broadcast Transaction: Android app that supports broadcasting transactions via QR codes for BTC, BCH, LTC, DASH, and ZCASH. Not updated since 2018-08-22.

Wallets: multisig coordinators

Wallets: desktop

  • List from bitcoin.org
  • Bitcoin Core
  • Specter Desktop: A desktop GUI for Bitcoin Core optimised for multisig workflows with offline signing wallets.
  • Electrum: one of the most popular bitcoin wallets. I'm worried about its security and privacy (see this HN thread), though some of the issues can be mitigated by running an Electrum Server.
    • electrs: an efficient re-implementation of Electrum Server in Rust. Great performance and codebase looks high quality.
  • Beancounter: utility for auditing the balance of Hierarchical Deterministic (HD) wallets. Supports multisig + segwit wallets.
  • MyEtherWallet has a utility for building an unsigned transaction (essentially just computing the nonce and gas), which can then be transferred to an offline machine for signing.
  • MyCrypto: can be used for offline signing, though the documentation is outdated, and it's not clear if it's possible to create the unsigned transaction in the latest desktop app (v1.7.13). The legacy website has this feature where it's called "Send Offline". I'm not sure if there's a desktop app for the legacy website, but it's probably possible to run it locally as well. However, as of 2021-01-02, the "Send Offline" feature looks broken: it only computes the nonce and not the gas.
  • Gnosis Safe: Ethereum wallet with support for multisig with Trezor and Ledger. As of 2021-01-04, seems it's not possible to run it offline or use a computer as a signer.
  • coinbin
  • Copay: TODO
  • Wasabi: privacy focused bitcoin wallet supporting CoinJoin. As of 2019-10-30, seems to have very active development.
  • JoinMarket: CoinJoin focused wallet.
  • gowallet: cross platform TUI wallet written in golang. Doesn't look maintained, and uses custom cryptography.

Wallets: Android

Wallets: hardware

Wallets: utilities

  • https://walletsrecovery.org: List of wallets with their supported derivation paths and other features, aimed to help wallet users understand the interoperability between wallets.
  • HWI: python library and CLI for interacting with hardware wallets in a unified way, compatible with multiple models.
  • HD Wallet Scanner: Node.js tool to find used addresses in HD wallets, bypassing the gap limit of 20 specified in BIP32.

Split HD seeds and secret sharing (SLIP39)

Split HD seeds and secret sharing (non-standard implementations)

Multisig

Operation systems for cold storage

Note: "Live OS" means that the OS is designed to be run on any computer by booting it from a USB stick or DVD.

  • Tails: Live Linux distro focused on privacy and anonymity and designed to leave no trace on the computers it's used on. All internet connections are forced to go through Tor. Bundled with Electrum. Seems to be the best maintained security/privacy focused OS based on git activity.
  • AirGap Vault Distribution: Debian-based Linux distro based on BitKey. Looks unmaintained, but the code is very simple and can probably be updated easily.
  • BitKey: Live Linux distro with built-in software for processing cryptocoins such as wallets, password managers, QR code generator, etc. Doesn't look maintained since mid 2018.
  • Qubes OS: OS architecture that heavily uses compartmentalization to improve security. Usually runs a Debian or Redhat distro. Has stricter hardware requirements than a regular OS.
    • qubes-whonix-bitcoin: guide for using Qubes and Whonix to run Electrum in an offline VM, connected to a separate VM serving an Electrum personal server.
  • Whonix: TODO.
  • NixOS: Facilitates reproducible builds which is great for security and bit rot.
  • Kodachi: Live Linux distro similar to Tails: amnesic by default (no data persistence) and uses Tor to route all traffic. Doesn't look maintained based on Github activity.

Price discovery

Other libraries and CLI tools

On hold for now

About

(WIP) Guide for secure management of crypto coins

Resources

Readme
Activity

Stars

2 stars

Watchers

2 watching

Forks

1 fork
Report repository

Releases

No releases published

Packages

No packages published