On Thu, Mar 24, 2016 at 3:58 AM, Michael Rogers <[email protected]> wrote: > > I'm probably missing something, but it seems to me that if you're using > the public key only as a (high entropy, easily disposed of) input to > local key derivation, an ordinary flash drive with some random data > would work just as well
That seems right - the protocol Elijah linked [1] just fetches a "secret" from the device, then does password-hashing using that secret. So while the device and password are two separate factors for decrypting local-stored data, they don't force a device-thief to interact with the device for every password guess. So that doesn't meet Elijah's requirement: """ how can we encrypt and decrypt local secrets in such a way that a weak password does not allow an attacker with possession of the device to be able to easily decrypt the local secrets. """ But if the device required unlocking with a local password or PIN before it responded then maybe using [1] to retrieve the public key as the decryption secret would work? Are there u2f devices like that? (A more dubious idea would be to encrypt the u2f handle with the password. If the handle has no structure then an attacker couldn't check password guesses by trial decryption, and would have to submit each password guess to the u2f token, which would presumably either reject it or return a signature with a wrong key, and that might add some delay to strengthen a weak password. But that's probably assuming too much about the handle). Trevor [1] https://jbp.io/2015/11/23/abusing-u2f-to-store-keys/ _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
