Topic: BIP 38 Discussion Thread - Passphrase-Protected Private Key Format - page 2. (Read 8729 times)

Recommended reading: Practical Cryptography, Ferguson & Schneier


Confirmation code allows generator (Bob) to prove he has produced an encrypted private key without revealing the private key. When the confirmation code is given to the owner (Alice), they both now have an address that can be funded, but neither can spend the funds. Alice needs the encrypted private key (to decrypt), or Bob needs the passphrase (to decrypt).

It's almost a zero-knowledge transaction, in that both parties know there is a private key, but neither knows what it is.

I don't know why we use double-hash.


The attack could be: You have two encrypted keys, decrypt one of them, partially spend it and keep the decrypted version around for later spending. Suppose they are both based on the same intermediate code and produced without the AES encryption part. If someone finds them (one decrypted, one encrypted), then that person can spend also the encrypted one. So I see your point for AES now, unless you forbid reusing intermediate codes.

Different question: what is the purpose of the confirmation code? If I can decrypt the encrypted key with my passphrase I can also be sure the address depends on the passphrase, and that it is only spendable with the passphrase. No need for a confirmation code it seems.

Because it can be, and little more.

The same reason we use SHA256(SHA256(whatever)) instead of SHA256(whatever).

Because, I figure why give an attacker 1 factor when we can give him 0 factors at pretty much no extra cost.  Also, the attacker could have some advantage if he has another encrypted private key and knows the corresponding unencrypted private key (but not the factors) for a different key pair based on the same intermediate code.  If such an attack exists, I don't know what it is, but I made that attack far more difficult by denying the attacker the freebie he would need to execute it.

Someone else had also pointed out something that I understood like this: if someone were to make an ASIC to crack these, his job just got that much harder.

Bump.

Question is still being asked. If the party generating the addresses, knowing seedb, cannot compute the private keys then why is seedb ever encrypted? The address passpoint*factorb cannot be redeemed without knowing passphrase and ownersalt.

Is there another reason to encrypt seedb?

Would you mind updating this wiki article to reflect this?
 - http://en.bitcoin.it/wiki/List_of_address_prefixes

If Bob were to disclose both the "intermediate code" and the encrypted private key he created to Charlie, then Charlie could determine that the two of them are associated, and could independently calculate the bitcoin address.  With the intermediate code, Charlie can "decrypt" the AES encryption on the key material generated by Bob, which is how he can get the bitcoin address, but he is still missing Alice's key material, which is only available with the original passphrase, so he can't get the private key actually needed to spend the funds.

A proposal that I'm drafting has exactly the same property you describe, possibly for much the same purpose you describe, but has more features, namely, Eddie the escrow agent being able to release the funds to Alice or Bob, while having no access to take them for himself.  The proposal also does not rely on Eddie for the funds to be released to Bob as would be the typical case if the transaction is successful.

Look at this (which could have fundamental unresolved issues being a draft in progress).

https://en.bitcoin.it/wiki/User:Casascius/Escrow_scheme_draft

What is the security flaw?

What is the purpose of AES encryption in the second method (EC multiply mode)?
You could simply place seedb unencrypted in the encrypted private key instead of encryptedpart1 and 2.

Thank you for the clarifications. I knew there was some vanity generation technique, but I was not familiar with the process. I see that BIP38 is particularly designed for use cases when the user wants a passphrase-based key. (I'll go read more about the EC addition process. When I was studying crypto, we didn't get into EC so much as factorization-based algorithms, and I really want to solidify my understanding of the roots of Bitcoin.) Inspiring work - thank you.

Yeah, but unfortunately it works not a ton better than the standard practice now: send a public key, keep the private key, and combine them with EC addition (my utility can do this as well).

The intermediate code is just as ugly as the public key, and the only advantage would be that the original requestor would keep around a passphrase instead of a private key.  That's not a hugely useful improvement because whether it's a phrase or a key, it's no longer needed once the vanity address is generated... the user won't have an interest in memorizing it or trying to engrave it in limited space.

Also AFAIK, vanity generation MUST use EC addition and not multiplication, otherwise it would run way too slow to be useful.  EC addition has a security flaw but it only affects a very specific use case and does not affect vanity generation.

I think this would work for vanity mining.  That problem does already has some solutions.  https://vanitypool.appspot.com/


How would proof be given?

The ability to generate addresses without knowledge of (exposure to) the private keys is masterful. I've studied cryptography (and even digital cash) in grad school and have practiced applied cryptography professionally for some years, but I'd have to really get back into my studies to properly analyze your methods. If they're sound, then this is a wonderful capability for Bitcoin. The BIP itself is written very clearly and concisely.

I know this comment isn't very substantive to the discussion, but I wanted to thank you for your efforts. I already thought you were awesome for producing physical Bitcoin coins (combining two of my favorite things: coinage and cryptography), so now you're pretty much my new hero.

EDIT: Here's something more substantive: This would solve the Vanity Address Service conundrum. Scenario: Alice wants a Vanity Address, but does not have the CPU power to generate one. Alice sends Bob her intermediate_passphrase_string. Bob has lots of compute power and can generate addresses without any knowledge of the private keys. When Alice's desired vanity string is found, Bob can provide the address and encrypted key to Alice, who can decrypt the private key and use it without fear that Bob will exploit it later. Bob can even show proof that he has found a valid vanity address before releasing the encrypted private key back to Alice (e.g., to request payment for service).

I've seen something like this proposed for vanity addresses before, but I believe this BIP solves it rather well. Is this accurate?

UPDATE: ... and now I have yet another idea ...

Over my head, sorry.    Get in a mind set discussion about certain things and the jokes start missing.

Not only is it hard to remember, it has enough bits to be a private key itself. I was making a little joke, not very good at jokes. 

Hard to remember though. 5 alphanumeric shouldn't be too hard to remember without having to write it down or mistype a very long password.

I agree that the current difficulty is sufficient. I thought the difficulty being configurable would be a nice feature, but you can always just use a longer password.


^^ Damn good password.

As he has it right now, it takes about a second to decode on my machine if you know the password. This would make it so that this could run on a phone in javascript at this difficulty when the password is known. Same machine would take half a year to crack 5 character single case. Make that upper lower and you're 12 years. Obviously, he had twenty machines and was not using the un-compiled code. For waht he is proposing the current hashing length is sufficient. If I'm calculating all of this right make it alpha numeric upper lower and that same thing takes 29 years on my single computer.

Could this be modified so that the amount of CPU per guess could be configured? For example if you had to hash something 100 times instead of once to get the key instead of 1 time it would take 6000 hours to crack instead of 60. But if you know the password it will still only take a few moments to decode.

Not sure about the exact internals of your protocol but something like that would be nice and really annoy the brute force attackers.

This is in reply to your other thread, but single input works, the multiple does not. Regardless of what I enter, it does just say unrecognized. Looking at your code, button for multiple just allows multiline and changes textbox1. The button1 sends the text off to an interpreter that doesn't recognize more than one address at a time.

Something else I noticed, if I add an address only, it says private key, unknown. Is there anyway to tell it what the private key is if I enter it backwards like that?