Bitcoin Forum

I think how the wallet is managed is one of the major problem of the bitcoin client as now. To use it you have to have it unencrypted and this is a serious security flaw as it allow a virus to directly steal it. I know it has been asked a lot of times but, we need a client that can use a CRYPTED wallet.dat

Then we have the fact that well the client automatically create wallet.dat in his folder inside roaming without telling you anything and while it is not a problem for people who know how the software work, it's a bit fail for new ppl, because by trying the bitcoin client you just end with a NEW folder under roaming that you don't even know it exist (you discover it LATER, when you go read the wiki). Not exactly the safer way, there should be like something in the client that allow you to create the wallet and place it where you want or something like that...

Read: http://gavinthink.blogspot.com/2011/06/why-arent-bitcoin-wallets-encrypted.html

Encryption is not some magic dust you sprinkle on an application and it magically becomes secure. If you can come up with a wallet encryption scheme that has more upsides than downsides, there's a good chance it will be implemented.

IMO, that's just inviting disaster. The client should only be running on machines that are inherently secure. Doing this will encourage people to run the client on insecure machines, which will compromise their wallets even if they are encrypted. Strong passwords will be forgotten, leading to lost BitCoins. Weak passwords will be brute forced, accomplishing nothing.

Yeah, but a forgotten password is everybody's own fault, while the average BTC user can't be expected to only keep his wallet on his walled-off linux machine with only carrier pigeon connectivity.
Of course, most known cases of theft have been linked to gross negligence, but that's just how people work - you don't worry until it's too late.

I, for one, would welcome wallet encryption, even if it's not 100% secure and perfect. I mean, what is 100% secure?

I really dont understand why people defend NOT encrypting the wallet.

Maybe I'm missing something.

Gavin Writes in the blog:
"First, losing your wallet or forgetting your password is (arguably) as big a threat as theft."
Even if we ran with this and said, 50/50 you lose your password or get your unencrypted wallet stolen, people would still choose to lose their password. At least some douch bag isnt out there spending them.


It seems to me nobody ever expects 'average' people to use bitcoins (whereby I define average as someone running windows, and is not really sure if blu-ray is the same as bluetooth).
In that case, I think just take down the windows binaries, and make users compile it themselves. if they can do that, they're ready for bitcoin.

BTW I really hate this elitest attitude.

It really doesn't make any difference whose fault it is. If anything, having it be your fault makes it worse.

Of course not. Since they can't be expected to secure their machine, they shouldn't be holding BitCoin keys on it. The best way to use a credit card is not to become a bank or a merchant.

Propose a scheme. I don't know how to do it so that the upside exceeds the downside. If you do, please share.

Ok, if your pc is infected, then encrypting don't help and you need a non-infected pc to use the wallet

But encrypting it is not only about viruses, it's also about more simpler things like someone use my pc and steal the file.

Then you will say that i can still delete the wallet.dat and keep the encrypted copy and unencrypt it only when i need it, and then i say, yes, but if we add this to the bitcoin client it is much easier.

Also if the client directly encrypt it we can make sure an unencrypted wallet NEVER goes on the hard disk (cause the client will unencrypt and use it on the memory and not the hard disk), so it will be impossible to later recover it from the hard disk (like if someone steal your hard disk)

It really doesn't make any difference whose fault it is. If anything, having it be your fault makes it worse.
[/quote]
if you say so.... I would not think so.
I was under the impression that BitCoin is meant for everybody, not only for banks... So there should be security enough for everybody to use it, otherwise it will fail.
As long as "oh noes you could install a keylogger specifically for bitcoin, which makes no encryption better than having encryption" is an argument, I won't bother, thank you ;-)

Jesus, how hard can it be to understand.

unencrypted :
- thief steals your hard drive : wallet.dat up for grabs be it linux or windows or w/e
- thief hacks your PC : wallet.dat up for grabs be it linux or windows or w/e
- get a trojan : trivial to add a couple of lines of code to an existing one to steal wallet.dat
Average time needed to steal all user's coins : microseconds

