Thanks Scott for the feed back, that is very well apprecia=
ted.=C2=A0

__
--0000000000001adbe1058e4ffcd9--
__

I agree that having a proof that is actually =
a proof is definitively better, especially when that seems feasible. We cou=
ld however argue that bG is an ephemeral secret and at that time is only kn=
ow to the client and server, but let's do not take that path.=C2=A0=C2=
=A0

The previous scheme was derived from a scheme =
where c is chosen by the server. In our scheme, c was not derived by the se=
rver but simply out of the control of the client for a given exchange (base=
). In fact, c is derived from base that includes the TLS randoms, and so th=
is was believed to prevent the generation of a proof for bG that woudl not =
be a public key for a given TLS exchange. In the scheme you propose, everyt=
hing is derived r which is completely under the control of the client. I ju=
st want to check that this does not provide some facilities to the client t=
o generate a proof for bG that may not be a key. I am happy to change the p=
roof scheme to what you propose.=C2=A0

A second qu=
estion I would have is how do we perform the check with X25519 X448.=C2=A0 =
=C2=A0=C2=A0

* do we need to check bH(R)G=C2=A0+ R as well as=C2=
=A0=C2=A0bH(R)G - R and consider it correct if one matches.

* I s=
uppose that r is clamed, but I am wondering if that is sufficient.=C2=A0

Yours,=C2=A0

Daniel

On Mon, Jul 22, 2=
019 at 11:43 AM Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:

It would appear that the Proof of Ownership listed i= n section 6.1 of the draft doesn=E2=80=99t work, in the sense that someone = without knowledge of the value b can still generate a valid proof.

=C2=A0Here is how he would do that:

- We assume that the putative client knows the = value bG (the public key), base and ecdhe_params; we assume that he does no= t know b.
- The client= computes c =3D poo_prf ( base + ecdhe_params + "tls12 poo")
The client picks an arbi= trary elliptic curve point R, and computes the point T =3D c(bG) + R.The client places R (as h= is supposed rG value) and T (as his supposed tG value) in poo_params, and b= G in the ecdhe_params.

=C2=A0Then, the server computes c(bG)= + rG; that is, c(bG) + R (for the client-provided R).=C2=A0 He then compar= es that to tG (that is, the client-provided T).=C2=A0 Of course, this will = pass (the client picked T to make this happen), and so the server will believe that the prover knows b, when he doesn=E2= =80=99t.

=C2=A0Now, I don=E2=80=99t know lurk,= and so I have no idea what sort of vulnerability this would allow.=C2=A0 H= owever, if you have a =E2=80=98proof of possession=E2=80=99, it should be a= n actual proof=E2=80=A6

=C2=A0One way to fix this is to use a= more normal Schnorr proof of knowledge:

=C2=A0

- We assume a hash function h( X + base + ecdhe= _params + =E2=80=9Ctls12 poo=E2=80=9D ), where X is an elliptic curve point= and returns a value between 1 and q-1, where q is the order of the curve; below, I=E2=80=99ll summarize this as h(X)
- The client selects a random value 1 (= between 1 and q-1 =E2=80=93 it must be chosen uniformly), and computes:
<= /u>

- R =3D rG
- = t =3D bh(R) + r mod q
The= client sends the point R and the value t in the poo_parameters, and the va= lue bG in the ecdhe_params.

- The server computes the points tG and bH(R)G = + R; and compares them =E2=80=93 it accepts the proof of ownership if they = are the same point.

=C2=A0

=C2=A0_______________________________________________

Lurk mailing list

Lurk@ietf.org

https://www.ietf.org/mailman/listinfo/lurk