[messaging] abusing u2f

[Trevor Perrin]

On Thu, Mar 24, 2016 at 3:58 AM, Michael Rogers
<michael at briarproject.org> 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/