Pages:
Author

Topic: Pondering a Highly Secure Deterministic Brainwallet - page 2. (Read 3263 times)

kjj
legendary
Activity: 1302
Merit: 1026
First, there is absolutely no chance in hell that you remember a passphrase with 160 bits of entropy.

Second, why aren't you just using the published HD wallet spec, using your seed?
newbie
Activity: 28
Merit: 0
I have been thinking long and hard about how I would like to structure my cold storage solution.  It involves a deterministic brainwallet approach.  I’m quite confident that it is extremely secure, and I would like to check my thinking with this community.  I am still quite new to this space, and I am not a programmer, so I don’t understand the deep technical workings of the open source code of brainwallets and encrypted keys.

I have read just about everything I can find about brainwallets, and have seen all of the very vocal advice to not use them.  That is all predicated on the assumption that our passphrases are not sufficiently random.  However, I have formulated my own MindHash approach that can repeatedly generate a large set of passhphrases that each well exceed 160 bits of entropy.  I’ll just have to say “trust me that I can do this” – and I am interested in your feedback about the security of the rest of my deterministic brainwallet design.

First some notation to make the rest of the description more clear:

PP1: a high-entropy passphrase to be used as the initial brainwallet seed
PP2: a different high-entropy passphrase to be used to encrypt all subsequent private keys

PK1: the first private key
PKn: the nth private key

ePK1: the first encrypted private key
ePKn: the nth encrypted private key

I use bitaddress.org to create the brainwallet private keys (PKn)
I use bit2factor.org to create encrypted private keys (ePKn) from the private keys (PKn).  (bit2factor.org uses BIP38 to encrypt private keys, and it works with blockchain.info for importing back for access to the money.)
(Of course, these are run while disconnected from the internet.)

So, here is the process to deterministically create n encrypted private keys and associated public addresses:

Use PP1 as initial passphrase to create the brainwallet PK1
Use PP2 as passphrase to encrypt PK1 to create ePK1
Use ePK1 as passphrase to create the brainwallet PK2
Use PP2 as passphrase to encrypt PK2 to create ePK2
Use ePK2 as passphrase to create the brainwallet PK3
Use PP2 as passphrase to encrypt PK3 to create ePK3
.
.
.
Use ePK(n-1) as passphrase to create the brainwallet PKn
Use PP2 as passphrase to encrypt PKn to create ePKn


Then, to put money into these addresses, I send small amounts of coin to addresses from the bottom up.  In other words, I send money to public address n first, then (n-1), then (n-2), and upwards.  But I would not put any money in the first few addresses (1, 2, 3, etc) just to be extra paranoid.

To use money, I would withdraw from the bottom up, so that the imported private keys can be discarded without jeopardizing the security of other addresses.

Benefits as I see them:
1) The actual final wallets are built with highly random private keys from prior steps in the deterministic approach, and a brute force attack would require solving two high-entropy passphrases.
2) I can very openly record the seed that my MindHash approach needs to generate the two high-entropy passphrases.  I can write the seed down, keep it on my computer and cloud storage, and in a safe deposit box.
3) With BIP38, even if one of my private keys was discovered, it is still strongly encrypted.

As a small test, I put a few BTC in one of my generated ePK1 addresses quite a while ago, and they are still safely there untouched.

At some point, I will have to find some secure and trusted DeadManDrop solution to document my scheme and mindhash approach for my family.  Any suggestions on that would be appreciated.

In the meantime, I look forward to your thoughts and feedback.  I am also specifically interested if the Key Derivation Functions of brainwallets in bitaddress.org and of BIP38 in bit2factor.org from a technical limitation standpoint as it pertains to my scheme above.

EDIT: a couple of minor typos corrected
Pages:
Jump to: