[tglugdlh] Keyed Hash Fob / Calculator

I want a simple independent device with which I can calculate HMAC (keyed hash).  This is for management of passwords among different accounts.

It's a good idea to have different passwords for different accounts and online services.  If one account gets compromised, the same password cannot be used elsewhere.

However, with lots of different passwords, one cannot remember them all, so one writes them down in a file.  But if that file is discovered (the computer holding it is compromised), then all accounts are compromised.  So we encrypt the file with a master password. (Essentially, this is what your web browser's password manager does.)

However, if we happen to decrypt that file on a compromised computer (keystroke logger), then the master password is compromised, again revealing all the passwords.  It would be nice if the master password is only ever typed into a secure machine (e.g., unconnected to the internet), however, one can't conveniently access one's personal password database.

We could put each password into its own file and encrypt each separately with its own password.  But we seem to be back where we started.  Or are we?

Imagine we have the HMAC calculator mentioned above.  We consider it a secure machine, a simple device with no operating system and dedicated purpose. We enter our master password and account identifier and generate a hash (services could even store our account identifier for us, though for most people with only one account per service, the identifier is probably the service name).   This hash, or a portion of it, is used as a "session" key to encrypt the per-account passwords on your computer.  Alternatively, the hash is directly used as the password for the account, though this is hard to memorize and inflexible if we ever wish to change the password.

I imagine using Colin Percival's Scrypt to encrypt each password file: this way, the portion of the hash that needs to be manually transfered (typed) from the calculator to the computer does not have to be very long.  I'm imagining the calculator is a decimal display, perhaps a dozen digits, giving the HMAC mod 10^11, plus a (Verhoeff) check digit.  10^11 possibilities is hopefully infeasible with Scrypt KDF.  The encryption utility on the computer should check the check digit when initially encrypting.

So, this calculator has a twelve digit display, 13 buttons: 0 - 9, Enter, Backspace, and Clear.  The digits are also labeled telephone dialpad style with letters so that alphabetic master passwords and account identifiers may be entered.  Solar powered would be nice: so we do not lose access to passwords if the battery dies; alternatively USB powered?  And it should be commodity and cheap, buy a new one if the old one breaks or is lost (it holds no permanent state), or, in a pinch, use a software implementation.

Update

Upon further consideration, this calculator has a few problems. (Though still it's an improvement of what I see as the current state of things.)

If one per-account "session" key is compromised, e.g., with a keystroke logger on the computer, knowing the account identifier is enough to offline brute force attack the master password. We slightly benefit in that a short session key and short account identifier may not be enough to uniquely determine the master password, requiring multiple accounts to be compromised. If suggested phone spelling is used for the master password (one digit per letter), its entropy is lower than for letters. A solution is to have the calculator use Scrypt as a hash function (instead of, say, MD5) making brute force attacks on the master password expensive. Unfortunately, this greatly increases the cost of the calculator, and it probably makes it impossible to be solar powered.

If two people use the same account ID, e.g., "amazon", and coincidentally the same master password, the calculator calculates the same HMAC for both. This property makes the scheme vulnerable to rainbow table attacks. The solution is for someone, probably the encryption application on the computer, to generate and store a random salt for each account, which the user has to transfer to the calculator each time he or she uses it. Until this point, it would have been possible to use an off the shelf encryption application, and independent Verhoeff checksum checker, but the need to generate, associate, and store a salt requires some (simple) custom application.

When initially encrypting, we must be sure that the user typed the master password correctly. (If not, the session password, and ultimately the account password, can never be recovered.) The use can be encouraged to do the initial session key generation several times. Upon input of the master password, the calculator displays a short checksum. The user is either required to always remember the checksum (perhaps one Verhoeff digit is enough?), or it can be permanently stored in the calculator. However, even though this checksum is short, it does enable brute force attacks against the master password because the attacker need only check password which have the correct checksum. Perhaps we can make this checksum computationally expensive to calculate also, but we do not want to lose the optimized-against-human-mistakes Verhoeff property.