Post
Topic
Board Development & Technical Discussion
Re: A bitcoin client with no PRNG. Possible?
by
DeathAndTaxes
on 09/07/2014, 04:59:25 UTC
My only concern would be that the deck be truly and well shuffled.

Good point.  However a Bitcoin address only has 128 bit security and properly shuffled a deck is 225 bits of entropy.  One would have to lose a lot of entropy to have any effect on security.   It takes about 9 riffle shuffles to properly shuffle a deck.  Not sure if human behavior can be modeled but I imagine a system of a wash, riffle shuffle, and cutting the deck could be devised to ensure adequate shuffle even by those with bad biases.  There are proven methods used by casinos to ensure decks have sufficient entropy however they are designed with efficiency of a professional in mind.  I am not sure if they would be optimal

I played a lot of poker in the past so I might not be the typical user.  I took a deck arranged it by suit (diamonds, clubs, hearts, spades) and in increasing rank (with Ace being high) such that the starting deck was from 2d to As.   I did 8 riffle shuffles trying to be casual and imprecise and cut the deck once at the end.  It took less than 3 minutes (and another 5 minutes to record the sequence).

I ended up with the following:
TdKh6sAc5s8hJcJs5c6h3s9s7cQsQh4s9h3c4h4c2hTs3hJh9c5hKc2cTc7s4dAh9d2dJdQdAd7hTh5d2s8c7dAsQcKd3d6d6cKs8s8d

Not too bad although there is a big clump of diamonds near the end.  Adding a wash at the beginning and mid sequence cut and additional ripples would probably improve things but I would be pretty confident using this sequence as an entropy seed (well not now that it has been shared).  One thing that occured to me is if the client asked the user for the actual card sequence it could run a statistical analysis and warn the user of a sequence which may show signs of insufficient shuffling.

If you take HMAC-512(card-sequence, "Bitcoin-Deckware) for the sequence above you get d017aa48483abd407348df1f7075faeb87e689f35735e0f2ffed551ef26b84bd6eaf8d56b328985 83c48aae1a60df9ad8929f69049122952b74a39c4c0bff909

This could be broken up as, first 256 bits is hd_seed, next 128 bits is initial kdf salt, last 128 bits is symmetric cipher salt.

hd_seed: d017aa48483abd407348df1f7075faeb87e689f35735e0f2ffed551ef26b84bd
kdf_salt:  6eaf8d56b32898583c48aae1a60df9ad
aes_salt: 8929f69049122952b74a39c4c0bff909