encrypted:
- thief steals your hard drive : thief more or less s.o.o.l
- thief hacks your PC : thief needs to grab wallet.dat, install a keylogger and wait patiently until user makes a payment, which could be today, next week, or never
- get a trojan : needs to target Bitcoin specifically and wait until a payment is made as above
Average time needed to steal all user's coins : days to weeks

FWIW, there are ways to evade the most common keyloggers. KeePass, for instance, has implemented one such system: http://sourceforge.net/projects/keepass/forums/forum/329220/topic/4198801

Also, AFAIK, encrypting wallet.dat doesn't prevent you from doing any other security measures you might find necessary.

NOT encrypting wallet.dat means that to be safe from the kids' friends, 0-day exploits and the occasional 'oops, shouldn't have downloaded that' you need some sort of security scheme, which probably involves encryption and passwords anyways. And how were you going to spend coins without unencrypting the keys, again?

Bitcoin is a specification and protocol. The bitcoin client that everybody is talking about is an implementation. But for the normal user, the only thing something "is" is what is in front of their face on the screen. So for new users, the bitcoin client from bitcoin.org is bitcoin. There's a great opportunity for somebody to develop a more full-featured client (with encryption, backup, payment confirmation, etc.). I bet one will emerge soon.

All this discussion is pointless. The developers are working on it, it should be included in the next version. You can see their progress here:

https://github.com/bitcoin/bitcoin/pull/232

If someone uses your pc?

You mean you don't have your own user login with encrypted home folder on your pc then I guess?  Because you should, if you're keeping many bitcoins on it. 

If someone stole my PC then I suppose they could crack the encryption and steal my wallet but I hope this security at least would buy me enough time to get my wallet backup to another PC and move my bitcoins to a safe place.

Ye well if we want to use bitcoins we should be able to keep the wallet with us, so maybe i have the big wallet encrypted somewhere and a wallet with few bitcoins that i bring around with me and someone can steal it. If the client directly encrypt this, the problem is solved

Personally, I am only allowed access to my encrypted wallet after I prick my finger and take a small blood sample. 12 hours later, my DNA is roughly confirmed and I'm allowed to "see" in the wallet. I can't make transactions to new addresses for about 5 days while confidence in my identity is confirmed.

Also, I'm required to submit nasal and fecal swabs. A few tests are run and the unique combination and relative numbers of various bacteria, as well as their particular drug resistances and other protein markers, are used to confirm that I am probably me, and probably alive. One time, I got food poisoning and this threw everything off until my bacterial load was back to normal. I couldn't spend bitcoins for a few weeks.

After those tests are approved, I have verbal passphrase that is checked not just for correctness, but for indicators of stress in order to test if I am likely being coerced. After that, I type in a password that varies daily based on another password that was encrypted with a one-time-pad. Then, a random block of text is generated on-screen for me to type out. You might be able to fake all the prior checks, but have fun trying to replicate the exact cadence of my typing.

All throughout this, I have a hidden microphone that listens for me saying a particular keyword that indicates that I'm under duress. If I drop it into conversation with whoever might be coercing me, my wallet is locked for 1 month.

After that, I am given 3 names of random friends and relatives who I must talk to in order to be given one-time passwords taken from separate books that I gave them previously.

One person is chosen to perform a "secret handshake" that varies slightly with each day of the week.

Then, my dog has to go through most of the above steps, because he's always with me. I haven't been able to get into my wallet this month because he really sucks at typing and can't remember his verbal password until I give him a treat.

So long non-niche market adoption! This is as asinine as owning a computer /just/ to store a wallet.dat on.

Running the client is not the only way to adopt BitCoin. Currently, it is most certainly not the best.

I think it's a requirement to use bitcoin with non-negligible amounts of money on a computer. It doesn't work without security, including strong confidentability and integrity of data.

You have to realize that what is secure enough now for a home computer user is very probably not sufficient. You are not going to change that by fussing around.

