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

[Squeamish Ossifrage <[e-mail]>]

Hi "Rene" (if that is your real name):

I would be curious to know how the quality of the research is different depending on whether it is signed ‘-=rsw’ or ‘Riad S. Wahby’.  Can you expand on that?

Shirley, using ‘real’ names would only make it easier to form preconceptions about the merit of an argument based on the name of who wrote it, no?  For example, wouldn't you expect much stricter scrutiny on an argument made by a queer carrion fowl calling themself Squeamish Ossifrage?  Nobody would give them a pass on the basis of nominal reputation!

If I were a spook who wanted to slip a back door or shoddy design into a standard for something like a PRNG or a PAKE, I would probably choose a boring name and quietly maintain a plausible-looking CV at a cryptography or networking company that nobody would bat an eye at, and then write long-winded discursive emails on an intimidating mailing list that discourages newcomers who aren't comfortably established in the field with their ‘real’ names (whatever it is that makes one name ‘real’ and another name fake).

Sincerely,
—Squeamish Ossifrage


P.S.  To keep this on-topic: The probability of a hash falling into a small subgroup is so small (e.g., ~1/2^252 for Curve25519) that any attack involving it necessarily implies a remarkable structured preimage attack on the hash function—or that you should have bought some lotto tickets instead of spending your time crouched over a glowing rectangle faffing around with hashes and curves.  If you chose a curve for which this probability was large enough to matter, you would be in serious trouble with rho anyway!

Similarly, for example, in AES-GCM there is an almost unimaginably larger probability, 1/2^128, of choosing an all-zero GHASH evaluation point, under which the authenticator is independent of the message content.  But the probability is so small that nobody cares.  And ‘But what if you abuse map_to_curve on its own in a place where the adversary can manipulate the algebraic structure?’ is no more an argument against the complete hash_to_curve design than ‘But what if you abuse GHASH on its own in a place where the adversary can manipulate the algebraic structure?’ is an argument against the complete AES-GCM design.

If you have a user who picks a password that hashes to a small subgroup, that's not a reason for failure—that's a reason to invite them to be coauthor on a paper (under a name they choose, which may not be the name a government has them under in a database that requires the help of a solicitor to change) in a flagship publication, about a novel attack on the hash function!


> 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., [e-mail] wrote:
>> Hello Feng,
>>
>> "Hao, Feng" <Feng.Hao=[e-mail]> 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
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>
>
> --
> email: [e-mail] | Skype: rstruik
> cell: [phone] | US: [phone]
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg