Topic: DeckWallet: looking for security feedback and comments (Read 1277 times)

Regarding the single round hashing I chose that method to make it compatible with brain wallets. That way users can get their coins even without the app (although the process is much more complicated of course). They can just write their password followed by the card ordering (ex: myPassword4CTS9D...KHQSAH) and get the address here. By far the main security feature is the card ordering, not the password, in fact the later is optional. An attacker would need to have the actual deck of cards to even try brute forcing the password if set. I consider the password as a 2FA and not the other way around.

I like the BIP-39 mnemonic idea very much. I will definitely implement that when I have some time. I'd also like the app to allow either generating/exporting the master public key (for deposits and balance checking), the list of the first X addresses, the actual mnemonic or an individual private key for a single address. This way even if a single address is redeemed the whole wallet doesn't have to be discarded because the mnemonic and the other keys have never been online.

Regarding your last phrase (if verifiable), I do want to make sure it is 100% verifiable. The current measures I've taken are:
- Code is open-source.
- Published app is not obfuscated, so it can be de-compiled.
- No access to Internet.
Any other recommendations to make it verifiable?

Most probably I'll add 2 modes in settings: "Brain wallet" (as it is working now) and "BIP-39" (which would be the default option).

I didn't see any direct issues.  Single round hashing is good and needing the deck sort of makes this like a two factor system but single round of a fast function like SHA-256 isn't ideal for hashing password.  Brute forcing passwords is easier for an attacker because a single attempt is so quick.  That is why I suggested a KDF such as PBKDF as it would provide additional security against moderately weak passwords (key stretching).  Still that is only a suggestion.  

As an user option you may want to consider allowing the user to enter a deck and select to output a BIP32 BIP-39 mnemonic seed.  This would provide a convenient way to generate (without using a PRNG) and backup any wallet which uses BIP-39 seeds (such as trezor).   Not everyone trusts PRNGs but generating a seed from cards, dice, or coins manually can be confusing.  An app which makes it easy to take a deck of cards and produce a secure high entropy seed would be useful.  I would recommend it (if verifiable).

You could memorize the order or write down the order and encrypt it with a gpg just for the fun.

Like a party guest who wants to play gin rummy noticing a deck of cards sitting on your bookshelf and wanders into your study or bedroom or whatever private area to get them...

Not only losing them, but shuffling them (or causing them to be shuffled, e.g. by dropping them). Or taking them through airport security the day after someone is in the news hiding secret messages in card orderings.

But sure, I get your point. I'll stop complaining about this.

What do you mean small accidents? Like losing the cards or burning them? That's why at least a second copy is recommended. Check the ann. thread. I'm asking for security opinions related to the app itself.

The cypherpunk in me loves steganography, but this seems really fragile in the sense that small accidents may cause huge losses.

(I know this is obvious but somebody needs to say it on the front page of this thread )

Thanks. I like the idea of generating a HD wallet to make it compatible with other wallets and to generate an unlimited number of addresses. Most probably I will implement it soon. Unfortunately that new version wouldn't be compatible with the current one so I'll need to handle that properly to allow current users to recover their coins.

Any comments regarding security? Do you see any problems savings big amounts of coins this way?

Two ideas:
1) You may want to use a KDF with multi-round hashing instead of a single hash.
2) Instead of generating an address from the seed use the seed to generate an entire HD wallet.

I've developed an Android app to easily and safely store bitcoins in a deck of cards:
Announcement | Google Play
I'd like some feedback from experienced users, especially regarding security.

Here's how it works:

• The entered cards are converted to 2-char strings and concatenated. For example 3 of hearths is represented as 3H. 10, Jack, Queen and King are represented as T, J, Q and K respectively.
• If a password is entered, it is pre-pended to the resulting string.
  Example seed: myPasswordAH4CTS9D...KHQS
• The first address is calculated as a brain address, using SHA256 from the full generated seed. The result is the same as manually entering the full string into http://bitaddress.org or other similar tool.
• The second address is calculated from the seed except the first card is moved to the end (Example: myPassword4CTS9D...KHQSAH)
• The third address is calculated from the seed except the first 2 cards are moved to the end (Example: myPasswordTS9D...KHQSAH4C) and so on.
• To check the generated wallet, the double SHA256 of the full seed is temporarily stored on RAM.
• Nothing is stored permanently and nothing is sent or received through Internet (the app doesn't have permission to do that).

More details here: https://bitcointalksearch.org/topic/android-deck-wallet-v10-store-your-bitcoins-in-a-deck-of-cards-811397

Please post your comments. I'll consider them to update the project.