Think about only one aspect: To make backups possible, pre-generated keys (addresses) are stored in the wallet. If you receive some amount of money, the security of that amount depends on the security of these keys since their creation until the money is moved to another address, which can take years.

Another point: If I can copy your wallet.dat, I can probably replace your entire bitcoin client as easily. I don't need to install a key logger then - I can do directly with the money whatever I want.

Or just another trick: You use your browser to look up payment addresses. Fine. I install some add-on into your browser which once in a while replaces some addresses with one of my owns. And you just wonder why your landlord throws you out.

You haven't proposed a complete scheme, so you're comparing the advantages and disadvantages of something that exists to something that isn't even specified. For example, under 'encrypted', you assume the thief cannot brute force your password. That will mean that your password will have to be the kinds of things a human being can't memorize reliably. Yet you don't consider the risks of forgotten passwords.

Anyone who has been around computers for at least ten years has had the experience of using a system you used to use regularly one time after a year or more of not using it and having no idea what your password is. This is the #1 way people will lose their BitCoins.

Just a few months ago, I had to use a system I used to use daily for six years with the same password after having not used it for just 8 months. I had no idea what my password was and had to recover it. I must have typed that password at least 2,000 times. And this was a short/simple password, I think it consisted of a short English word and two digits that were meaningful to me -- but I don't even remember that for sure. A password that short would be useless for protecting your wallet. And there's nobody to recover your password for you with BitCoins.

Remember, if your password is only needed to transfer coins, the thief will know exactly how valuable cracking your wallet is. And he'll probably have access to a vast network of compromised machines to use to brute force your password.

If you have a scheme for wallet encryption that you think has advantages that outweigh its disadvantages, propose it.

Why are you arguing against passwords? You seem to believe that passwords create more issues than they solve. Is this a universal thing, or does it only apply in the case of bitcoins (and why)?

I'm not asking if you think passwords have caveats (they do). I'm asking why you think they are worse than no encryption at all. For them to be worse, they would have to make MORE people vulnerable to bitcoin loss then unencrypted wallets. Seems unlikely. Surely, you don't advocate the universal abolishment of passwords? But that's exactly how I read your quote above.


*EDIT*
Let me say where I think this argument is coming from. Correct me if I'm wrong.
Your angle: People such as youself have secure machines, thus passwords do not add anything. For you, they only create the potential for a forgotten password.
My Angle: most people who pick up bitcoin will be vulnerable to wallet.dat theft, especially as the userbase shifts. Passwords can help protect a lot of them.

Solution? By default the client encrypts the wallet, but for advanced users it can be disabled (my target audience is likely to leave it an whatever the default is).

Because I believe they create more problems than they solve in this case. If you think otherwise, propose a schemce.

It applies only to this specific case. Passwords are great "is X allowed to do Y". They are *not* great for this case. At least, not in any of the proposals I've seen.

You are more likely to lose your BitCoins through forgetting your password than you are to have them stolen by a trojan. If the passwords are made short enough that people will remember them, they will be brute forced, giving the worst of both worlds -- a false sense of security, and a risk of losing your own wallet if you can't muster enough power to brute force.

I have yet to hear your proposal. I can't evaluate a proposal I haven't heard. I can't think of one that doesn't make things worse for the average user. Maybe you can. If so, let's hear it.

Maybe thats true, in your case. But if bitcoins are 'successful' they will end up in the hands of a lot of users where this is not going to be true. I tihnk on average your statement will be false (and this prediction is tied to the adoption level of bitcoin in general).

BTW, I run keypass, with a monster master key. So I probably wouldnt remember my own bitcoin password. It would be stupidly complex. I would prefer that personally to a wallet.dat file in the open.

Maybe if BitCoins are successful it will be because a solution comes around that doesn't have either of these issues.

Someday I should tell you about the day my daughter fall and hit her head, and the many things she did that day that she has no recollection of. If you change your keypass password, keep a backup that can use the old password for at least a few days. ;)

