possible attack if SHA-256 is reversible

[pts]

Let's suppose the attacker can read the keyfile, and he wants to compute the password without an access to the U2F token. Let's suppose that the attacker can compute the inverse of any SHA-256 hash (FYI this is not feasible as of 2017-11-30).

The keyfile contains sha256(public_key_x) as keyhash. The attacker reads it, reverses the SHA-256, and computes public_key_y from public_key_x (see the eckr.pointsOnCurve method how), and thus he gets the password.

From this we learn that if SHA-256 is easy to reverse, then security of this crypto is also easy to break.

Swapping the roles of public_key_x and public_key_y wouldn't be much better either. This way the keyfile would contain sha256(public_key_y), from which the attacker can get public_key_x, but he still faces the problem of modular cubic root to compute public_key_x from public_key_y. Computing modular cubic root is not much slower than modular square root (https://math.stackexchange.com/q/673418/5758), so the attacker can quickly get the password this way.

I don't have an improvement suggestion which avoids hashing altogether.

My improvement suggestions are any of the following:

• The keyhash stored in the keyfile should be sha512(public_key_x + public_key_y), and the password should be public_key_x + public_key_y (64 bytes, but has only about 32 bytes of entropy).

• The keyhash stored in the keyfile should be hmac_sha256(public_key_x, public_key_y), and the password should be public_key_x (32 bytes, almost full entropy).

[darkskiez]

I've changed to sha512 used the keyhandle as a kindof salt and added both keyparts.

Do you think that addresses your concerns?

[pts]

Yes, thank you!