UppaJung
commented
4 years ago This has been on the to-do list. It was a much-more important component of the very-early DiceKey design because we've been trying to remove the number of cases where a checksum would be necessary:
- For automated scanning, the error-correction codes on the dice themselves already make the likelihood of an incorrect read so small.
- The app will keep internal checksums of DiceKeys it has previously scanned, so if you're using the same DiceKey multiple times with the same app/device it will differentiate a DiceKey it expects/recognizes from one that is new.
- The app design will strongly discourage (disallow, but allowing override) users from encrypting data unless the key was either scanned automatically (validated with error correction) or, if entered manually, if the DiceKey matches a checksum or has successfully decrypted an encrypted message (proving that it was entered without error.)
While good design necessitates that we try to do everything to prevent errors before requiring steps that involve human interaction, we're still going to offer checksums for those who want the extra re-assurance.
We're going to have a backup-to-words feature, though it will not use BIP39. When writing a word list down on paper, you will not get feedback if the checksum doesn't match until you need to recover, at which point it's too late to fix the error. Thus, backup to words should have error correction codes, not just error detection (checksums). Also, the BIP39 list has words that differ by edit distance 1, whereas we will likely use a word list where the values differ by edit distance >= 4.
My1
Basically what the title says, to have some quick way to make sure that the dicekey loaded is correct and hasnt been wrongly scanned, decoded or whatever that could happen over time one could make a kind of checksum over the dicekey and convert that to something that humans can quickly compare without needing to think a lot comparing things that are not overly intuitive.
One Possible example that I have seen to compare some binary stuff would be this fun thing: https://github.com/digitalbitbox/bitbox02-firmware/pull/623
Basically this uses the BIP39 list (could be any list of a ton of words you can easily use to encode a bytestream into, just was available in that specific instance and encoded the first 44 bits of the AppID-Hash of U2F. (Despite me Coding this for the Bitbox. it was originally by the Keepkey)
although this wouldnt be so awesome with Dicekeys from a security perspective as an AppID-hash is public and nothing to hide, the content of your Dicekey kinda is, so one could throw the Dicekey Data into a hash or HMAC with a statically defined secret or honestly whatever as long as it's a one-way function you cannot reverse to obtain even part of the secret.
so these words could be written onto the dicekey box or even remembered depending on the frequency of use, which might be a bit more if used in combo with a password manager) and shown upon scanning of the Dicekey to easily verify the scanning result hasnt changed over time. or even if the dicekey is stored digitally in some cryptographic device like a TPM, Smartcard or whatever, it could be used to publicly identify the device, making that easier to make sure it hasnt been changed while not needing more of an "explicit" verification.