That’s a generalization, and of course the “safest” way to store tokens varies depending both upon your circumstances and what you consider safe. But generally peaking, depite numerous debates that will undoubtedly continue, the fact remains this is the most secure method for storing cryptocurrencies. That’s because you minimize the electronic attack surface, reducing the defense to the physical realm.
There are dangers and pitfalls with paper wallets to be fair, but they are entirely avoidable. That’s what this post is all about – debunking the popular notion that paper wallets are a good choice in theory, but not in practice! Let’s see how it goes, and please – to the makers of hardware wallets, I use your products and love them, it’s not personal.
Here’s what I consider a “paper wallet”:
I know that thoughtful people will disagree, that’s why I state this up front. Notice for example, that I’ve excluded by definition all services which require sending your private key somewhere. That’s not unreasonable either given the nature of asymmetric cryptography. It’s one thing for me to carefully use private keys to sign messages, but quite another to willingly share them – that’s a non-starter.
Maybe this isn’t true in every possible situation, but in general I consider paper wallets safer than hardware wallets, and here’s why. More trust must be extended to more parties by the user of that hardware wallet, without much real ability to verify things.
First of all, to be clear – both paper wallets and hardware wallets are fundamentally safer than the other types, so long as best practices are followed. But paper wallets are safer than hardware wallets too, since they do not require extending the same level of trust to third parties and devices – more on that in a bit.
All the options except paper wallets and hardware wallets have significantly less ability to securely store your keys. That’s because all other options involve storing the private key(s) on a device that interacts with the Internet, exposing it to a higher level of risk.
Both hardware devices and paper wallets are safer than using wallet software running on devices that connect to the Internet, but using paper wallets requires little or no trust in third parties. Hardware wallets require absolute trust of the device designer, chip fabricators, hardware manufacturers, supply chain partners, distribution channels and national governments potentially involved in getting that supposedly safe piece of hardware into your hands.
It should be noted also that a USB hardware wallet requires trust on an ongoing basis, in any interactions it has a host device. Every time tokens are managed or balance is checked or keys backed up it connects to and implicitly trusts the host. To be fair, these hardware wallets are designed to be secure against this specific threat, but some non-zero level of risk will always exist exist.
Both approaches derive their security from isolating private keys from the network. However a hardware wallet has both more actual attack vectors, and is therefore less secure in my estimation. On the other hand, there are compensating strategies in hardware, leading to an endless cat and mouse game.
The most fundamental difference that hardware wallets have is that a great deal of trust must be extended, without the ability to verify. Historical trends suggest that compromises of commercial hardware devices by manufacturers are increasing. The chain of trust really includes the entire supply chain, and continues over time with firmware updates.
With wallet makers eager to adopt new cryptocurrency support in order to gain market share, we can expect an ongoing stream of (sometimes vulnerable) firmware updates as a pattern of behavior from most vendors. That spells trouble, but is the inevitable result of using commercial devices. See where I’m going with this?
Needless to say, hardware wallets to date also need to be connected to a computer to use the common functions like checking balances. They are designed to avoid being compromised by hostile host machines, right? You’ve been careful to ensure the host machine has no malware or compromised software? Nobody has had physical access to the machine right?
Note that some hardware devices like OpenDime have developed effective mitigating strategies. Their device keeps the private key locked up until a hole has been physically punched through a marked area on the device, i.e. protection at the hardware level. Physical isolation from the host like this mitigates the threat, but most of the device makers could improve.
So the best practice is to generate the keys offline using a machine that never touches the Internet. Typically an inexpensive device, since features are not what you want. For the advanced practitioners, this means disabling most of the input ports/hardware. What exactly that looks like varies depending on the device, your level of interest, etc. Maybe this means buying a cheap new laptop, but before turning it on, physically disabling wi-fi, bluetooth, USB, HDMI, microphone, camera, and ethernet and only allowing the keyboard, monitor, etc.
You never want to use a networked printer, and unless you require having a QR code it should suffice to use manual handwriting, engraving, carving, stamping or whatever instead of a printer. Handwriting on paper should be laminated and is ideally stored in a safe environment like a safe or a safety deposit box.
So there is one initial transfer of the script to generate keys to deal with for most people using paper wallets. This event has the potential for trouble to happen, since you’re using some means to transfer a file onto your new device. So take reasonable precautions – I like using a trusted bootable USB with the file on it, but this is by no means totally secure. For those who object that in actual practice I cheat by extending trust to a USB device …. extend that trust to the keyboard instead, and type in the script twice and when the two versions match exactly you’re ready to run the script and you’ve relied only on keyboard input.
Of course, take precautions against fading, water damage, etc. So laminate the paper, or use something more durable, and put in a safe or safety deposit box to avoid the elements if need be.
I think the real concern is that this always entails writing down one string of characters upon which depends the safety of all coins at that address. In fact you can avoid having a single string be your “key” to guard by using the kinds of strategies that delegate permission if m of n strings are presented.
See Shamir’s Secret Sharing, a personal favorite of mine, and an ingenious method for breaking up the information contained in a number into multiple numbers based on logic that’s understandable, even if the actual implementation details are tougher to understand. So for example, you might break up a private key into 3 pseudo-keys, 2 of which will be required to construct the actual private key.
When I suggest not to sweat the implementation details, I mean do what you can. If you can’t read the code and make sense of it, don’t worry. Commonly used, well vetted code has been around for years to generate the keys offline. Taking steps to insure you’ve downloaded and installed a verified copy of well known software is essential though – they have checksums for good reason!
Different situations present unique opportunities for people to make mistakes, and new possibilities exist with paper wallets. Every technique has ways to screw up no? A common example I hear cited is sending a private key to the printer when printing the paper wallet. It’s true you would not face that possible exposure if you used an online wallet because you wouldn’t have control of the key. With power comes responsibility. The real answer is always better operational security.
I don’t think using a printer for this is ever a good idea, but perhaps that’s not for you. You should never print to a networked printer, simply because that exposes the private key to devices on the network. Even if directly connected to the same machine it’s risky to use a printer. Common threats include, but are not limited to, malware scraping the keys from host memory, and residual info including key left in printer memory. So just don’t.
The bad rap that paper wallets usually get is due to perceived difficulty in exercising sufficient operational security. Strong opsec is at the heart of safe paper wallet use, since the goal of a paper wallet is to reduce the problem of securing a digital key to the realm of physical security.
Luckily for us all, most losses of tokens from wallets occur due to clever PC malware infections, malicious online wallet sites, unsafe computing habits, unexpected loss of devices/backups and so on. Can’t remember the last time I heard of money stolen from a paper wallet.
It doesn’t matter whether you’re using an unpatched windows machine or a hardened debian laptop with almost all I/O physically disabled there is an inherent risk of compromise that is substantially higher for any device communicating online using any useful networking protocols. I use quantifiers like “high level of risk” because in truth it is a bit of a slippery slope. There is always some level of possible interaction with other, networked devices from even the most hardened airgapped devices.
Paper wallets give you options with the highest level of control over the security of the private keys. This security is derived both from generating the private-public key pair offline, and from the variety of storage options. One reason I wrote this is so I can write in future about taking paper wallets to the next level using other well known information hiding techniques and alternate methods of persistence.
The main takeaway here should be that paper wallets can be extremely secure, in that they are subject to your direct control and physical security measures. But practising good opsec means everything; be safe money, not potential theft victim.