4 ms·
> It's more like TADA — Trust After Device Additions. Indeed. Or, "TA-DAA"! (trust after device addition/alteration, again) I'm not comfortable with this "sec
by e12e 8y ago
> It's more like TADA — Trust After Device Additions.
Indeed. Or, "TA-DAA"! (trust after device addition/alteration, again)
I'm not comfortable with this "secure" device held key.
Maybe a private key that's pass-phrase derived could anchor the trust? So that the device key just becomes a trusted sub key/cert? With maybe a 30 day validity before renewal. (renewal ux being: please enter your pass phrase to insure continued integrity...)?
- geofft 8y agoThis is the idea of cryptocurrency "brainwallets," and the result seems to be that people are really bad at picking high-entropy passphrases. One of the nice things about cryptocurrency from a cryptography point of view is that it provides a direct, real-world monetary benefit to attacks. So we don't have to wonder if people will pick good passphrases or they'll be brute-forced—the experiment happened, and it wasn't promising. Using a passphrase alongside some online verification mechanism by a semi-trusted third party (e.g., your initial Signal app generates a secret, encrypts it to your passphrase, and stores it on Signal's servers who only return the encrypted secret to "your" new phone if it has your phone number too) might be enough.
- e12e 8y agoYeah, "cryptographically secure" and "something you remember" doesn't mix well. 128 bits (say) is a lot of data to memorize. Having it be a real approximation to random doesn't help. I suppose the pgp/ssh model of secure device holding the master key plus the ability to backup (eg qr code printout in a safe). An approximation for phones would be a random key locked in the device with a pin, an the ability to transfer and backup keys as you mention. Other than that - I've not really heard of gpg keys or ssh keys being brute forced - but that may be because by the point you gain access to the (encrypted) private key - you already have access to everything else? [ed: for example there are 52 cards in a normal deck of cards, meaning each card encodes about 5.7 bits(2^5=32,2^6=64). You could represent a ~128 bit key as a sequence of ~23 random cards. Or add add a few checksum bits and use half a deck (26 cards). Note, shuffling a deck isn't a great source of randomness, but you could use dice or a computer to generate the key - then map it to a sequence of cards.]
- ben0x539 8y ago128 bits is like, what, ten words chosen randomly from a suitably large dictionary? Is that really prohibitive? Even as random alphanumeric string that doesn't seem beyond muscle memory. Seems like the biggest pain would be to input it consistently on a phone keyboard.
- e12e 8y ago10 random words from a really large dictionary. Narrow down to, say words three to five letters, and 128 bits get tricky. It's easier in the sense that we have a certain active/passive vocabulary - but you'd probably need a mnemonic with words too. [ed: input is definitely a challenge. I've considered making various alternative input methods - but in the end 128 bits is a lot of data to input without error. Especially on a phone. Of course on a phone you might have a pin protected secure enclave for example, or use an external nfc key etc. But it then we're back to some way to remember 128 bits - and maybe even without the luxury of "practice" by way of typing it a few times a day...]
- geofft 8y agoSeems hard to reliably remember 10 words chosen randomly unless you use them very regularly. I don't want to type in a ten-word passphrase every time I open my texting app?