Re: [CFRG] I-D Action: draft-irtf-cfrg-hash-to-curve-16.txt

[Jeff Burdges <[e-mail]>]

I should not have even mentioned squeeze, sorry.  I suggest to either
clarify that counter may be a compile-time constant, or else explicitly
say counter must support 1 and 2, while just not saying anything about
other values.  It does not really matter the exact "weasel wording", so
long implementors feel okay not using dynamic allocators here.

Jeff





On Jan 10 2023, at 8:52 am, Mike Hamburg <[e-mail]> wrote:

> My two cents: I would prefer not to specify it as a squeeze behavior,
> especially since that’s also complex and even fewer implementations
> need to do it in practice.
>  
> Maybe we could specify that implementations of hash_to_field may be
> restricted in terms of what counts they support, and that supporting
> {1,2} suffices for all the uses in this spec?
>  
> Or we could specify that hash_to_field may be internal?  Then you
> definitely wouldn’t need to implement it for all N, just for the cases that
> actually come up.
>  
> Regards,
> — Mike
>  
>> On Jan 10, 2023, at 1:24 PM, Jeff Burdges <[e-mail]> wrote:
>>  
>>  
>> Appears hash_to_field and expand_message should not involve an arbitrary
>> counter.  Instead, they should either (a) be specified in terms of some
>> squeeze behavior, or else (b) have the counter restricted somehow.  I'm
>> sure (b) suffices since hash_to_field needs a counter of only one or
>> two.  
>>  
>> In fact, you could merely say the counter is a constant, not a runtime
>> variable.  An implementation that uses a constant is then compliant,
>> while an implementation that uses a runtime variable "exceeds" the spec,
>> which is fine.
>>  
>> As is, this adds implementation complexity for platforms without a
>> dynamic allocator, ala https://github.com/arkworks-rs/algebra/issues/572
>>  
>> Best,
>> Jeff
>>