"If I'm in the hospital why don't I have one of those things on my wrist?" "Look at your wrist." "Oh!"
"Are you not supposed to tell me how I got here so they can see if I remember?" "Actually, I have several times."

I don't want to let the perfect be the enemy of the good. But I've yet to see a solution that I think is better than what we have now, for the average person.

The scheme is so standard from pgp, gpg, bcrypt, truecrypt etc it should be obvious.


The password (or in this case, passphrase) is as secure as the user chooses. ANY is better than none, because even a weak one needs some effort and custom tools to crack.


Then, write it down.


So you put lots of money in a bitcoin wallet and then don't use it?

People tend to be careful when it comes to money. If they aren't, they only have themselves to blame. I can't see how other peoples' idiocy is an excuse to hinder my security.


The first sentence makes no sense whatsoever. And I don't care how vast his network is, he is not going to crack my password in the remaining lifetime of the universe.

But a forgotten password results in lost coins for the whole network, while stolen coins are still circulating.

That's tools, not schemes.

Why do you say that as if it were a bad thing.

It isnt a bad thing that it may happen sometimes, but it would be a bad thing if it was the default.

Easier to understand now?

That doesn't protect you against malware at all.

Please see the 9th post in this thread.

FWIW they are already implementing this. And I'm done arguing.

1) Only true if you have full disk encryption. Otherwise, your operating system may have placed the unencrypted private data anywhere (temporary files, swap space ...)

2) Nonsense. Malware can just read the RAM of your Bitcoin client.

3) See second.

1) Only if the client implementation allows this to be done. Memory pages can be locked and prevented from swapping to disk.

2) The private keys need only be unencrypted when payments are made or new addresses are created. And while possible in theory, for multiple reasons, reading the RAM of the Bitcoin client is probably the most difficult way to get the keys. A simple keylogger or even replacing the bitcoin client with your own (it's open source, after all) would work just as well. The thing is, these are very specific attacks and much more involved than just making a copy of wallet.dat. And the hacker still needs to wait until the passphrase is actually typed, giving the user time to notice something is wrong.

3) See second

And now I'm really done repeating myself.

I don't think you understand the issue. By a "complete scheme", I mean answers to questions like:

1) Is password complexity enforced? If so, what are the complexity rules?

2) Is any other way provided to get into the private keys other than the password?

3) What is the password needed for? Only to send money? Or even to see what accounts exist on the system?

And so on.

Without a complete scheme, there is no way to evaluate the advantages and disadvantages. As I've said, I can't think of a scheme whose advantages outweigh the disadvantages.

That's a trivial task. Every other video game kiddie knows how to cheat by manipulating RAM data. Reading only is even easier.

I don't think you understand what within wallet.dat needs to be protected and how passphrase based encryption works. If you did, you'd know the answers to your questions 2 and 3 are obvious.


Well, I'll leave you here demanding your scheme.

You are making a bit of a strawman argument here.

Mike did not propose such a stupid idea to just protect the current wallet.dat file by password. He distinguished between the private and public keys, and he proposed that those private keys are protected only. And those private keys are only decrypted when an actual transaction is made.

It does not protect against everything - as I argued - but it isn't as stupid as you quote it either.

I presumed that this was what he intended, and I pointed out the problem with that scheme. A human will have to choose a password simple enough that they can remember it for many years but complex enough that an attacker cannot brute force it even if the attacker specifically knows which wallets have the largest BitCoin balances and the attacker has a botnet to use to brute force passwords on.

I wasn't kidding about my example. I really did have a password I used at least 20 times a week for more than six years that I didn't use for 8 months and forgot. It was a short/simple password too.

How bad this is depends to some extent on password complexity rules. If you force a very complex password, you ease the brute forcing issue. If you don't, you ease the password forgetting rule. Maybe someone knows how to make this work. I don't.

Users do not really understand the concept of a password that absolutely cannot be bypassed. A regular question on many forums is some variant of "I forgot the password to my X, how do I recover it?" where X is a WinRAR archive or a disk encryption scheme. They are stunned that the answer is "you're 100% screwed".

