Quote from: DeathAndTaxes on July 09, 2014, 12:48:42 AM

Someone mentioned using the random ordering of a deck of cards as the entropy for an HD wallet seed (I can't recall if it was electrum developer or armory developer but great idea). It had never occured to me but there are 52! possible permutations (52 * 51 * 50 * 49 .... *1) to the ordering of a shuffled deck of cards. That is ~80,658,175,170,943,900,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 or ~225 bits of entropy. It is faster, and easier than rolling a number of dice. Unlike dice there is no issue of bias (a dice which favors higher numbers). I wouldn't recommend it but you could even leave a backup of the seed in plain sight by keeping the deck in the proper order in the box.

So it got me thinking could you design a wallet which made absolutely no PRNG calls. CSPRNG are potential weak link in any cryptographic system and as most rely on deep OS level calls flaws or intentional backdoors can be difficult to detect (or at least provable state that they don't exist). The only client operations that I can think that require the use of cryptographically secure random numbers are key generation, transaction signing, and wallet encryption (salt in key derivation function).

HMAC(card sequence) -> seed
BIP38(seed) -> master pubkey and master key (and indirectly all derived keys and pubkeys)
RFC6979(key, message_hash) -> k value
LEFT16BYTES(HMAC(seed)) -> salt (on password change LEFT16BYTES(HMAC(old_salt)) -> new_salt)

So one deck of cards, a lifetime of secure transactions, and no additional sources of entropy required. Anything I am missing?

+1

Entropy should always at least be visible in an editable field, though it could be initially filled with PSRNG output.

Cards, dice, free association, it doesn't matter. Let the user decide. That way as a wallet dev you will never be the one that blew it.