We have to keep in mind that this is fundamentally storing a password. Just point the cursor into a text editor, hit “Send” on the Arduboy, and your password is in the clear. That limitation means that other parts of this setup just don’t derive a lot of value from being over-engineered.
The random number generator is the least of my concerns. We’re not doing ephemeral keys or DH here! And using the time of day isn’t too bad - it’s a since-start clock with 32 bits that cycles every 20 minutes - and you should not use the lowest 3 bits due to lack of resolution. If we take 8 bits off the top, it will cycle about every 4 seconds, and we can still get 16 middle bits quite easily. If micros() is captured a few random times during initial unlock PIN entry (triggered by keypresses), then whitened with the hash function, it should be possible to get about 250 bits of entropy of reasonable quality.
Initial passcode - this will use a double legged PBKDF2 sequence, once to check against a stored hash to see if you belong here, and the second leg (different HMAC key) to prime the encrypted storage. That will use PBKDF2 over a base value with a block number so that every block has a unique key. I have yet to decide if that second leg will just generate the base key, or unlock a stored base key. The second option has the advantage that you can change your passcode without re-encrypting all of the storage.
The double legged process ensures that if you examine memory to get the entry-permission hash, you don’t get anything you could use to decrypt memory.
All of that is necessary because we really don’t have secure storage. Just load up another sketch and it can read out all of EEPROM!
I’m expecting that I can leverage HMAC-SHA256 in some way for the crypto operations. That is an attempt to limit the code size.
I expect that given the need to store both passwords AND a field indicating what the password is for, this utility will warn you once, then just take over all of EEPROM. Even then, it will only be good for between 30 and 50 passwords. That means anything else stored in EEPROM will be gone.
I am looking at one way to limit EEPROM consumption. Rather than always store a “site description”, there will be a list of canned site labels in progmem - think ebay, FB, amazon, gmail - that can be used in the description while consuming only a byte or two. Think of it as a static compression dictionary!
You say “my Arduboy” like you have only one? What’s the point in that?
In some small ways, this is better than more complex solutions. Lots of systems lock down both the running of arbitrary software (for password management), and also the use of higher capability USB functions (such as for memory sticks). As a result, people load all their passwords into either a text file or a spreadsheet. But almost nobody locks down USB keyboard and mouse functionality. Moderately secure crypto in an Arduboy should be better than a text file! Next project? An Arduboy mouse jiggler.