But I cannot do a fair job of criticizing a scheme without knowing what that scheme is. Nor is it fair for him to argue we should add encryption because he imagines a scheme that is not actually capable of being realized.

It seems easier to implement an embedded wallet that plugs into USB and stores the private key. The device has a small LCD screen and an "Approve" button. When you spend something in your bitcoin client the transaction is sent to the USB device for signature. The USB device checks the amount to be spent, and prints to the user the net amount to be spent: Pay 20B ?
Upon pressing Approve the transaction is signed with the private key and sent to the client for broadcast into the network. There's no way rouge software to fake the displayed amount or the Approve button.

Such a device would cost 10-20$ in large quantities and would be practically impossible to hack.
http://www.mini-box.com/picoLCD-20x2-OEM
http://www.mini-box.com/core/media/media.nl?id=18681&c=ACCT127230&h=13d54ca450368cba4c0e

http://en.wikipedia.org/wiki/Two-factor_authentication (http://en.wikipedia.org/wiki/Two-factor_authentication)

Someone give me a client that I can use two-factor authentication with. Until then, all other methods are insecure to some extent or other.

Two-factor authentication exacerbates the problem. Now, instead of one thing that can go wrong causing you to lose your bitcoins (loss of the wallet), there are three things -- loss of the wallet, loss of the password, and loss of the second factor.

Well, I'm not suggesting that you be forced to use any method. If you want to continue to use the current wallet.dat as is, then go ahead, I could care less what happens to your wallet or anyone else's for that matter. All I'm saying/asking, is give us some options, so if I'm okay with having more points of failure (loss of the wallet, loss of the password, and loss of the second factor), then I have those options to choose from. Because as is right now, I don't have ANY other options.

1. mount truecrypt volume
2. start bitcoind with datadir=T:\bitcoin\ (truecrypt mounted volume)
3. unmount when you're done

If I use GPG for my e-mails in Evolution, for every encrypted e-mail it asks for the password.
Why not implement this also in a bitcoin client: for every transaction the password is required, and the wallet is decrypted but not saved on HD, only in RAM when it is needed for the transaction.
This way the wallet is never decrypted in a file on the HD and is difficult to be stolen.

Grue method is nice but adding an option to set the T:\bitcoin\ (truecrypt mounted volume) thing in the client would really help, instead of having to type datadir etc etc

I don't think you understand fully the problem two-factor authentication solves. It's impossible to create a client that uses two factor authentication, once you are "authenticated" to the local client and it proceeds to decript your wallet, your bitcoins are available to the attacker. What I am proposing is NOT two factor, but an embedded wallet that handles the private key operations and minimal user input using secure hardware. Using a pin to unlock the device is purely optional, to prevent from physical theft.

Two factor is usable for authenticating against PayPal/MtGox online wallets, assuming you trust them to handle security better than your own computer.



The embedded wallet makes an encrypted backup each time you connect it to your computer. You can easily arrange online backup. The backup is encrypted with a key that you can read of the wallet's display, write on a piece of paper, and store it in a safe place.
Sure, you can loose that too, but it's a practical solution that actually works. Your solution "just keep your computer safe and make plenty of (safe) backups" is simply not practical for 90% of the people out there, because securing your computer has a tremendous learning curve. Securing a piece of paper on the other hand is something people do pretty well, see paper money.

Most people don't keep long-term savings in the form of paper money precisely because paper can be easily lost, stolen, or damaged. That said, I do think appropriate hardware is probably the best solution for most people. (Assuming trusting someone else with your key is out of the question.)

As soon as Bitcoin is accepted more broadly, the industry will produce smartcards for Bitcoin. Then you will have the keys generated on the smartcard, and they will never leave it. And the smartcard asks for a long PIN, which is typed into a trusted reader rather than a PC, and you have only a limited count of chances to enter the correct PIN.

This will be very secure, but it will include the danger of loss like almost every secure solution.

