Discussion:
Schnorr NIZK over Curve 25519
(too old to reply)
Stojan Dimitrovski
2018-03-20 20:55:05 UTC
Permalink
Hi all,

I have a few questions regarding RFC 8235 over EC, specifically Curve 25519.

I wrote a simple implementation to prove that the protocol does work
(duh, of course it does). However, in the process of which I had to
modify libsodium to do scalar multiplication over Ed25519 without
clamping.

This was done specifically when calculating `G x [r]` since the scalar
`r` comes out of a computation.

Now, I'm not an expert at EC mathematics, but as far as I can tell
clamping on scalars is done to make sure that the scalar is always a
multiple of the subgroup's cofactor (`h = 8` for Ed25519).

Now, I am curious to know how I can avoid accidentally placing `r` in
an unfortunate subgroup, but to avoid clamping?

Would this be enough:

`r = h * (v - a * c) mod n`

or ... by knowing that since `v` is already "clamped" i.e. `v`, `a`,
and `c` are already multiples of `h`, it goes by definition that the
value `r` cannot be in an unfortunate subgroup?

Another question I have is: do you see any relevance in the _hinting_
of the RFC to use subgroups with a small cofactor (1, 2, 4) contrasted
with the cofactor 8 of Curve 25519?

Thanks!

For brevity, I paste the RFC 8235 protocol over ECs here:

In the setup of the scheme, Alice publishes her public key
A = G x [a], where a is the private key chosen uniformly at random
from [1, n-1].

The protocol works in three passes:

1. Alice chooses a number v uniformly at random from [1, n-1] and
computes V = G x [v]. She sends V to Bob.

2. Bob chooses a challenge c uniformly at random from [0, 2^t-1],
where t is the bit length of the challenge (say, t = 80). Bob
sends c to Alice.

3. Alice computes r = v - a * c mod n and sends it to Bob.

At the end of the protocol, Bob performs the following checks. If
any check fails, the verification is unsuccessful.

1. To verify A is a valid point on the curve and A x [h] is not the
point at infinity;

2. To verify V = G x [r] + A x [c].

The first check ensures that A is a valid public key, hence the
discrete logarithm of A with respect to the base G actually exists.
Unlike in the DSA-like group setting where a full modular
exponentiation is required to validate a public key, in the ECDSA-
like setting, the public key validation incurs almost negligible cost
due to the cofactor being small (e.g., 1, 2, or 4).
--
Stojan Dimitrovski
http://stojan.me
Ben Smith
2018-03-21 18:35:55 UTC
Permalink
Hi all,
Post by Stojan Dimitrovski
At the end of the protocol, Bob performs the following checks. If
any check fails, the verification is unsuccessful.
1. To verify A is a valid point on the curve and A x [h] is not the
point at infinity;
2. To verify V = G x [r] + A x [c].
The first check ensures that A is a valid public key, hence the
discrete logarithm of A with respect to the base G actually exists.
That's not quite correct. If A is a legitimate multiple of G and T is
a point of order 2, say, then A+T also passes this test, but it has no
discrete log w.r.t. G (and is therefore not a valid public key). What
Test 1 is really telling you is that A is a point on the curve and
that the order of A is not a divisor of h. In this case, where the
curve order is h*prime, this lets you deduce that the order of A is
divisible by the prime---but that's all (there might be bits of h left
over). Multiplying everything by 8 pushes everything right into the
interesting subgroup, and removes that sort of ambiguity.


ben
--
You know we all became mathematicians for the same reason: we were lazy.
--Max Rosenlicht
Loading...