Re: [CFRG] please use real names (was: Re: Small subgroup question for draft-irtf-cfrg-hash-to-curve)

To the best of my knowledge, there is no requirement for participants in the IRTF to use their real names.

Participants do, however, agree to follow the intellectual property disclosure rules, and other requirements, of the Note Well. These require a certain amount of transparency.

There is some tension between these two points, but my understanding is that it is possible to participate in IRTF pseudonymously while complying with the Note Well.

Colin

> On 10 Apr 2021, at 16:34, Rene Struik <rstruik.ext@gmail.com> wrote:
> 
> Hi "rsw":
> 
> As a general courtesy, may I suggest that all communications use people's real names and not some obscure acronym.
> 
> The CFRG is supposed to be a research forum, where people do not hide their identity. In fact, in my opinion, IETF should have no place for communications by "anonymous".
> 
> Rene
> 
> On 2021-04-10 11:12 a.m., rsw@cs.stanford.edu wrote:
>> Hello Feng,
>> 
>> "Hao, Feng" <Feng.Hao=40warwick.ac.uk@dmarc.ietf.org> wrote:
>>> Rsw also gave a similar example of having all zeros for the hash.
>>> Let me clarify that we are not – and shouldn’t be - concerned with
>>> any of such cases since the values are uniformly distributed within
>>> their respective range.
>> Right. And the argument is precisely the same for hash-to-curve!
>> 
>> Let me be perfectly clear: the property that hash_to_curve gives
>> is that the output is a uniformly* distributed point in the (big)
>> prime-order subgroup of the target elliptic curve.
>> 
>> At the risk of seeming didactic (in which case, apologies): the
>> identity element is indeed an element of the target group G.
>> 
>> Put another way: fix a generator g of group G of prime order q. Then,
>> hash_to_curve returns g^r in G, for r sampled uniformly* at random
>> in 0 <= r < q. Under the assumption that discrete log is hard in G,
>> hash_to_curve does not reveal r. Under the preimage and collision
>> resistance of the underlying hash function, one cannot choose any
>> particular r or find two inputs that hash to the same r.
>> 
>> I hope this helps clarify the security properties, and why focus
>> on low-order points at intermediate steps of the computation is not
>> relevant to the security of hash_to_curve as specified.
>> 
>> * uniformly except for some statistical distance less than 2^-100.
>> 
>> Regards,
>> 
>> -=rsw
>> 
>> _______________________________________________
>> CFRG mailing list
>> CFRG@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
> 
> 
> -- 
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
Colin Perkins
https://csperkins.org/