For what I read in the last few days, I think when I start buying large amounts of bitcoins, I will have an offline machine generating secure wallet keys and print them on paper for backups.


EDIT:
At the moment, I watch my offline address with block explorer, but that's not perfectly secure, they could fool me into believing that there happened something.

I don't believe smartcards will be any more secure than a password protected wallet.dat.
Once you enter your PIN, the trojanized client takes over the communication with the smart card, and instructs it to sign a transaction that empties your wallet to the hacker's address. Since you have no control on the amount that the smart card is signing away, there's no way you can prevent it or detect it, and it's equivalent to a trojan stealing your wallet.dat and password.

The hacker does not care about your private key, what he needs is the ability to impersonate you, that's why it is essential that a dedicated hardware wallet has it's own secure display and keyboard, with which you can verify the paid amount and a user friendly representation of the payee address.

Generating keys on an offline machine is probably the best solution at this point, but you will have to eventually need to connect to the network and spend, right ? Maybe you could split them in small amounts and have a paper version that you can scan and spend. Overall, not very user friendly.

People keep important paper documents in a fireproof safe.  They don't keep paper money there because paper money depreciates while governments inflate the money supply.

That's why I said: You need a smart card reader with a PIN pad, you should never enter the PIN into a PC. Especially for Bitcoin it would be very easy to display the transaction facts on the reader as well.

In other words, it's just on paper. But they put that paper in a super-secure location. Which is exactly what the client already supports.

This is the logic of all the hardcore anti-encryption people in this thread:


Good thing JoelKatz wasn't the one running MtGox or he would've stored all the passwords in outright cleartext ("no point hashing the passwords, an attacker who obtains the database can just brute force them all anyway")

Also, you should never bother washing your clothes because you might get hit by a planecrash tomorrow in which case the effort would be wasted  (this is RE: forgotten password paranoia)

You're forgetting one thing, which is that you can have multiple copies of your wallet. Any risk in forgetting a password or losing your second factor can be mitigated by having an inaccessible wallet one a flash drive/CD in a safe. Also, although people forget passwords, they don't forget personal details. You can use a strong password for your day-to-day wallet encryption, but then on the backup flash drive, have your wallet also encrypted but with a slightly less-robust password that can be composed by you or only by someone who knows you very well. Put a text file on the flash drive with instructions on how to compose the password.

I'm not talking about vague preference questions that can change, such as "What is your favorite book?" but details such as the name of the bone that you broke when you were 15, the occupation of the person you were named after, the name of the house you lived in in college, whom your nickname is a reference to, etc.

No spaces, all lowercase, no grammatical articles.

I would only forget such things if I was shot in the head, but I'm certain that my family could put together the password if I died and they cooperated.

What about multiple keys (a la LUKS)? Granted, it will be slightly less secure, but you could burn an emergency recovery key under an obfuscated filename on a disc and hide it / give it to your wife. Or, cut the key in half and tell each half to two relatives who never talk to each other... Tattoo the last syllable on your private parts. :)

On the other hand, I agree that false sense of security is more dangerous than trojans for inexperienced users. They will eventually prefer online services, IMO. But since our primary concern seems to be losing of passwords, being able to define multiple keys could help, and it shouldn't be too hard to implement on top of currently proposed encryption scheme.

No, my anti-crypto criticism goes like this:




And by the way, I am glad that there is no RSA involved in Bitcoin.

Actually, the business logic and web machine would not have been expected to protect the password. The authentication system, however, would have been a purpose-built fortress, and it would not have stored the password in cleartext.

My objection is to using encryption in applications where it creates more problems than it solves and doesn't solve the real problems anyway. I am a big advocate of secure encryption and authentication technologies when applied on appropriate hardware to the problems they actually solve.

To give a small update about the encryption system currently implemented and being tested for the bitcoin client:

