|
This reverts commit c48736a18976a8d1c62fec3dbfa5c8c4dce38bc6.
The authentication indeed breaks down if an identity element is provided
as a public key, but this is merely a specific variant of a more
general algebraic issue.
What actually matters is rejecting points at infinity when they appear
*as the result of the secret derivation* (the exponentiation), not
as the client public keys. This might happen whenever an element from
any non-prime subgroup is used in secret derivation.
All-zero shared secrets must be rejected. This is correct, robust, and
doesn't rely on enumeration of all possible "bad" curve points.
This is tricky to model because Tamarin's Diffie-Hellman primitives
assume prime-order group, but implementations usually aren't. In
particular, X25519 has a cofactor and thus small-order points that end
up as an identity element after multiplying them by a clamped scalar.
One such point is:
e0eb7a7c3b41b8ae1656e3faf19fc46ada098deb9c32b1fd866205165f49b800
Checks remain implicit in the model, but must be explicitly done in
real implementations.
|
|
If the server doesn't check that the user's public key is an identity
element O (point at infinity), authentication breaks down.
Because O^x = O, no matter the verification secret, the final result
will be: h(<O, challenge, O, username>). Username is assumed to be
public information in the model, and the challenge is openly sent into
the network. What's supposed to prove authenticity of the client via its
secret key and identity, now becomes a trivial universal backdoor with
the server challenge acting as a direct invitiation.
|
