Hello, Tony,

--047d7b47204eee59e0050dc7a2b1--
> I totally understand that a property that occurs with 2^{-18} (as=
Bernstein did with BADA55 curves) can be forced to exist in the selected c=
urve. The example that I posted earlier is the specific curve that is stand=
ardized in Russia, by a group of experts where the condition mentioned by P=
aul ("a group w=
here even if a single person is trusted") is satisfied ("trusted" for us, not for the internation=
al community and CFRG, I suppose).

=

=

> When we generated our curves and f=
ixed base points, the main problem that we addressed was to ensure that for=
all protocols that make use of elliptic curves and require "provably =
unknown" logarithms of some points (for example, password protected ke=
y establishment, PAKE, EKE, PACE, etc.) can obtain such a property: x-coord=
inates of base points and constant points for prototocols are chosen by has=
hing some random seeds =E2=80=93 we don't want only a blind belief of r=
andomness of such points (the most painful example here is Dual EC DRBG, of=
course). We look at curve generation problem in a similar way: we cannot b=
e secure against the unknown bad properties of curves that occur with proba=
bility of 2^{-18} =E2=80=93 even if the procedure is totally "rigid&qu=
ot;. But at least we can be sure that if some bad property of our curves is=
found, we would know that this couldn't be a "backdoor" that=
can be exploited only by developers of the curve, who know some logarithms=
, preimages etc. (again, as with DUAL EC DRBG).

> If to talk about new c=
urves for CFRG document, the usage of deterministic ("rigid") pro=
cedure is quite reasonable, we agree here. We've posted our curve becau=
se we think that it can be interesting for CFRG to look at one of the urves=
that have been standardized for all Russian cryptographic community. We=
9;ll post some specific comments to the current draft later today.

We know about BADA55 curves, we tried=
to explain our position on them in my reply to Alyssa; for now I don't=
have anything to add. Anyway, thanks for taking part in the discussion. We=
'll try to formulate our comments and suggestions for the current draft=
later today.

Kind= regards,

Stanislav

2015-01-28 20:22 GMT+03:00 Tony Arcieri <ba=
scule@gmail.com>:

On Wed, J= an 28, 2015 at 6:14 AM, Stanislav V. Smyshlyaev <smyshsv@gmail.com>= wrote:As we believe (and= as it has been mentioned earlier during discussion at CFRG), the initital = seed value doesn't have to be chosen explicitly in case of trust in bas= ic hash function properties =E2=80=93 to gain some "backdoor-type"= ; properties of the curve with d =3D hash(W), one has either to combine suc= h algebraic properties of a curve with properties of a hash function (for a= trivial example, to have an ability to obtain a hash preimage) or to choos= e a very probable "backdoor-type" property of a curve (such that = it is possible to obtain by random choice of a curve).Hi Stanislav,Dan B= ernstein and Tanja Lange have already demonstrated that such "verifiab= ly random" generation procedures can be used to surreptitiously tweak = specific curve parameters:I for one would not feel particularl= y inclined to trust a curve generated with this method, and would personall= y prefer the sort of rigid curve generation approach that this committee an= d others have been working on to any curve with large unexplained mystery c= onstants.

--Tony Arcieri