• Only private keys are encrypted, and you only need the private key to do transactions.
• The GUI currently only has one way for unlocking a wallet, namely by entering a passphrase. The disk format does support several independent passphrases, although adding a second one is currently not implemented. In the future, this may allow a "generate unlock code" wizard or something similar.
• There are almost no restrictions on what the passphrase can be, although the GUI will encourage you to choose a long one.
• Attempts are made to use mlock() and similar calls to prevent the memory pages containing passwords and encryption keys to leak to swap, but this is not in general possible (as it needs cooperation from openssl and graphic libraries).

Great work. How computationally expensive is the algorithm that converts the passphrase to the key that decrypts the private keys? What I'm worried about is a trojan that captures the encrypted private keys and plaintext public keys (or hashes), and then knows how many BTC each wallet holds. He can then try to brute force the wallets with the most coins using compromised machines to do the brute forcing.

You can find some technical details here: https://github.com/TheBlueMatt/bitcoin/commit/9914f01fac25ff3891c3af8ac76c3ad5d6c3e9c6

25,000 rounds of SHA-512, salt changed each time the wallet is encrypted. Sounds good to me.

FFS, don't gox your own password derivation scheme, especially not one with a fixed difficulty, especially one that the current miners can attack (low asymptotic hardware cost).

Password derivation is a well studied field, please tell me Pieter why would you favor this solution over scrypt ?
http://www.tarsnap.com/scrypt.html

We didn't. It uses OpenSSL's EVP_BytesToKey routine with a standard hash function.

It's not, the number of iterations is stored in the file. The implementation will probably try to iterate for 0.1s, which gives already >100000 iterations on my system here. 25000 is just a minimum/default.

We specifically don't use SHA256 for that reason.

The disk format has an "derivation method" field, which is currently always zero (meaning EVP+SHA512), but may in the future be extended to support other methods.

This is done with the intention to support more derivation methods in the future, including scrypt, which looks really nice and aplicable here. I'm not sure scrypt is not "too young" to trust right now, though.

You can find some of the discussion about the system here: http://forum.bitcoin.org/index.php?topic=8728.20
Note that the resulting hash of the passphrase is never stored directly or indirectly, and the only thing encrypted with it is a random 256-bit AES key, so a rainbow-table attack is not possible.

Cool. Hopefully we won't have a wave of forgotten passwords, like the wave of stolen wallets we had. Secondary passwords / unlock codes would prevent this from happening, since I'm guessing inexperienced users would take notice, if it's by default. Maybe one unlock code could be generated by default and displayed on setup for the first version, before implementing a proper management interface. User has the option to ignore it.

It's salted, so a rainbow table attack is impossible for that reason as well.

