Is this going to be as secure as I hope?

S. Dale Morrey sdalemorrey at gmail.com
Fri Feb 14 13:30:31 MST 2014


I'm in the process of constructing a webwallet for crypto currencies.
There are no private keys kept anywhere on the server.  The public keys are
merely tracked by a modified coindaemon that has the ability to have "watch
only" keys.

However to make this work cleanly I need to be able to have the user
recover their own privatekey when they want to create a spend, at least
long enough to sign the transaction and hand it back to the network.

To do this I've devised an algorithm to derive the private key on the
client.

All the bytes of username+password+key creation time are inserted into a
byte array.
This is 0 padded to reach a length of 256 bytes.
The array is sent to SHA256 and hashed and salted with a 9 digit pin.

>From there the hash is handed to whatever standard ECDSA key creation
function is standard for the coin.

To enforce a 9 digit pin and yet make it easy enough to remember I'm
implementing what I call a synesthetic PIN.  It's a 3 by 3 grid you can
fill with the colors white, black, grey, red, orange, yellow, green, blue,
indigo, violet.

Each color actually corresponds to a digit [0..9]
(To aid the color blind such as myself there will be the option to just
enter a 9 digit pin instead).
Colors will be in a color picker and will be reusable.

This has the advantage of making a keystroke logger effectively useless as
long as they use the provided input methods to pick.

I do worry that this process removes a great deal of entropy from the input.
I'm content with the fact that as long as there are at least 160 bits of
entropy it should be at least as safe as the current methods of key
creation (I hope).

The problem I'm hitting against is this.
The ASCII space between 0 & 255 has many non-printable characters.  By
limiting the input to only printable characters, it takes away a great deal
of potential entropy from the key creation process.

Can someone walk me through how much entropy we actually have in play here?

A username must be any combination of printable characters with a minimum
length of 7
A password must be any combination of printable characters with a minimum
length of 10
Key creation time is a 32 bit number (Unix time)
PIN is a 9 digit number which is generated by pressing colors into a grid
(so it may be subject to some selection bias, but 3 repeats or more of a
single color would be disallowed as would contigous runs of 3 or more i.e.
0123456789 would be disallowed as would 000000000 (which incidently is the
combination to my luggage)

So what does the math look like on this?  Do I have at least 160 bits of
entropy or should I add or remove something?  Thanks!


More information about the PLUG mailing list