The thing is that many people think that their password is safe as they use something of similar size/complexity on web-sites. However, on a web-site the attacker cannot really brute force it until he has access to the encrypted password file or a hash of the password (maybe with some seed). Without this the hacker is left with a few attempts a second (through the web-page login), with the risk of locking the account he tries to gain access to. With brainwallets the attacker can start brute forcing with trillions of attempts a second just by looking at the blockchain. (or in the case of a paper backup, once he has access to the encrypted private key).
I really want Mycelium users to use safe and verifiable mechanisms that do not lure them into using something that they think is safe while it is not.
So how about if we convert the attack on the blockchain into an attack on a website instead. We can do it by adding a protocol to the client to save the strong key, encrypted with the human password, on S3 Amazon cloud or Dropbox or something. Only the strong key shows up on the blockchain and an attacker would have to dig up the user Dropbox account before conducting a dictionary attack. The unencrypted strong key never leaves Mycelium. If I get you right you suggest that the private key is encrypted with a human generated (potentially weak) password. The encrypted private key is stored on dropbox. Access to dropbox is with a different human generated (potentially weak, or the same) password. This would make you vulnerable to an insider attack at dropbox, or one of their historical hacks. |
|
|
|
This is certainly true if you encrypt a JPG image, as a cracking program can easily check whether a brute-force result yields a valid JPG file.
It may be much more difficult with just the text of the key, because that looks like gibberish anyway. Even with a relatively short password, many brute-force attempts may yield some similar gibberish, so the cracking program cannot discern the valid key from other wrong results with wrong passwords.
This is an important argument. It should be noted, however, that it is relevant if private key is in the raw, 32-byte form. If it is, the attacker has no idea whether he got the right passphrase until he performs ECDSA to create the public key, then ripemd160(sha256()) to create the address, and then search the blockchain for the address. That's a lot of work for each try, and only when you get lucky can you start hoping that there are unspent outputs. In case of the usual WIF-encoded private keys, it seems easier because of the checksum. First of all, the brute-force attacker checks if candidate begins with a "5". Next, she converts it to hex, and checks if last four bytes are sha256(sha256()) of the remainder. If not, move on. If yes, only then search the blockchain. This eliminates most of slow steps related to blockchain search. Does this make sense? How does computational burden compare between all the hashing and checking the blockchain in the above examples? Yes, this makes sense. However, this also means that if the user (by accident) enters the wrong passphrase (this would happen a lot as it is pretty long), then he will get a different private key and address. Also, if the bitcoin address is on the same paper, which is VERY convenient, then you can brute force on the private key until you get the right address. I would really prefer to make the passphrase strong enough to withstand that. It may not have to be as strong as the private itself, as you still need access to the encrypted private key, but it should be in the same ballpark. |
|
|
|
Also, passwords have to be strong to have any real effect (unfortunately making them easier to forget). This is certainly true if you encrypt a JPG image, as a cracking program can easily check whether a brute-force result yields a valid JPG file. It may be much more difficult with just the text of the key, because that looks like gibberish anyway. Even with a relatively short password, many brute-force attempts may yield some similar gibberish, so the cracking program cannot discern the valid key from other wrong results with wrong passwords. But anyway, the password should not be too short. Therefore the best solution for encrypted export I have seen is this:
The wallet exports a JPG image which contains the encrypted private key both as text and a QR-code (also contains bitcoin address, label etc). The encryption key is derived from a passphrase. The passphrase is automatically generated and contains enough entropy to make brute force unfeasible. The JPG goes to the SD-card, an email, dropbox, or whatever. The passphrase is only displayed on the device once during export.
The user has to write the passphrase down, as it is impossible to remember. This can be on a printout of the JPG or on something else.
We can add a "Verify Export" feature that allows you to verify that your key can be imported, keys that have been verified get tagged.
We can add a feature that nags you as long as you have not verified all your keys. Yes, sounds very good to me. I am still not sure how useful it would be in the real world, how many users would actually use it, etc. I would also tend to offer a passphrase entered by the user, because there are some people who can remember it. That would protect against theft of the paper wallet. (For example, I have a method of constructing passwords by taking a few letters from the name of the object, like from a domain name or from "Mycelium", and encrypting them mentally, before adding some static salt, which I can remember, because it is always the same. Otherwise my poor memory could never cope with the many passwords I have to remember. But that is another matter.) The actual JPEG would not be encrypted. The private key is encrypted and then turned into a Base58 encoded string which is present as text and a QR code in the JPG. This way you can easily and safely print it out using your computer or whatever. Before Base58 encoding a short byte header will be added (magic byes) which allows the wallet to detect that this is an encrypted private key. Regarding the passphrase: Very few people can remember a strong passphrase that cannot be brute forced (I for one can't). We have already seen brute forced brainwallets, and IMO brainwallets are a generally bad idea: http://www.reddit.com/r/Bitcoin/comments/1b8yde/be_careful_with_brain_wallets_there_are_people/ and http://www.reddit.com/r/Bitcoin/comments/1j9p2d/blockchaininfo_unauthorized_transactionhow_could/The thing is that many people think that their password is safe as they use something of similar size/complexity on web-sites. However, on a web-site the attacker cannot really brute force it until he has access to the encrypted password file or a hash of the password (maybe with some seed). Without this the hacker is left with a few attempts a second (through the web-page login), with the risk of locking the account he tries to gain access to. With brainwallets the attacker can start brute forcing with trillions of attempts a second just by looking at the blockchain. (or in the case of a paper backup, once he has access to the encrypted private key). I really want Mycelium users to use safe and verifiable mechanisms that do not lure them into using something that they think is safe while it is not. To have something as strong as our private key need 128 bits of entropy. That is a very long and very complex passphrase. The average user would need it generated for him and put on paper. Sorry for the rant  |
|
|
|
Still anxiously awaiting Neft Vodka's distribution in the U.S.
I'm curious if anyone knows ... is the vodka sold in the White Barrel any different product than that sold in the Black Barrel?
The content is the same. I like the white barrel better, and it is also the one with the Bitcoin logo on it. So the black one doesn't have a bitcoin logo?? Good to know... Any place one can buy these with bitcoin? I might be selling a few for bitcoin soon... if my shipment arrives. However, you will have to come and visit me in Denmark. I am sure we can arrange for a tasting while we are at it. |
|
|
|
The Sound of NEFTIn the window of my office I have an empty barrel of black NEFT. Twice a day it makes a clicking sound, in the morning when it heats up, and in the evening when it cools down. It is the bottom of the barrel that makes the sound when the pressure goes up and down. (You need to keep the lid on and closed tightly). The barrel I have has a small dent close to the bottom, so I don't know if this happens with all barrels. This is the NEFT sound!Whenever I hear it I think about NEFT  Crazy idea for marketing?
|
|
|
|
This is a still unripe idea, but I'll mention it here, just in case somebody can improve it to make it really useful. I was trying to create a private key backup and was worried to let the file with the private key wander through insecure communications channels and systems like Windows computers. So I found a ZIP archiver that can encrypt and zipped and encrypted the file right on the phone. Now I can move and store the file through insecure channels and on insecure machines. An example could be that you have a safe phone and a safe computer with a printer, but no safe connection between the two. Another example is safe storage of the backup on an unsafe computer. You would never decrypt your backup on that unsafe computer, but you could move it back to a safe phone and decrypt it only there. (A safe phone could be a factory-reset phone with only Mycelium and a ZIP archiver app on it.) Remaining problems are, obviously: - You have to remember the encryption key safely.
- The ZIP archiver program could steal the key.
I used ZArchiver, which is apparently the most powerful ZIP archiver for Android. My reasoning is that nobody writes a powerful first-class archiver only to embed a virus in it. But, of course, a residual risk always remains. In theory, Mycelium itself could contain an encrypting ZIP archiver or some other encrypting software, if the idea holds any water. I'm putting this out here for discussion, in case there is any interest and I have not overlooked some fundamental counter-indication. Interesting idea. One of the current export features allows you to export directly from a phone to a printer with no intermediate computer. Demo: http://www.youtube.com/watch?v=W7V2myIwAuESo if you have a trusted phone and printer that accepts SD-cards, this is a very viable solution. As you say, passwords can be forgotten. Also, passwords have to be strong to have any real effect (unfortunately making them easier to forget). Therefore the best solution for encrypted export I have seen is this: The wallet exports a JPG image which contains the encrypted private key both as text and a QR-code (also contains bitcoin address, label etc). The encryption key is derived from a passphrase. The passphrase is automatically generated and contains enough entropy to make brute force unfeasible. The JPG goes to the SD-card, an email, dropbox, or whatever. The passphrase is only displayed on the device once during export. The user has to write the passphrase down, as it is impossible to remember. This can be on a printout of the JPG or on something else. We can add a "Verify Export" feature that allows you to verify that your key can be imported, keys that have been verified get tagged. We can add a feature that nags you as long as you have not verified all your keys. |
|
|
|
|
Next version will feature a new "Send" wizard, where you manage the receiving address and amount to send from the same screen. This allows you to specify the amount before you enter the receiver. Also, if your clipboard contains a number you can paste it when specifying the amount to send.
All in all this should make the wallet much better in local p2p exchange scenarios, where the amount being bargained (and often calculated in an external app) can be specified (possibly pasted) before the receiving address is scanned. Our feedback tells us that the amount is the important thing, while the address is just a means to an end.
The next version will probably hit the Mycelium Beta Testers group later today.
|
|
|
|
Not sure if this got clear here: Of course other apps can access the clipboard and if they request it in the manifest (the user gets warned about that) also to the sdcard. Users should be aware that it is as easy as 3 lines of code to get any app to wake up whenever anybody puts anything into the clipboard. Such an app can then parse and granted it has internet access, send the private key home. --> droidwallInteresting. Unfortunately it apparently requires root access to enforce its firewall rules. Root access enables it to attack the wallet  For high security I would still prefer a cheap dedicated device which only runs Mycelium. |
|
|
|
It is always good with some inspiration. |
|
|
|
Cold storage is fine … Cold storage does not create security. It only makes it a little bit more difficult for a Trojan to grab the private key. It does not deter malware programmers—it merely challenges them. Perhaps it attracts them.  It is probably better to prevent malware in the first place, but that is also difficult. Essentially you should not keep large amounts on a phone, and if you do, keep all other software and updates to the absolute minimum. I am hoping for a separate piece of dedicated hardware to keep the private key in and to do any signing, with an observable, minimal data channel to the phone or computer that does the external communications. We don't have that yet, it is a hope for the future. hgmichna, I believe we have discussed this before, so instead of repeating myself let me quote myself (isn't that the same ): If you use Mycelium for large amounts I suggest that you use a dedicated device for optimal security. Personally I use an old second hand Android 2.2, which I got for free, and which I nuked to factory defaults, installed cyanogenmod, no SIM, and only installed mycelium. I keep the device in my safe along with paper backups. Whenever I want to "load up" my spending wallet on my daily phone I use the Cold Storage feature. I might add: Only use you daily phone for what you are prepared to loose. Bitcoins on your phone it is like cash in your pants (with a PIN). |
|
|
|
Sorry if I missed it, but how does Mycelium calculate Bitcoin price, and is there some standard that everyone uses now that Gox got Goxed?
If you have chosen USD as your local currency the market price is determined by the latest trade on Bitstamp and MtGox and calculating the weighted average according to trade volume. For the other currencies we currently only use MtGox (Bitstamp only trades in USD). This is obviously not optimal, especially given the current circumstances. We actually happened to discuss this yesterday, and I am delighted to tell that Peter Šurda (Bitcoin blogger and economist) has joined our team in Vienna Here is our current thinking: 1. Let the user choose which exchange to base the price on. Initially available choices would be Bitstamp and MtGox. We can expand the list as we go (the default will probably be Bitstamp) 2. Take the USD price of the selected exchange. (It occurs to me that USD is the only currency with any significant volume on MtGox, and the only currency traded on Bitstamp.) 3. Convert the USD price to the selected local currency using official public foreign exchange rates. 4. Display that price on the main view including the chosen exchange "1 BTC~103 USD (Bitstamp)" Displaying the name of the exchange is important in situations where two users are doing an in-person trade, as this helps them understand why they see different prices. We are going to discuss this further internally today, and if you have any suggestions we'd love to hear them. It will take a week or two before we have an update ready. |
|
|
|
In mycelium,
how do you backup your encrypted wallet.dat?
Mycelium works differently then Bitcoin-QT in many ways. One of which is that it has no wallet.dat file. For backup there are 3 basic approaches, all of which is done in the Keys & Addresses view. Long clicking on a key lets you choose Export, which allows you to: - 1. Click "Show QR-code", which displays a QR-code that contains you private key in SIPA format. You can scan that with another Mycelium wallet instance to import it, or take a picture with a camera, and later print it out, or keep it on the SD card in a safe place.
- 2. Same as above, but additionally click "Copy Private Key to Clipboard". The SIPA formatted private key will go to the clipboard as text, and from there you can use it with other apps. Please note that other apps on your device have access to it, so be careful.
- 3. Click "External Storage". If your device has an SD-card which contains a folder called "mycelium-export" this will export a JPG file to it, which contains the bitcoin address and private key as strings and QR-codes. From there you can print it out directly on a printer that accepts SD cards. Here is a demo that shows how it is done. This is what I always do.
If you use Mycelium for large amounts I suggest that you use a dedicated device for optimal security. Personally I use an old second hand Android 2.2, which I got for free, and which I nuked to factory defaults, installed cyanogenmod, no SIM, and only installed mycelium. I keep the device in my safe along with paper backups. Whenever I want to "load up" my spending wallet on my daily phone I use the Cold Storage feature. There is a nice demo of it here. I presume the above warning about the clipboard access also applies to a jpg exported to the SD card...? Yes. |
|
|
|
Ooooooh, Android Bitcoin Wallet just announced they're working on offline transaction sending via bluetooth (create transaction, sign, and transmit over bluetooth to the other phone, which can then broadcast to the web). You guys better step it up! (granted their wallet doesn't even do private/public key management yet, and they keep insisting it's a bad idea, despite using just one key for all transactions, anyway) Hey Rassah.. always pushing the envelope That is an interesting feature. Andreas and I discussed today, and we like it. We do however have some other awesome features in the pipe-line. We will revisit "bluetooth bridging" going forward. |
|
|
|
In mycelium,
how do you backup your encrypted wallet.dat?
Mycelium works differently then Bitcoin-QT in many ways. One of which is that it has no wallet.dat file. For backup there are 3 basic approaches, all of which is done in the Keys & Addresses view. Long clicking on a key lets you choose Export, which allows you to: - 1. Click "Show QR-code", which displays a QR-code that contains you private key in SIPA format. You can scan that with another Mycelium wallet instance to import it, or take a picture with a camera, and later print it out, or keep it on the SD card in a safe place.
- 2. Same as above, but additionally click "Copy Private Key to Clipboard". The SIPA formatted private key will go to the clipboard as text, and from there you can use it with other apps. Please note that other apps on your device have access to it, so be careful.
- 3. Click "External Storage". If your device has an SD-card which contains a folder called "mycelium-export" this will export a JPG file to it, which contains the bitcoin address and private key as strings and QR-codes. From there you can print it out directly on a printer that accepts SD cards. Here is a demo that shows how it is done. This is what I always do.
If you use Mycelium for large amounts I suggest that you use a dedicated device for optimal security. Personally I use an old second hand Android 2.2, which I got for free, and which I nuked to factory defaults, installed cyanogenmod, no SIM, and only installed mycelium. I keep the device in my safe along with paper backups. Whenever I want to "load up" my spending wallet on my daily phone I use the Cold Storage feature. There is a nice demo of it here. |
|
|
|
What? Why can't the change address simply be the paper wallet itself? Plus isn't this how Android Bitcoin Wallet works already, sending from it's main address, and sending all change right back to the same main address?
The app doesn't know you imported a key from a paper wallet. Most wallets will not replace keys but add to them. Hence the problem. So, then, what are the risks with Mycelium that people should be worried about? Is there a change that, when you tell it to spend from a paper wallet, that it can create an address it doesn't own private keys to to send change to? I'm having trouble getting this, as I thought the sending and receiving change was typically straightforward... P.S. sorry for pestering you, I just want to make sure I understand this right. When you use the Cold Storage spending feature in Mycelium it knows that you are spending from an external private key (e.g. paper). It creates an in-memory one-key wallet for this one spending. After that it is wiped from memory. If there is any change left it gets sent back to the one key where it came from (e.g. paper). Note that even though Mycelium only has the private key in memory very briefly your private key is only as safe as your device was at the time of spending. A very sophisticated app that has root privileges on you device might snag it from memory. For optimal security use a dedicated device. An old second hand device will do if you nuke it to factory defaults, install cyanogenmod, no SIM, and only install and use for this purpose. |
|
|
|
Still anxiously awaiting Neft Vodka's distribution in the U.S.
I'm curious if anyone knows ... is the vodka sold in the White Barrel any different product than that sold in the Black Barrel?
The content is the same. I like the white barrel better, and it is also the one with the Bitcoin logo on it. |
|
|
|
Ha. I just realized that I am adding fuel to a thread I started two years ago. In Bitcoin land that is a very long time. Now that I am at it, please bear with me. I am on my way home from a bitcoin meetup in Copenhagen, 3 1/2 hours each way. Since the BCCAPI was announced 2 years and 4 days ago we have seen numerous attempts at starting Android wallets on top of it. The most successful being BitcoinSpinner. We have all learned a lot about what in my mind was an experiment, at least back then. Now everything is different. Bitcoin has gained tenfold or more in value. Well funded companies are shooting up all over. As for mysels, I have quit a sunning carrer in IT (at VMware), gained 10 pounds, my wife hardly recognizes me, and my children do not know who I am. Never the less, I have had the best time of my life doing what I am best at: developing great Bitcoin software. What I am currently working on: The best mobile wallet on the planetWhat the future brings? I don't know, but I am sure it is going to be interesting and something with Bitcoin. What did the last two years of bitcoin life bring to you? |
|
|
|
|
The thing is, that in order to spend from an arbitrary private key you need to know the unspent outputs sent to its address. This means scanning the block chain from the first point in time (block) where the first transaction sent funds to it. If this point is not known you will have to scan all the way from the genesis block up till now.
Clients running in SVP mode were not meant for that, and cannot do that efficiently.
Instead they create a random key and track it from the point (block) where they were created. Because the key is a random 256 bit value it is unique beyond reasonable doubt, and it is safe to assume that previous blocks did not contain transactions that send any funds to it. This way SVP clients can do with much less storage and (with bloom filters) much less bandwidth than full bitcoin nodes, while still validating soundness.
|
|
|
|
|
Show Posts
