https://en.bitcoin.it/w/api.php?action=feedcontributions&feedformat=atom&user=LirazBitcoin Wiki - User contributions [en]2026-05-25T20:26:51ZUser contributionsMediaWiki 1.43.8https://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62197User talk:Ryanc2017-01-25T13:55:29Z<p>Liraz: typos</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 5-8 mnemonic words (64 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 5-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 64 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 5 words, even with a strong KDF and salt, but 5 truly random words should be enough for anyone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 5 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice. With 5 random words a 250,000,000 brainflayer botnet generating 100 guesses a second (10X faster than you're currently getting) would take 12 years to crack an '''unsalted''' Warpwallet. Salting the Warpwallet would banish cryptographic attacks to the realm of science fiction.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure. <br />
<br />
* [[User:RyanC|RyanC]] You are wrong. The consensus on this from other experts is that you are wrong. Your recommendations will harm users. I've talked to several otherwise smart people who have lost painfully large sums of money to various deterministic wallet tools. Such tools are a trap for people who are smart, but don't quite understand how effective password cracking can be. Many people think they do, but there is a lot of bad advice about passwords and passphrases out there. I personally have used passphrases in the past for things like GPG keys that would have gotten me 0wned if I'd used them even in WarpWallet. I'm done arguing with you, it's clearly not productive. Please talk with some of the Bitcoin developers about this if you still don't believe me. Please also understand how incredibly frustrating it is to have seen firsthand how much damage tools like this can cause their typical users (a paper was published about this), and then have people say "oh, but it's fine if I use it perfectly, so it's okay for everyone". If you want to use it, I can't stop you, but recommending these tools to random newbies is gross negligence. I also want to point out that it's a bit absurd to recommend hardware wallets if you categorically don't trust CSPRNGs. Why are their CSPRNGs trustworthy and others not?<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 23:45, 24 January 2017 (UTC)<br />
# I'd like to point out you are so fixated on only one branch of the attack tree that you're not seeing how your argument could apply equally well to the other branch that you dismiss as a "tinfoil hat threat" despite massive real-world evidence to the contrary. I could rephrase your comment: "You are wrong. The consensus of endpoint security experts is that you are wrong, and your recommendations to just trust endpoint software is gross negligence that will end up hurting users. If you don't believe me go talk to another expert on endpoint security. Oh but it's fine for me if I setup a perfectly secure endpoint, so it's OK for everybody. Automatic wallet generation on untrusted endpoints are a trap for smart people who don't understand how effective endpoint comprimising techniques are at subverting the integrity of their system in endlessly creative ways". My argument isn't that "my" threat is more important that "your" threat. My argument is that both threats are substantial and that I don't think we should dismiss either of them. If there's a tradeoff to be made where mitigating one risk comes at the expense of mitigating another we need to find the right balance to make a wise choice. Seeing things in black and white, your camp vs my camp, as an argument to be won, that's an all too human but very dangerous an unproductive attitude for a security expert to take.<br />
# Trustworthy is a probability not a binary value. Convenience is also a matter of degree. There's an inescapable trade-off. You can say: As an expert, I recommend you hold up to $100 in your pocket, up to $10000 in a steel vault and the rest in stocks or whatever. You'd be right to criticize my position if I was being simple minded to the point of absurdity. If I somehow miscommunicated that impression, I wouldn't blame you for feeling like there's no point in talking to this idiot.<br />
# For the record, Hardware CSPRNGs are no more trustworthy, if anything I trust them even less because they're such high value targets. That's why I limit their use to relatively small sums. Great for day-to-day use though. Very convenient. But I'm anticipating to wake up one day and learn a whole bunch of wallets got their funds swept and we eventually trace that back to weak/weakened wallet creation. I hope I'll be proven wrong but in the meantime, like you, I'm trying to help users minimize their exposure.<br />
# Before I sign off and stop troubling you with unwanted discussion, I just wanted to express my appreciation for the time you've taken to explain your position, the efforts to protect users and also that you went public with your research and didn't use it to run another botnet. You're a philanthropist. I've been benefiting from your advice and have been spreading it to anyone foolish enough to consider using SHA256 brainwallets. I've even done experiments with leaving various amounts of funds in SHA256 brainwallets just to see what would happen and have seen them grabbed with my own eyes. I never meant to downplay your research or imply that brainwallet stealing botnets don't exist. They obviously do and it's important to take that risk into account. If there's a gap in our understanding I think it's due each of us spending more time researching different classes of threats. I used to work with the military and spent a good chunk of my life researching sophisticated malware. Endpoint security risks looms ever large in my mind. I guess that makes me atypically skeptical of claims of system integrity. I imagine for you the risk of users choosing bad passwords/passphrases, having cracked so many of them seems to deserve more of an emphasis. <br />
# Sorry you feel the discussion was unproductive. If I've rubbed you the wrong way I apologize. FWIW, I found it productive.You've also convinced me that Warpwallet makes it too easy to avoid salting and the default should be changed. I'll try to get a patch through. I'll also be updating my recommendations on the resources I control to stress that the salt is mandatory and that using Warpwallet is unsafe without it.<br />
# We both agree that the threats are real and significant, we just place different weights on them. Before our correspondence it was my understanding that ROI for attacking '''salted''' warpwallets was so low that it would make the operation of a botnet most likely unprofitable. I don't think we disagree on that. I think we might disagree on the optimal set of trade-offs to factor into our recommendations to non-experts where protecting against one risk necessarily weakens protection against another. We agree that salts are essential and should be mandatory, key stretching adds security but isn't a silver bullet, humans are bad as sources of entropy, end-point security is really hard, blindly trusting RNGs is unwise, Warpwallet being a PITA to use and a privacy risk to use as your main wallet, and that your research is very important it and you're doing the Bitcoin community a huge service being an advocate against unsafe practices. That's a lot of common ground. Nice chatting with you Ryan (for me anyhow).<br />
<br />
** [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:49, 24 January 2017 (UTC) I mean, it boggles my mind how worried we are about losing Warpwallets <s>coins</s> to exotic risks such as Bitflayer botnets with millions of nodes, and meanwhile, the standard recommendation is to:<br />
# Trust endpoints that can and have been compromised in endlessly creative ways<br />
# Get that endpoint to create a hard to remember seed for your wallet<br />
# Write down the seed on a piece of paper(!), that can be lost, stolen, burned, or water-logged<br />
<br />
If worst comes to worse and the government, or criminals or whatever are looking for your coins, they'll ransack your house and bank vaults, find that piece of paper and all of our sophisticated crypto goes up in smoke. I think the future will look back to us and laugh: secrets are meant to be remembered, not written down!<br />
<br />
* [[User:RyanC|RyanC]] People run these botnets already! I gave a talk last summer, one of the bots robbed our bait wallet live on stage! This problem is solved trivially with BIP38 paper wallets. Risk of loss can be mitigated by making multiple copies and storing them in different locations. Requiring adversaries to steal your paper wallet and crack the passphrase is better than publishing what is effectively a hash of your passphrase and hoping for the best.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 00:01, 25 January 2017 (UTC) Clarified what I meant regarding botnets above. Regarding BIP38, like all automatic wallet generation procedures, the security of a BIP38 wallet depends on the security of the endpoint generating it, which is not a trivial problem for users to solve. We integrate a BIP38 paper wallet generation tool into BitKey. It's very useful, but I tell people if they don't trust us, our build process and/or their ability to independently verify the integrity of the software, they might want to use something else instead they don't have to trust. Trust-minimized solutions are better than solutions that require trust. I think that was the one of the key innovations Bitcoin/blockchain introduced: http://nakamotoinstitute.org/trusted-third-parties/</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62196User talk:Ryanc2017-01-25T13:51:56Z<p>Liraz: /* What about salting? */ In opposition to black and white thinking</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 5-8 mnemonic words (64 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 5-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 64 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 5 words, even with a strong KDF and salt, but 5 truly random words should be enough for anyone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 5 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice. With 5 random words a 250,000,000 brainflayer botnet generating 100 guesses a second (10X faster than you're currently getting) would take 12 years to crack an '''unsalted''' Warpwallet. Salting the Warpwallet would banish cryptographic attacks to the realm of science fiction.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure. <br />
<br />
* [[User:RyanC|RyanC]] You are wrong. The consensus on this from other experts is that you are wrong. Your recommendations will harm users. I've talked to several otherwise smart people who have lost painfully large sums of money to various deterministic wallet tools. Such tools are a trap for people who are smart, but don't quite understand how effective password cracking can be. Many people think they do, but there is a lot of bad advice about passwords and passphrases out there. I personally have used passphrases in the past for things like GPG keys that would have gotten me 0wned if I'd used them even in WarpWallet. I'm done arguing with you, it's clearly not productive. Please talk with some of the Bitcoin developers about this if you still don't believe me. Please also understand how incredibly frustrating it is to have seen firsthand how much damage tools like this can cause their typical users (a paper was published about this), and then have people say "oh, but it's fine if I use it perfectly, so it's okay for everyone". If you want to use it, I can't stop you, but recommending these tools to random newbies is gross negligence. I also want to point out that it's a bit absurd to recommend hardware wallets if you categorically don't trust CSPRNGs. Why are their CSPRNGs trustworthy and others not?<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 23:45, 24 January 2017 (UTC)<br />
# I'd like to point out you are so fixated on only one branch of the attack tree that you're not seeing how your argument could apply equally well to the other branch that you dismiss a "tinfoil hat threat" despite massive real-world evidence to the contrary. I could rephrase your comment: "You are wrong. The consensus on endpoint security experts are that you are wrong, and your recommendations to just trust endpoint software is gross negligence that will end up hurting users. If you don't believe me go talk to another expert on endpoint security. Oh but it's fine for me if I setup a perfectly secure endpoint, so it's OK for everybody. Automatic wallet generation on untrusted endpoint are a trap for smart people who don't understand how effective endpoint comprimising techniques are at subverting the integrity of their system in endlessly creative ways". My argument isn't that "my" threat is more important that "your" threat. My argument is that both threats are substantial and that I don't think we should dismiss either of them. If there's a tradeoff to be made where mitigating one risk comes at the expense of mitigating another we need to find the right balance to make a wise choice. Seeing things in black and white, your camp vs my camp, as an argument to be won, that's an all too human but very dangerous an unproductive attitude for a security expert to take.<br />
# Trustworthy is a probability not a binary value. Convenience is also a matter of degree. There's an inescapable trade-off. You can say: As an expert, I recommend you hold up to $100 in your pocket, up to $10000 in a steel vault and the rest in stocks or whatever. You'd be right to criticize my position if I was being simple minded to the point of absurdity. If I somehow miscommunicated that impression, I wouldn't blame you for feeling like there's no point in talking to this idiot.<br />
# For the record, Hardware CSPRNGs are no more trustworthy, if anything I trust them even less because they're such high value targets. That's why I limit their use to relatively small sums. Great for day-to-day use though. Very convenient. But I'm anticipating to wake up one day and learn a whole bunch of wallets got their funds swept and we eventually trace that back to weak/weakened wallet creation. I hope I'll be proven wrong but in the meantime, like you, I'm trying to help users minimize their exposure.<br />
# Before I sign off and stop troubling you with unwanted discussion, I just wanted to express my appreciation for the time you've taken to explain your position, the efforts to protect users and also that you went public with your research and didn't use it to run another botnet. You're a philanthropist. I've been benefiting from your advice and have been spreading it to anyone foolish enough to consider using SHA256 brainwallets. I've even done experiments with leaving various amounts of funds in SHA256 brainwallets just to see what would happen and have seen them grabbed with my own eyes. I never meant to downplay your research or imply that brainwallet stealing botnets don't exist. They obviously do and it's important to take that risk into account. If there's a gap in our understanding I think it's due each of us spending more time researching different classes of threats. I used to work with the military and spent a good chunk of my life researching sophisticated malware. Endpoint security risks looms ever large in my mind. I guess that makes me atypically skeptical of claims of system integrity. I imagine for you the risk of users choosing bad passwords/passphrases, having cracked so many of them seems to deserve more of an emphasis. <br />
# Sorry you feel the discussion was unproductive. If I've rubbed you the wrong way I apologize. FWIW, I found it productive.You've also convinced me that Warpwallet makes it too easy to avoid salting and the default should be changed. I'll try to get a patch through. I'll also be updating my recommendations on the resources I control to stress that the salt is mandatory and that using Warpwallet is unsafe without it.<br />
# We both agree that the threats are real and significant, we just place different weights on them. Before our correspondence it was my understanding that ROI for attacking '''salted''' warpwallets was so low that it would make the operation of a botnet most likely unprofitable. I don't think we disagree on that. I think we might disagree on the optimal set of trade-offs to factor into our recommendations to non-experts where protecting against one risk necessarily weakens protection against another. We agree that salts are essential and should be mandatory, key stretching adds security but isn't a silver bullet, humans are bad as sources of entropy, end-point security is really hard, blindly trusting RNGs is unwise, Warpwallet being a PITA to use and a privacy risk to use as your main wallet, and that your research is very important it and you're doing the Bitcoin community a huge service being an advocate against unsafe practices. That's a lot of common ground. Nice chatting with you Ryan (for me anyhow).<br />
<br />
** [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:49, 24 January 2017 (UTC) I mean, it boggles my mind how worried we are about losing Warpwallets <s>coins</s> to exotic risks such as Bitflayer botnets with millions of nodes, and meanwhile, the standard recommendation is to:<br />
# Trust endpoints that can and have been compromised in endlessly creative ways<br />
# Get that endpoint to create a hard to remember seed for your wallet<br />
# Write down the seed on a piece of paper(!), that can be lost, stolen, burned, or water-logged<br />
<br />
If worst comes to worse and the government, or criminals or whatever are looking for your coins, they'll ransack your house and bank vaults, find that piece of paper and all of our sophisticated crypto goes up in smoke. I think the future will look back to us and laugh: secrets are meant to be remembered, not written down!<br />
<br />
* [[User:RyanC|RyanC]] People run these botnets already! I gave a talk last summer, one of the bots robbed our bait wallet live on stage! This problem is solved trivially with BIP38 paper wallets. Risk of loss can be mitigated by making multiple copies and storing them in different locations. Requiring adversaries to steal your paper wallet and crack the passphrase is better than publishing what is effectively a hash of your passphrase and hoping for the best.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 00:01, 25 January 2017 (UTC) Clarified what I meant regarding botnets above. Regarding BIP38, like all automatic wallet generation procedures, the security of a BIP38 wallet depends on the security of the endpoint generating it, which is not a trivial problem for users to solve. We integrate a BIP38 paper wallet generation tool into BitKey. It's very useful, but I tell people if they don't trust us, our build process and/or their ability to independently verify the integrity of the software, they might want to use something else instead they don't have to trust. Trust-minimized solutions are better than solutions that require trust. I think that was the one of the key innovations Bitcoin/blockchain introduced: http://nakamotoinstitute.org/trusted-third-parties/</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62195User talk:Ryanc2017-01-25T13:16:55Z<p>Liraz: /* Another reply */ On second thought, 5 words should be the minimum, juuuust in case</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 5-8 mnemonic words (64 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 5-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 64 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 5 words, even with a strong KDF and salt, but 5 truly random words should be enough for anyone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 5 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice. With 5 random words a 250,000,000 brainflayer botnet generating 100 guesses a second (10X faster than you're currently getting) would take 12 years to crack an '''unsalted''' Warpwallet. Salting the Warpwallet would banish cryptographic attacks to the realm of science fiction.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure. <br />
<br />
* [[User:RyanC|RyanC]] You are wrong. The consensus on this from other experts is that you are wrong. Your recommendations will harm users. I've talked to several otherwise smart people who have lost painfully large sums of money to various deterministic wallet tools. Such tools are a trap for people who are smart, but don't quite understand how effective password cracking can be. Many people think they do, but there is a lot of bad advice about passwords and passphrases out there. I personally have used passphrases in the past for things like GPG keys that would have gotten me 0wned if I'd used them even in WarpWallet. I'm done arguing with you, it's clearly not productive. Please talk with some of the Bitcoin developers about this if you still don't believe me. Please also understand how incredibly frustrating it is to have seen firsthand how much damage tools like this can cause their typical users (a paper was published about this), and then have people say "oh, but it's fine if I use it perfectly, so it's okay for everyone". If you want to use it, I can't stop you, but recommending these tools to random newbies is gross negligence. I also want to point out that it's a bit absurd to recommend hardware wallets if you categorically don't trust CSPRNGs. Why are their CSPRNGs trustworthy and others not?<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 23:45, 24 January 2017 (UTC) <br />
# Trustworthy is a probability not a binary value. Convenience is also a matter of degree. There's an inescapable trade-off. You can say: As an expert, I recommend you hold up to $100 in your pocket, up to $10000 in a steel vault and the rest in stocks or whatever. You'd be right to criticize my position if I was being simple minded to the point of absurdity. If I somehow miscommunicated that impression, I wouldn't blame you for feeling like there's no point in talking to this idiot.<br />
# For the record, Hardware CSPRNGs are no more trustworthy, if anything I trust them even less because they're such high value targets. That's why I limit their use to relatively small sums. Great for day-to-day use though. Very convenient. But I'm anticipating to wake up one day and learn a whole bunch of wallets got their funds swept and we eventually trace that back to weak/weakened wallet creation. I hope I'll be proven wrong but in the meantime, like you, I'm trying to help users minimize their exposure.<br />
# Before I sign off and stop troubling you with unwanted discussion, I just wanted to express my appreciation for the time you've taken to explain your position, the efforts to protect users and also that you went public with your research and didn't use it to run another botnet. You're a philanthropist. I've been benefiting from your advice and have been spreading it to anyone foolish enough to consider using SHA256 brainwallets. I've even done experiments with leaving various amounts of funds in SHA256 brainwallets just to see what would happen and have seen them grabbed with my own eyes. I never meant to downplay your research or imply that brainwallet stealing botnets don't exist. They obviously do and it's important to take that risk into account. If there's a gap in our understanding I think it's due each of us spending more time researching different classes of threats. I used to work with the military and spent a good chunk of my life researching sophisticated malware. Endpoint security risks looms ever large in my mind. I guess that makes me atypically skeptical of claims of system integrity. I imagine for you the risk of users choosing bad passwords/passphrases, having cracked so many of them seems to deserve more of an emphasis. <br />
# Sorry you feel the discussion was unproductive. If I've rubbed you the wrong way I apologize. FWIW, I found it productive.You've also convinced me that Warpwallet makes it too easy to avoid salting and the default should be changed. I'll try to get a patch through. I'll also be updating my recommendations on the resources I control to stress that the salt is mandatory and that using Warpwallet is unsafe without it.<br />
# We both agree that the threats are real and significant, we just place different weights on them. Before our correspondence it was my understanding that ROI for attacking '''salted''' warpwallets was so low that it would make the operation of a botnet most likely unprofitable. I don't think we disagree on that. I think we might disagree on the optimal set of trade-offs to factor into our recommendations to non-experts where protecting against one risk necessarily weakens protection against another. We agree that salts are essential and should be mandatory, key stretching adds security but isn't a silver bullet, humans are bad as sources of entropy, end-point security is really hard, blindly trusting RNGs is unwise, Warpwallet being a PITA to use and a privacy risk to use as your main wallet, and that your research is very important it and you're doing the Bitcoin community a huge service being an advocate against unsafe practices. That's a lot of common ground. Nice chatting with you Ryan (for me anyhow).<br />
<br />
** [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:49, 24 January 2017 (UTC) I mean, it boggles my mind how worried we are about losing Warpwallets <s>coins</s> to exotic risks such as Bitflayer botnets with millions of nodes, and meanwhile, the standard recommendation is to:<br />
# Trust endpoints that can and have been compromised in endlessly creative ways<br />
# Get that endpoint to create a hard to remember seed for your wallet<br />
# Write down the seed on a piece of paper(!), that can be lost, stolen, burned, or water-logged<br />
<br />
If worst comes to worse and the government, or criminals or whatever are looking for your coins, they'll ransack your house and bank vaults, find that piece of paper and all of our sophisticated crypto goes up in smoke. I think the future will look back to us and laugh: secrets are meant to be remembered, not written down!<br />
<br />
* [[User:RyanC|RyanC]] People run these botnets already! I gave a talk last summer, one of the bots robbed our bait wallet live on stage! This problem is solved trivially with BIP38 paper wallets. Risk of loss can be mitigated by making multiple copies and storing them in different locations. Requiring adversaries to steal your paper wallet and crack the passphrase is better than publishing what is effectively a hash of your passphrase and hoping for the best.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 00:01, 25 January 2017 (UTC) Clarified what I meant regarding botnets above. Regarding BIP38, like all automatic wallet generation procedures, the security of a BIP38 wallet depends on the security of the endpoint generating it, which is not a trivial problem for users to solve. We integrate a BIP38 paper wallet generation tool into BitKey. It's very useful, but I tell people if they don't trust us, our build process and/or their ability to independently verify the integrity of the software, they might want to use something else instead they don't have to trust. Trust-minimized solutions are better than solutions that require trust. I think that was the one of the key innovations Bitcoin/blockchain introduced: http://nakamotoinstitute.org/trusted-third-parties/</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62192User talk:Ryanc2017-01-25T00:08:59Z<p>Liraz: /* What about salting? */ clear up ambiguity</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 4-8 mnemonic words (52 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 4-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 52 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 4 words, even with a strong KDF and salt, but 4 truly random words should actually be enough for someone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 4 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure. <br />
<br />
* [[User:RyanC|RyanC]] You are wrong. The consensus on this from other experts is that you are wrong. Your recommendations will harm users. I've talked to several otherwise smart people who have lost painfully large sums of money to various deterministic wallet tools. Such tools are a trap for people who are smart, but don't quite understand how effective password cracking can be. Many people think they do, but there is a lot of bad advice about passwords and passphrases out there. I personally have used passphrases in the past for things like GPG keys that would have gotten me 0wned if I'd used them even in WarpWallet. I'm done arguing with you, it's clearly not productive. Please talk with some of the Bitcoin developers about this if you still don't believe me. Please also understand how incredibly frustrating it is to have seen firsthand how much damage tools like this can cause their typical users (a paper was published about this), and then have people say "oh, but it's fine if I use it perfectly, so it's okay for everyone". If you want to use it, I can't stop you, but recommending these tools to random newbies is gross negligence. I also want to point out that it's a bit absurd to recommend hardware wallets if you categorically don't trust CSPRNGs. Why are their CSPRNGs trustworthy and others not?<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 23:45, 24 January 2017 (UTC) <br />
# Trustworthy is a probability not a binary value. Convenience is also a matter of degree. There's an inescapable trade-off. You can say: As an expert, I recommend you hold up to $100 in your pocket, up to $10000 in a steel vault and the rest in stocks or whatever. You'd be right to criticize my position if I was being simple minded to the point of absurdity. If I somehow miscommunicated that impression, I wouldn't blame you for feeling like there's no point in talking to this idiot.<br />
# For the record, Hardware CSPRNGs are no more trustworthy, if anything I trust them even less because they're such high value targets. That's why I limit their use to relatively small sums. Great for day-to-day use though. Very convenient. But I'm anticipating to wake up one day and learn a whole bunch of wallets got their funds swept and we eventually trace that back to weak/weakened wallet creation. I hope I'll be proven wrong but in the meantime, like you, I'm trying to help users minimize their exposure.<br />
# Before I sign off and stop troubling you with unwanted discussion, I just wanted to express my appreciation for the time you've taken to explain your position, the efforts to protect users and also that you went public with your research and didn't use it to run another botnet. You're a philanthropist. I've been benefiting from your advice and have been spreading it to anyone foolish enough to consider using SHA256 brainwallets. I've even done experiments with leaving various amounts of funds in SHA256 brainwallets just to see what would happen and have seen them grabbed with my own eyes. I never meant to downplay your research or imply that brainwallet stealing botnets don't exist. They obviously do and it's important to take that risk into account. If there's a gap in our understanding I think it's due each of us spending more time researching different classes of threats. I used to work with the military and spent a good chunk of my life researching sophisticated malware. Endpoint security risks looms ever large in my mind. I guess that makes me atypically skeptical of claims of system integrity. I imagine for you the risk of users choosing bad passwords/passphrases, having cracked so many of them seems to deserve more of an emphasis. <br />
# Sorry you feel the discussion was unproductive. If I've rubbed you the wrong way I apologize. FWIW, I found it productive.You've also convinced me that Warpwallet makes it too easy to avoid salting and the default should be changed. I'll try to get a patch through. I'll also be updating my recommendations on the resources I control to stress that the salt is mandatory and that using Warpwallet is unsafe without it.<br />
# We both agree that the threats are real and significant, we just place different weights on them. Before our correspondence it was my understanding that ROI for attacking '''salted''' warpwallets was so low that it would make the operation of a botnet most likely unprofitable. I don't think we disagree on that. I think we might disagree on the optimal set of trade-offs to factor into our recommendations to non-experts where protecting against one risk necessarily weakens protection against another. We agree that salts are essential and should be mandatory, key stretching adds security but isn't a silver bullet, humans are bad as sources of entropy, end-point security is really hard, blindly trusting RNGs is unwise, Warpwallet being a PITA to use and a privacy risk to use as your main wallet, and that your research is very important it and you're doing the Bitcoin community a huge service being an advocate against unsafe practices. That's a lot of common ground. Nice chatting with you Ryan (for me anyhow).<br />
<br />
** [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:49, 24 January 2017 (UTC) I mean, it boggles my mind how worried we are about losing Warpwallets <s>coins</s> to exotic risks such as Bitflayer botnets with millions of nodes, and meanwhile, the standard recommendation is to:<br />
# Trust endpoints that can and have been compromised in endlessly creative ways<br />
# Get that endpoint to create a hard to remember seed for your wallet<br />
# Write down the seed on a piece of paper(!), that can be lost, stolen, burned, or water-logged<br />
<br />
If worst comes to worse and the government, or criminals or whatever are looking for your coins, they'll ransack your house and bank vaults, find that piece of paper and all of our sophisticated crypto goes up in smoke. I think the future will look back to us and laugh: secrets are meant to be remembered, not written down!<br />
<br />
* [[User:RyanC|RyanC]] People run these botnets already! I gave a talk last summer, one of the bots robbed our bait wallet live on stage! This problem is solved trivially with BIP38 paper wallets. Risk of loss can be mitigated by making multiple copies and storing them in different locations. Requiring adversaries to steal your paper wallet and crack the passphrase is better than publishing what is effectively a hash of your passphrase and hoping for the best.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 00:01, 25 January 2017 (UTC) Clarified what I meant regarding botnets above. Regarding BIP38, like all automatic wallet generation procedures, the security of a BIP38 wallet depends on the security of the endpoint generating it, which is not a trivial problem for users to solve. We integrate a BIP38 paper wallet generation tool into BitKey. It's very useful, but I tell people if they don't trust us, our build process and/or their ability to independently verify the integrity of the software, they might want to use something else instead they don't have to trust. Trust-minimized solutions are better than solutions that require trust. I think that was the one of the key innovations Bitcoin/blockchain introduced: http://nakamotoinstitute.org/trusted-third-parties/</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62191User talk:Ryanc2017-01-25T00:01:10Z<p>Liraz: /* What about salting? */ BIP38 clarification</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 4-8 mnemonic words (52 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 4-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 52 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 4 words, even with a strong KDF and salt, but 4 truly random words should actually be enough for someone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 4 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure. <br />
<br />
* [[User:RyanC|RyanC]] You are wrong. The consensus on this from other experts is that you are wrong. Your recommendations will harm users. I've talked to several otherwise smart people who have lost painfully large sums of money to various deterministic wallet tools. Such tools are a trap for people who are smart, but don't quite understand how effective password cracking can be. Many people think they do, but there is a lot of bad advice about passwords and passphrases out there. I personally have used passphrases in the past for things like GPG keys that would have gotten me 0wned if I'd used them even in WarpWallet. I'm done arguing with you, it's clearly not productive. Please talk with some of the Bitcoin developers about this if you still don't believe me. Please also understand how incredibly frustrating it is to have seen firsthand how much damage tools like this can cause their typical users (a paper was published about this), and then have people say "oh, but it's fine if I use it perfectly, so it's okay for everyone". If you want to use it, I can't stop you, but recommending these tools to random newbies is gross negligence. I also want to point out that it's a bit absurd to recommend hardware wallets if you categorically don't trust CSPRNGs. Why are their CSPRNGs trustworthy and others not?<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 23:45, 24 January 2017 (UTC) <br />
# Trustworthy is a probability not a binary value. Convenience is also a matter of degree. There's an inescapable trade-off. You can say: As an expert, I recommend you hold up to $100 in your pocket, up to $10000 in a steel vault and the rest in stocks or whatever. You'd be right to criticize my position if I was being simple minded to the point of absurdity. If I somehow miscommunicated that impression, I wouldn't blame you for feeling like there's no point in talking to this idiot.<br />
# For the record, Hardware CSPRNGs are no more trustworthy, if anything I trust them even less because they're such high value targets. That's why I limit their use to relatively small sums. Great for day-to-day use though. Very convenient. But I'm anticipating to wake up one day and learn a whole bunch of wallets got their funds swept and we eventually trace that back to weak/weakened wallet creation. I hope I'll be proven wrong but in the meantime, like you, I'm trying to help users minimize their exposure.<br />
# Before I sign off and stop troubling you with unwanted discussion, I just wanted to express my appreciation for the time you've taken to explain your position, the efforts to protect users and also that you went public with your research and didn't use it to run another botnet. You're a philanthropist. I've been benefiting from your advice and have been spreading it to anyone foolish enough to consider using SHA256 brainwallets. I've even done experiments with leaving various amounts of funds in SHA256 brainwallets just to see what would happen and have seen them grabbed with my own eyes. I never meant to downplay your research or imply that brainwallet stealing botnets don't exist. They obviously do and it's important to take that risk into account. If there's a gap in our understanding I think it's due each of us spending more time researching different classes of threats. I used to work with the military and spent a good chunk of my life researching sophisticated malware. Endpoint security risks looms ever large in my mind. I guess that makes me atypically skeptical of claims of system integrity. I imagine for you the risk of users choosing bad passwords/passphrases, having cracked so many of them seems to deserve more of an emphasis. <br />
# Sorry you feel the discussion was unproductive. If I've rubbed you the wrong way I apologize. FWIW, I found it productive.You've also convinced me that Warpwallet makes it too easy to avoid salting and the default should be changed. I'll try to get a patch through. I'll also be updating my recommendations on the resources I control to stress that the salt is mandatory and that using Warpwallet is unsafe without it.<br />
# We both agree that the threats are real and significant, we just place different weights on them. Before our correspondence it was my understanding that ROI for attacking '''salted''' warpwallets was so low that it would make the operation of a botnet most likely unprofitable. I don't think we disagree on that. I think we might disagree on the optimal set of trade-offs to factor into our recommendations to non-experts where protecting against one risk necessarily weakens protection against another. We agree that salts are essential and should be mandatory, key stretching adds security but isn't a silver bullet, humans are bad as sources of entropy, end-point security is really hard, blindly trusting RNGs is unwise, Warpwallet being a PITA to use and a privacy risk to use as your main wallet, and that your research is very important it and you're doing the Bitcoin community a huge service being an advocate against unsafe practices. That's a lot of common ground. Nice chatting with you Ryan (for me anyhow).<br />
<br />
** [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:49, 24 January 2017 (UTC) I mean, it boggles my mind how worried we are about losing coints to exotic risks such as Bitflayer botnets with millions of nodes, and meanwhile, the standard recommendation is to:<br />
# Trust endpoints that can and have been compromised in endlessly creative ways<br />
# Get that endpoint to create a hard to remember seed for your wallet<br />
# Write down the seed on a piece of paper(!), that can be lost, stolen, burned, or water-logged<br />
<br />
If worst comes to worse and the government, or criminals or whatever are looking for your coins, they'll ransack your house and bank vaults, find that piece of paper and all of our sophisticated crypto goes up in smoke. I think the future will look back to us and laugh: secrets are meant to be remembered, not written down!<br />
<br />
* [[User:RyanC|RyanC]] People run these botnets already! I gave a talk last summer, one of the bots robbed our bait wallet live on stage! This problem is solved trivially with BIP38 paper wallets. Risk of loss can be mitigated by making multiple copies and storing them in different locations. Requiring adversaries to steal your paper wallet and crack the passphrase is better than publishing what is effectively a hash of your passphrase and hoping for the best.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 00:01, 25 January 2017 (UTC) Clarified what I meant regarding botnets above. Regarding BIP38, like all automatic wallet generation procedures, the security of a BIP38 wallet depends on the security of the endpoint generating it, which is not a trivial problem for users to solve. We integrate a BIP38 paper wallet generation tool into BitKey. It's very useful, but I tell people if they don't trust us, our build process and/or their ability to independently verify the integrity of the software, they might want to use something else instead they don't have to trust. Trust-minimized solutions are better than solutions that require trust. I think that was the one of the key innovations Bitcoin/blockchain introduced: http://nakamotoinstitute.org/trusted-third-parties/</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62190User talk:Ryanc2017-01-24T23:45:50Z<p>Liraz: OK, thanks anyway</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 4-8 mnemonic words (52 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 4-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 52 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 4 words, even with a strong KDF and salt, but 4 truly random words should actually be enough for someone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 4 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure. <br />
<br />
* [[User:RyanC|RyanC]] You are wrong. The consensus on this from other experts is that you are wrong. Your recommendations will harm users. I've talked to several otherwise smart people who have lost painfully large sums of money to various deterministic wallet tools. Such tools are a trap for people who are smart, but don't quite understand how effective password cracking can be. Many people think they do, but there is a lot of bad advice about passwords and passphrases out there. I personally have used passphrases in the past for things like GPG keys that would have gotten me 0wned if I'd used them even in WarpWallet. I'm done arguing with you, it's clearly not productive. Please talk with some of the Bitcoin developers about this if you still don't believe me. Please also understand how incredibly frustrating it is to have seen firsthand how much damage tools like this can cause their typical users (a paper was published about this), and then have people say "oh, but it's fine if I use it perfectly, so it's okay for everyone". If you want to use it, I can't stop you, but recommending these tools to random newbies is gross negligence. I also want to point out that it's a bit absurd to recommend hardware wallets if you categorically don't trust CSPRNGs. Why are their CSPRNGs trustworthy and others not?<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 23:45, 24 January 2017 (UTC) <br />
# Trustworthy is a probability not a binary value. Convenience is also a matter of degree. There's an inescapable trade-off. You can say: As an expert, I recommend you hold up to $100 in your pocket, up to $10000 in a steel vault and the rest in stocks or whatever. You'd be right to criticize my position if I was being simple minded to the point of absurdity. If I somehow miscommunicated that impression, I wouldn't blame you for feeling like there's no point in talking to this idiot.<br />
# For the record, Hardware CSPRNGs are no more trustworthy, if anything I trust them even less because they're such high value targets. That's why I limit their use to relatively small sums. Great for day-to-day use though. Very convenient. But I'm anticipating to wake up one day and learn a whole bunch of wallets got their funds swept and we eventually trace that back to weak/weakened wallet creation. I hope I'll be proven wrong but in the meantime, like you, I'm trying to help users minimize their exposure.<br />
# Before I sign off and stop troubling you with unwanted discussion, I just wanted to express my appreciation for the time you've taken to explain your position, the efforts to protect users and also that you went public with your research and didn't use it to run another botnet. You're a philanthropist. I've been benefiting from your advice and have been spreading it to anyone foolish enough to consider using SHA256 brainwallets. I've even done experiments with leaving various amounts of funds in SHA256 brainwallets just to see what would happen and have seen them grabbed with my own eyes. I never meant to downplay your research or imply that brainwallet stealing botnets don't exist. They obviously do and it's important to take that risk into account. If there's a gap in our understanding I think it's due each of us spending more time researching different classes of threats. I used to work with the military and spent a good chunk of my life researching sophisticated malware. Endpoint security risks looms ever large in my mind. I guess that makes me atypically skeptical of claims of system integrity. I imagine for you the risk of users choosing bad passwords/passphrases, having cracked so many of them seems to deserve more of an emphasis. <br />
# Sorry you feel the discussion was unproductive. If I've rubbed you the wrong way I apologize. FWIW, I found it productive.You've also convinced me that Warpwallet makes it too easy to avoid salting and the default should be changed. I'll try to get a patch through. I'll also be updating my recommendations on the resources I control to stress that the salt is mandatory and that using Warpwallet is unsafe without it.<br />
# We both agree that the threats are real and significant, we just place different weights on them. Before our correspondence it was my understanding that ROI for attacking '''salted''' warpwallets was so low that it would make the operation of a botnet most likely unprofitable. I don't think we disagree on that. I think we might disagree on the optimal set of trade-offs to factor into our recommendations to non-experts where protecting against one risk necessarily weakens protection against another. We agree that salts are essential and should be mandatory, key stretching adds security but isn't a silver bullet, humans are bad as sources of entropy, end-point security is really hard, blindly trusting RNGs is unwise, Warpwallet being a PITA to use and a privacy risk to use as your main wallet, and that your research is very important it and you're doing the Bitcoin community a huge service being an advocate against unsafe practices. That's a lot of common ground. Nice chatting with you Ryan (for me anyhow).<br />
<br />
** [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:49, 24 January 2017 (UTC) I mean, it boggles my mind how worried we are about losing coints to exotic risks such as Bitflayer botnets with millions of nodes, and meanwhile, the standard recommendation is to:<br />
# Trust endpoints that can and have been compromised in endlessly creative ways<br />
# Get that endpoint to create a hard to remember seed for your wallet<br />
# Write down the seed on a piece of paper(!), that can be lost, stolen, burned, or water-logged<br />
<br />
If worst comes to worse and the government, or criminals or whatever are looking for your coins, they'll ransack your house and bank vaults, find that piece of paper and all of our sophisticated crypto goes up in smoke. I think the future will look back to us and laugh: secrets are meant to be remembered, not written down!<br />
<br />
* [[User:RyanC|RyanC]] People run these botnets already! I gave a talk last summer, one of the bots robbed our bait wallet live on stage! This problem is solved trivially with BIP38 paper wallets. Risk of loss can be mitigated by making multiple copies and storing them in different locations. Requiring adversaries to steal your paper wallet and crack the passphrase is better than publishing what is effectively a hash of your passphrase and hoping for the best.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62188User talk:Ryanc2017-01-24T17:50:09Z<p>Liraz: /* What about salting? */</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 4-8 mnemonic words (52 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 4-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 52 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 4 words, even with a strong KDF and salt, but 4 truly random words should actually be enough for someone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 4 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure. <br />
<br />
** [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:49, 24 January 2017 (UTC) I mean, it boggles my mind how worried we are about losing coints to exotic risks such as Bitflayer botnets with millions of nodes, and meanwhile, the standard recommendation is to:<br />
# Trust endpoints that can and have been compromised in endlessly creative ways<br />
# Get that endpoint to create a hard to remember seed for your wallet<br />
# Write down the seed on a piece of paper(!), that can be lost, stolen, burned, or water-logged<br />
<br />
If worst comes to worse and the government, or criminals or whatever are looking for your coins, they'll ransack your house and bank vaults, find that piece of paper and all of our sophisticated crypto goes up in smoke. I think the future will look back to us and laugh: secrets are meant to be remembered, not written down!</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62187User talk:Ryanc2017-01-24T17:49:05Z<p>Liraz: /* What about salting? */</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 4-8 mnemonic words (52 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 4-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 52 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 4 words, even with a strong KDF and salt, but 4 truly random words should actually be enough for someone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 4 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure. <br />
<br />
** [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:49, 24 January 2017 (UTC) I mean, it boggles my mind how worried we are about losing coints to exotic risks such as Bitflayer botnets with millions of nodes, and meanwhile, the standard recommendation is to:<br />
# Trust endpoints that can and have been compromised in endlessly creative ways<br />
# Get that endpoint to create a hard to remember seed for your wallet<br />
# Write down the seed on a piece of paper(!), that can be lost, stolen, burned, or water-logged<br />
<br />
If worst comes to worse and the government, or criminals or whatever are looking for your coins, they'll ransack your house and bank vaults, find that piece of paper and all of our sophisticated crypto goes up in smoke. I think the future will look back to us and laugh: secrets are meant to be remembered, not written down!<br />
<br />
<br />
# Write it down to <br />
these terribly untrustworthy end-points to computer</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62186User talk:Ryanc2017-01-24T17:35:02Z<p>Liraz: /* What about salting? */</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 4-8 mnemonic words (52 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 4-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 52 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 4 words, even with a strong KDF and salt, but 4 truly random words should actually be enough for someone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 4 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62185User talk:Ryanc2017-01-24T17:34:21Z<p>Liraz: /* What about salting? */ Warpwallet good for some things, not everything</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 4-8 mnemonic words (52 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 4-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 52 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 4 words, even with a strong KDF and salt, but 4 truly random words should actually be enough for someone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 4 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:34, 24 January 2017 (UTC) For sure, it isn't a good tool to use for your main wallet. That was not my recommendation. Neither is a paper wallet. For my main day-to-day wallet I use (and recommend) a hardware wallet. Partially spending Warpwallet isn't as convenient or efficient, but it's not that much different in that respect from other cold storage transactions. In practice, it takes a few seconds of additional work relative to a standard cold storage transaction. I've documented that workflow on bitkey.io if you're interested. My point is that even in it's current form it's a useful way to place funds in cold storage. The concept of a Brainwallet is actually a pretty good one in my opinion. Encouraging people to backup their wallets in paper (which most wallets do) opens a whole other can of worms. I find it hard to believe we would be doing that if we had a decent easy to remember alternative that wasn't pitifully insecure.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62184User talk:Ryanc2017-01-24T17:30:04Z<p>Liraz: /* What about salting? */ salting should be mandatory - agreed</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 4-8 mnemonic words (52 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 4-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 52 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 4 words, even with a strong KDF and salt, but 4 truly random words should actually be enough for someone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 4 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:30, 24 January 2017 (UTC) FWIW, I agree that WarpWallet should make the salting mandatory, or at least the default. I'll look into patching that myself and trying to get them to accept that.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62183User talk:Ryanc2017-01-24T17:20:50Z<p>Liraz: /* Another reply */ thoughts on improving key generation techniques</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
* [[User:RyanC|RyanC]] Because the dice might be biased, so it's hard to be sure how many is enough, and some foolish person will make up their own die rolls because rolling a die 50 times is too hard. If you display the process output of the die rolls along with the CSPRNG output (generated before the die rolls to shut down any tinfoil hattery about the CSPRNG being malicious adaptively) and xor the two together to output the keys, behavior can be validated.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 17:20, 24 January 2017 (UTC) <br />
# I really like your idea, though I would implement it differently because I'm not much good at doing XOR in my head, and the more friction something involves the less likely I am to do it. I do agree that creating a user-verifiable key generation tool could blend the best of both manual and automatic entropy. That could be a good default and a real improvement to existing key generation techniques. I'm thinking there's a good way to implement that which would feature the best of what I like about Warpwallets and HD wallets. There would be two steps. First, we would have an entropy collection step that we can reproduce and verify in a deterministic way. For example our tool generates 4-8 mnemonic words (52 - 104 bits) from the CSPRNG and then prompts the user for N additional bits of entropy, using a tool like zxcvbn to measure the entropy. We don't need to XOR, we can just append the manually entropy to the computer entropy. From that we generate a new mnemonic 4-8 word code. The output is deterministic so we could have another mode that allows us to repeat and verify the result, for the "tinfoil" crowd. If it's malware at least it's deterministic malware. Different implementations in different languages running on different platforms could be compared for bonus tinfoil-hat points. Now that we have 52 - 104 bits of entropy, we can use the warpwallet algorithm WITH a mandatory salt to generate the final 12 word BIP39 key. I'd get more tinfoil points for suggesting we force users to seed the wallet with more than 4 words, even with a strong KDF and salt, but 4 truly random words should actually be enough for someone who isn't holding huge sums in their wallet, and we should balance the risk of theft from monster botnets with the much more banal and routine risk of misplacing/exposing your paper wallet and/or forgetting a long mnemonic. If a to-be-stretched-and-salted seed is just 4 words, users are much more likely to store it successfully in their heads, ALA XKCD. For more high risk wallets, 6-8 seed words would be more appropriate, so that could be a choice.<br />
# The above scheme wouldn't be idiot proof (I believe that's an impossible goal), but it would be more idiot proof than either letting a potentially unfaithful wallet/RNG generate keys for you or trusting the user to do enough die rolls. I also think that user stupidity is something we could a lot to mitigate with a good UX embedding educational elements and an interface that doesn't encourage the user to cheat themselves. <br />
# If someone is rolling dice instead of letting the computer generate the seed for them, they're probably already quite a bit more informed regarding the risks <br />
# Biased dice provide less entropy, but they still provide some. The higher the bias, the less entropy we're getting out of each dice roll, the higher the likelyhood someone is going to notice the bias so there's a natural balance there that would mitigate the most aggressive abuses. <br />
# Even without mixing in computer generated entropy, we can compensate for loaded dice by adding more dice rolls, stretching the entropy with an even stronger KDF (e.g., using a native implementation of scrypt running for longer), mixing-in an e-mail salt and/or distributing instructions for testing the fairness of dice so at least some experts will detect and warn the community regarding exploitable shenanigans. The result will still be deterministic so you could run the technique using multiple implementations, on multiple platforms, and if you get the same result you're probably safe, even without doing the math by by hand.<br />
# I don't think it's fair to call the concern from sophisticated malware tinfoil asshattery. I agree that excessive security concerns are a net-loss, not a net-gain, especially if they just encourage users to subvert the security. But worrying about the wrong things while ignoring real risks is another way you get less security. End-point security is the bane of security and the Achilles heal of encryption schemes. Security is only as strong as it's weakest link and the crypto is usually not the weakest link. Schneier gave the analogy of an armored truck transporting valuables between two park benches. Case in point, Snowden leaks didn't reveal the NSA was using QC or alien crypto-analysis to break civilian crypto schemes. It revealed TAO compromising end-point security by hook and crook. People were distracting themselves looking under the crypto streetlamp - discussing the relative merits of a 1024 PGP key vs a 2048 PGP key. If you suspect someone might be spending hundreds of millions to break your security you should probably shore up your defenses where they are weakest and implement extreme SecOps, not refine your crypto schemes on relatively poorly secured endpoints.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet uses an asynchronous scrypt implementation. Every time the progress bar updates is several milliseconds where computations were not being done.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
* [[User:RyanC|RyanC]] The hardware cost estimates in the scrypt paper aren't terribly relevant. Nobody's going to build ASICs to crack brainwallets or warpwallets - the hardware costs are too high and the payoff too uncertain. I have yet to see even a GPU implementation of elliptic curve public key generation (no, that is not what oclvanitygen does), let alone an FPGA one. What has been implemented on GPU is elliptic curve point addition, but that's only about one order of magnitude more efficient than on CPU from the benchmarks I've done.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.<br />
<br />
* [[User:RyanC|RyanC]] WarpWallet allows an empty salt, and that is the default. Get them to accept a patch that makes it abundantly clear how bad it is not to use a salt, and then we can talk about the security it adds. Attacking a thing that I have seen people do is not a strawman. We should make better tools that make insecure usage difficult.<br />
<br />
[[User:RyanC|RyanC]]<br />
<br />
Even aside from the entropy issue, WarpWallet isn't a good tool. It generates uncompressed addresses and keys which are more expensive to use. It has no built-in scheme for multiple addresses. Partially spending a WarpWallet requires tedious manual transaction work of the sort that people can and do screw up.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Luke-jr&diff=62180User talk:Luke-jr2017-01-24T14:07:56Z<p>Liraz: /* Weighing in on my discussion with RyanC */ new section</p>
<hr />
<div>* My comments on [[Tonal Bitcoin]] are not "trolling". They are my opinions, and you can discuss it on the talk page based on the merits. If you delete my comments again from a discuss page, I will ask the administrators to ban your account. That is not acceptable wikipedia behavior [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]])<br />
<br />
== Thanks for helping on the [[Heaven Sent Gaming]] article. ==<br />
<br />
The bias was sloppy copyediting on my part, thanks for fixing it. [[User:Anon y Mouse|Anon y Mouse]] ([[User talk:Anon y Mouse|talk]]) 10:55, 24 August 2014 (UTC)<br />
<br />
== Headers ==<br />
<br />
Hi Luke, can you restore the [[Headers]] article please? It was useful for finding information about headers, and it's not obvious where people need to go without this reference article. There's already an article for [[block]]s, so I don't see why you needed to delete this, since it was useful.<br />
<br />
: There was no useful information, it was just a stub. Furthermore, headers are not a thing, they are just a part of a block... --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 21:03, 5 September 2014 (UTC)<br />
<br />
== deep web ==<br />
<br />
Luke-jr, bitcoin and deep web is closely related, as I previosly said... Your wiki contains bitcoin services as well as hidden wiki, it is only info ( nothing illegal) [[User:TheHiddenWiki|TheHiddenWiki]] ([[User talk:TheHiddenWiki|talk]]) 14:53, 11 September 2014 (UTC)<br />
<br />
== 247exchange ==<br />
<br />
Hello Luke,<br />
is it possible to list our exchange service 247exchange.com here please: https://en.bitcoin.it/wiki/Buying_Bitcoins_(the_newbie_version)?<br />
We accept credit/debit cards (Visa, MasterCard, Maestro) for instant buying Bitcoin. SWIFT and SEPA bank transfers are also accepted. All countries except USA (where we don't have the licenses yet) are supported.<br />
Our exchange is licensed, secure and easy-to-use.<br />
Thanks in advance!<br />
<br />
== Weighing in on my discussion with RyanC ==<br />
<br />
Hi Luke, I've been discussing the pros/cons of Warpwallets with Ryan Castelluci on his [[User talk:Ryanc|talk page]]. Could you share your analysis? <br />
<br />
It's a long discussion so to reiterate my position: <br />
<br />
1) There is a [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ real problem] with the faithfulness of blackbox RNGs that is hard to solve. RyanC agrees with me on that point.<br />
<br />
2) It's unwise to trust systems we can't verify when the stakes are high. For example, we can recommend users verify they're running a trustworthy wallet on a clean computer. Sounds great but if you really want to be sure that's very hard even for an expert. We can recommend they verify their wallet is actually (not just "supposed to", according to the source) using a faithful CSPRNG to generate the seed but '''nobody''' knows how to do that.<br />
<br />
3) What I like about Warpwallet is that it provides a unique blend of [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ simplicity with security].<br />
<br />
It's not idiot proof, but none of the other solutions are either. For some use cases it's a genuinely better recommendation than the more traditional alternatives, and if that's true we owe it to the non-experts who look up to us not to parrot old advice. When a new technique comes along, let's think it through. <br />
<br />
We also need to accept that different solutions have relative advantages and trade-offs. Computer security is hard. There's no way around nuance. There are no absolutes. Nothing we recommend will fully protect users from being stupid or negligent. Some users will always choose the dancing pigs. <br />
<br />
We can recommend they don't store large amounts in hot wallets, but they'll do that anyway. We can recommend they don't backup their "encrypted" wallet to the cloud, but of course they will. We can recommend a random passphrase and they'll use something from a dictionary or a famous quote. We can recommend they pay more for a hardware wallet from a trustworthy source, they won't be able to tell who's trustworthy and they'll just opt to pay less. They're lose their paper backups to the cleaning lady, fire and flood. They will forget their encryption passwords.<br />
<br />
We don't respond to that by treating everyone like stupid irresponsible babies. We accept personal responsibility and give those that want it the best advice we have.<br />
<br />
4) Warpwallet is mostly guilty by association with naive SHA256 Brainwallets. Putting the SHA256 technique in anything with a web interface was like leaving a loaded gun around. Of course people got hurt and that's tragic.<br />
<br />
I understand why the natural reaction to that is just to taboo the whole brainwallet concept after that, but using extreme key stretching together with salting is something qualitatively different.<br />
<br />
You can't just cut and paste the SHA256 brainwallet public service announcement on to the new thing because the stupid thing came first. That would be like giving SHA256 brainwallets a pass if Warpwallet came first. The devil is in the details. We need to re-evaluate based on evidence. Warpwallet changes the cost of attack so that there's no longer a weak central point of failure users are known to be notoriously bad at.<br />
<br />
Case in point, the Warpwallet challenge offered a $20,000 jackpot to crack an intentionally weak 8-character unsalted wallet and survived unclaimed for 2.5 years. RyanC has argued a large botnet running his software could crack the challenge in a year or so and I hope someone does that to prove him right.<br />
<br />
But if the challenge was modified to use an unknown e-mail salt, Ryanc's Brainflayer running on a 25M node botnet would never find it. The universe would end first. If Warpwallet challenge included a list of 1000 possible e-mail salts, it would take the botnet 9 years to crack. To search 10,000 suspected e-mail salts: 90 years. That's not my opinion, that's math.<br />
<br />
Maybe I'm missing something, but my conclusion is that if you use Warpwallet with a pretty good passphrase and your e-mail as salt, you're much more likely to get your coins stolen by someone beating you over the head with a $5 wrench than a Brainflayer botnet with millions of nodes running for decades.<br />
<br />
Don't you agree? If not, that's fine, but please help me understand why.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62179User talk:Ryanc2017-01-24T04:06:39Z<p>Liraz: /* Another reply */ Why mix in the CSPRNG at all?</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
* [[User:Liraz|Liraz]] ([[User talk:Liraz|talk]]) 04:06, 24 January 2017 (UTC) Why not just generate the BIP39 mnemonic directly from the 50 die rolls? Why use the CSPRNG at all? As soon as you mix in the CSPRNG the output of the program is no longer deterministic making it harder to verify that it is operating faithfully. If 50 die rolls provide sufficient entropy, let's just use that.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62178User talk:Ryanc2017-01-24T03:59:20Z<p>Liraz: /* What about salting? */ new section</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.<br />
<br />
== What about salting? ==<br />
<br />
You haven't responded to your thoughts on salting at all. Without salting I would agree that Warpwallet is just a slower to compute improvement of the bitaddress style brainwallet. With salting, it's something qualitatively different. The Warpwallet challenge used an unsalted passphrase to make a point, but criticizing the weakened version is attacking a straw man.<br />
<br />
To illustrate, a 25M Brainflayer botnet cracking Warpwallets at 10 guesses/sec could search through 52 bits of unsalted entropy in a year. Now spread that power over 1000 target e-mails (e.g., suspected warpwallet holders) and searching the space takes 1000 years.<br />
<br />
If the Warpwallet 8-alphanumeric challenge was on an unknown salt, Brainflayer would never find it. If the challenge included a list of 1000 e-mails, it would take about 9 years to crack. To search 10,000 suspect e-mails: 90 years.<br />
<br />
The economics of attacking salted/unsalted warpwallets are vastly different, and that's an important part of what Warpwallet brings to the table, but you're not addressing that.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62177User talk:Ryanc2017-01-24T03:39:10Z<p>Liraz: /* Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency */ new section</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.<br />
<br />
== Another reply ==<br />
<br />
The 10 keys per second is on a four core i7 that's about five years old, and is a real world number.<br />
<br />
The 60,000 times more expensive figure isn't a mistake. The same system that can do 10 warpwallet keys per second can do about 600k traditional brainwallet keys per second. The reason for this is that it's not just sha256 vs scrypt+pbkdf2 - the public key generation step must be taken into account and it is much, much slower than sha256. My code is available - https://rya.nc/brainflayer - run your own benchmarks if you find mine questionable.<br />
<br />
As far as the rest of your hypothetical math goes... that's assuming "perfect use". It falls apart once the tool gets into the hands of actual users.<br />
<br />
Most actual people don't know how to create a secure passphrase. Even if you tell them to use diceware, many of them will do something "clever" and still fail.<br />
<br />
There are great tools that are secure under "typical use" with mnemonics that can easily be memorized with a little work. Compared with that, why would you ever recommend the thing that has much weaker security when common usage mistakes are made?<br />
<br />
The only other real argument you've got here is about RNGs. Most popular wallets are now using deterministic nonces which dramatically reduce that problem. The key generation remains a risk (though a very tiny one). There is a simple solution to that. Write a tool that generates a BIP39 mnemonic (perhaps also allow electrum compatible output?) by combining CSPRNG output with a hash of the results of 50 die rolls. You get a securely generated seed that is possible to memorize so long as at least on of the entropy sources is good. If you'd like to write such a tool, I'd be happy to audit the code.<br />
<br />
== Brainflayer on CPUs not an upper bound on SHA256 brainwallet cracking efficiency ==<br />
<br />
I'm impressed (and somewhat surprised) that Brainflayer can do 10 warpwallet guesses/sec. That's at least an order of magnitude faster than the JS implementation. I would have guessed that the performance gap between code running on V8 and a compiled library would be smaller.<br />
<br />
Hard to argue with actual Brainflayer benchmarks, but I think Colin Percival had a point that a realistic estimate of how much scrypt was more expensive to crack would be to assume advanced cracking attempts would involve highly customized hardware. <br />
<br />
If you reimplemented Brainflayer to take advantage highly customized hardware you could probably crank up the number of SHA256 brainwallet passphrase guesses much faster you could crank up warpwallets passphrase attempts, including the public key generation step. I admit this is just a hunch, the difficulty of scaling up public key generation on custom hardware is not something I'm familiar with. I'm just assuming that this step wasn't designed to be difficult to accelerate in hardware, unlike scrypt.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62174User talk:Ryanc2017-01-24T01:55:49Z<p>Liraz: /* Warpwallet security analysis */</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
FWIW, as far as I can tell you made a huge mistake in your estimation of how much more difficult it is to calculate a warpwallet than a SHA256 brainwallet. You're calculation is off by 6 orders of magnitude. Warpwallet uses 524,288 iterations of scrypt + 131,072 iterations of PBKDF2. That is not 60,000 more expensive than calculating a SHA256 hashed brainwallet. It's closer to 100 billion times more expensive.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62173User talk:Ryanc2017-01-24T01:16:08Z<p>Liraz: /* Warpwallet security analysis */ new section</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/<br />
<br />
== Reply ==<br />
<br />
Yes, that is me. In my talk, my comment about WarpWallet was intended to mean "if you still want to do something like this, at least use warpwallet instead". I regret that it was not phrased more clearly. WarpWallet is merely a bad idea (without a seed, it's about 60,000 times more work to crack on CPU) rather than a catastrophically foolish one.<br />
<br />
Even if WarpWallet with eight diceware words is secure, I don't think that should be recommended because I believe people will not follow passphrase creation advice.<br />
<br />
I am aware of the challenge wallet the WarpWallet creators made. A large botnet (several million nodes) could crack it in a few months (assume 10 guesses per second per node).<br />
<br />
Tools that provide a random seed and do not allow free text entry are fine because it would take a lot of effort to use insecurely. WarpWallet is easy to use insecurely, electrum, armory, and bip39 are hard to use insecurely.<br />
<br />
As far as bad RNGs go... I think people are safer trusting the RNG of reputable bitcoin wallets than trying to provide their own entropy. If a widespread vulnerability in those wallets is found, it would pose an existential threat to bitcoin.<br />
<br />
== Warpwallet security analysis ==<br />
<br />
Hi Ryan. Thanks for replying. <br />
<br />
What I like about Warpwallet's use of KDFs + salt is that it<br />
has the potential to raise the cost of attack beyond the point where it is worth's an attacker's trouble to attempt. You don't spend $100M cracking a $1M safe.<br />
<br />
Whether or not that is true depends on the validity of the underlying assumptions and a bit of basic math. You're the brainwallet cracking expert so I'm very much interested in your viewpoint on this.<br />
<br />
A few questions:<br />
<br />
1) You estimated that a large botnet could crack the unsalted 8-character Warpwallet challenge within several months. What if the challenge was salted with an unknown email? Would it still be feasible in your opinion for a salted Warpwallet 8-character challenge to be cracked?<br />
<br />
2) How much faster in your experience is a low-level (e.g., C) implementation of Warpwallet than the in-browser version? On an 3.2 GHz Core i5 the JS WarpWallet implementation takes about 20 seconds to generate a key from a passphrase. A C implementation would have to be 8X faster and run on all 4 cores to get to 10/reqs a second. Does that about match up with your real-world testing?<br />
<br />
3) Are there any mistakes in maxtaco's cost cracking calculator: http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
The calculator estimates that cracking the unsalted random 8-character Warpwallet challenge would cost $1.2M. <br />
<br />
Here's my analysis, please correct me where you think I've got it wrong.<br />
<br />
Assuming Max's calculation is about right, if the challenge narrowed down the salts to 2 possible e-mails then cracking cost would be $2.4M. If it provided a list of 100 e-mails then the cost would be $120M.<br />
<br />
What that seems to imply is that even with the largest botnets and advances in future hardware a truly global search is impossible and even narrowing that down to large number of target e-mails would be unprofitable for attackers. If this is true a warpwallet cracking botnet is unlikely to be worth anyone's trouble to run in the first place.<br />
<br />
And that's for a passphrase with just 47 bits of entropy.<br />
<br />
If a user generated the recommended 8 words with diceware that's about 100 bits of entropy, raising the cost of attack to a million trillion trillion USD for an unsalted warpwallet, well well above what any wallet is worth under the most optimistic usage scenario.<br />
<br />
You pointed out that users make mistakes, and we know humans are notoriously poor sources of entropy. All true, but that kind of security in depth seems to provide quite a bit of room for error. Users are not just bad at choosing passphrases, they're bad at understanding security in general. If you're not a security expert you're likely to do a poor job keeping your wallet keys secret in the face of determined attackers, regardless of how they were originally generated. In that case, a Warpwallet is not going to be the weakest link. If you know enough to create a strong passphrase, a Warpwallet is not going to be the weakest link. <br />
<br />
Either way, a Warpwallet doesn't seem like that bad an idea. Does it really deserve to be guilty by association with naive Brainwallet implementations?<br />
<br />
Especially when the alternative is to just trust a blackbox process to generate keys for you. I agree that a global RNG failure would be devastating to Bitcoin and cryptography in general. But a local failure like the ones that [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ have already happened] would just result in your coins getting stolen. <br />
<br />
Why should we place any more faith in the ability of a non expert to verify the integrity of the software they are using than in their ability to generate a secure passphrase? <br />
<br />
Generating a secure passphrase with a verifiably secure source of entropy is actually vastly more simple than trying to rule out all the places a backdoor in the automatic seed generation process could be hiding. And so is explaining how to generate a secure passphrase vs how to verify that you're using a faithful wallet. <br />
<br />
This touches the heart of the issue because the Bitcoin wiki is an educational resource for non-experts. If we overestimate the risks of a Warpwallet while underestimating the risks of unfaithful software we may end up giving users bad advice and increase the probability they will lose coins.</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62163User talk:Ryanc2017-01-23T20:07:02Z<p>Liraz: If this is "the" RyanC safe to assume he knows all about warpwallets</p>
<hr />
<div>== Suspicious minds ==<br />
<br />
Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62161User talk:Ryanc2017-01-23T19:10:36Z<p>Liraz: /* Same Ryan Castelluci from DEFCON talk? */ new section</p>
<hr />
<div>Hello Ryanc:<br />
<br />
1) Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
2) Could you please read up on Warpwallet, Key Derivation Functions and salts? It's true that old-style Brainwallets were very dangerous, but advances have made new-style Brainwallets such as Warpwallet many orders of magnitude more resistant to dictionary attack. Warpwallet is developed by very experienced developers who also happen to be the founders of keybase.io.<br />
<br />
http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/<br />
<br />
== Same Ryan Castelluci from DEFCON talk? ==<br />
<br />
First, if you're the same Ryan from the DEFCON talk on Brainwallets, thanks for publishing your research and increasing awareness of the issues. Your talk was one of the inspirations for adding Warpwallet to BitKey.<br />
<br />
However if you're the same Ryan that leaves me confused, because you recommended Warpwallet yourself in your talk, and you should know the Warpwallet challenge for an unsalted 8 character password lasted for 2.5 years before it expired. <br />
<br />
Do you disagree that using Warpwallet with a strong passphrase (e.g., eight diceware words) and an e-mail salt would provide very good security, unlike bitaddress-style brainwallets of old?<br />
<br />
The problem with trusting RNGs to generate your wallet keys are very real:<br />
<br />
http://www.zdnet.com/google-confirms-bitcoin-theft-vulnerability-in-android-7000019431/</div>Lirazhttps://en.bitcoin.it/w/index.php?title=User_talk:Ryanc&diff=62160User talk:Ryanc2017-01-23T18:59:02Z<p>Liraz: why did you revert warpwallet edit?</p>
<hr />
<div>Hello Ryanc:<br />
<br />
1) Could you please explain what you found suspicious about my Brainwallet edits? <br />
<br />
2) Could you please read up on Warpwallet, Key Derivation Functions and salts? It's true that old-style Brainwallets were very dangerous, but advances have made new-style Brainwallets such as Warpwallet many orders of magnitude more resistant to dictionary attack. Warpwallet is developed by very experienced developers who also happen to be the founders of keybase.io.<br />
<br />
http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Passphrase_generation&diff=62158Passphrase generation2017-01-23T10:36:47Z<p>Liraz: /* See also */</p>
<hr />
<div>In various places in Bitcoin, it is important to generate secure passwords/passphrases. Security is especially important in Bitcoin because if your BTC is stolen, there is often no recourse. Bitcoin transactions cannot be reversed.<br />
<br />
==Strength==<br />
<br />
There are two very different use-cases for passwords in Bitcoin. The first and more common is an "offline passphrase". With an offline passphrase, something prevents an attacker from trying to guess your passphrase as fast as he might like. <br />
<br />
Examples include:<br />
<br />
* Website passwords. The website will rate-limit attempts on your password.<br />
* Wallet passphrases. An attacker needs both the wallet file and your wallet passphrase.<br />
* Hardware wallet PIN. An attacker needs both the hardware wallet and your PIN.<br />
<br />
All of the advice you've ever heard about password security has been for the offline password use-case.<br />
<br />
The second use-case is an "online passphrase", where the passphrase is essentially the ''only'' thing protecting your BTC. In this case, your passphrase much be ''massively'' more secure than usual, and you '''can not''' rely on any password-creation advice you've ever heard. <br />
<br />
For use cases that are vulnerable to a global passphrase cracking search, imagine that the entire world could be constantly trying to crack your passphrase, billions of attempts per second, all the time and with no restriction. This is not a normal situation outside of Bitcoin. <br />
<br />
Examples of keys that could be cracked by a global search:<br />
<br />
* The seed/mnemonic of an HD wallet.<br />
* The input to an insecure bitaddress-style "brain wallet"<br />
<br />
Example of keys that could be cracked by a targeted search:<br />
<br />
* The passphrase on a wallet file that may become public, or that an attacker could gain access to.<br />
* The input to a secure "brain wallet" with e-mail salting, and an expensive Key Derivation Function.<br />
<br />
== Crypto standards that increase resistance to passphrase cracking ==<br />
<br />
=== Key Derivation Functions ===<br />
<br />
Since humans are poor sources of entropy, whenever a passphrase is involved it is recommended to use programs that implement an attack resistant KDF ([https://en.wikipedia.org/wiki/Key_derivation_function Key Derivation Function]) to translate the user supplied passphrase into the ultimate encryption key. KDF functions are similar in concept to hashes such as SHA256, except that they are designed to be hard to compute. This slows down an attacker by increasing the computational cost of each passphrase cracking attempt, providing additional security per bit of entropy.<br />
<br />
KDF functions can usually be tuned to provide additional or less security by configuring how many rounds of encryption need to be executed to derive a key from a passphrase. Usability places an upper bound on the number of rounds. For example, a typical number of rounds is 2 ^ 18, or 262144 which may take half a minute on a modern computer.<br />
<br />
KDF functions such as Scrypt and PBKDF2 have good reputations. PBKDF2 is older and has received more scrutiny from the cryptographic community but is easier to accelerate by several orders of magnitude using custom parallel hardware. scrypt is newer and has received less scrutiny, but was specifically designed to be more difficult to accelerate using custom hardware. Some programs (e.g., WarpWallet) use both.<br />
<br />
A KDF can slow down advanced passphrase cracking attempts from billions of cracking attempts per second to hundreds of attempts per second.<br />
<br />
=== Salting ===<br />
<br />
Salting is a technique for cryptographically segmenting the passphrase cracking search space. <br />
Without salting, an attacker can attempt to crack all passphrases simultaneously in a global search space, increasing the expected ROI for his efforts. <br />
<br />
For example, some Brainwallet programs use e-mail based salting to thwart global dictionary attacks. an attacker can still attempt to crack a passphrase, but he has to calculate a different key for each potential e-mail in his list. An attacker can not know for certain than any particular e-mail has been used as a salt.<br />
<br />
== Standards for offline passphrases ==<br />
<br />
Between 64 and 80 bits of entropy seems reasonable. The password must be totally random (see later sections on generation). Hardware wallets have additional protections, and it's OK that they often allow only a short PIN.<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 20-25 digits<br />
* Hexadecimal: 16-20 characters<br />
* All lowercase or all uppercase letters: 14-18 characters<br />
* All lowercase or all uppercase letters + numbers: 13-16 characters<br />
* Mixed case letters: 12-15 characters<br />
* Mixed case letters + numbers: 11-14 characters<br />
* All standard keyboard characters: 9-11 characters<br />
* Diceware words: 5-7 words<br />
* Random English words (100,000-word wordlist): 4-5 words<br />
<br />
== Standards for online passphrases ==<br />
<br />
Usually you don't have to personally generate an online passphrase. The most common case of an online passphrase in Bitcoin is the mnemonic for an HD wallet seed, but a good wallet should securely generate it for you (this is the several-word mnemonic that most wallets tell you to write down when first run), assuming it has not been tampered with.<br />
<br />
In case you need to manually generate an online passphrase, 128 bits of entropy is required. The passphrase must be totally random (see later sections on generation).<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 39 digits<br />
* Hexadecimal: 32 characters<br />
* All lowercase or all uppercase letters: 28 characters<br />
* All lowercase or all uppercase letters + numbers: 25 characters<br />
* Mixed case letters: 23 characters<br />
* Mixed case letters + numbers: 22 characters<br />
* All standard keyboard characters: 20 characters<br />
* Diceware words: 10 words<br />
* Random English words (100,000-word wordlist): 8 words<br />
<br />
== Risks of automatic seed/passphrase generation ==<br />
<br />
Automatic wallet seed/passphrase generation is only secure using:<br />
<br />
#'''Faithful wallet software''': that has not been maliciously tampered with. If you haven't compiled wallet software yourself on a trustworthy computer running a trustworthy compiler, trustworthy source code is no guarantee for a trustworthy binary. See the [http://wiki.c2.com/?TheKenThompsonHack Ken Thompson hack] for details. Wallets with a deterministic build process (e.g., Bitcoin Core) are more resistant to attack.<br />
<br />
#'''Faithful RNG''': An RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator]) may be implemented in software, hardware or both. Wallet software relies on the security of the RNG, to generate your wallet's private keys securely. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
#'''Faithful hardware''': software is executed by hardware. Unfaithful hardware may execute faithful software unfaithfully. This would be especially difficult to detect for computations where the final output is non-deterministic, such as an unfaithful hardware execution of Random Number Generator routines. The risk of such an attack is increased by the opaqueness of hardware implementation, and the centralized capital intensive nature of hardware manufacturing, making hardware companies more vulnerable to coercion, especially in undemocratic countries where most hardware manufacturing currently takes place.<br />
<br />
For high risk applications, a pair of [http://rpg.stackexchange.com/questions/70802/how-can-i-test-whether-a-die-is-fair fair dice] can provide a simpler, verifiably secure source of entropy.<br />
<br />
==How not to generate passphrases==<br />
<br />
Humans are ''really, really'' bad at generating passphrases on their own. Don't try it. If at any step in the passphrase-generation process your brain is being used to choose something at random or randomize something, then you're doing it wrong.<br />
<br />
Do not take words out of a book or other work. The words must be absolutely random.<br />
<br />
Do not use the xkcd password generation method.<br />
<br />
==Using dice==<br />
Dice can be used as one way to generate random numbers and passwords. However, in order to achieve security, you must use them in a certain way.<br />
<br />
===Secure dice===<br />
<br />
Casual dice for board games are not shaped perfectly, and will be somewhat biased toward certain numbers. Special casino dice are available which do not have this flaw.<br />
<br />
The extent to which slightly-biased dice actually affect real-world security depends on the use-case. For the use-cases on this page, if the dice is random enough to not notice its bias when playing games, then it is ''probably'' good enough.<br />
<br />
===Generating passwords===<br />
<br />
To generate passwords, write down a list of acceptable characters, and sequentially number each character starting from 1. For example, if you want to generate a 4-digit PIN, you would create a list like this:<br />
<br />
<pre>1 0<br />
2 1<br />
...<br />
10 9</pre><br />
<br />
If you wanted to generate a password with characters in [a-zA-Z], you would create a list like this:<br />
<pre>1 a<br />
2 b<br />
...<br />
52 Z</pre><br />
<br />
Now you need to figure out how many dice you're going to need to roll. Your dice should all have the same number of sides. If your character list has C characters, and each of your dice have S sides, then you need to roll log<sub>S</sub>(C) dice, rounded up. For example, log<sub>6</sub>(52) is about 2.2, which you round up to 3. So if your character list contains 52 characters, then you need to roll 3 6-sided dice.<br />
<br />
Here, the dice are assumed to be numbered from 1 to S. If this is not the case, then you must create a system to translate the dice results into a range from 1 to S. For example, if you are dealing with 10-sided dice labeled from 0 to 9, then you can add 1 to the roll.<br />
<br />
Roll the required number of dice and put them in a random order. Do not sort the dice from highest to lowest or anything like that. In fact, to prevent any personal bias from entering into the ordering, you may want to roll the dice and then put the dice into a line with your eyes closed.<br />
<br />
Say that d<sub>0</sub> is the rightmost dice you rolled, d<sub>1</sub> is the second-from-rightmost dice you rolled, etc. Then the random number is:<br />
<br />
1 + [(d<sub>0</sub> - 1) × S<sup>0</sup>] + [(d<sub>1</sub> - 1) × S<sup>1</sup>] + [(d<sub>2</sub> - 1) × S<sup>2</sup>] + ...<br />
<br />
For example, if we rolled 316 with 6-sided dice, this becomes:<br />
<br />
1 + [(6 - 1) × 6<sup>0</sup>] + [(1 - 1) × 6<sup>1</sup>] + [(3 - 1) × 6<sup>2</sup>]<br><br />
= 1 + [5 × 1] + [0 × 6] + [2 × 36]<br><br />
= 1 + 5 + 0 + 72<br><br />
= 78<br />
<br />
So our random character would be the 78<sup>th</sup> character in the list.<br />
<br />
'''Important''': If your number is larger than you need, then you must totally reroll for this character. Do not try to "wrap the numbers around" or keep only certain dice, as this results in a non-random distribution. (For the adventurous only: You can safely reduce the number of rerolls by pretending that the highest-order die has fewer sides. Eg. on a 6-sided die say that 1&4 = 1, 2&5 = 2, 3&6 = 3; or that 1&2&3 = 1 and 4&5&6 = 2. Still multiply it by the appropriate power of 6, not 3 or 2. But the die must be evenly divided, you must ensure that the maximum possible value is still greater than or equal to the highest-value character, and you must use the exact same treatment of the high-order die throughout the generation process.)<br />
<br />
'''Important''': There are a variety of different ways to get a random number from multiple dice, but they are usually non-random. For example, ''adding'' dice would be very non-random. The above method ensures a random distribution if the dice themselves are random and if they are ordered randomly.<br />
<br />
If the password is L characters long, then password has log<sub>2</sub>(C<sup>L</sup>) bits of entropy.<br />
<br />
===Generating passphrases===<br />
<br />
As above, but use a list of words instead of a list of characters.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Generating keys, seeds, and random numbers (Advanced)===<br />
<br />
This section is mainly intended for programmers and advanced users.<br />
<br />
Warning: it is considered unsafe to directly handle Bitcoin keys, as doing so is error-prone, and often causes people to send BTC into oblivion.<br />
<br />
If you want to generate a large number for use as a key or seed, you can do the following.<br />
<br />
First, decide how many bits of security you want. 128 bits is probably secure for most things. We will call this value B.<br />
<br />
Next, roll log<sub>S</sub>(2<sup>B</sup>) dice, rounded up, where S is the number of sides per die. For example, with 6-sided dice you would need to roll 50 dice. Put the results right next to each other in a string of text, so for example if you roll 3, 2, 5, 6, 1, you'd start your string as "32561", and then continue on for a total of 50 digits. If your dice have enough sides to result in two-digit numbers, put a leading zero in front of single-digit numbers.<br />
<br />
Then hash your string with a command like <tt>echo "32561..." |sha256sum</tt>. The resulting hash is your random number. If you want a 128-bit or 512-bit number use sha128sum or sha512sum, respectively. If you want some in-between number of bits, use the next larger hash size and then cut off the number where you need it.<br />
<br />
You can generate any size of random number by combining the outputs. For example, let's say that you want 768 bits of randomness and for some reason you can only use sha256sum. You can do this like:<br />
<br />
<pre>$ echo "32561..." |sha256sum<br />
cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed5 -<br />
$ echo "Last hash: cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed Orig entropy: 532561..." |sha256sum<br />
6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c -<br />
$ echo "Last hash: 6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c Orig entropy: 532561..." |sha256sum<br />
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -</pre><br />
<br />
Then concatenate all of those hashes to get your final random number. In this example the result is <tt>cf6a25b...52b855</tt>.<br />
<br />
'''Important''': When generating a stream of random numbers like this, you have to put your source entropy back in at each step.<br />
<br />
If you want to generate a number in a range with a range size that is not a power of two, choose the next-largest power of two and select the correct number of bits based on that. If the resulting number is too large, '''discard''' all of those bits and grab new ones from the endless stream of random bits. Do not use the modulo operator, as that introduces a bias. For example, if you want to generate a number from 0 to 9 (range size = 10), select the next-higher power of 2, 16. If your random stream starts 0xA52F..., grab 4 bits (log<sub>2</sub>(16) = 4), giving 0xA = 10. This is outside of the range, so discard those bits and move onto the next 4 bits, 0x5 = 5. This is in the range, so the final result is 5.<br />
<br />
==Using a computer==<br />
<br />
Computers are good at generating secure random numbers, but you have to be careful to use the right commands. A lot of commands, programming language features, and snippets that you'll find online will give ''insecure'' random numbers which look random, but are predictable. For example, the C <tt>rand</tt> function, the Python <tt>random</tt> module, and the Windows <tt>%RANDOM%</tt> variable are all insecure random number sources.<br />
<br />
<span style="color:red">'''Do not get your passwords from anything in a Web browser, even if the page says that it's using purely client-side JavaScript'''</span><br />
<br />
===Linux===<br />
<br />
There are many different packages for generating random passwords/passphrases on Linux, but none of them are installed by default on all Linux machines, so we will provide a method that uses more standard commands. If you would like a more concise and easy-to-use command, we recommend installing an actual password generator package.<br />
<br />
The following command will generate a 20-character random password:<br />
<br />
<pre>seq 126 |awk '{printf "%c", $0}' |grep -o '[a-zA-Z0-9]\|[[:punct:]]' | \<br />
shuf --random-source=/dev/urandom --repeat --head-count=20 | tr --delete '\n'</pre><br />
<br />
Change <tt>-head-count=20</tt> to change the password length, and <tt><nowiki>[a-zA-Z0-9]\|[[:punct:]]</nowiki></tt> to change the character set. Note that this command will never use characters outside of ASCII, even if your grep pattern would select such characters.<br />
<br />
To generate a passphrase made of words, create a file called <tt>words</tt> with one word per line and Unix-style line endings, and run:<br />
<br />
<pre>shuf --random-source=/dev/urandom --repeat --head-count=7 words | tr '\n' ' '</pre><br />
<br />
Change <tt>-head-count=7</tt> to change the number of words.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Windows===<br />
<br />
[http://keepass.info/ KeePass] includes a password generator, though not a word-based passphrase generator.<br />
<br />
(If anyone knows of some better ones, edit this page to add it.)<br />
<br />
== See also ==<br />
<br />
* [https://github.com/dropbox/zxcvbn zxcvbn] - A realistic passphrase strength estimator<br />
* [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne stores his Bitcoin] - introduction to WarpWallet with passphrase entropy cracking cost calculator.<br />
* [[BitKey]] - Live USB/DVD that supports running zxcvbn and WarpWallet offline</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Passphrase_generation&diff=62157Passphrase generation2017-01-23T10:33:42Z<p>Liraz: /* See also */</p>
<hr />
<div>In various places in Bitcoin, it is important to generate secure passwords/passphrases. Security is especially important in Bitcoin because if your BTC is stolen, there is often no recourse. Bitcoin transactions cannot be reversed.<br />
<br />
==Strength==<br />
<br />
There are two very different use-cases for passwords in Bitcoin. The first and more common is an "offline passphrase". With an offline passphrase, something prevents an attacker from trying to guess your passphrase as fast as he might like. <br />
<br />
Examples include:<br />
<br />
* Website passwords. The website will rate-limit attempts on your password.<br />
* Wallet passphrases. An attacker needs both the wallet file and your wallet passphrase.<br />
* Hardware wallet PIN. An attacker needs both the hardware wallet and your PIN.<br />
<br />
All of the advice you've ever heard about password security has been for the offline password use-case.<br />
<br />
The second use-case is an "online passphrase", where the passphrase is essentially the ''only'' thing protecting your BTC. In this case, your passphrase much be ''massively'' more secure than usual, and you '''can not''' rely on any password-creation advice you've ever heard. <br />
<br />
For use cases that are vulnerable to a global passphrase cracking search, imagine that the entire world could be constantly trying to crack your passphrase, billions of attempts per second, all the time and with no restriction. This is not a normal situation outside of Bitcoin. <br />
<br />
Examples of keys that could be cracked by a global search:<br />
<br />
* The seed/mnemonic of an HD wallet.<br />
* The input to an insecure bitaddress-style "brain wallet"<br />
<br />
Example of keys that could be cracked by a targeted search:<br />
<br />
* The passphrase on a wallet file that may become public, or that an attacker could gain access to.<br />
* The input to a secure "brain wallet" with e-mail salting, and an expensive Key Derivation Function.<br />
<br />
== Crypto standards that increase resistance to passphrase cracking ==<br />
<br />
=== Key Derivation Functions ===<br />
<br />
Since humans are poor sources of entropy, whenever a passphrase is involved it is recommended to use programs that implement an attack resistant KDF ([https://en.wikipedia.org/wiki/Key_derivation_function Key Derivation Function]) to translate the user supplied passphrase into the ultimate encryption key. KDF functions are similar in concept to hashes such as SHA256, except that they are designed to be hard to compute. This slows down an attacker by increasing the computational cost of each passphrase cracking attempt, providing additional security per bit of entropy.<br />
<br />
KDF functions can usually be tuned to provide additional or less security by configuring how many rounds of encryption need to be executed to derive a key from a passphrase. Usability places an upper bound on the number of rounds. For example, a typical number of rounds is 2 ^ 18, or 262144 which may take half a minute on a modern computer.<br />
<br />
KDF functions such as Scrypt and PBKDF2 have good reputations. PBKDF2 is older and has received more scrutiny from the cryptographic community but is easier to accelerate by several orders of magnitude using custom parallel hardware. scrypt is newer and has received less scrutiny, but was specifically designed to be more difficult to accelerate using custom hardware. Some programs (e.g., WarpWallet) use both.<br />
<br />
A KDF can slow down advanced passphrase cracking attempts from billions of cracking attempts per second to hundreds of attempts per second.<br />
<br />
=== Salting ===<br />
<br />
Salting is a technique for cryptographically segmenting the passphrase cracking search space. <br />
Without salting, an attacker can attempt to crack all passphrases simultaneously in a global search space, increasing the expected ROI for his efforts. <br />
<br />
For example, some Brainwallet programs use e-mail based salting to thwart global dictionary attacks. an attacker can still attempt to crack a passphrase, but he has to calculate a different key for each potential e-mail in his list. An attacker can not know for certain than any particular e-mail has been used as a salt.<br />
<br />
== Standards for offline passphrases ==<br />
<br />
Between 64 and 80 bits of entropy seems reasonable. The password must be totally random (see later sections on generation). Hardware wallets have additional protections, and it's OK that they often allow only a short PIN.<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 20-25 digits<br />
* Hexadecimal: 16-20 characters<br />
* All lowercase or all uppercase letters: 14-18 characters<br />
* All lowercase or all uppercase letters + numbers: 13-16 characters<br />
* Mixed case letters: 12-15 characters<br />
* Mixed case letters + numbers: 11-14 characters<br />
* All standard keyboard characters: 9-11 characters<br />
* Diceware words: 5-7 words<br />
* Random English words (100,000-word wordlist): 4-5 words<br />
<br />
== Standards for online passphrases ==<br />
<br />
Usually you don't have to personally generate an online passphrase. The most common case of an online passphrase in Bitcoin is the mnemonic for an HD wallet seed, but a good wallet should securely generate it for you (this is the several-word mnemonic that most wallets tell you to write down when first run), assuming it has not been tampered with.<br />
<br />
In case you need to manually generate an online passphrase, 128 bits of entropy is required. The passphrase must be totally random (see later sections on generation).<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 39 digits<br />
* Hexadecimal: 32 characters<br />
* All lowercase or all uppercase letters: 28 characters<br />
* All lowercase or all uppercase letters + numbers: 25 characters<br />
* Mixed case letters: 23 characters<br />
* Mixed case letters + numbers: 22 characters<br />
* All standard keyboard characters: 20 characters<br />
* Diceware words: 10 words<br />
* Random English words (100,000-word wordlist): 8 words<br />
<br />
== Risks of automatic seed/passphrase generation ==<br />
<br />
Automatic wallet seed/passphrase generation is only secure using:<br />
<br />
#'''Faithful wallet software''': that has not been maliciously tampered with. If you haven't compiled wallet software yourself on a trustworthy computer running a trustworthy compiler, trustworthy source code is no guarantee for a trustworthy binary. See the [http://wiki.c2.com/?TheKenThompsonHack Ken Thompson hack] for details. Wallets with a deterministic build process (e.g., Bitcoin Core) are more resistant to attack.<br />
<br />
#'''Faithful RNG''': An RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator]) may be implemented in software, hardware or both. Wallet software relies on the security of the RNG, to generate your wallet's private keys securely. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
#'''Faithful hardware''': software is executed by hardware. Unfaithful hardware may execute faithful software unfaithfully. This would be especially difficult to detect for computations where the final output is non-deterministic, such as an unfaithful hardware execution of Random Number Generator routines. The risk of such an attack is increased by the opaqueness of hardware implementation, and the centralized capital intensive nature of hardware manufacturing, making hardware companies more vulnerable to coercion, especially in undemocratic countries where most hardware manufacturing currently takes place.<br />
<br />
For high risk applications, a pair of [http://rpg.stackexchange.com/questions/70802/how-can-i-test-whether-a-die-is-fair fair dice] can provide a simpler, verifiably secure source of entropy.<br />
<br />
==How not to generate passphrases==<br />
<br />
Humans are ''really, really'' bad at generating passphrases on their own. Don't try it. If at any step in the passphrase-generation process your brain is being used to choose something at random or randomize something, then you're doing it wrong.<br />
<br />
Do not take words out of a book or other work. The words must be absolutely random.<br />
<br />
Do not use the xkcd password generation method.<br />
<br />
==Using dice==<br />
Dice can be used as one way to generate random numbers and passwords. However, in order to achieve security, you must use them in a certain way.<br />
<br />
===Secure dice===<br />
<br />
Casual dice for board games are not shaped perfectly, and will be somewhat biased toward certain numbers. Special casino dice are available which do not have this flaw.<br />
<br />
The extent to which slightly-biased dice actually affect real-world security depends on the use-case. For the use-cases on this page, if the dice is random enough to not notice its bias when playing games, then it is ''probably'' good enough.<br />
<br />
===Generating passwords===<br />
<br />
To generate passwords, write down a list of acceptable characters, and sequentially number each character starting from 1. For example, if you want to generate a 4-digit PIN, you would create a list like this:<br />
<br />
<pre>1 0<br />
2 1<br />
...<br />
10 9</pre><br />
<br />
If you wanted to generate a password with characters in [a-zA-Z], you would create a list like this:<br />
<pre>1 a<br />
2 b<br />
...<br />
52 Z</pre><br />
<br />
Now you need to figure out how many dice you're going to need to roll. Your dice should all have the same number of sides. If your character list has C characters, and each of your dice have S sides, then you need to roll log<sub>S</sub>(C) dice, rounded up. For example, log<sub>6</sub>(52) is about 2.2, which you round up to 3. So if your character list contains 52 characters, then you need to roll 3 6-sided dice.<br />
<br />
Here, the dice are assumed to be numbered from 1 to S. If this is not the case, then you must create a system to translate the dice results into a range from 1 to S. For example, if you are dealing with 10-sided dice labeled from 0 to 9, then you can add 1 to the roll.<br />
<br />
Roll the required number of dice and put them in a random order. Do not sort the dice from highest to lowest or anything like that. In fact, to prevent any personal bias from entering into the ordering, you may want to roll the dice and then put the dice into a line with your eyes closed.<br />
<br />
Say that d<sub>0</sub> is the rightmost dice you rolled, d<sub>1</sub> is the second-from-rightmost dice you rolled, etc. Then the random number is:<br />
<br />
1 + [(d<sub>0</sub> - 1) × S<sup>0</sup>] + [(d<sub>1</sub> - 1) × S<sup>1</sup>] + [(d<sub>2</sub> - 1) × S<sup>2</sup>] + ...<br />
<br />
For example, if we rolled 316 with 6-sided dice, this becomes:<br />
<br />
1 + [(6 - 1) × 6<sup>0</sup>] + [(1 - 1) × 6<sup>1</sup>] + [(3 - 1) × 6<sup>2</sup>]<br><br />
= 1 + [5 × 1] + [0 × 6] + [2 × 36]<br><br />
= 1 + 5 + 0 + 72<br><br />
= 78<br />
<br />
So our random character would be the 78<sup>th</sup> character in the list.<br />
<br />
'''Important''': If your number is larger than you need, then you must totally reroll for this character. Do not try to "wrap the numbers around" or keep only certain dice, as this results in a non-random distribution. (For the adventurous only: You can safely reduce the number of rerolls by pretending that the highest-order die has fewer sides. Eg. on a 6-sided die say that 1&4 = 1, 2&5 = 2, 3&6 = 3; or that 1&2&3 = 1 and 4&5&6 = 2. Still multiply it by the appropriate power of 6, not 3 or 2. But the die must be evenly divided, you must ensure that the maximum possible value is still greater than or equal to the highest-value character, and you must use the exact same treatment of the high-order die throughout the generation process.)<br />
<br />
'''Important''': There are a variety of different ways to get a random number from multiple dice, but they are usually non-random. For example, ''adding'' dice would be very non-random. The above method ensures a random distribution if the dice themselves are random and if they are ordered randomly.<br />
<br />
If the password is L characters long, then password has log<sub>2</sub>(C<sup>L</sup>) bits of entropy.<br />
<br />
===Generating passphrases===<br />
<br />
As above, but use a list of words instead of a list of characters.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Generating keys, seeds, and random numbers (Advanced)===<br />
<br />
This section is mainly intended for programmers and advanced users.<br />
<br />
Warning: it is considered unsafe to directly handle Bitcoin keys, as doing so is error-prone, and often causes people to send BTC into oblivion.<br />
<br />
If you want to generate a large number for use as a key or seed, you can do the following.<br />
<br />
First, decide how many bits of security you want. 128 bits is probably secure for most things. We will call this value B.<br />
<br />
Next, roll log<sub>S</sub>(2<sup>B</sup>) dice, rounded up, where S is the number of sides per die. For example, with 6-sided dice you would need to roll 50 dice. Put the results right next to each other in a string of text, so for example if you roll 3, 2, 5, 6, 1, you'd start your string as "32561", and then continue on for a total of 50 digits. If your dice have enough sides to result in two-digit numbers, put a leading zero in front of single-digit numbers.<br />
<br />
Then hash your string with a command like <tt>echo "32561..." |sha256sum</tt>. The resulting hash is your random number. If you want a 128-bit or 512-bit number use sha128sum or sha512sum, respectively. If you want some in-between number of bits, use the next larger hash size and then cut off the number where you need it.<br />
<br />
You can generate any size of random number by combining the outputs. For example, let's say that you want 768 bits of randomness and for some reason you can only use sha256sum. You can do this like:<br />
<br />
<pre>$ echo "32561..." |sha256sum<br />
cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed5 -<br />
$ echo "Last hash: cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed Orig entropy: 532561..." |sha256sum<br />
6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c -<br />
$ echo "Last hash: 6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c Orig entropy: 532561..." |sha256sum<br />
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -</pre><br />
<br />
Then concatenate all of those hashes to get your final random number. In this example the result is <tt>cf6a25b...52b855</tt>.<br />
<br />
'''Important''': When generating a stream of random numbers like this, you have to put your source entropy back in at each step.<br />
<br />
If you want to generate a number in a range with a range size that is not a power of two, choose the next-largest power of two and select the correct number of bits based on that. If the resulting number is too large, '''discard''' all of those bits and grab new ones from the endless stream of random bits. Do not use the modulo operator, as that introduces a bias. For example, if you want to generate a number from 0 to 9 (range size = 10), select the next-higher power of 2, 16. If your random stream starts 0xA52F..., grab 4 bits (log<sub>2</sub>(16) = 4), giving 0xA = 10. This is outside of the range, so discard those bits and move onto the next 4 bits, 0x5 = 5. This is in the range, so the final result is 5.<br />
<br />
==Using a computer==<br />
<br />
Computers are good at generating secure random numbers, but you have to be careful to use the right commands. A lot of commands, programming language features, and snippets that you'll find online will give ''insecure'' random numbers which look random, but are predictable. For example, the C <tt>rand</tt> function, the Python <tt>random</tt> module, and the Windows <tt>%RANDOM%</tt> variable are all insecure random number sources.<br />
<br />
<span style="color:red">'''Do not get your passwords from anything in a Web browser, even if the page says that it's using purely client-side JavaScript'''</span><br />
<br />
===Linux===<br />
<br />
There are many different packages for generating random passwords/passphrases on Linux, but none of them are installed by default on all Linux machines, so we will provide a method that uses more standard commands. If you would like a more concise and easy-to-use command, we recommend installing an actual password generator package.<br />
<br />
The following command will generate a 20-character random password:<br />
<br />
<pre>seq 126 |awk '{printf "%c", $0}' |grep -o '[a-zA-Z0-9]\|[[:punct:]]' | \<br />
shuf --random-source=/dev/urandom --repeat --head-count=20 | tr --delete '\n'</pre><br />
<br />
Change <tt>-head-count=20</tt> to change the password length, and <tt><nowiki>[a-zA-Z0-9]\|[[:punct:]]</nowiki></tt> to change the character set. Note that this command will never use characters outside of ASCII, even if your grep pattern would select such characters.<br />
<br />
To generate a passphrase made of words, create a file called <tt>words</tt> with one word per line and Unix-style line endings, and run:<br />
<br />
<pre>shuf --random-source=/dev/urandom --repeat --head-count=7 words | tr '\n' ' '</pre><br />
<br />
Change <tt>-head-count=7</tt> to change the number of words.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Windows===<br />
<br />
[http://keepass.info/ KeePass] includes a password generator, though not a word-based passphrase generator.<br />
<br />
(If anyone knows of some better ones, edit this page to add it.)<br />
<br />
== See also ==<br />
<br />
* [https://github.com/dropbox/zxcvbn zxcvbn] - A realistic passphrase strength estimator<br />
* [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne stores his Bitcoin] - introduction to WarpWallet with passphrase entropy cost estimator<br />
* [[BitKey]] - Live USB/DVD that supports running zxcvbn and WarpWallet offline</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Brainwallet&diff=62156Brainwallet2017-01-23T10:25:48Z<p>Liraz: /* WarpWallet */ internal link to strong passphrase</p>
<hr />
<div>A '''brainwallet''' refers to the concept of storing Bitcoins in your brain by remembering the secret seed from which your wallet keys are generated.<br />
<br />
= WarpWallet =<br />
<br />
One of the best ways to create a brainwallet is use [https://keybase.io/warp/ WarpWallet] on a secure, malware-free computer to to generate your wallet keys from a [[Passphrase generation|strong passphrase]], salted to your email address.<br />
<br />
An advantage of this wallet generation method is that it not vulnerable to a malicious or broken Random Number Generator.<br />
<br />
A disadvantage is that only a single address is generated at a time and [[address reuse]] can introduce privacy problems.<br />
<br />
WarpWallet uses a strong bruteforce resistant Key Derivation Function: 2^18 rounds of scrypt + pbkdf. Older methods of creating a brainwallet (e.g., bitaddress.org) from a passphrase are extremely error prone and dangerous. See discussion below.<br />
<br />
==Usage example==<br />
<br />
# Boot [[BitKey]] on an offline computer in cold-offline mode. <br />
<br />
# Run WarpWallet <br />
<br />
# Use a strong passphrase to generate your wallet key. Salt with your e-mail.<br />
<br />
= Memorizing a wallet generated seed =<br />
<br />
An alternative to using WarpWallet with a strong user supplied passphrase is to use trusted Bitcoin wallet software to generate a mnemonic seed and then memorize it. <br />
<br />
This assumes the Random Number Generator used to generate the seed is not broken or compromised.<br />
<br />
Such seeds are generated by wallets like [[Electrum]], [[Armory]] and [[Mycelium]].<br />
<br />
==Electrum based Example==<br />
<br />
# On a computer with no malware (e.g., offline PC running live in RAM from [[BitKey]]), run [[Electrum]] and generate the 13-word recovery seed.<br />
# Memorize the seed using http://en.wikipedia.org/wiki/Mnemonic_peg_system<br />
# When spending or saving, restore the wallet from memory using the seed.<br />
# Use the master public key to create an online watch-only wallet, where you can send to but not spend.<br />
# Spend from the wallet in the manner of [[Cold_storage|deep cold storage]]. Transferring the unsigned transaction to the cold storage computer, signing it and broadcasting to the network.<br />
<br />
= Risk of losing coins =<br />
<br />
If the secret seed to your wallet is not recorded anywhere, the Bitcoins can be thought of as being held only in the mind of the owner. If a brainwallet is forgotten or the person dies or is permanently incapacitated, the Bitcoins are lost forever. <br />
<br />
Using techniques like memory pegging allow them to be memorized and recalled easily.<br />
<br />
==Example Mnemonic Peg==<br />
<br />
To memorize a mnemonic seed with this method you must invent a story which hits the words as "keynotes". Try to make it like a fairy tale story, use imagery. Make it somehow striking and emotionally resonant. When remembering you just remember the key words, not all the other words - the other can be remembered more as images and thoughts (which are hard to write down)<br />
<br />
Let's say we have this seed:<br />
<br />
witch collapse practice feed shame open despair creek road again ice least<br />
<br />
You'd imagine walking through a building familiar to you, maybe your own home or workplace or school.<br />
<br />
* You imagine looking in the first room and seeing your mother dressed as a '''witch''', playing the jenga boardgame until the tower '''collapses'''.<br />
* You walk to the next room and see your father '''practising''' with a longbow, he shoots a chicken to '''feeds''' himself.<br />
* In the next room you see your brother naked in '''shame''' attempting to cover himself, he's looking through a window that's '''open''' and flapping in the wind.<br />
* Now you reach the kitchen, girlfriend is looking at Picasso's [https://en.wikipedia.org/wiki/Guernica_%28Picasso%29 Guernica] on the wall. She is in '''despair''' from it. Next to it is a television playing the show Dawson's '''Creek'''.<br />
* Next you're in the garage, your childhood friend is working on his car. He plans to go on a '''road''' trip for the 5th time this month, he's going '''again'''.<br />
* Finally to go outside to the garden. It's early spring and the ground is covered in melting '''ice'''. Two of your other friends are there, one friend has a huge basket of apples, the other has a smaller basket but you're holding only some apples. You've got the '''least''' apples.<br />
<br />
Repeat this story in your head several times over a short period - the first few days. It will sink in, deep, after that. You'll only have to revisit it very occasionally. After a while you can ignore it for months and it'll still come back, not that I'd recommend relying on that.<br />
<br />
==Video Example of Mnemonic Peg Method==<br />
<br />
From the BBC documentary The Human Mind (2003) by Professor Robert Winston. Approximately 31 minutes in. Memorizing a list of 30 random words.<br />
<br />
https://www.youtube.com/watch?v=lRhfQCW1f68&t=1867<br />
<br />
==Fallible Memory==<br />
<br />
Despite the memory aids, human memory can be very fallible. So if your only storage is memory you may find that it just vanished one day. Keeping a copy stored on paper somewhere could be a useful backup, depending on circumstances.<br />
<br />
=Dangerous Old-Style Brainwallets =<br />
<br />
An early old-style brainwallet was created by by memorization of a passphrase and converting it a [[private key]] with a weak key derivation algorithm (example: two rounds of SHA256). That private key is then used to compute a Bitcoin address. <br />
<br />
This method was extremely dangerous because it was vulnerable to global dictionary and bruteforce attacks and relied on humans as a source of entropy.<br />
<br />
Modern brainwallets such as WarpWallet have proven much more resistant to attack due to the strong Key Derivation Function and e-mail based salting. For example, the WarpWallet challenge offered a 20 BTC prize for anyone managing to crack an unsalted random 8-character brainwallet. The challenge has resisted attack for 2.5 years.<br />
<br />
Note that even with WarpWallet, using a single address still has problems associated with [[address reuse]].<br />
<br />
==Legacy Code==<br />
<br />
If you have coins in an old-style brainwallet, the website http://www.bitaddress.org/ contains a GUI for generating the private key using the sha256(passphrase) algorithm. It's highly recommended you move the out as soon as you can.<br />
<br />
==Low Entropy from Human-Generated Passphrases==<br />
<br />
Practically everyone who knows about or cares loudly yells at people DO NOT USE BRAINWALLETS [GENERATED BY HUMANS]. We've seen pretty concrete evidence that users are resistant to good advice in this space, and they are shocked when their favorite quotation is cracked and they lose their coins<br />
<br />
==Ryan Castellucci DEFCON Talk==<br />
<br />
Ryan Castellucci gave a talk at DEFCON23 about cracking brainwallet passphrases. Although brainwallet passphrases were being exploited for years by this point, the talk helped bring the issues to more popular consciousness.<ref>[https://rya.nc/cracking_cryptocurrency_brainwallets.pdf Ryan Castellucci DEFCON Talk]</ref><ref>[https://www.reddit.com/r/Bitcoin/comments/3g9f1s/why_im_releasing_a_brainwallet_cracker_at_defcon/ Reddit thread on Ryan's talk]</ref><ref>[https://www.youtube.com/watch?v=foil0hzl4Pg a video of Ryan's talk]</ref><br />
<br />
=References=<br />
<references><br />
</references></div>Lirazhttps://en.bitcoin.it/w/index.php?title=Passphrase_generation&diff=62155Passphrase generation2017-01-23T10:23:34Z<p>Liraz: Risks of automatic seed/passphrase generation</p>
<hr />
<div>In various places in Bitcoin, it is important to generate secure passwords/passphrases. Security is especially important in Bitcoin because if your BTC is stolen, there is often no recourse. Bitcoin transactions cannot be reversed.<br />
<br />
==Strength==<br />
<br />
There are two very different use-cases for passwords in Bitcoin. The first and more common is an "offline passphrase". With an offline passphrase, something prevents an attacker from trying to guess your passphrase as fast as he might like. <br />
<br />
Examples include:<br />
<br />
* Website passwords. The website will rate-limit attempts on your password.<br />
* Wallet passphrases. An attacker needs both the wallet file and your wallet passphrase.<br />
* Hardware wallet PIN. An attacker needs both the hardware wallet and your PIN.<br />
<br />
All of the advice you've ever heard about password security has been for the offline password use-case.<br />
<br />
The second use-case is an "online passphrase", where the passphrase is essentially the ''only'' thing protecting your BTC. In this case, your passphrase much be ''massively'' more secure than usual, and you '''can not''' rely on any password-creation advice you've ever heard. <br />
<br />
For use cases that are vulnerable to a global passphrase cracking search, imagine that the entire world could be constantly trying to crack your passphrase, billions of attempts per second, all the time and with no restriction. This is not a normal situation outside of Bitcoin. <br />
<br />
Examples of keys that could be cracked by a global search:<br />
<br />
* The seed/mnemonic of an HD wallet.<br />
* The input to an insecure bitaddress-style "brain wallet"<br />
<br />
Example of keys that could be cracked by a targeted search:<br />
<br />
* The passphrase on a wallet file that may become public, or that an attacker could gain access to.<br />
* The input to a secure "brain wallet" with e-mail salting, and an expensive Key Derivation Function.<br />
<br />
== Crypto standards that increase resistance to passphrase cracking ==<br />
<br />
=== Key Derivation Functions ===<br />
<br />
Since humans are poor sources of entropy, whenever a passphrase is involved it is recommended to use programs that implement an attack resistant KDF ([https://en.wikipedia.org/wiki/Key_derivation_function Key Derivation Function]) to translate the user supplied passphrase into the ultimate encryption key. KDF functions are similar in concept to hashes such as SHA256, except that they are designed to be hard to compute. This slows down an attacker by increasing the computational cost of each passphrase cracking attempt, providing additional security per bit of entropy.<br />
<br />
KDF functions can usually be tuned to provide additional or less security by configuring how many rounds of encryption need to be executed to derive a key from a passphrase. Usability places an upper bound on the number of rounds. For example, a typical number of rounds is 2 ^ 18, or 262144 which may take half a minute on a modern computer.<br />
<br />
KDF functions such as Scrypt and PBKDF2 have good reputations. PBKDF2 is older and has received more scrutiny from the cryptographic community but is easier to accelerate by several orders of magnitude using custom parallel hardware. scrypt is newer and has received less scrutiny, but was specifically designed to be more difficult to accelerate using custom hardware. Some programs (e.g., WarpWallet) use both.<br />
<br />
A KDF can slow down advanced passphrase cracking attempts from billions of cracking attempts per second to hundreds of attempts per second.<br />
<br />
=== Salting ===<br />
<br />
Salting is a technique for cryptographically segmenting the passphrase cracking search space. <br />
Without salting, an attacker can attempt to crack all passphrases simultaneously in a global search space, increasing the expected ROI for his efforts. <br />
<br />
For example, some Brainwallet programs use e-mail based salting to thwart global dictionary attacks. an attacker can still attempt to crack a passphrase, but he has to calculate a different key for each potential e-mail in his list. An attacker can not know for certain than any particular e-mail has been used as a salt.<br />
<br />
== Standards for offline passphrases ==<br />
<br />
Between 64 and 80 bits of entropy seems reasonable. The password must be totally random (see later sections on generation). Hardware wallets have additional protections, and it's OK that they often allow only a short PIN.<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 20-25 digits<br />
* Hexadecimal: 16-20 characters<br />
* All lowercase or all uppercase letters: 14-18 characters<br />
* All lowercase or all uppercase letters + numbers: 13-16 characters<br />
* Mixed case letters: 12-15 characters<br />
* Mixed case letters + numbers: 11-14 characters<br />
* All standard keyboard characters: 9-11 characters<br />
* Diceware words: 5-7 words<br />
* Random English words (100,000-word wordlist): 4-5 words<br />
<br />
== Standards for online passphrases ==<br />
<br />
Usually you don't have to personally generate an online passphrase. The most common case of an online passphrase in Bitcoin is the mnemonic for an HD wallet seed, but a good wallet should securely generate it for you (this is the several-word mnemonic that most wallets tell you to write down when first run), assuming it has not been tampered with.<br />
<br />
In case you need to manually generate an online passphrase, 128 bits of entropy is required. The passphrase must be totally random (see later sections on generation).<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 39 digits<br />
* Hexadecimal: 32 characters<br />
* All lowercase or all uppercase letters: 28 characters<br />
* All lowercase or all uppercase letters + numbers: 25 characters<br />
* Mixed case letters: 23 characters<br />
* Mixed case letters + numbers: 22 characters<br />
* All standard keyboard characters: 20 characters<br />
* Diceware words: 10 words<br />
* Random English words (100,000-word wordlist): 8 words<br />
<br />
== Risks of automatic seed/passphrase generation ==<br />
<br />
Automatic wallet seed/passphrase generation is only secure using:<br />
<br />
#'''Faithful wallet software''': that has not been maliciously tampered with. If you haven't compiled wallet software yourself on a trustworthy computer running a trustworthy compiler, trustworthy source code is no guarantee for a trustworthy binary. See the [http://wiki.c2.com/?TheKenThompsonHack Ken Thompson hack] for details. Wallets with a deterministic build process (e.g., Bitcoin Core) are more resistant to attack.<br />
<br />
#'''Faithful RNG''': An RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator]) may be implemented in software, hardware or both. Wallet software relies on the security of the RNG, to generate your wallet's private keys securely. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
#'''Faithful hardware''': software is executed by hardware. Unfaithful hardware may execute faithful software unfaithfully. This would be especially difficult to detect for computations where the final output is non-deterministic, such as an unfaithful hardware execution of Random Number Generator routines. The risk of such an attack is increased by the opaqueness of hardware implementation, and the centralized capital intensive nature of hardware manufacturing, making hardware companies more vulnerable to coercion, especially in undemocratic countries where most hardware manufacturing currently takes place.<br />
<br />
For high risk applications, a pair of [http://rpg.stackexchange.com/questions/70802/how-can-i-test-whether-a-die-is-fair fair dice] can provide a simpler, verifiably secure source of entropy.<br />
<br />
==How not to generate passphrases==<br />
<br />
Humans are ''really, really'' bad at generating passphrases on their own. Don't try it. If at any step in the passphrase-generation process your brain is being used to choose something at random or randomize something, then you're doing it wrong.<br />
<br />
Do not take words out of a book or other work. The words must be absolutely random.<br />
<br />
Do not use the xkcd password generation method.<br />
<br />
==Using dice==<br />
Dice can be used as one way to generate random numbers and passwords. However, in order to achieve security, you must use them in a certain way.<br />
<br />
===Secure dice===<br />
<br />
Casual dice for board games are not shaped perfectly, and will be somewhat biased toward certain numbers. Special casino dice are available which do not have this flaw.<br />
<br />
The extent to which slightly-biased dice actually affect real-world security depends on the use-case. For the use-cases on this page, if the dice is random enough to not notice its bias when playing games, then it is ''probably'' good enough.<br />
<br />
===Generating passwords===<br />
<br />
To generate passwords, write down a list of acceptable characters, and sequentially number each character starting from 1. For example, if you want to generate a 4-digit PIN, you would create a list like this:<br />
<br />
<pre>1 0<br />
2 1<br />
...<br />
10 9</pre><br />
<br />
If you wanted to generate a password with characters in [a-zA-Z], you would create a list like this:<br />
<pre>1 a<br />
2 b<br />
...<br />
52 Z</pre><br />
<br />
Now you need to figure out how many dice you're going to need to roll. Your dice should all have the same number of sides. If your character list has C characters, and each of your dice have S sides, then you need to roll log<sub>S</sub>(C) dice, rounded up. For example, log<sub>6</sub>(52) is about 2.2, which you round up to 3. So if your character list contains 52 characters, then you need to roll 3 6-sided dice.<br />
<br />
Here, the dice are assumed to be numbered from 1 to S. If this is not the case, then you must create a system to translate the dice results into a range from 1 to S. For example, if you are dealing with 10-sided dice labeled from 0 to 9, then you can add 1 to the roll.<br />
<br />
Roll the required number of dice and put them in a random order. Do not sort the dice from highest to lowest or anything like that. In fact, to prevent any personal bias from entering into the ordering, you may want to roll the dice and then put the dice into a line with your eyes closed.<br />
<br />
Say that d<sub>0</sub> is the rightmost dice you rolled, d<sub>1</sub> is the second-from-rightmost dice you rolled, etc. Then the random number is:<br />
<br />
1 + [(d<sub>0</sub> - 1) × S<sup>0</sup>] + [(d<sub>1</sub> - 1) × S<sup>1</sup>] + [(d<sub>2</sub> - 1) × S<sup>2</sup>] + ...<br />
<br />
For example, if we rolled 316 with 6-sided dice, this becomes:<br />
<br />
1 + [(6 - 1) × 6<sup>0</sup>] + [(1 - 1) × 6<sup>1</sup>] + [(3 - 1) × 6<sup>2</sup>]<br><br />
= 1 + [5 × 1] + [0 × 6] + [2 × 36]<br><br />
= 1 + 5 + 0 + 72<br><br />
= 78<br />
<br />
So our random character would be the 78<sup>th</sup> character in the list.<br />
<br />
'''Important''': If your number is larger than you need, then you must totally reroll for this character. Do not try to "wrap the numbers around" or keep only certain dice, as this results in a non-random distribution. (For the adventurous only: You can safely reduce the number of rerolls by pretending that the highest-order die has fewer sides. Eg. on a 6-sided die say that 1&4 = 1, 2&5 = 2, 3&6 = 3; or that 1&2&3 = 1 and 4&5&6 = 2. Still multiply it by the appropriate power of 6, not 3 or 2. But the die must be evenly divided, you must ensure that the maximum possible value is still greater than or equal to the highest-value character, and you must use the exact same treatment of the high-order die throughout the generation process.)<br />
<br />
'''Important''': There are a variety of different ways to get a random number from multiple dice, but they are usually non-random. For example, ''adding'' dice would be very non-random. The above method ensures a random distribution if the dice themselves are random and if they are ordered randomly.<br />
<br />
If the password is L characters long, then password has log<sub>2</sub>(C<sup>L</sup>) bits of entropy.<br />
<br />
===Generating passphrases===<br />
<br />
As above, but use a list of words instead of a list of characters.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Generating keys, seeds, and random numbers (Advanced)===<br />
<br />
This section is mainly intended for programmers and advanced users.<br />
<br />
Warning: it is considered unsafe to directly handle Bitcoin keys, as doing so is error-prone, and often causes people to send BTC into oblivion.<br />
<br />
If you want to generate a large number for use as a key or seed, you can do the following.<br />
<br />
First, decide how many bits of security you want. 128 bits is probably secure for most things. We will call this value B.<br />
<br />
Next, roll log<sub>S</sub>(2<sup>B</sup>) dice, rounded up, where S is the number of sides per die. For example, with 6-sided dice you would need to roll 50 dice. Put the results right next to each other in a string of text, so for example if you roll 3, 2, 5, 6, 1, you'd start your string as "32561", and then continue on for a total of 50 digits. If your dice have enough sides to result in two-digit numbers, put a leading zero in front of single-digit numbers.<br />
<br />
Then hash your string with a command like <tt>echo "32561..." |sha256sum</tt>. The resulting hash is your random number. If you want a 128-bit or 512-bit number use sha128sum or sha512sum, respectively. If you want some in-between number of bits, use the next larger hash size and then cut off the number where you need it.<br />
<br />
You can generate any size of random number by combining the outputs. For example, let's say that you want 768 bits of randomness and for some reason you can only use sha256sum. You can do this like:<br />
<br />
<pre>$ echo "32561..." |sha256sum<br />
cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed5 -<br />
$ echo "Last hash: cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed Orig entropy: 532561..." |sha256sum<br />
6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c -<br />
$ echo "Last hash: 6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c Orig entropy: 532561..." |sha256sum<br />
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -</pre><br />
<br />
Then concatenate all of those hashes to get your final random number. In this example the result is <tt>cf6a25b...52b855</tt>.<br />
<br />
'''Important''': When generating a stream of random numbers like this, you have to put your source entropy back in at each step.<br />
<br />
If you want to generate a number in a range with a range size that is not a power of two, choose the next-largest power of two and select the correct number of bits based on that. If the resulting number is too large, '''discard''' all of those bits and grab new ones from the endless stream of random bits. Do not use the modulo operator, as that introduces a bias. For example, if you want to generate a number from 0 to 9 (range size = 10), select the next-higher power of 2, 16. If your random stream starts 0xA52F..., grab 4 bits (log<sub>2</sub>(16) = 4), giving 0xA = 10. This is outside of the range, so discard those bits and move onto the next 4 bits, 0x5 = 5. This is in the range, so the final result is 5.<br />
<br />
==Using a computer==<br />
<br />
Computers are good at generating secure random numbers, but you have to be careful to use the right commands. A lot of commands, programming language features, and snippets that you'll find online will give ''insecure'' random numbers which look random, but are predictable. For example, the C <tt>rand</tt> function, the Python <tt>random</tt> module, and the Windows <tt>%RANDOM%</tt> variable are all insecure random number sources.<br />
<br />
<span style="color:red">'''Do not get your passwords from anything in a Web browser, even if the page says that it's using purely client-side JavaScript'''</span><br />
<br />
===Linux===<br />
<br />
There are many different packages for generating random passwords/passphrases on Linux, but none of them are installed by default on all Linux machines, so we will provide a method that uses more standard commands. If you would like a more concise and easy-to-use command, we recommend installing an actual password generator package.<br />
<br />
The following command will generate a 20-character random password:<br />
<br />
<pre>seq 126 |awk '{printf "%c", $0}' |grep -o '[a-zA-Z0-9]\|[[:punct:]]' | \<br />
shuf --random-source=/dev/urandom --repeat --head-count=20 | tr --delete '\n'</pre><br />
<br />
Change <tt>-head-count=20</tt> to change the password length, and <tt><nowiki>[a-zA-Z0-9]\|[[:punct:]]</nowiki></tt> to change the character set. Note that this command will never use characters outside of ASCII, even if your grep pattern would select such characters.<br />
<br />
To generate a passphrase made of words, create a file called <tt>words</tt> with one word per line and Unix-style line endings, and run:<br />
<br />
<pre>shuf --random-source=/dev/urandom --repeat --head-count=7 words | tr '\n' ' '</pre><br />
<br />
Change <tt>-head-count=7</tt> to change the number of words.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Windows===<br />
<br />
[http://keepass.info/ KeePass] includes a password generator, though not a word-based passphrase generator.<br />
<br />
(If anyone knows of some better ones, edit this page to add it.)<br />
<br />
== See also ==<br />
<br />
* [https://github.com/dropbox/zxcvbn zxcvbn] - A realistic passphrase strength estimator<br />
* [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne stores his Bitcoin] - introduction to WarpWallet<br />
* [[BitKey]] - Live USB/DVD that supports running zxcvbn and WarpWallet offline</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Passphrase_generation&diff=62154Passphrase generation2017-01-23T09:34:21Z<p>Liraz: /* Standards for online passphrases */ caveat regarding letting wallet generate seed for you</p>
<hr />
<div>In various places in Bitcoin, it is important to generate secure passwords/passphrases. Security is especially important in Bitcoin because if your BTC is stolen, there is often no recourse. Bitcoin transactions cannot be reversed.<br />
<br />
==Strength==<br />
<br />
There are two very different use-cases for passwords in Bitcoin. The first and more common is an "offline passphrase". With an offline passphrase, something prevents an attacker from trying to guess your passphrase as fast as he might like. <br />
<br />
Examples include:<br />
<br />
* Website passwords. The website will rate-limit attempts on your password.<br />
* Wallet passphrases. An attacker needs both the wallet file and your wallet passphrase.<br />
* Hardware wallet PIN. An attacker needs both the hardware wallet and your PIN.<br />
<br />
All of the advice you've ever heard about password security has been for the offline password use-case.<br />
<br />
The second use-case is an "online passphrase", where the passphrase is essentially the ''only'' thing protecting your BTC. In this case, your passphrase much be ''massively'' more secure than usual, and you '''can not''' rely on any password-creation advice you've ever heard. <br />
<br />
For use cases that are vulnerable to a global passphrase cracking search, imagine that the entire world could be constantly trying to crack your passphrase, billions of attempts per second, all the time and with no restriction. This is not a normal situation outside of Bitcoin. <br />
<br />
Examples of keys that could be cracked by a global search:<br />
<br />
* The seed/mnemonic of an HD wallet.<br />
* The input to an insecure bitaddress-style "brain wallet"<br />
<br />
Example of keys that could be cracked by a targeted search:<br />
<br />
* The passphrase on a wallet file that may become public, or that an attacker could gain access to.<br />
* The input to a secure "brain wallet" with e-mail salting, and an expensive Key Derivation Function.<br />
<br />
== Crypto standards that increase resistance to passphrase cracking ==<br />
<br />
=== Key Derivation Functions ===<br />
<br />
Since humans are poor sources of entropy, whenever a passphrase is involved it is recommended to use programs that implement an attack resistant KDF ([https://en.wikipedia.org/wiki/Key_derivation_function Key Derivation Function]) to translate the user supplied passphrase into the ultimate encryption key. KDF functions are similar in concept to hashes such as SHA256, except that they are designed to be hard to compute. This slows down an attacker by increasing the computational cost of each passphrase cracking attempt, providing additional security per bit of entropy.<br />
<br />
KDF functions can usually be tuned to provide additional or less security by configuring how many rounds of encryption need to be executed to derive a key from a passphrase. Usability places an upper bound on the number of rounds. For example, a typical number of rounds is 2 ^ 18, or 262144 which may take half a minute on a modern computer.<br />
<br />
KDF functions such as Scrypt and PBKDF2 have good reputations. PBKDF2 is older and has received more scrutiny from the cryptographic community but is easier to accelerate by several orders of magnitude using custom parallel hardware. scrypt is newer and has received less scrutiny, but was specifically designed to be more difficult to accelerate using custom hardware. Some programs (e.g., WarpWallet) use both.<br />
<br />
A KDF can slow down advanced passphrase cracking attempts from billions of cracking attempts per second to hundreds of attempts per second.<br />
<br />
=== Salting ===<br />
<br />
Salting is a technique for cryptographically segmenting the passphrase cracking search space. <br />
Without salting, an attacker can attempt to crack all passphrases simultaneously in a global search space, increasing the expected ROI for his efforts. <br />
<br />
For example, some Brainwallet programs use e-mail based salting to thwart global dictionary attacks. an attacker can still attempt to crack a passphrase, but he has to calculate a different key for each potential e-mail in his list. An attacker can not know for certain than any particular e-mail has been used as a salt.<br />
<br />
== Standards for offline passphrases ==<br />
<br />
Between 64 and 80 bits of entropy seems reasonable. The password must be totally random (see later sections on generation). Hardware wallets have additional protections, and it's OK that they often allow only a short PIN.<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 20-25 digits<br />
* Hexadecimal: 16-20 characters<br />
* All lowercase or all uppercase letters: 14-18 characters<br />
* All lowercase or all uppercase letters + numbers: 13-16 characters<br />
* Mixed case letters: 12-15 characters<br />
* Mixed case letters + numbers: 11-14 characters<br />
* All standard keyboard characters: 9-11 characters<br />
* Diceware words: 5-7 words<br />
* Random English words (100,000-word wordlist): 4-5 words<br />
<br />
== Standards for online passphrases ==<br />
<br />
Usually you don't have to personally generate an online passphrase. The most common case of an online passphrase in Bitcoin is the mnemonic for an HD wallet seed, but a good wallet should securely generate it for you (this is the several-word mnemonic that most wallets tell you to write down when first run), assuming it has not been tampered with.<br />
<br />
In case you need to manually generate an online passphrase, 128 bits of entropy is required. The passphrase must be totally random (see later sections on generation).<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 39 digits<br />
* Hexadecimal: 32 characters<br />
* All lowercase or all uppercase letters: 28 characters<br />
* All lowercase or all uppercase letters + numbers: 25 characters<br />
* Mixed case letters: 23 characters<br />
* Mixed case letters + numbers: 22 characters<br />
* All standard keyboard characters: 20 characters<br />
* Diceware words: 10 words<br />
* Random English words (100,000-word wordlist): 8 words<br />
<br />
==How not to generate passphrases==<br />
<br />
Humans are ''really, really'' bad at generating passphrases on their own. Don't try it. If at any step in the passphrase-generation process your brain is being used to choose something at random or randomize something, then you're doing it wrong.<br />
<br />
Do not take words out of a book or other work. The words must be absolutely random.<br />
<br />
Do not use the xkcd password generation method.<br />
<br />
==Using dice==<br />
Dice can be used as one way to generate random numbers and passwords. However, in order to achieve security, you must use them in a certain way.<br />
<br />
===Secure dice===<br />
<br />
Casual dice for board games are not shaped perfectly, and will be somewhat biased toward certain numbers. Special casino dice are available which do not have this flaw.<br />
<br />
The extent to which slightly-biased dice actually affect real-world security depends on the use-case. For the use-cases on this page, if the dice is random enough to not notice its bias when playing games, then it is ''probably'' good enough.<br />
<br />
===Generating passwords===<br />
<br />
To generate passwords, write down a list of acceptable characters, and sequentially number each character starting from 1. For example, if you want to generate a 4-digit PIN, you would create a list like this:<br />
<br />
<pre>1 0<br />
2 1<br />
...<br />
10 9</pre><br />
<br />
If you wanted to generate a password with characters in [a-zA-Z], you would create a list like this:<br />
<pre>1 a<br />
2 b<br />
...<br />
52 Z</pre><br />
<br />
Now you need to figure out how many dice you're going to need to roll. Your dice should all have the same number of sides. If your character list has C characters, and each of your dice have S sides, then you need to roll log<sub>S</sub>(C) dice, rounded up. For example, log<sub>6</sub>(52) is about 2.2, which you round up to 3. So if your character list contains 52 characters, then you need to roll 3 6-sided dice.<br />
<br />
Here, the dice are assumed to be numbered from 1 to S. If this is not the case, then you must create a system to translate the dice results into a range from 1 to S. For example, if you are dealing with 10-sided dice labeled from 0 to 9, then you can add 1 to the roll.<br />
<br />
Roll the required number of dice and put them in a random order. Do not sort the dice from highest to lowest or anything like that. In fact, to prevent any personal bias from entering into the ordering, you may want to roll the dice and then put the dice into a line with your eyes closed.<br />
<br />
Say that d<sub>0</sub> is the rightmost dice you rolled, d<sub>1</sub> is the second-from-rightmost dice you rolled, etc. Then the random number is:<br />
<br />
1 + [(d<sub>0</sub> - 1) × S<sup>0</sup>] + [(d<sub>1</sub> - 1) × S<sup>1</sup>] + [(d<sub>2</sub> - 1) × S<sup>2</sup>] + ...<br />
<br />
For example, if we rolled 316 with 6-sided dice, this becomes:<br />
<br />
1 + [(6 - 1) × 6<sup>0</sup>] + [(1 - 1) × 6<sup>1</sup>] + [(3 - 1) × 6<sup>2</sup>]<br><br />
= 1 + [5 × 1] + [0 × 6] + [2 × 36]<br><br />
= 1 + 5 + 0 + 72<br><br />
= 78<br />
<br />
So our random character would be the 78<sup>th</sup> character in the list.<br />
<br />
'''Important''': If your number is larger than you need, then you must totally reroll for this character. Do not try to "wrap the numbers around" or keep only certain dice, as this results in a non-random distribution. (For the adventurous only: You can safely reduce the number of rerolls by pretending that the highest-order die has fewer sides. Eg. on a 6-sided die say that 1&4 = 1, 2&5 = 2, 3&6 = 3; or that 1&2&3 = 1 and 4&5&6 = 2. Still multiply it by the appropriate power of 6, not 3 or 2. But the die must be evenly divided, you must ensure that the maximum possible value is still greater than or equal to the highest-value character, and you must use the exact same treatment of the high-order die throughout the generation process.)<br />
<br />
'''Important''': There are a variety of different ways to get a random number from multiple dice, but they are usually non-random. For example, ''adding'' dice would be very non-random. The above method ensures a random distribution if the dice themselves are random and if they are ordered randomly.<br />
<br />
If the password is L characters long, then password has log<sub>2</sub>(C<sup>L</sup>) bits of entropy.<br />
<br />
===Generating passphrases===<br />
<br />
As above, but use a list of words instead of a list of characters.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Generating keys, seeds, and random numbers (Advanced)===<br />
<br />
This section is mainly intended for programmers and advanced users.<br />
<br />
Warning: it is considered unsafe to directly handle Bitcoin keys, as doing so is error-prone, and often causes people to send BTC into oblivion.<br />
<br />
If you want to generate a large number for use as a key or seed, you can do the following.<br />
<br />
First, decide how many bits of security you want. 128 bits is probably secure for most things. We will call this value B.<br />
<br />
Next, roll log<sub>S</sub>(2<sup>B</sup>) dice, rounded up, where S is the number of sides per die. For example, with 6-sided dice you would need to roll 50 dice. Put the results right next to each other in a string of text, so for example if you roll 3, 2, 5, 6, 1, you'd start your string as "32561", and then continue on for a total of 50 digits. If your dice have enough sides to result in two-digit numbers, put a leading zero in front of single-digit numbers.<br />
<br />
Then hash your string with a command like <tt>echo "32561..." |sha256sum</tt>. The resulting hash is your random number. If you want a 128-bit or 512-bit number use sha128sum or sha512sum, respectively. If you want some in-between number of bits, use the next larger hash size and then cut off the number where you need it.<br />
<br />
You can generate any size of random number by combining the outputs. For example, let's say that you want 768 bits of randomness and for some reason you can only use sha256sum. You can do this like:<br />
<br />
<pre>$ echo "32561..." |sha256sum<br />
cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed5 -<br />
$ echo "Last hash: cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed Orig entropy: 532561..." |sha256sum<br />
6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c -<br />
$ echo "Last hash: 6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c Orig entropy: 532561..." |sha256sum<br />
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -</pre><br />
<br />
Then concatenate all of those hashes to get your final random number. In this example the result is <tt>cf6a25b...52b855</tt>.<br />
<br />
'''Important''': When generating a stream of random numbers like this, you have to put your source entropy back in at each step.<br />
<br />
If you want to generate a number in a range with a range size that is not a power of two, choose the next-largest power of two and select the correct number of bits based on that. If the resulting number is too large, '''discard''' all of those bits and grab new ones from the endless stream of random bits. Do not use the modulo operator, as that introduces a bias. For example, if you want to generate a number from 0 to 9 (range size = 10), select the next-higher power of 2, 16. If your random stream starts 0xA52F..., grab 4 bits (log<sub>2</sub>(16) = 4), giving 0xA = 10. This is outside of the range, so discard those bits and move onto the next 4 bits, 0x5 = 5. This is in the range, so the final result is 5.<br />
<br />
==Using a computer==<br />
<br />
Computers are good at generating secure random numbers, but you have to be careful to use the right commands. A lot of commands, programming language features, and snippets that you'll find online will give ''insecure'' random numbers which look random, but are predictable. For example, the C <tt>rand</tt> function, the Python <tt>random</tt> module, and the Windows <tt>%RANDOM%</tt> variable are all insecure random number sources.<br />
<br />
<span style="color:red">'''Do not get your passwords from anything in a Web browser, even if the page says that it's using purely client-side JavaScript'''</span><br />
<br />
===Linux===<br />
<br />
There are many different packages for generating random passwords/passphrases on Linux, but none of them are installed by default on all Linux machines, so we will provide a method that uses more standard commands. If you would like a more concise and easy-to-use command, we recommend installing an actual password generator package.<br />
<br />
The following command will generate a 20-character random password:<br />
<br />
<pre>seq 126 |awk '{printf "%c", $0}' |grep -o '[a-zA-Z0-9]\|[[:punct:]]' | \<br />
shuf --random-source=/dev/urandom --repeat --head-count=20 | tr --delete '\n'</pre><br />
<br />
Change <tt>-head-count=20</tt> to change the password length, and <tt><nowiki>[a-zA-Z0-9]\|[[:punct:]]</nowiki></tt> to change the character set. Note that this command will never use characters outside of ASCII, even if your grep pattern would select such characters.<br />
<br />
To generate a passphrase made of words, create a file called <tt>words</tt> with one word per line and Unix-style line endings, and run:<br />
<br />
<pre>shuf --random-source=/dev/urandom --repeat --head-count=7 words | tr '\n' ' '</pre><br />
<br />
Change <tt>-head-count=7</tt> to change the number of words.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Windows===<br />
<br />
[http://keepass.info/ KeePass] includes a password generator, though not a word-based passphrase generator.<br />
<br />
(If anyone knows of some better ones, edit this page to add it.)<br />
<br />
== See also ==<br />
<br />
* [https://github.com/dropbox/zxcvbn zxcvbn] - A realistic passphrase strength estimator<br />
* [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne stores his Bitcoin] - introduction to WarpWallet<br />
* [[BitKey]] - Live USB/DVD that supports running zxcvbn and WarpWallet offline</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Passphrase_generation&diff=62153Passphrase generation2017-01-23T09:26:49Z<p>Liraz: See also section</p>
<hr />
<div>In various places in Bitcoin, it is important to generate secure passwords/passphrases. Security is especially important in Bitcoin because if your BTC is stolen, there is often no recourse. Bitcoin transactions cannot be reversed.<br />
<br />
==Strength==<br />
<br />
There are two very different use-cases for passwords in Bitcoin. The first and more common is an "offline passphrase". With an offline passphrase, something prevents an attacker from trying to guess your passphrase as fast as he might like. <br />
<br />
Examples include:<br />
<br />
* Website passwords. The website will rate-limit attempts on your password.<br />
* Wallet passphrases. An attacker needs both the wallet file and your wallet passphrase.<br />
* Hardware wallet PIN. An attacker needs both the hardware wallet and your PIN.<br />
<br />
All of the advice you've ever heard about password security has been for the offline password use-case.<br />
<br />
The second use-case is an "online passphrase", where the passphrase is essentially the ''only'' thing protecting your BTC. In this case, your passphrase much be ''massively'' more secure than usual, and you '''can not''' rely on any password-creation advice you've ever heard. <br />
<br />
For use cases that are vulnerable to a global passphrase cracking search, imagine that the entire world could be constantly trying to crack your passphrase, billions of attempts per second, all the time and with no restriction. This is not a normal situation outside of Bitcoin. <br />
<br />
Examples of keys that could be cracked by a global search:<br />
<br />
* The seed/mnemonic of an HD wallet.<br />
* The input to an insecure bitaddress-style "brain wallet"<br />
<br />
Example of keys that could be cracked by a targeted search:<br />
<br />
* The passphrase on a wallet file that may become public, or that an attacker could gain access to.<br />
* The input to a secure "brain wallet" with e-mail salting, and an expensive Key Derivation Function.<br />
<br />
== Crypto standards that increase resistance to passphrase cracking ==<br />
<br />
=== Key Derivation Functions ===<br />
<br />
Since humans are poor sources of entropy, whenever a passphrase is involved it is recommended to use programs that implement an attack resistant KDF ([https://en.wikipedia.org/wiki/Key_derivation_function Key Derivation Function]) to translate the user supplied passphrase into the ultimate encryption key. KDF functions are similar in concept to hashes such as SHA256, except that they are designed to be hard to compute. This slows down an attacker by increasing the computational cost of each passphrase cracking attempt, providing additional security per bit of entropy.<br />
<br />
KDF functions can usually be tuned to provide additional or less security by configuring how many rounds of encryption need to be executed to derive a key from a passphrase. Usability places an upper bound on the number of rounds. For example, a typical number of rounds is 2 ^ 18, or 262144 which may take half a minute on a modern computer.<br />
<br />
KDF functions such as Scrypt and PBKDF2 have good reputations. PBKDF2 is older and has received more scrutiny from the cryptographic community but is easier to accelerate by several orders of magnitude using custom parallel hardware. scrypt is newer and has received less scrutiny, but was specifically designed to be more difficult to accelerate using custom hardware. Some programs (e.g., WarpWallet) use both.<br />
<br />
A KDF can slow down advanced passphrase cracking attempts from billions of cracking attempts per second to hundreds of attempts per second.<br />
<br />
=== Salting ===<br />
<br />
Salting is a technique for cryptographically segmenting the passphrase cracking search space. <br />
Without salting, an attacker can attempt to crack all passphrases simultaneously in a global search space, increasing the expected ROI for his efforts. <br />
<br />
For example, some Brainwallet programs use e-mail based salting to thwart global dictionary attacks. an attacker can still attempt to crack a passphrase, but he has to calculate a different key for each potential e-mail in his list. An attacker can not know for certain than any particular e-mail has been used as a salt.<br />
<br />
== Standards for offline passphrases ==<br />
<br />
Between 64 and 80 bits of entropy seems reasonable. The password must be totally random (see later sections on generation). Hardware wallets have additional protections, and it's OK that they often allow only a short PIN.<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 20-25 digits<br />
* Hexadecimal: 16-20 characters<br />
* All lowercase or all uppercase letters: 14-18 characters<br />
* All lowercase or all uppercase letters + numbers: 13-16 characters<br />
* Mixed case letters: 12-15 characters<br />
* Mixed case letters + numbers: 11-14 characters<br />
* All standard keyboard characters: 9-11 characters<br />
* Diceware words: 5-7 words<br />
* Random English words (100,000-word wordlist): 4-5 words<br />
<br />
== Standards for online passphrases ==<br />
<br />
Usually you don't have to personally generate an online passphrase. The most common case of an online passphrase in Bitcoin is the mnemonic for an HD wallet seed, but your wallet should securely generate it for you (this is the several-word mnemonic that most wallets tell you to write down when first run).<br />
<br />
In case you need to manually generate an online passphrase, 128 bits of entropy is required. The passphrase must be totally random (see later sections on generation).<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 39 digits<br />
* Hexadecimal: 32 characters<br />
* All lowercase or all uppercase letters: 28 characters<br />
* All lowercase or all uppercase letters + numbers: 25 characters<br />
* Mixed case letters: 23 characters<br />
* Mixed case letters + numbers: 22 characters<br />
* All standard keyboard characters: 20 characters<br />
* Diceware words: 10 words<br />
* Random English words (100,000-word wordlist): 8 words<br />
<br />
==How not to generate passphrases==<br />
<br />
Humans are ''really, really'' bad at generating passphrases on their own. Don't try it. If at any step in the passphrase-generation process your brain is being used to choose something at random or randomize something, then you're doing it wrong.<br />
<br />
Do not take words out of a book or other work. The words must be absolutely random.<br />
<br />
Do not use the xkcd password generation method.<br />
<br />
==Using dice==<br />
Dice can be used as one way to generate random numbers and passwords. However, in order to achieve security, you must use them in a certain way.<br />
<br />
===Secure dice===<br />
<br />
Casual dice for board games are not shaped perfectly, and will be somewhat biased toward certain numbers. Special casino dice are available which do not have this flaw.<br />
<br />
The extent to which slightly-biased dice actually affect real-world security depends on the use-case. For the use-cases on this page, if the dice is random enough to not notice its bias when playing games, then it is ''probably'' good enough.<br />
<br />
===Generating passwords===<br />
<br />
To generate passwords, write down a list of acceptable characters, and sequentially number each character starting from 1. For example, if you want to generate a 4-digit PIN, you would create a list like this:<br />
<br />
<pre>1 0<br />
2 1<br />
...<br />
10 9</pre><br />
<br />
If you wanted to generate a password with characters in [a-zA-Z], you would create a list like this:<br />
<pre>1 a<br />
2 b<br />
...<br />
52 Z</pre><br />
<br />
Now you need to figure out how many dice you're going to need to roll. Your dice should all have the same number of sides. If your character list has C characters, and each of your dice have S sides, then you need to roll log<sub>S</sub>(C) dice, rounded up. For example, log<sub>6</sub>(52) is about 2.2, which you round up to 3. So if your character list contains 52 characters, then you need to roll 3 6-sided dice.<br />
<br />
Here, the dice are assumed to be numbered from 1 to S. If this is not the case, then you must create a system to translate the dice results into a range from 1 to S. For example, if you are dealing with 10-sided dice labeled from 0 to 9, then you can add 1 to the roll.<br />
<br />
Roll the required number of dice and put them in a random order. Do not sort the dice from highest to lowest or anything like that. In fact, to prevent any personal bias from entering into the ordering, you may want to roll the dice and then put the dice into a line with your eyes closed.<br />
<br />
Say that d<sub>0</sub> is the rightmost dice you rolled, d<sub>1</sub> is the second-from-rightmost dice you rolled, etc. Then the random number is:<br />
<br />
1 + [(d<sub>0</sub> - 1) × S<sup>0</sup>] + [(d<sub>1</sub> - 1) × S<sup>1</sup>] + [(d<sub>2</sub> - 1) × S<sup>2</sup>] + ...<br />
<br />
For example, if we rolled 316 with 6-sided dice, this becomes:<br />
<br />
1 + [(6 - 1) × 6<sup>0</sup>] + [(1 - 1) × 6<sup>1</sup>] + [(3 - 1) × 6<sup>2</sup>]<br><br />
= 1 + [5 × 1] + [0 × 6] + [2 × 36]<br><br />
= 1 + 5 + 0 + 72<br><br />
= 78<br />
<br />
So our random character would be the 78<sup>th</sup> character in the list.<br />
<br />
'''Important''': If your number is larger than you need, then you must totally reroll for this character. Do not try to "wrap the numbers around" or keep only certain dice, as this results in a non-random distribution. (For the adventurous only: You can safely reduce the number of rerolls by pretending that the highest-order die has fewer sides. Eg. on a 6-sided die say that 1&4 = 1, 2&5 = 2, 3&6 = 3; or that 1&2&3 = 1 and 4&5&6 = 2. Still multiply it by the appropriate power of 6, not 3 or 2. But the die must be evenly divided, you must ensure that the maximum possible value is still greater than or equal to the highest-value character, and you must use the exact same treatment of the high-order die throughout the generation process.)<br />
<br />
'''Important''': There are a variety of different ways to get a random number from multiple dice, but they are usually non-random. For example, ''adding'' dice would be very non-random. The above method ensures a random distribution if the dice themselves are random and if they are ordered randomly.<br />
<br />
If the password is L characters long, then password has log<sub>2</sub>(C<sup>L</sup>) bits of entropy.<br />
<br />
===Generating passphrases===<br />
<br />
As above, but use a list of words instead of a list of characters.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Generating keys, seeds, and random numbers (Advanced)===<br />
<br />
This section is mainly intended for programmers and advanced users.<br />
<br />
Warning: it is considered unsafe to directly handle Bitcoin keys, as doing so is error-prone, and often causes people to send BTC into oblivion.<br />
<br />
If you want to generate a large number for use as a key or seed, you can do the following.<br />
<br />
First, decide how many bits of security you want. 128 bits is probably secure for most things. We will call this value B.<br />
<br />
Next, roll log<sub>S</sub>(2<sup>B</sup>) dice, rounded up, where S is the number of sides per die. For example, with 6-sided dice you would need to roll 50 dice. Put the results right next to each other in a string of text, so for example if you roll 3, 2, 5, 6, 1, you'd start your string as "32561", and then continue on for a total of 50 digits. If your dice have enough sides to result in two-digit numbers, put a leading zero in front of single-digit numbers.<br />
<br />
Then hash your string with a command like <tt>echo "32561..." |sha256sum</tt>. The resulting hash is your random number. If you want a 128-bit or 512-bit number use sha128sum or sha512sum, respectively. If you want some in-between number of bits, use the next larger hash size and then cut off the number where you need it.<br />
<br />
You can generate any size of random number by combining the outputs. For example, let's say that you want 768 bits of randomness and for some reason you can only use sha256sum. You can do this like:<br />
<br />
<pre>$ echo "32561..." |sha256sum<br />
cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed5 -<br />
$ echo "Last hash: cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed Orig entropy: 532561..." |sha256sum<br />
6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c -<br />
$ echo "Last hash: 6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c Orig entropy: 532561..." |sha256sum<br />
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -</pre><br />
<br />
Then concatenate all of those hashes to get your final random number. In this example the result is <tt>cf6a25b...52b855</tt>.<br />
<br />
'''Important''': When generating a stream of random numbers like this, you have to put your source entropy back in at each step.<br />
<br />
If you want to generate a number in a range with a range size that is not a power of two, choose the next-largest power of two and select the correct number of bits based on that. If the resulting number is too large, '''discard''' all of those bits and grab new ones from the endless stream of random bits. Do not use the modulo operator, as that introduces a bias. For example, if you want to generate a number from 0 to 9 (range size = 10), select the next-higher power of 2, 16. If your random stream starts 0xA52F..., grab 4 bits (log<sub>2</sub>(16) = 4), giving 0xA = 10. This is outside of the range, so discard those bits and move onto the next 4 bits, 0x5 = 5. This is in the range, so the final result is 5.<br />
<br />
==Using a computer==<br />
<br />
Computers are good at generating secure random numbers, but you have to be careful to use the right commands. A lot of commands, programming language features, and snippets that you'll find online will give ''insecure'' random numbers which look random, but are predictable. For example, the C <tt>rand</tt> function, the Python <tt>random</tt> module, and the Windows <tt>%RANDOM%</tt> variable are all insecure random number sources.<br />
<br />
<span style="color:red">'''Do not get your passwords from anything in a Web browser, even if the page says that it's using purely client-side JavaScript'''</span><br />
<br />
===Linux===<br />
<br />
There are many different packages for generating random passwords/passphrases on Linux, but none of them are installed by default on all Linux machines, so we will provide a method that uses more standard commands. If you would like a more concise and easy-to-use command, we recommend installing an actual password generator package.<br />
<br />
The following command will generate a 20-character random password:<br />
<br />
<pre>seq 126 |awk '{printf "%c", $0}' |grep -o '[a-zA-Z0-9]\|[[:punct:]]' | \<br />
shuf --random-source=/dev/urandom --repeat --head-count=20 | tr --delete '\n'</pre><br />
<br />
Change <tt>-head-count=20</tt> to change the password length, and <tt><nowiki>[a-zA-Z0-9]\|[[:punct:]]</nowiki></tt> to change the character set. Note that this command will never use characters outside of ASCII, even if your grep pattern would select such characters.<br />
<br />
To generate a passphrase made of words, create a file called <tt>words</tt> with one word per line and Unix-style line endings, and run:<br />
<br />
<pre>shuf --random-source=/dev/urandom --repeat --head-count=7 words | tr '\n' ' '</pre><br />
<br />
Change <tt>-head-count=7</tt> to change the number of words.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Windows===<br />
<br />
[http://keepass.info/ KeePass] includes a password generator, though not a word-based passphrase generator.<br />
<br />
(If anyone knows of some better ones, edit this page to add it.)<br />
<br />
== See also ==<br />
<br />
* [https://github.com/dropbox/zxcvbn zxcvbn] - A realistic passphrase strength estimator<br />
* [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne stores his Bitcoin] - introduction to WarpWallet<br />
* [[BitKey]] - Live USB/DVD that supports running zxcvbn and WarpWallet offline</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Passphrase_generation&diff=62152Passphrase generation2017-01-23T09:19:37Z<p>Liraz: /* Strength */ KDFs now explained below</p>
<hr />
<div>In various places in Bitcoin, it is important to generate secure passwords/passphrases. Security is especially important in Bitcoin because if your BTC is stolen, there is often no recourse. Bitcoin transactions cannot be reversed.<br />
<br />
==Strength==<br />
<br />
There are two very different use-cases for passwords in Bitcoin. The first and more common is an "offline passphrase". With an offline passphrase, something prevents an attacker from trying to guess your passphrase as fast as he might like. <br />
<br />
Examples include:<br />
<br />
* Website passwords. The website will rate-limit attempts on your password.<br />
* Wallet passphrases. An attacker needs both the wallet file and your wallet passphrase.<br />
* Hardware wallet PIN. An attacker needs both the hardware wallet and your PIN.<br />
<br />
All of the advice you've ever heard about password security has been for the offline password use-case.<br />
<br />
The second use-case is an "online passphrase", where the passphrase is essentially the ''only'' thing protecting your BTC. In this case, your passphrase much be ''massively'' more secure than usual, and you '''can not''' rely on any password-creation advice you've ever heard. <br />
<br />
For use cases that are vulnerable to a global passphrase cracking search, imagine that the entire world could be constantly trying to crack your passphrase, billions of attempts per second, all the time and with no restriction. This is not a normal situation outside of Bitcoin. <br />
<br />
Examples of keys that could be cracked by a global search:<br />
<br />
* The seed/mnemonic of an HD wallet.<br />
* The input to an insecure bitaddress-style "brain wallet"<br />
<br />
Example of keys that could be cracked by a targeted search:<br />
<br />
* The passphrase on a wallet file that may become public, or that an attacker could gain access to.<br />
* The input to a secure "brain wallet" with e-mail salting, and an expensive Key Derivation Function.<br />
<br />
== Crypto standards that increase resistance to passphrase cracking ==<br />
<br />
=== Key Derivation Functions ===<br />
<br />
Since humans are poor sources of entropy, whenever a passphrase is involved it is recommended to use programs that implement an attack resistant KDF ([https://en.wikipedia.org/wiki/Key_derivation_function Key Derivation Function]) to translate the user supplied passphrase into the ultimate encryption key. KDF functions are similar in concept to hashes such as SHA256, except that they are designed to be hard to compute. This slows down an attacker by increasing the computational cost of each passphrase cracking attempt, providing additional security per bit of entropy.<br />
<br />
KDF functions can usually be tuned to provide additional or less security by configuring how many rounds of encryption need to be executed to derive a key from a passphrase. Usability places an upper bound on the number of rounds. For example, a typical number of rounds is 2 ^ 18, or 262144 which may take half a minute on a modern computer.<br />
<br />
KDF functions such as Scrypt and PBKDF2 have good reputations. PBKDF2 is older and has received more scrutiny from the cryptographic community but is easier to accelerate by several orders of magnitude using custom parallel hardware. scrypt is newer and has received less scrutiny, but was specifically designed to be more difficult to accelerate using custom hardware. Some programs (e.g., WarpWallet) use both.<br />
<br />
A KDF can slow down advanced passphrase cracking attempts from billions of cracking attempts per second to hundreds of attempts per second.<br />
<br />
=== Salting ===<br />
<br />
Salting is a technique for cryptographically segmenting the passphrase cracking search space. <br />
Without salting, an attacker can attempt to crack all passphrases simultaneously in a global search space, increasing the expected ROI for his efforts. <br />
<br />
For example, some Brainwallet programs use e-mail based salting to thwart global dictionary attacks. an attacker can still attempt to crack a passphrase, but he has to calculate a different key for each potential e-mail in his list. An attacker can not know for certain than any particular e-mail has been used as a salt.<br />
<br />
== Standards for offline passphrases ==<br />
<br />
Between 64 and 80 bits of entropy seems reasonable. The password must be totally random (see later sections on generation). Hardware wallets have additional protections, and it's OK that they often allow only a short PIN.<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 20-25 digits<br />
* Hexadecimal: 16-20 characters<br />
* All lowercase or all uppercase letters: 14-18 characters<br />
* All lowercase or all uppercase letters + numbers: 13-16 characters<br />
* Mixed case letters: 12-15 characters<br />
* Mixed case letters + numbers: 11-14 characters<br />
* All standard keyboard characters: 9-11 characters<br />
* Diceware words: 5-7 words<br />
* Random English words (100,000-word wordlist): 4-5 words<br />
<br />
== Standards for online passphrases ==<br />
<br />
Usually you don't have to personally generate an online passphrase. The most common case of an online passphrase in Bitcoin is the mnemonic for an HD wallet seed, but your wallet should securely generate it for you (this is the several-word mnemonic that most wallets tell you to write down when first run).<br />
<br />
In case you need to manually generate an online passphrase, 128 bits of entropy is required. The passphrase must be totally random (see later sections on generation).<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 39 digits<br />
* Hexadecimal: 32 characters<br />
* All lowercase or all uppercase letters: 28 characters<br />
* All lowercase or all uppercase letters + numbers: 25 characters<br />
* Mixed case letters: 23 characters<br />
* Mixed case letters + numbers: 22 characters<br />
* All standard keyboard characters: 20 characters<br />
* Diceware words: 10 words<br />
* Random English words (100,000-word wordlist): 8 words<br />
<br />
==How not to generate passphrases==<br />
<br />
Humans are ''really, really'' bad at generating passphrases on their own. Don't try it. If at any step in the passphrase-generation process your brain is being used to choose something at random or randomize something, then you're doing it wrong.<br />
<br />
Do not take words out of a book or other work. The words must be absolutely random.<br />
<br />
Do not use the xkcd password generation method.<br />
<br />
==Using dice==<br />
Dice can be used as one way to generate random numbers and passwords. However, in order to achieve security, you must use them in a certain way.<br />
<br />
===Secure dice===<br />
<br />
Casual dice for board games are not shaped perfectly, and will be somewhat biased toward certain numbers. Special casino dice are available which do not have this flaw.<br />
<br />
The extent to which slightly-biased dice actually affect real-world security depends on the use-case. For the use-cases on this page, if the dice is random enough to not notice its bias when playing games, then it is ''probably'' good enough.<br />
<br />
===Generating passwords===<br />
<br />
To generate passwords, write down a list of acceptable characters, and sequentially number each character starting from 1. For example, if you want to generate a 4-digit PIN, you would create a list like this:<br />
<br />
<pre>1 0<br />
2 1<br />
...<br />
10 9</pre><br />
<br />
If you wanted to generate a password with characters in [a-zA-Z], you would create a list like this:<br />
<pre>1 a<br />
2 b<br />
...<br />
52 Z</pre><br />
<br />
Now you need to figure out how many dice you're going to need to roll. Your dice should all have the same number of sides. If your character list has C characters, and each of your dice have S sides, then you need to roll log<sub>S</sub>(C) dice, rounded up. For example, log<sub>6</sub>(52) is about 2.2, which you round up to 3. So if your character list contains 52 characters, then you need to roll 3 6-sided dice.<br />
<br />
Here, the dice are assumed to be numbered from 1 to S. If this is not the case, then you must create a system to translate the dice results into a range from 1 to S. For example, if you are dealing with 10-sided dice labeled from 0 to 9, then you can add 1 to the roll.<br />
<br />
Roll the required number of dice and put them in a random order. Do not sort the dice from highest to lowest or anything like that. In fact, to prevent any personal bias from entering into the ordering, you may want to roll the dice and then put the dice into a line with your eyes closed.<br />
<br />
Say that d<sub>0</sub> is the rightmost dice you rolled, d<sub>1</sub> is the second-from-rightmost dice you rolled, etc. Then the random number is:<br />
<br />
1 + [(d<sub>0</sub> - 1) × S<sup>0</sup>] + [(d<sub>1</sub> - 1) × S<sup>1</sup>] + [(d<sub>2</sub> - 1) × S<sup>2</sup>] + ...<br />
<br />
For example, if we rolled 316 with 6-sided dice, this becomes:<br />
<br />
1 + [(6 - 1) × 6<sup>0</sup>] + [(1 - 1) × 6<sup>1</sup>] + [(3 - 1) × 6<sup>2</sup>]<br><br />
= 1 + [5 × 1] + [0 × 6] + [2 × 36]<br><br />
= 1 + 5 + 0 + 72<br><br />
= 78<br />
<br />
So our random character would be the 78<sup>th</sup> character in the list.<br />
<br />
'''Important''': If your number is larger than you need, then you must totally reroll for this character. Do not try to "wrap the numbers around" or keep only certain dice, as this results in a non-random distribution. (For the adventurous only: You can safely reduce the number of rerolls by pretending that the highest-order die has fewer sides. Eg. on a 6-sided die say that 1&4 = 1, 2&5 = 2, 3&6 = 3; or that 1&2&3 = 1 and 4&5&6 = 2. Still multiply it by the appropriate power of 6, not 3 or 2. But the die must be evenly divided, you must ensure that the maximum possible value is still greater than or equal to the highest-value character, and you must use the exact same treatment of the high-order die throughout the generation process.)<br />
<br />
'''Important''': There are a variety of different ways to get a random number from multiple dice, but they are usually non-random. For example, ''adding'' dice would be very non-random. The above method ensures a random distribution if the dice themselves are random and if they are ordered randomly.<br />
<br />
If the password is L characters long, then password has log<sub>2</sub>(C<sup>L</sup>) bits of entropy.<br />
<br />
===Generating passphrases===<br />
<br />
As above, but use a list of words instead of a list of characters.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Generating keys, seeds, and random numbers (Advanced)===<br />
<br />
This section is mainly intended for programmers and advanced users.<br />
<br />
Warning: it is considered unsafe to directly handle Bitcoin keys, as doing so is error-prone, and often causes people to send BTC into oblivion.<br />
<br />
If you want to generate a large number for use as a key or seed, you can do the following.<br />
<br />
First, decide how many bits of security you want. 128 bits is probably secure for most things. We will call this value B.<br />
<br />
Next, roll log<sub>S</sub>(2<sup>B</sup>) dice, rounded up, where S is the number of sides per die. For example, with 6-sided dice you would need to roll 50 dice. Put the results right next to each other in a string of text, so for example if you roll 3, 2, 5, 6, 1, you'd start your string as "32561", and then continue on for a total of 50 digits. If your dice have enough sides to result in two-digit numbers, put a leading zero in front of single-digit numbers.<br />
<br />
Then hash your string with a command like <tt>echo "32561..." |sha256sum</tt>. The resulting hash is your random number. If you want a 128-bit or 512-bit number use sha128sum or sha512sum, respectively. If you want some in-between number of bits, use the next larger hash size and then cut off the number where you need it.<br />
<br />
You can generate any size of random number by combining the outputs. For example, let's say that you want 768 bits of randomness and for some reason you can only use sha256sum. You can do this like:<br />
<br />
<pre>$ echo "32561..." |sha256sum<br />
cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed5 -<br />
$ echo "Last hash: cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed Orig entropy: 532561..." |sha256sum<br />
6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c -<br />
$ echo "Last hash: 6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c Orig entropy: 532561..." |sha256sum<br />
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -</pre><br />
<br />
Then concatenate all of those hashes to get your final random number. In this example the result is <tt>cf6a25b...52b855</tt>.<br />
<br />
'''Important''': When generating a stream of random numbers like this, you have to put your source entropy back in at each step.<br />
<br />
If you want to generate a number in a range with a range size that is not a power of two, choose the next-largest power of two and select the correct number of bits based on that. If the resulting number is too large, '''discard''' all of those bits and grab new ones from the endless stream of random bits. Do not use the modulo operator, as that introduces a bias. For example, if you want to generate a number from 0 to 9 (range size = 10), select the next-higher power of 2, 16. If your random stream starts 0xA52F..., grab 4 bits (log<sub>2</sub>(16) = 4), giving 0xA = 10. This is outside of the range, so discard those bits and move onto the next 4 bits, 0x5 = 5. This is in the range, so the final result is 5.<br />
<br />
==Using a computer==<br />
<br />
Computers are good at generating secure random numbers, but you have to be careful to use the right commands. A lot of commands, programming language features, and snippets that you'll find online will give ''insecure'' random numbers which look random, but are predictable. For example, the C <tt>rand</tt> function, the Python <tt>random</tt> module, and the Windows <tt>%RANDOM%</tt> variable are all insecure random number sources.<br />
<br />
<span style="color:red">'''Do not get your passwords from anything in a Web browser, even if the page says that it's using purely client-side JavaScript'''</span><br />
<br />
===Linux===<br />
<br />
There are many different packages for generating random passwords/passphrases on Linux, but none of them are installed by default on all Linux machines, so we will provide a method that uses more standard commands. If you would like a more concise and easy-to-use command, we recommend installing an actual password generator package.<br />
<br />
The following command will generate a 20-character random password:<br />
<br />
<pre>seq 126 |awk '{printf "%c", $0}' |grep -o '[a-zA-Z0-9]\|[[:punct:]]' | \<br />
shuf --random-source=/dev/urandom --repeat --head-count=20 | tr --delete '\n'</pre><br />
<br />
Change <tt>-head-count=20</tt> to change the password length, and <tt><nowiki>[a-zA-Z0-9]\|[[:punct:]]</nowiki></tt> to change the character set. Note that this command will never use characters outside of ASCII, even if your grep pattern would select such characters.<br />
<br />
To generate a passphrase made of words, create a file called <tt>words</tt> with one word per line and Unix-style line endings, and run:<br />
<br />
<pre>shuf --random-source=/dev/urandom --repeat --head-count=7 words | tr '\n' ' '</pre><br />
<br />
Change <tt>-head-count=7</tt> to change the number of words.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Windows===<br />
<br />
[http://keepass.info/ KeePass] includes a password generator, though not a word-based passphrase generator.<br />
<br />
(If anyone knows of some better ones, edit this page to add it.)</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Passphrase_generation&diff=62151Passphrase generation2017-01-23T09:18:53Z<p>Liraz: /* Strength */ give more concrete and accurate examples of passphrase attacks</p>
<hr />
<div>In various places in Bitcoin, it is important to generate secure passwords/passphrases. Security is especially important in Bitcoin because if your BTC is stolen, there is often no recourse. Bitcoin transactions cannot be reversed.<br />
<br />
==Strength==<br />
<br />
There are two very different use-cases for passwords in Bitcoin. The first and more common is an "offline passphrase". With an offline passphrase, something prevents an attacker from trying to guess your passphrase as fast as he might like. <br />
<br />
Examples include:<br />
<br />
* Website passwords. The website will rate-limit attempts on your password.<br />
* Wallet passphrases. An attacker needs both the wallet file and your wallet passphrase.<br />
* Hardware wallet PIN. An attacker needs both the hardware wallet and your PIN.<br />
<br />
All of the advice you've ever heard about password security has been for the offline password use-case.<br />
<br />
The second use-case is an "online passphrase", where the passphrase is essentially the ''only'' thing protecting your BTC. In this case, your passphrase much be ''massively'' more secure than usual, and you '''can not''' rely on any password-creation advice you've ever heard. <br />
<br />
For use cases that are vulnerable to a global passphrase cracking search, imagine that the entire world could be constantly trying to crack your passphrase, billions of attempts per second, all the time and with no restriction. This is not a normal situation outside of Bitcoin. <br />
<br />
Examples of keys that could be cracked by a global search:<br />
<br />
* The seed/mnemonic of an HD wallet.<br />
* The input to an insecure bitaddress-style "brain wallet"<br />
<br />
Example of keys that could be cracked by a targeted search:<br />
<br />
* The passphrase on a wallet file that may become public, or that an attacker could gain access to.<br />
* The input to a secure "brain wallet" with e-mail salting, and an expensive key derivation function (e.g., scrypt).<br />
<br />
== Crypto standards that increase resistance to passphrase cracking ==<br />
<br />
=== Key Derivation Functions ===<br />
<br />
Since humans are poor sources of entropy, whenever a passphrase is involved it is recommended to use programs that implement an attack resistant KDF ([https://en.wikipedia.org/wiki/Key_derivation_function Key Derivation Function]) to translate the user supplied passphrase into the ultimate encryption key. KDF functions are similar in concept to hashes such as SHA256, except that they are designed to be hard to compute. This slows down an attacker by increasing the computational cost of each passphrase cracking attempt, providing additional security per bit of entropy.<br />
<br />
KDF functions can usually be tuned to provide additional or less security by configuring how many rounds of encryption need to be executed to derive a key from a passphrase. Usability places an upper bound on the number of rounds. For example, a typical number of rounds is 2 ^ 18, or 262144 which may take half a minute on a modern computer.<br />
<br />
KDF functions such as Scrypt and PBKDF2 have good reputations. PBKDF2 is older and has received more scrutiny from the cryptographic community but is easier to accelerate by several orders of magnitude using custom parallel hardware. scrypt is newer and has received less scrutiny, but was specifically designed to be more difficult to accelerate using custom hardware. Some programs (e.g., WarpWallet) use both.<br />
<br />
A KDF can slow down advanced passphrase cracking attempts from billions of cracking attempts per second to hundreds of attempts per second.<br />
<br />
=== Salting ===<br />
<br />
Salting is a technique for cryptographically segmenting the passphrase cracking search space. <br />
Without salting, an attacker can attempt to crack all passphrases simultaneously in a global search space, increasing the expected ROI for his efforts. <br />
<br />
For example, some Brainwallet programs use e-mail based salting to thwart global dictionary attacks. an attacker can still attempt to crack a passphrase, but he has to calculate a different key for each potential e-mail in his list. An attacker can not know for certain than any particular e-mail has been used as a salt.<br />
<br />
== Standards for offline passphrases ==<br />
<br />
Between 64 and 80 bits of entropy seems reasonable. The password must be totally random (see later sections on generation). Hardware wallets have additional protections, and it's OK that they often allow only a short PIN.<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 20-25 digits<br />
* Hexadecimal: 16-20 characters<br />
* All lowercase or all uppercase letters: 14-18 characters<br />
* All lowercase or all uppercase letters + numbers: 13-16 characters<br />
* Mixed case letters: 12-15 characters<br />
* Mixed case letters + numbers: 11-14 characters<br />
* All standard keyboard characters: 9-11 characters<br />
* Diceware words: 5-7 words<br />
* Random English words (100,000-word wordlist): 4-5 words<br />
<br />
== Standards for online passphrases ==<br />
<br />
Usually you don't have to personally generate an online passphrase. The most common case of an online passphrase in Bitcoin is the mnemonic for an HD wallet seed, but your wallet should securely generate it for you (this is the several-word mnemonic that most wallets tell you to write down when first run).<br />
<br />
In case you need to manually generate an online passphrase, 128 bits of entropy is required. The passphrase must be totally random (see later sections on generation).<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 39 digits<br />
* Hexadecimal: 32 characters<br />
* All lowercase or all uppercase letters: 28 characters<br />
* All lowercase or all uppercase letters + numbers: 25 characters<br />
* Mixed case letters: 23 characters<br />
* Mixed case letters + numbers: 22 characters<br />
* All standard keyboard characters: 20 characters<br />
* Diceware words: 10 words<br />
* Random English words (100,000-word wordlist): 8 words<br />
<br />
==How not to generate passphrases==<br />
<br />
Humans are ''really, really'' bad at generating passphrases on their own. Don't try it. If at any step in the passphrase-generation process your brain is being used to choose something at random or randomize something, then you're doing it wrong.<br />
<br />
Do not take words out of a book or other work. The words must be absolutely random.<br />
<br />
Do not use the xkcd password generation method.<br />
<br />
==Using dice==<br />
Dice can be used as one way to generate random numbers and passwords. However, in order to achieve security, you must use them in a certain way.<br />
<br />
===Secure dice===<br />
<br />
Casual dice for board games are not shaped perfectly, and will be somewhat biased toward certain numbers. Special casino dice are available which do not have this flaw.<br />
<br />
The extent to which slightly-biased dice actually affect real-world security depends on the use-case. For the use-cases on this page, if the dice is random enough to not notice its bias when playing games, then it is ''probably'' good enough.<br />
<br />
===Generating passwords===<br />
<br />
To generate passwords, write down a list of acceptable characters, and sequentially number each character starting from 1. For example, if you want to generate a 4-digit PIN, you would create a list like this:<br />
<br />
<pre>1 0<br />
2 1<br />
...<br />
10 9</pre><br />
<br />
If you wanted to generate a password with characters in [a-zA-Z], you would create a list like this:<br />
<pre>1 a<br />
2 b<br />
...<br />
52 Z</pre><br />
<br />
Now you need to figure out how many dice you're going to need to roll. Your dice should all have the same number of sides. If your character list has C characters, and each of your dice have S sides, then you need to roll log<sub>S</sub>(C) dice, rounded up. For example, log<sub>6</sub>(52) is about 2.2, which you round up to 3. So if your character list contains 52 characters, then you need to roll 3 6-sided dice.<br />
<br />
Here, the dice are assumed to be numbered from 1 to S. If this is not the case, then you must create a system to translate the dice results into a range from 1 to S. For example, if you are dealing with 10-sided dice labeled from 0 to 9, then you can add 1 to the roll.<br />
<br />
Roll the required number of dice and put them in a random order. Do not sort the dice from highest to lowest or anything like that. In fact, to prevent any personal bias from entering into the ordering, you may want to roll the dice and then put the dice into a line with your eyes closed.<br />
<br />
Say that d<sub>0</sub> is the rightmost dice you rolled, d<sub>1</sub> is the second-from-rightmost dice you rolled, etc. Then the random number is:<br />
<br />
1 + [(d<sub>0</sub> - 1) × S<sup>0</sup>] + [(d<sub>1</sub> - 1) × S<sup>1</sup>] + [(d<sub>2</sub> - 1) × S<sup>2</sup>] + ...<br />
<br />
For example, if we rolled 316 with 6-sided dice, this becomes:<br />
<br />
1 + [(6 - 1) × 6<sup>0</sup>] + [(1 - 1) × 6<sup>1</sup>] + [(3 - 1) × 6<sup>2</sup>]<br><br />
= 1 + [5 × 1] + [0 × 6] + [2 × 36]<br><br />
= 1 + 5 + 0 + 72<br><br />
= 78<br />
<br />
So our random character would be the 78<sup>th</sup> character in the list.<br />
<br />
'''Important''': If your number is larger than you need, then you must totally reroll for this character. Do not try to "wrap the numbers around" or keep only certain dice, as this results in a non-random distribution. (For the adventurous only: You can safely reduce the number of rerolls by pretending that the highest-order die has fewer sides. Eg. on a 6-sided die say that 1&4 = 1, 2&5 = 2, 3&6 = 3; or that 1&2&3 = 1 and 4&5&6 = 2. Still multiply it by the appropriate power of 6, not 3 or 2. But the die must be evenly divided, you must ensure that the maximum possible value is still greater than or equal to the highest-value character, and you must use the exact same treatment of the high-order die throughout the generation process.)<br />
<br />
'''Important''': There are a variety of different ways to get a random number from multiple dice, but they are usually non-random. For example, ''adding'' dice would be very non-random. The above method ensures a random distribution if the dice themselves are random and if they are ordered randomly.<br />
<br />
If the password is L characters long, then password has log<sub>2</sub>(C<sup>L</sup>) bits of entropy.<br />
<br />
===Generating passphrases===<br />
<br />
As above, but use a list of words instead of a list of characters.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Generating keys, seeds, and random numbers (Advanced)===<br />
<br />
This section is mainly intended for programmers and advanced users.<br />
<br />
Warning: it is considered unsafe to directly handle Bitcoin keys, as doing so is error-prone, and often causes people to send BTC into oblivion.<br />
<br />
If you want to generate a large number for use as a key or seed, you can do the following.<br />
<br />
First, decide how many bits of security you want. 128 bits is probably secure for most things. We will call this value B.<br />
<br />
Next, roll log<sub>S</sub>(2<sup>B</sup>) dice, rounded up, where S is the number of sides per die. For example, with 6-sided dice you would need to roll 50 dice. Put the results right next to each other in a string of text, so for example if you roll 3, 2, 5, 6, 1, you'd start your string as "32561", and then continue on for a total of 50 digits. If your dice have enough sides to result in two-digit numbers, put a leading zero in front of single-digit numbers.<br />
<br />
Then hash your string with a command like <tt>echo "32561..." |sha256sum</tt>. The resulting hash is your random number. If you want a 128-bit or 512-bit number use sha128sum or sha512sum, respectively. If you want some in-between number of bits, use the next larger hash size and then cut off the number where you need it.<br />
<br />
You can generate any size of random number by combining the outputs. For example, let's say that you want 768 bits of randomness and for some reason you can only use sha256sum. You can do this like:<br />
<br />
<pre>$ echo "32561..." |sha256sum<br />
cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed5 -<br />
$ echo "Last hash: cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed Orig entropy: 532561..." |sha256sum<br />
6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c -<br />
$ echo "Last hash: 6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c Orig entropy: 532561..." |sha256sum<br />
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -</pre><br />
<br />
Then concatenate all of those hashes to get your final random number. In this example the result is <tt>cf6a25b...52b855</tt>.<br />
<br />
'''Important''': When generating a stream of random numbers like this, you have to put your source entropy back in at each step.<br />
<br />
If you want to generate a number in a range with a range size that is not a power of two, choose the next-largest power of two and select the correct number of bits based on that. If the resulting number is too large, '''discard''' all of those bits and grab new ones from the endless stream of random bits. Do not use the modulo operator, as that introduces a bias. For example, if you want to generate a number from 0 to 9 (range size = 10), select the next-higher power of 2, 16. If your random stream starts 0xA52F..., grab 4 bits (log<sub>2</sub>(16) = 4), giving 0xA = 10. This is outside of the range, so discard those bits and move onto the next 4 bits, 0x5 = 5. This is in the range, so the final result is 5.<br />
<br />
==Using a computer==<br />
<br />
Computers are good at generating secure random numbers, but you have to be careful to use the right commands. A lot of commands, programming language features, and snippets that you'll find online will give ''insecure'' random numbers which look random, but are predictable. For example, the C <tt>rand</tt> function, the Python <tt>random</tt> module, and the Windows <tt>%RANDOM%</tt> variable are all insecure random number sources.<br />
<br />
<span style="color:red">'''Do not get your passwords from anything in a Web browser, even if the page says that it's using purely client-side JavaScript'''</span><br />
<br />
===Linux===<br />
<br />
There are many different packages for generating random passwords/passphrases on Linux, but none of them are installed by default on all Linux machines, so we will provide a method that uses more standard commands. If you would like a more concise and easy-to-use command, we recommend installing an actual password generator package.<br />
<br />
The following command will generate a 20-character random password:<br />
<br />
<pre>seq 126 |awk '{printf "%c", $0}' |grep -o '[a-zA-Z0-9]\|[[:punct:]]' | \<br />
shuf --random-source=/dev/urandom --repeat --head-count=20 | tr --delete '\n'</pre><br />
<br />
Change <tt>-head-count=20</tt> to change the password length, and <tt><nowiki>[a-zA-Z0-9]\|[[:punct:]]</nowiki></tt> to change the character set. Note that this command will never use characters outside of ASCII, even if your grep pattern would select such characters.<br />
<br />
To generate a passphrase made of words, create a file called <tt>words</tt> with one word per line and Unix-style line endings, and run:<br />
<br />
<pre>shuf --random-source=/dev/urandom --repeat --head-count=7 words | tr '\n' ' '</pre><br />
<br />
Change <tt>-head-count=7</tt> to change the number of words.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Windows===<br />
<br />
[http://keepass.info/ KeePass] includes a password generator, though not a word-based passphrase generator.<br />
<br />
(If anyone knows of some better ones, edit this page to add it.)</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Passphrase_generation&diff=62150Passphrase generation2017-01-23T09:10:32Z<p>Liraz: crypto standards that increase resistant to passphrase cracking</p>
<hr />
<div>In various places in Bitcoin, it is important to generate secure passwords/passphrases. Security is especially important in Bitcoin because if your BTC is stolen, there is often no recourse. Bitcoin transactions cannot be reversed.<br />
<br />
==Strength==<br />
<br />
There are two very different use-cases for passwords in Bitcoin. The first and more common is an "offline passphrase". With an offline passphrase, something prevents an attacker from trying to guess your passphrase as fast as he might like. <br />
<br />
Examples include:<br />
<br />
* Website passwords. The website will rate-limit attempts on your password.<br />
* Wallet passphrases. An attacker needs both the wallet file and your wallet passphrase.<br />
* Hardware wallet PIN. An attacker needs both the hardware wallet and your PIN.<br />
<br />
All of the advice you've ever heard about password security has been for the offline password use-case.<br />
<br />
The second use-case is an "online passphrase", where the passphrase is essentially the ''only'' thing protecting your BTC. In this case, your passphrase much be ''massively'' more secure than usual, and you '''can not''' rely on any password-creation advice you've ever heard. Essentially, the entire world will be constantly trying to attack your passphrase at full force and with no restriction. This is not a normal situation outside of Bitcoin. <br />
<br />
Examples include:<br />
<br />
* The seed/mnemonic of an HD wallet.<br />
* The passphrase on a wallet file that may become public, or that an attacker could gain access to.<br />
* The input to an insecure bitaddress-style "brain wallet" <br />
* The input to a secure "brain wallet" with e-mail salting, and an expensive key derivation function (e.g., scrypt).<br />
<br />
== Crypto standards that increase resistance to passphrase cracking ==<br />
<br />
=== Key Derivation Functions ===<br />
<br />
Since humans are poor sources of entropy, whenever a passphrase is involved it is recommended to use programs that implement an attack resistant KDF ([https://en.wikipedia.org/wiki/Key_derivation_function Key Derivation Function]) to translate the user supplied passphrase into the ultimate encryption key. KDF functions are similar in concept to hashes such as SHA256, except that they are designed to be hard to compute. This slows down an attacker by increasing the computational cost of each passphrase cracking attempt, providing additional security per bit of entropy.<br />
<br />
KDF functions can usually be tuned to provide additional or less security by configuring how many rounds of encryption need to be executed to derive a key from a passphrase. Usability places an upper bound on the number of rounds. For example, a typical number of rounds is 2 ^ 18, or 262144 which may take half a minute on a modern computer.<br />
<br />
KDF functions such as Scrypt and PBKDF2 have good reputations. PBKDF2 is older and has received more scrutiny from the cryptographic community but is easier to accelerate by several orders of magnitude using custom parallel hardware. scrypt is newer and has received less scrutiny, but was specifically designed to be more difficult to accelerate using custom hardware. Some programs (e.g., WarpWallet) use both.<br />
<br />
A KDF can slow down advanced passphrase cracking attempts from billions of cracking attempts per second to hundreds of attempts per second.<br />
<br />
=== Salting ===<br />
<br />
Salting is a technique for cryptographically segmenting the passphrase cracking search space. <br />
Without salting, an attacker can attempt to crack all passphrases simultaneously in a global search space, increasing the expected ROI for his efforts. <br />
<br />
For example, some Brainwallet programs use e-mail based salting to thwart global dictionary attacks. an attacker can still attempt to crack a passphrase, but he has to calculate a different key for each potential e-mail in his list. An attacker can not know for certain than any particular e-mail has been used as a salt.<br />
<br />
== Standards for offline passphrases ==<br />
<br />
Between 64 and 80 bits of entropy seems reasonable. The password must be totally random (see later sections on generation). Hardware wallets have additional protections, and it's OK that they often allow only a short PIN.<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 20-25 digits<br />
* Hexadecimal: 16-20 characters<br />
* All lowercase or all uppercase letters: 14-18 characters<br />
* All lowercase or all uppercase letters + numbers: 13-16 characters<br />
* Mixed case letters: 12-15 characters<br />
* Mixed case letters + numbers: 11-14 characters<br />
* All standard keyboard characters: 9-11 characters<br />
* Diceware words: 5-7 words<br />
* Random English words (100,000-word wordlist): 4-5 words<br />
<br />
== Standards for online passphrases ==<br />
<br />
Usually you don't have to personally generate an online passphrase. The most common case of an online passphrase in Bitcoin is the mnemonic for an HD wallet seed, but your wallet should securely generate it for you (this is the several-word mnemonic that most wallets tell you to write down when first run).<br />
<br />
In case you need to manually generate an online passphrase, 128 bits of entropy is required. The passphrase must be totally random (see later sections on generation).<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 39 digits<br />
* Hexadecimal: 32 characters<br />
* All lowercase or all uppercase letters: 28 characters<br />
* All lowercase or all uppercase letters + numbers: 25 characters<br />
* Mixed case letters: 23 characters<br />
* Mixed case letters + numbers: 22 characters<br />
* All standard keyboard characters: 20 characters<br />
* Diceware words: 10 words<br />
* Random English words (100,000-word wordlist): 8 words<br />
<br />
==How not to generate passphrases==<br />
<br />
Humans are ''really, really'' bad at generating passphrases on their own. Don't try it. If at any step in the passphrase-generation process your brain is being used to choose something at random or randomize something, then you're doing it wrong.<br />
<br />
Do not take words out of a book or other work. The words must be absolutely random.<br />
<br />
Do not use the xkcd password generation method.<br />
<br />
==Using dice==<br />
Dice can be used as one way to generate random numbers and passwords. However, in order to achieve security, you must use them in a certain way.<br />
<br />
===Secure dice===<br />
<br />
Casual dice for board games are not shaped perfectly, and will be somewhat biased toward certain numbers. Special casino dice are available which do not have this flaw.<br />
<br />
The extent to which slightly-biased dice actually affect real-world security depends on the use-case. For the use-cases on this page, if the dice is random enough to not notice its bias when playing games, then it is ''probably'' good enough.<br />
<br />
===Generating passwords===<br />
<br />
To generate passwords, write down a list of acceptable characters, and sequentially number each character starting from 1. For example, if you want to generate a 4-digit PIN, you would create a list like this:<br />
<br />
<pre>1 0<br />
2 1<br />
...<br />
10 9</pre><br />
<br />
If you wanted to generate a password with characters in [a-zA-Z], you would create a list like this:<br />
<pre>1 a<br />
2 b<br />
...<br />
52 Z</pre><br />
<br />
Now you need to figure out how many dice you're going to need to roll. Your dice should all have the same number of sides. If your character list has C characters, and each of your dice have S sides, then you need to roll log<sub>S</sub>(C) dice, rounded up. For example, log<sub>6</sub>(52) is about 2.2, which you round up to 3. So if your character list contains 52 characters, then you need to roll 3 6-sided dice.<br />
<br />
Here, the dice are assumed to be numbered from 1 to S. If this is not the case, then you must create a system to translate the dice results into a range from 1 to S. For example, if you are dealing with 10-sided dice labeled from 0 to 9, then you can add 1 to the roll.<br />
<br />
Roll the required number of dice and put them in a random order. Do not sort the dice from highest to lowest or anything like that. In fact, to prevent any personal bias from entering into the ordering, you may want to roll the dice and then put the dice into a line with your eyes closed.<br />
<br />
Say that d<sub>0</sub> is the rightmost dice you rolled, d<sub>1</sub> is the second-from-rightmost dice you rolled, etc. Then the random number is:<br />
<br />
1 + [(d<sub>0</sub> - 1) × S<sup>0</sup>] + [(d<sub>1</sub> - 1) × S<sup>1</sup>] + [(d<sub>2</sub> - 1) × S<sup>2</sup>] + ...<br />
<br />
For example, if we rolled 316 with 6-sided dice, this becomes:<br />
<br />
1 + [(6 - 1) × 6<sup>0</sup>] + [(1 - 1) × 6<sup>1</sup>] + [(3 - 1) × 6<sup>2</sup>]<br><br />
= 1 + [5 × 1] + [0 × 6] + [2 × 36]<br><br />
= 1 + 5 + 0 + 72<br><br />
= 78<br />
<br />
So our random character would be the 78<sup>th</sup> character in the list.<br />
<br />
'''Important''': If your number is larger than you need, then you must totally reroll for this character. Do not try to "wrap the numbers around" or keep only certain dice, as this results in a non-random distribution. (For the adventurous only: You can safely reduce the number of rerolls by pretending that the highest-order die has fewer sides. Eg. on a 6-sided die say that 1&4 = 1, 2&5 = 2, 3&6 = 3; or that 1&2&3 = 1 and 4&5&6 = 2. Still multiply it by the appropriate power of 6, not 3 or 2. But the die must be evenly divided, you must ensure that the maximum possible value is still greater than or equal to the highest-value character, and you must use the exact same treatment of the high-order die throughout the generation process.)<br />
<br />
'''Important''': There are a variety of different ways to get a random number from multiple dice, but they are usually non-random. For example, ''adding'' dice would be very non-random. The above method ensures a random distribution if the dice themselves are random and if they are ordered randomly.<br />
<br />
If the password is L characters long, then password has log<sub>2</sub>(C<sup>L</sup>) bits of entropy.<br />
<br />
===Generating passphrases===<br />
<br />
As above, but use a list of words instead of a list of characters.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Generating keys, seeds, and random numbers (Advanced)===<br />
<br />
This section is mainly intended for programmers and advanced users.<br />
<br />
Warning: it is considered unsafe to directly handle Bitcoin keys, as doing so is error-prone, and often causes people to send BTC into oblivion.<br />
<br />
If you want to generate a large number for use as a key or seed, you can do the following.<br />
<br />
First, decide how many bits of security you want. 128 bits is probably secure for most things. We will call this value B.<br />
<br />
Next, roll log<sub>S</sub>(2<sup>B</sup>) dice, rounded up, where S is the number of sides per die. For example, with 6-sided dice you would need to roll 50 dice. Put the results right next to each other in a string of text, so for example if you roll 3, 2, 5, 6, 1, you'd start your string as "32561", and then continue on for a total of 50 digits. If your dice have enough sides to result in two-digit numbers, put a leading zero in front of single-digit numbers.<br />
<br />
Then hash your string with a command like <tt>echo "32561..." |sha256sum</tt>. The resulting hash is your random number. If you want a 128-bit or 512-bit number use sha128sum or sha512sum, respectively. If you want some in-between number of bits, use the next larger hash size and then cut off the number where you need it.<br />
<br />
You can generate any size of random number by combining the outputs. For example, let's say that you want 768 bits of randomness and for some reason you can only use sha256sum. You can do this like:<br />
<br />
<pre>$ echo "32561..." |sha256sum<br />
cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed5 -<br />
$ echo "Last hash: cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed Orig entropy: 532561..." |sha256sum<br />
6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c -<br />
$ echo "Last hash: 6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c Orig entropy: 532561..." |sha256sum<br />
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -</pre><br />
<br />
Then concatenate all of those hashes to get your final random number. In this example the result is <tt>cf6a25b...52b855</tt>.<br />
<br />
'''Important''': When generating a stream of random numbers like this, you have to put your source entropy back in at each step.<br />
<br />
If you want to generate a number in a range with a range size that is not a power of two, choose the next-largest power of two and select the correct number of bits based on that. If the resulting number is too large, '''discard''' all of those bits and grab new ones from the endless stream of random bits. Do not use the modulo operator, as that introduces a bias. For example, if you want to generate a number from 0 to 9 (range size = 10), select the next-higher power of 2, 16. If your random stream starts 0xA52F..., grab 4 bits (log<sub>2</sub>(16) = 4), giving 0xA = 10. This is outside of the range, so discard those bits and move onto the next 4 bits, 0x5 = 5. This is in the range, so the final result is 5.<br />
<br />
==Using a computer==<br />
<br />
Computers are good at generating secure random numbers, but you have to be careful to use the right commands. A lot of commands, programming language features, and snippets that you'll find online will give ''insecure'' random numbers which look random, but are predictable. For example, the C <tt>rand</tt> function, the Python <tt>random</tt> module, and the Windows <tt>%RANDOM%</tt> variable are all insecure random number sources.<br />
<br />
<span style="color:red">'''Do not get your passwords from anything in a Web browser, even if the page says that it's using purely client-side JavaScript'''</span><br />
<br />
===Linux===<br />
<br />
There are many different packages for generating random passwords/passphrases on Linux, but none of them are installed by default on all Linux machines, so we will provide a method that uses more standard commands. If you would like a more concise and easy-to-use command, we recommend installing an actual password generator package.<br />
<br />
The following command will generate a 20-character random password:<br />
<br />
<pre>seq 126 |awk '{printf "%c", $0}' |grep -o '[a-zA-Z0-9]\|[[:punct:]]' | \<br />
shuf --random-source=/dev/urandom --repeat --head-count=20 | tr --delete '\n'</pre><br />
<br />
Change <tt>-head-count=20</tt> to change the password length, and <tt><nowiki>[a-zA-Z0-9]\|[[:punct:]]</nowiki></tt> to change the character set. Note that this command will never use characters outside of ASCII, even if your grep pattern would select such characters.<br />
<br />
To generate a passphrase made of words, create a file called <tt>words</tt> with one word per line and Unix-style line endings, and run:<br />
<br />
<pre>shuf --random-source=/dev/urandom --repeat --head-count=7 words | tr '\n' ' '</pre><br />
<br />
Change <tt>-head-count=7</tt> to change the number of words.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Windows===<br />
<br />
[http://keepass.info/ KeePass] includes a password generator, though not a word-based passphrase generator.<br />
<br />
(If anyone knows of some better ones, edit this page to add it.)</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Passphrase_generation&diff=62149Passphrase generation2017-01-23T08:25:45Z<p>Liraz: /* Strength */ update brainwallet advice to state of the art</p>
<hr />
<div>In various places in Bitcoin, it is important to generate secure passwords/passphrases. Security is especially important in Bitcoin because if your BTC is stolen, there is often no recourse. Bitcoin transactions cannot be reversed.<br />
<br />
==Strength==<br />
<br />
There are two very different use-cases for passwords in Bitcoin. The first and more common is an "offline passphrase". With an offline passphrase, something prevents an attacker from trying to guess your passphrase as fast as he might like. Examples include:<br />
<br />
* Website passwords. The website will rate-limit attempts on your password.<br />
* Wallet passphrases. An attacker needs both the wallet file and your wallet passphrase.<br />
* Hardware wallet PIN. An attacker needs both the hardware wallet and your PIN.<br />
<br />
All of the advice you've ever heard about password security has been for the offline password use-case.<br />
<br />
The second use-case is an "online passphrase", where the passphrase is essentially the ''only'' thing protecting your BTC. In this case, your passphrase much be ''massively'' more secure than usual, and you '''can not''' rely on any password-creation advice you've ever heard. Essentially, the entire world will be constantly trying to attack your passphrase at full force and with no restriction. This is not a normal situation outside of Bitcoin. <br />
<br />
Examples include:<br />
<br />
* The seed/mnemonic of an HD wallet.<br />
* The passphrase on a wallet file that may become public, or that an attacker has otherwise gained access to.<br />
* The input to a secure "brain wallet" with e-mail salting, and an expensive key derivation function (e.g., scrypt).<br />
<br />
=== Standards for offline passphrases ===<br />
<br />
Between 64 and 80 bits of entropy seems reasonable. The password must be totally random (see later sections on generation). Hardware wallets have additional protections, and it's OK that they often allow only a short PIN.<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 20-25 digits<br />
* Hexadecimal: 16-20 characters<br />
* All lowercase or all uppercase letters: 14-18 characters<br />
* All lowercase or all uppercase letters + numbers: 13-16 characters<br />
* Mixed case letters: 12-15 characters<br />
* Mixed case letters + numbers: 11-14 characters<br />
* All standard keyboard characters: 9-11 characters<br />
* Diceware words: 5-7 words<br />
* Random English words (100,000-word wordlist): 4-5 words<br />
<br />
=== Standards for online passphrases ===<br />
<br />
Usually you don't have to personally generate an online passphrase. The most common case of an online passphrase in Bitcoin is the mnemonic for an HD wallet seed, but your wallet should securely generate it for you (this is the several-word mnemonic that most wallets tell you to write down when first run).<br />
<br />
In case you need to manually generate an online passphrase, 128 bits of entropy is required. The passphrase must be totally random (see later sections on generation).<br />
<br />
This corresponds to the following password/passphrase lengths:<br />
<br />
* Digits only: 39 digits<br />
* Hexadecimal: 32 characters<br />
* All lowercase or all uppercase letters: 28 characters<br />
* All lowercase or all uppercase letters + numbers: 25 characters<br />
* Mixed case letters: 23 characters<br />
* Mixed case letters + numbers: 22 characters<br />
* All standard keyboard characters: 20 characters<br />
* Diceware words: 10 words<br />
* Random English words (100,000-word wordlist): 8 words<br />
<br />
==How not to generate passphrases==<br />
<br />
Humans are ''really, really'' bad at generating passphrases on their own. Don't try it. If at any step in the passphrase-generation process your brain is being used to choose something at random or randomize something, then you're doing it wrong.<br />
<br />
Do not take words out of a book or other work. The words must be absolutely random.<br />
<br />
Do not use the xkcd password generation method.<br />
<br />
==Using dice==<br />
Dice can be used as one way to generate random numbers and passwords. However, in order to achieve security, you must use them in a certain way.<br />
<br />
===Secure dice===<br />
<br />
Casual dice for board games are not shaped perfectly, and will be somewhat biased toward certain numbers. Special casino dice are available which do not have this flaw.<br />
<br />
The extent to which slightly-biased dice actually affect real-world security depends on the use-case. For the use-cases on this page, if the dice is random enough to not notice its bias when playing games, then it is ''probably'' good enough.<br />
<br />
===Generating passwords===<br />
<br />
To generate passwords, write down a list of acceptable characters, and sequentially number each character starting from 1. For example, if you want to generate a 4-digit PIN, you would create a list like this:<br />
<br />
<pre>1 0<br />
2 1<br />
...<br />
10 9</pre><br />
<br />
If you wanted to generate a password with characters in [a-zA-Z], you would create a list like this:<br />
<pre>1 a<br />
2 b<br />
...<br />
52 Z</pre><br />
<br />
Now you need to figure out how many dice you're going to need to roll. Your dice should all have the same number of sides. If your character list has C characters, and each of your dice have S sides, then you need to roll log<sub>S</sub>(C) dice, rounded up. For example, log<sub>6</sub>(52) is about 2.2, which you round up to 3. So if your character list contains 52 characters, then you need to roll 3 6-sided dice.<br />
<br />
Here, the dice are assumed to be numbered from 1 to S. If this is not the case, then you must create a system to translate the dice results into a range from 1 to S. For example, if you are dealing with 10-sided dice labeled from 0 to 9, then you can add 1 to the roll.<br />
<br />
Roll the required number of dice and put them in a random order. Do not sort the dice from highest to lowest or anything like that. In fact, to prevent any personal bias from entering into the ordering, you may want to roll the dice and then put the dice into a line with your eyes closed.<br />
<br />
Say that d<sub>0</sub> is the rightmost dice you rolled, d<sub>1</sub> is the second-from-rightmost dice you rolled, etc. Then the random number is:<br />
<br />
1 + [(d<sub>0</sub> - 1) × S<sup>0</sup>] + [(d<sub>1</sub> - 1) × S<sup>1</sup>] + [(d<sub>2</sub> - 1) × S<sup>2</sup>] + ...<br />
<br />
For example, if we rolled 316 with 6-sided dice, this becomes:<br />
<br />
1 + [(6 - 1) × 6<sup>0</sup>] + [(1 - 1) × 6<sup>1</sup>] + [(3 - 1) × 6<sup>2</sup>]<br><br />
= 1 + [5 × 1] + [0 × 6] + [2 × 36]<br><br />
= 1 + 5 + 0 + 72<br><br />
= 78<br />
<br />
So our random character would be the 78<sup>th</sup> character in the list.<br />
<br />
'''Important''': If your number is larger than you need, then you must totally reroll for this character. Do not try to "wrap the numbers around" or keep only certain dice, as this results in a non-random distribution. (For the adventurous only: You can safely reduce the number of rerolls by pretending that the highest-order die has fewer sides. Eg. on a 6-sided die say that 1&4 = 1, 2&5 = 2, 3&6 = 3; or that 1&2&3 = 1 and 4&5&6 = 2. Still multiply it by the appropriate power of 6, not 3 or 2. But the die must be evenly divided, you must ensure that the maximum possible value is still greater than or equal to the highest-value character, and you must use the exact same treatment of the high-order die throughout the generation process.)<br />
<br />
'''Important''': There are a variety of different ways to get a random number from multiple dice, but they are usually non-random. For example, ''adding'' dice would be very non-random. The above method ensures a random distribution if the dice themselves are random and if they are ordered randomly.<br />
<br />
If the password is L characters long, then password has log<sub>2</sub>(C<sup>L</sup>) bits of entropy.<br />
<br />
===Generating passphrases===<br />
<br />
As above, but use a list of words instead of a list of characters.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Generating keys, seeds, and random numbers (Advanced)===<br />
<br />
This section is mainly intended for programmers and advanced users.<br />
<br />
Warning: it is considered unsafe to directly handle Bitcoin keys, as doing so is error-prone, and often causes people to send BTC into oblivion.<br />
<br />
If you want to generate a large number for use as a key or seed, you can do the following.<br />
<br />
First, decide how many bits of security you want. 128 bits is probably secure for most things. We will call this value B.<br />
<br />
Next, roll log<sub>S</sub>(2<sup>B</sup>) dice, rounded up, where S is the number of sides per die. For example, with 6-sided dice you would need to roll 50 dice. Put the results right next to each other in a string of text, so for example if you roll 3, 2, 5, 6, 1, you'd start your string as "32561", and then continue on for a total of 50 digits. If your dice have enough sides to result in two-digit numbers, put a leading zero in front of single-digit numbers.<br />
<br />
Then hash your string with a command like <tt>echo "32561..." |sha256sum</tt>. The resulting hash is your random number. If you want a 128-bit or 512-bit number use sha128sum or sha512sum, respectively. If you want some in-between number of bits, use the next larger hash size and then cut off the number where you need it.<br />
<br />
You can generate any size of random number by combining the outputs. For example, let's say that you want 768 bits of randomness and for some reason you can only use sha256sum. You can do this like:<br />
<br />
<pre>$ echo "32561..." |sha256sum<br />
cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed5 -<br />
$ echo "Last hash: cf6a25b9ef81af3d2b1d6f62a9780637f5e27720cafb07bb0515228ada325ed Orig entropy: 532561..." |sha256sum<br />
6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c -<br />
$ echo "Last hash: 6d7f302e01da0a7131377d57ee93aaff0b26ebd25e52c7dea0a5eeddabac151c Orig entropy: 532561..." |sha256sum<br />
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -</pre><br />
<br />
Then concatenate all of those hashes to get your final random number. In this example the result is <tt>cf6a25b...52b855</tt>.<br />
<br />
'''Important''': When generating a stream of random numbers like this, you have to put your source entropy back in at each step.<br />
<br />
If you want to generate a number in a range with a range size that is not a power of two, choose the next-largest power of two and select the correct number of bits based on that. If the resulting number is too large, '''discard''' all of those bits and grab new ones from the endless stream of random bits. Do not use the modulo operator, as that introduces a bias. For example, if you want to generate a number from 0 to 9 (range size = 10), select the next-higher power of 2, 16. If your random stream starts 0xA52F..., grab 4 bits (log<sub>2</sub>(16) = 4), giving 0xA = 10. This is outside of the range, so discard those bits and move onto the next 4 bits, 0x5 = 5. This is in the range, so the final result is 5.<br />
<br />
==Using a computer==<br />
<br />
Computers are good at generating secure random numbers, but you have to be careful to use the right commands. A lot of commands, programming language features, and snippets that you'll find online will give ''insecure'' random numbers which look random, but are predictable. For example, the C <tt>rand</tt> function, the Python <tt>random</tt> module, and the Windows <tt>%RANDOM%</tt> variable are all insecure random number sources.<br />
<br />
<span style="color:red">'''Do not get your passwords from anything in a Web browser, even if the page says that it's using purely client-side JavaScript'''</span><br />
<br />
===Linux===<br />
<br />
There are many different packages for generating random passwords/passphrases on Linux, but none of them are installed by default on all Linux machines, so we will provide a method that uses more standard commands. If you would like a more concise and easy-to-use command, we recommend installing an actual password generator package.<br />
<br />
The following command will generate a 20-character random password:<br />
<br />
<pre>seq 126 |awk '{printf "%c", $0}' |grep -o '[a-zA-Z0-9]\|[[:punct:]]' | \<br />
shuf --random-source=/dev/urandom --repeat --head-count=20 | tr --delete '\n'</pre><br />
<br />
Change <tt>-head-count=20</tt> to change the password length, and <tt><nowiki>[a-zA-Z0-9]\|[[:punct:]]</nowiki></tt> to change the character set. Note that this command will never use characters outside of ASCII, even if your grep pattern would select such characters.<br />
<br />
To generate a passphrase made of words, create a file called <tt>words</tt> with one word per line and Unix-style line endings, and run:<br />
<br />
<pre>shuf --random-source=/dev/urandom --repeat --head-count=7 words | tr '\n' ' '</pre><br />
<br />
Change <tt>-head-count=7</tt> to change the number of words.<br />
<br />
Note that there is a risk when acquiring your wordlist of an attacker giving you a wordlist that has duplicated or highly similar words. For example, the wordlist might look like it contains 1 million words, but actually be the same 1000 words repeated over and over again. Or all of the words might have an "o" in the fourth position. Etc. This can cause you to significantly overestimate the security of your passphrase. Therefore, you must acquire your wordlist from a trusted source.<br />
<br />
===Windows===<br />
<br />
[http://keepass.info/ KeePass] includes a password generator, though not a word-based passphrase generator.<br />
<br />
(If anyone knows of some better ones, edit this page to add it.)</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62148Hardware wallet2017-01-22T21:22:45Z<p>Liraz: /* Security risks */ internal links to cold storage</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security risks ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it's important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail to protect your Bitcoin:<br />
<br />
# '''Malware swaps recipient Bitcoin addresses''': a hardware wallet won't protect you from being tricked into sending Bitcoin to the wrong address. For example, malware on a PC could monitor for high value transactions and then swap out the recipient's authentic Bitcoin address for an address controlled by the attacker. When the stakes are high, multi factor (e.g., over the phone) confirmation of a recipient's Bitcoin address is recommended.<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* [[Cold storage]] solutions implemented with open source software and general purpose hardware (e.g., [[BitKey]], Pi Wallet), using a verifiable source of entropy such as physical dice may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Commercial hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]: slush's Hardware wallet wire protocol discussion<br />
* [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 Re: Split private keys]: kjj's Todo List discussion for client protocol requirements<br />
* [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Bitcoin Hardware Wallet Comparison] - information about using Bitcoin hardware wallets for cold storage.<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62147Hardware wallet2017-01-22T18:20:57Z<p>Liraz: /* Security risks */</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security risks ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it's important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail to protect your Bitcoin:<br />
<br />
# '''Malware swaps recipient Bitcoin addresses''': a hardware wallet won't protect you from being tricked into sending Bitcoin to the wrong address. For example, malware on a PC could monitor for high value transactions and then swap out the recipient's authentic Bitcoin address for an address controlled by the attacker. When the stakes are high, multi factor (e.g., over the phone) confirmation of a recipient's Bitcoin address is recommended.<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Commercial hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]: slush's Hardware wallet wire protocol discussion<br />
* [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 Re: Split private keys]: kjj's Todo List discussion for client protocol requirements<br />
* [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Bitcoin Hardware Wallet Comparison] - information about using Bitcoin hardware wallets for cold storage.<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62146Hardware wallet2017-01-22T17:47:59Z<p>Liraz: /* Security risks */ added malware swapping addresses risk</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security risks ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it's important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail to protect your Bitcoin:<br />
<br />
# '''Malware swaps recipient Bitcoin addresses''': a hardware wallet won't protect you from being tricked into sending Bitcoin to the wrong address. For example, malware on a PC could monitor for high value transactions and then swap out the recipient's authentic Bitcoin address for an address controller by the attacker. When the stakes are high, multi factor (e.g., over the phone) confirmation of a recipient's Bitcoin address is recommended.<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Commercial hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]: slush's Hardware wallet wire protocol discussion<br />
* [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 Re: Split private keys]: kjj's Todo List discussion for client protocol requirements<br />
* [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Bitcoin Hardware Wallet Comparison] - information about using Bitcoin hardware wallets for cold storage.<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62145Hardware wallet2017-01-22T17:38:50Z<p>Liraz: /* Security risks */</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security risks ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Commercial hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]: slush's Hardware wallet wire protocol discussion<br />
* [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 Re: Split private keys]: kjj's Todo List discussion for client protocol requirements<br />
* [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Bitcoin Hardware Wallet Comparison] - information about using Bitcoin hardware wallets for cold storage.<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62144Hardware wallet2017-01-22T16:35:48Z<p>Liraz: /* Related Resources */</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security risks ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Commercial hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]: slush's Hardware wallet wire protocol discussion<br />
* [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 Re: Split private keys]: kjj's Todo List discussion for client protocol requirements<br />
* [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Bitcoin Hardware Wallet Comparison] - information about using Bitcoin hardware wallets for cold storage.<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62143Hardware wallet2017-01-22T16:35:21Z<p>Liraz: /* Related Resources */</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security risks ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Commercial hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]: slush's Hardware wallet wire protocol discussion<br />
* [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]: kjj's Todo List discussion for client protocol requirements<br />
* [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Bitcoin Hardware Wallet Comparison] - information about using Bitcoin hardware wallets for cold storage.<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62142Hardware wallet2017-01-22T16:34:05Z<p>Liraz: /* Related Resources */ removed broken link 404</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security risks ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Commercial hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]: slush's Hardware wallet wire protocol discussion: <br />
* [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]: kjj's Todo List discussion for client protocol requirements: <br />
* [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Bitcoin Hardware Wallet Comparison] - information about using Bitcoin hardware wallets for cold storage.<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62141Hardware wallet2017-01-22T16:32:14Z<p>Liraz: /* Related Resources */ cleaned up links</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security risks ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Commercial hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]: slush's Hardware wallet wire protocol discussion: <br />
* [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]: kjj's Todo List discussion for client protocol requirements: <br />
* [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Bitcoin Hardware Wallet Comparison] - information about using Bitcoin hardware wallets for cold storage.<br />
* [http://www.offlinewallets.com/hardware-wallets Offline Hardware Wallets]: Various Hardware Wallets and Reviews <br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62140Hardware wallet2017-01-22T16:29:00Z<p>Liraz: changed section titles</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security risks ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Commercial hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* slush's Hardware wallet wire protocol discussion: [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]<br />
* kjj's Todo List discussion for client protocol requirements: [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]<br />
* paybitcoin's original post: [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Buy Bitcoin Worldwide] - information about using Bitcoin hardware wallets for cold storage.<br />
* Various Hardware Wallets and Reviews: [http://www.offlinewallets.com/hardware-wallets Offline Hardware Wallets]<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62139Hardware wallet2017-01-22T16:28:00Z<p>Liraz: see also section</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security considerations ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Purchasable hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* slush's Hardware wallet wire protocol discussion: [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]<br />
* kjj's Todo List discussion for client protocol requirements: [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]<br />
* paybitcoin's original post: [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Buy Bitcoin Worldwide] - information about using Bitcoin hardware wallets for cold storage.<br />
* Various Hardware Wallets and Reviews: [http://www.offlinewallets.com/hardware-wallets Offline Hardware Wallets]<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
== See Also ==<br />
<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Cold storage]]<br />
* [[Paper wallet]]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62138Hardware wallet2017-01-22T16:25:03Z<p>Liraz: /* Security considerations */</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security considerations ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Purchasable hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* slush's Hardware wallet wire protocol discussion: [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]<br />
* kjj's Todo List discussion for client protocol requirements: [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]<br />
* paybitcoin's original post: [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Buy Bitcoin Worldwide] - information about using Bitcoin hardware wallets for cold storage.<br />
* Various Hardware Wallets and Reviews: [http://www.offlinewallets.com/hardware-wallets Offline Hardware Wallets]<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=BitKey&diff=62137BitKey2017-01-22T16:22:56Z<p>Liraz: /* Links */</p>
<hr />
<div>Live CD/USB distro designed to be a self-contained Bitcoin Swiss Army Knife that supports air-gapped Bitcoin transactions and makes offline cold storage (slightly more) practical. Developed by [https://www.turnkeylinux.org TurnKey GNU/Linux]. First released in 2014.<br />
<br />
It supports verifiably secure Bitcoin wallet creation and transaction workflows that provide defense in depth while minimizing third party trust. Development is guided by the philosophy that you shouldn't have to trust anyone, including BitKey authors and even BitKey itself.<br />
<br />
Latest version bundles [[Electrum]] Bitcoin client, Warpwallet [[Brainwallet]], coinbin, incognito chromium, bitaddress, qrcode, zxcvbn and bx (libbitcoin-explorer).<br />
<br />
== See also ==<br />
<br />
* [[Brainwallet]]<br />
* [[Cold storage]]<br />
<br />
== Links ==<br />
<br />
* [https://bitkey.io/ https://bitkey.io]<br />
* [https://en.wikipedia.org/wiki/Live_USB Live USB]<br />
* [http://nakamotoinstitute.org/trusted-third-parties/ Trusted third parties are a security hole]<br />
* [https://www.turnkeylinux.org/blog/secure-bitcoin-transactions Closest you can get to perfectly secure Bitcoin transactions]<br />
* [http://linuxbsdos.com/2014/07/20/bitkey-a-secure-debian-based-live-os-for-bitcoin-transactions/ BitKey review on LinuxBSDOS]<br />
* [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne stores his Bitcoin]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=BitKey&diff=62136BitKey2017-01-22T16:22:35Z<p>Liraz: /* Links */</p>
<hr />
<div>Live CD/USB distro designed to be a self-contained Bitcoin Swiss Army Knife that supports air-gapped Bitcoin transactions and makes offline cold storage (slightly more) practical. Developed by [https://www.turnkeylinux.org TurnKey GNU/Linux]. First released in 2014.<br />
<br />
It supports verifiably secure Bitcoin wallet creation and transaction workflows that provide defense in depth while minimizing third party trust. Development is guided by the philosophy that you shouldn't have to trust anyone, including BitKey authors and even BitKey itself.<br />
<br />
Latest version bundles [[Electrum]] Bitcoin client, Warpwallet [[Brainwallet]], coinbin, incognito chromium, bitaddress, qrcode, zxcvbn and bx (libbitcoin-explorer).<br />
<br />
== See also ==<br />
<br />
* [[Brainwallet]]<br />
* [[Cold storage]]<br />
<br />
== Links ==<br />
<br />
* [https://bitkey.io/ https://bitkey.io]<br />
* [https://en.wikipedia.org/wiki/Live_USB Live USB]<br />
* [http://nakamotoinstitute.org/trusted-third-parties/ Trusted third parties are a security hole]<br />
* [http://linuxbsdos.com/2014/07/20/bitkey-a-secure-debian-based-live-os-for-bitcoin-transactions/ BitKey review on LinuxBSDOS]<br />
* [https://www.turnkeylinux.org/blog/secure-bitcoin-transactions Closest you can get to perfectly secure Bitcoin transactions]<br />
* [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne stores his Bitcoin]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=BitKey&diff=62135BitKey2017-01-22T16:21:36Z<p>Liraz: expanded description, bundled components, and security philosophy</p>
<hr />
<div>Live CD/USB distro designed to be a self-contained Bitcoin Swiss Army Knife that supports air-gapped Bitcoin transactions and makes offline cold storage (slightly more) practical. Developed by [https://www.turnkeylinux.org TurnKey GNU/Linux]. First released in 2014.<br />
<br />
It supports verifiably secure Bitcoin wallet creation and transaction workflows that provide defense in depth while minimizing third party trust. Development is guided by the philosophy that you shouldn't have to trust anyone, including BitKey authors and even BitKey itself.<br />
<br />
Latest version bundles [[Electrum]] Bitcoin client, Warpwallet [[Brainwallet]], coinbin, incognito chromium, bitaddress, qrcode, zxcvbn and bx (libbitcoin-explorer).<br />
<br />
== See also ==<br />
<br />
* [[Brainwallet]]<br />
* [[Cold storage]]<br />
<br />
== Links ==<br />
<br />
* [https://bitkey.io/ https://bitkey.io]<br />
* [https://en.wikipedia.org/wiki/Live_USB Live USB]<br />
* [http://nakamotoinstitute.org/trusted-third-parties/ Trusted third parties are a security hole]<br />
* [http://linuxbsdos.com/2014/07/20/bitkey-a-secure-debian-based-live-os-for-bitcoin-transactions/ BitKey review]<br />
* [https://www.turnkeylinux.org/blog/secure-bitcoin-transactions Closest you can get to perfectly secure Bitcoin transactions]<br />
* [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne stores his Bitcoin]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=BitKey&diff=62134BitKey2017-01-22T16:02:54Z<p>Liraz: added categories</p>
<hr />
<div>Live CD/USB distro designed to be a self-contained Bitcoin Swiss Army Knife that supports air-gapped Bitcoin transactions and makes offline cold storage (slightly more) practical. Developed by [https://www.turnkeylinux.org TurnKey GNU/Linux]<br />
<br />
== See also ==<br />
<br />
* [[Brainwallet]]<br />
* [[Cold storage]]<br />
<br />
== Links ==<br />
<br />
* [https://bitkey.io/ https://bitkey.io]<br />
* [http://linuxbsdos.com/2014/07/20/bitkey-a-secure-debian-based-live-os-for-bitcoin-transactions/ BitKey review]<br />
* [https://www.turnkeylinux.org/blog/secure-bitcoin-transactions Closest you can get to perfectly secure Bitcoin transactions]<br />
* [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne stores his Bitcoin]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62133Hardware wallet2017-01-22T15:54:40Z<p>Liraz: /* Security considerations */ summarize advantages of hardware wallets</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security considerations ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.<br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
In summary:<br />
<br />
* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).<br />
<br />
* Cold storage solutions implemented with open source software and general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases (e.g., long term savings).<br />
<br />
== Purchasable hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* slush's Hardware wallet wire protocol discussion: [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]<br />
* kjj's Todo List discussion for client protocol requirements: [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]<br />
* paybitcoin's original post: [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Buy Bitcoin Worldwide] - information about using Bitcoin hardware wallets for cold storage.<br />
* Various Hardware Wallets and Reviews: [http://www.offlinewallets.com/hardware-wallets Offline Hardware Wallets]<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62132Hardware wallet2017-01-22T15:38:45Z<p>Liraz: /* Security considerations */</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security considerations ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record. <br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
Cold storage solutions implemented with general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases such as a long term savings account.<br />
<br />
== Purchasable hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* slush's Hardware wallet wire protocol discussion: [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]<br />
* kjj's Todo List discussion for client protocol requirements: [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]<br />
* paybitcoin's original post: [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Buy Bitcoin Worldwide] - information about using Bitcoin hardware wallets for cold storage.<br />
* Various Hardware Wallets and Reviews: [http://www.offlinewallets.com/hardware-wallets Offline Hardware Wallets]<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Hardware_wallet&diff=62131Hardware wallet2017-01-22T15:38:09Z<p>Liraz: added security considerations section</p>
<hr />
<div>A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.<br />
<br />
They have major advantages over standard software wallets:<br />
<br />
* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext<br />
* immune to computer viruses that steal from software wallets<br />
* can be used securely and interactively, as opposed to a [[paper wallet]] which must be imported to software at some point<br />
* much of the time, the software is open source, allowing a user to validate the entire operation of the device<br />
<br />
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.<br />
<br />
== Security considerations ==<br />
<br />
To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record. <br />
<br />
However, it important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet.<br />
<br />
How a hardware wallet could fail:<br />
<br />
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of an RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.<br />
<br />
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.<br />
<br />
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.<br />
<br />
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].<br />
<br />
Cold storage solutions implemented with general purpose hardware, using a verifiable source of entropy (e.g., physical dice) may provide superior security for some use cases such as a long term savings account.<br />
<br />
== Purchasable hardware wallets (ordered chronologically) ==<br />
<br />
=== Pi Wallet - cold storage ===<br />
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]<br />
<br />
The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.<br />
<br />
Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.<br />
<br />
[https://www.pi-wallet.com/ pi-wallet.com]<br />
<br />
<br />
<br clear="all"><br />
<br />
=== [[TREZOR]] The Bitcoin Safe ===<br />
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with TREZOR]]<br />
<br />
[[TREZOR]] is a secure bitcoin storage and a transaction signing tool. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.<br />
<br />
It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case TREZOR gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet. <br />
<br />
TREZOR also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.<br />
<br />
[https://BuyTrezor.com E-shop BuyTrezor.com] | [https://doc.satoshilabs.com/ TREZOR Documentation] | [https://bitcointrezor.com BitcoinTrezor.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger HW.1 - USB Smartcard Hardware Wallet ===<br />
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]<br />
<br />
HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.<br />
<br />
It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.<br />
<br />
Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.<br />
<br />
It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.<br />
<br />
[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]<br />
<br />
Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.<br />
<br />
The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.<br />
<br />
The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.<br />
<br />
[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===<br />
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]<br />
<br />
The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.<br />
<br />
The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).<br />
<br />
[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]<br />
<br />
<br clear="all"><br />
<br />
=== BWALLET TREZOR clone ===<br />
<br />
[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]<br />
<br />
BWALLET is a clone of Trezor by a Chinese company.<br />
Trezor code is open source and this device operates like a Trezor.<br />
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Merek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware. <br />
<br />
[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]<br />
<br />
<br clear="all"><br />
<br />
=== KeepKey: Your Private Bitcoin Vault ===<br />
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]<br />
<br />
KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.<br />
<br />
KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper wallets. <br />
<br />
[https://www.keepkey.com keepkey.com]<br />
<br />
<br clear="all"><br />
<br />
=== Opendime: Bitcoin Credit Stick ===<br />
<br />
[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]<br />
<br />
The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick" <br />
<br />
Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. <br />
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.<br />
<br />
It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.<br />
<br />
[http://www.opendime.com Opendime.com]<br />
<br />
* [https://opendime.com/#faq Opendime FAQ]<br />
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]<br />
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]<br />
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский<br />
* Works as USB drive with no need for software<br />
* [https://github.com/opendime/electrum Opendime Electrum plugin]<br />
* [https://github.com/opendime/ Opendime source files and key verification]<br />
<br />
<br clear="all"><br />
<br />
=== CoolWallet: The Ultimate Bitcoin Safe ===<br />
<!-- 2016-04-09: Consider removing this device until actually for sale? --><br />
<br />
[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]<br />
<br />
CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.<br />
<br />
Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button. <br />
<br />
CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device. <br />
<br />
[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]<br />
<br />
<br clear="all"><br />
<br />
=== BlochsTech card: Your user friendly Bitcoin wallet ===<br />
<!-- 2016-04-09: Possible vaporware / scam? Website insecure & badly designed with no substantial info. Consider finding technical docs, real reviews or removing this device. --><br />
<br />
[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]<br />
<br />
The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.<br />
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.<br />
<br />
Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),<br />
however in the long run it is fully capable of functionally replacing the VISA system in all nations.<br />
<br />
[http://www.BlochsTech.com BlochsTech.com]<br />
<br />
<br clear="all"><br />
<br />
<br />
<br />
=== BitLox Bitcoin Hardware Wallet ===<br />
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]<br />
<br />
BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.<br />
<br />
At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.<br />
<br />
Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app. <br />
<br />
BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet. <br />
<br />
[http://www.bitlox.com bitlox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Digital Bitbox ===<br />
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]<br />
<br />
* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.<br />
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.<br />
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.<br />
* Multisig out-of-the-box including Copay support.<br />
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).<br />
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.<br />
<br />
[https://digitalbitbox.com digitalbitbox.com]<br />
<br />
<br clear="all"><br />
<br />
=== Ledger Nano S - USB Smartcard Hardware Wallet ===<br />
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]<br />
<br />
Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.<br />
<br />
Main features:<br />
* cryptographic secrets protected by a secure chip<br />
* open source embedded Bitcoin app<br />
* Confirmation of transactions on the embedded screen<br />
* Built-in 4 digits PIN security lock<br />
* Built-in onboarding (seed generation and recovery)<br />
* BIP39 seed (12/18/24 words), easy backup and restoration<br />
* Multi-apps support: FIDO U2F, GPG, SSH…<br />
* USB connectivity<br />
* Foldable and compact casing<br />
<br />
[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]<br />
<br />
<br clear="all"><br />
<br />
== Not purchasable hardware wallets ==<br />
<br />
=== BitcoinCard Megion Technologies-Card based wallet ===<br />
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]<br />
[http://www.bitcoincard.org/ Bitcoincard Home Page]<br />
<br />
[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]<br />
<br />
Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.<br />
<br />
<br clear="all"><br />
<br />
=== BitSafe - allten/someone42's hardware wallet ===<br />
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]<br />
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.<br />
<br clear="all"><br />
=== someone42's original prototype ===<br />
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]<br />
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]<br />
<br />
Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.<br />
<br clear="all"><br />
=== Other/Defunct but with good discussion: ===<br />
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]<br />
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.<br />
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]<br />
:Great discussion and good ideas from jim618. Also linked the following video:<br />
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]<br />
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.<br />
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]<br />
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.<br />
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]<br />
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)<br />
<br />
== Smart Card based wallets ==<br />
This type of device requires complete trust in the host device, as there is no method for user input.<br />
See [[Smart card wallet]]<br />
<br />
== Related Resources ==<br />
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.<br />
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback<br />
* slush's Hardware wallet wire protocol discussion: [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]<br />
* kjj's Todo List discussion for client protocol requirements: [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 in topic Re: Split private keys]<br />
* paybitcoin's original post: [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]<br />
* [https://www.buybitcoinworldwide.com/wallets/ Buy Bitcoin Worldwide] - information about using Bitcoin hardware wallets for cold storage.<br />
* Various Hardware Wallets and Reviews: [http://www.offlinewallets.com/hardware-wallets Offline Hardware Wallets]<br />
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]<br />
<br />
[[Category:Security]]<br />
[[Category:Wallets]]<br />
[[Category:Hardware]]</div>Lirazhttps://en.bitcoin.it/w/index.php?title=Wallet_Security_Dos_and_Don%27ts&diff=62130Wallet Security Dos and Don'ts2017-01-22T12:53:32Z<p>Liraz: /* See also */ added cold storage internal link</p>
<hr />
<div>This article should not be considered as a replacement for the more in-depth articles on best practices, however key points in wallet security:<br />
<br />
== Do ==<br />
<br />
* DO seek to understand what you are doing, before you do it<br />
* DO verify understanding by testing with small low value transactions<br />
* DO encrypt your wallet with a strong passphrase<br />
* DO use recommended software from the list at https://bitcoin.org/en/choose-your-wallet<br />
* DO make multiple redundant backups of your wallet<br />
* DO keep your OS up to date and run a virus scanner<br />
* DO manage significant amounts in offline wallets (cold/paper/hardware)<br />
* DO prepare for black swan disaster scenarios when dealing with large sums (e.g., fire & water damage, theft, head injury and death)<br />
<br />
== Don't ==<br />
<br />
* DO NOT trust an untrustworthy device or program to generate your wallet keys<br />
* DO NOT generate cold storage keys on Internet-connected machines.<br />
* DO NOT reconnect to the Internet a machine that has had access to cold storage keys.<br />
* DO NOT reuse a wallet encryption passphrases with online services<br />
* DO NOT store your wallet on cloud storage (Dropbox, etc.)<br />
* DO NOT re-use addresses (including paper wallet addresses) if you care about privacy<br />
<br />
== See also ==<br />
<br />
* [[Securing your wallet]]<br />
* [[Hardware wallet]]<br />
* [[Brainwallet]]<br />
* [[Paper wallet]]<br />
* [[Cold storage]]<br />
* [[How to set up a secure offline savings wallet]]<br />
* [[Paper ECDSA private keys]]</div>Liraz