The same GPUs that are used for mining can be easily reconfigured to attack PKBDF - SHA512 (that EVP_BytesToKey uses). The hacker only needs to rent the mining farm for the duration of the attack.  There will plenty of GPU farms available for rent when ASICs put them out of bussines (indeed, ASICs probably can't be configured to attack another hash).

A single 5970 can try 10.000 keys per second of the 100.000 iteration variety, so it can break a 40 bit entropy password in about 100 days. If you can rent a 5970 for a few $/day, than you can break many wallets for a few hundred dollars each. You know from the start what wallet is worth cracking from those you managed to stole, since the public key thus the amount enclosed are stored in plain text. It would be cost effective to crack allinvain's wallet even if he uses a 50bit entropy password, which let's face it not many users do.

Regarding scrypt being too young, from what I've seen in the code it still employs PKBDF2 before and and after the the memory-hard part. So even if it fails at being memory-hard, it will not compromise the password, it will be at least as secure as the current scheme.

That doesn't matter. Computers get faster exponentially, it doesn't matter whether you hash 10 times or 1000 times, if you want it to be secure for years or decades.

Password complexity cannot be substituted by this. Passwords get exponentially harder to break when you add more characters. (That's the whole point in password and key lengths).

You will have the advantage of AES256 over AES128 when you have more than 20 characters of random (same probability for each character independend of other characters). With 40 characters you reach the highest level AES256 can give you. That should be good for quite a while.

How did you come to these numbers?

@40 bits of entropy the average time to crack a password, given 10000 trials per second, is
2^40/10000/60/60/24/2 = 636 days

And, FWIW, a 8 character all-lowercase random alphanumeric is typically more than 40 bits entropy.

@50 bits
2^50/10000/60/60/24/2 = 651562 days

Hard to see the cost effectiveness of a 1000 5970s blasting out keys for a year or two. And that's still only an 8 character alphanumeric with one special character.

The 10k passwords/sec seems is a bit off. I've seen that on a few different forums. I think that was for cracking zip files or something.

A single 5870 can do 4.2 MD5 ghash/sec in whitepixel. A 5970 probably like 7 (in an x4 rig, they got 28.6 Ghash/sec).

At 40 bits that would be:

2^40/7000000000/60/2 = 1.3 minutes on average.

At 50 bits:

2^50/7000000000/60/60/2 = 22.3 hours on average.

Okay that can't be right. Would somebody please tell me what I'm assuming that is wrong? (Whitepixel data) (http://whitepixel.zorinaq.com)

You're assuming it only takes one hash to try a password.

http://www.youtube.com/watch?v=3yoduTFjZW4&#t=1143s

Somebody is building a better wallet, with built in two factor. Hmm.

I think I've assumed 100.000 keys per second. With the correction, it costs maybe a few thousand $ to break a 40 bit entropy wallet.


Absolutely not. 8 single case alphanumerics can have at most 41.3 bits of entropy (5.17 bits/char (http://en.wikipedia.org/wiki/Password_strength)), assuming a perfect random number generator and no inter-symbol memory (i.e something not generated by a human). An average 8 character human-generated password has about 18 bits of entropy (http://www.consealsecurity.com/conseal-blog/how-random/), and that after allowing the whole set of 94 printable ASCII characters !

I must insist on this point because it's the main takeaway: users don't choose good passwords. The average PayPal user has about 42 bits of entropy (http://research.microsoft.com/pubs/74164/www2007.pdf), and the majority of PayPal users have even less.

http://img842.imageshack.us/img842/4339/passss.png

It follows than that if you can increase the asymptotic hardware cost for the attacker with 2^10 or 2^20, as scrypt allows, you are achieving a great deal: moving from a situation where most passwords are crackable for a few thousand $, to a situation where most passwords need a few million dollars to crack. The same can be achieved by forcing users to chose good passwords, but that's hated by users and requires more implementation effort than just dropping scrypt in the source code.

The GPG keys are replaced periodically.  If you forget the passphrase, you are not likely to lose large sums of money. A savings wallet may be stored for decades. Are you really going to remember a passphrase consisting of 32 random digits in 10 years?

Computers are now fast enough that you pretty much have to write down important secure passwords (With the security implications understood my most).

Take-away: good passphrases are hard.

Why do we need encryption? If you need to keep a wallet for a long time drop it on 3-10 drives and delete the originals, or make them on live cds and have them connect online until you need to spend them.

my philosophy is as follows

1. humans are forgetful.
2. humans are predictable.
3. humans loose stuff, hence 3-10 copies, also for data redundancy.

The best solution i can think of is to hypnotize and embed you passwords into your friends in such a way that you do not even know the password. But we are not all mentalist now are we?

overall the most realistic solution i can think of is the standalone bit coin device. it would connect over wifi and never need to be hooked up to a computer. it could have a qr code reader for use at stores and such.

What if you lose one of the 3-10 copies and the person who finds it empties your wallet? The Bitcoin system, obviously, has protection against double spending. So you're screwed in that case.

I think you are taking the term "air gap" too literally :)

The assumption was a 100k rounds of SHA-512, not a single round of MD5. I don't know if the 10k trials / sec is correct, I just assumed that the OP had it right. It translates to roughly 1 gigahash/second of SHA-512 per 5970 which sounds slightly high to me but is probably ok given the assumption that GPUs wll probably keep getting more powerful each year.