Hash to field with custom hash function

[bellebaum]

Hi,

I am trying to use this library to implement BBS Signatures and Proofs as well as various extensions. To do this, I need a hash-to-curve with a bit of flexibility in the hashing-part. Specifically, I need to be able to exchange the hash function. Ideally, I would also be able to use incremental hash APIs.

I understand that my own expand_message and this library's blst_map_to_g1 will get me most of the way there. What is missing is the option to construct field elements (fp) from byte strings (by interpretation as big endian and calculation mod p). Essentially the following functionality:

blst/src/hash_to_field.c

Lines 145 to 151 in 097818a

	limbs_from_be_bytes(elem, bytes, L);
	bytes += L;
	/*
	* L-bytes block % P, output is in Montgomery domain...
	*/
	redc_mont_384(elems[0], elem, BLS12_381_P, p0);
	mul_mont_384(elems[0], elems[0], BLS12_381_RRRR, BLS12_381_P, p0);

Would it be possible to add this to the public API? Say as a function void blst_fp_from_be_bytes(blst_fp *out, const byte *in, size_t len)?

Thanks in advance :)

[dot-asm]

I need a hash-to-curve with a bit of flexibility in the hashing-part.

One can override expand_message_xmd by compiling with -Dexpand_message_xmd=custom_expand_message_xmd. It was added to meet BBS, though the question was about Blake at the time...

blst_fp_from_be_bytes

I don't see how it would help. I mean what will you do with the said fp element?

[dot-asm]

Formally speaking one can make a case for adding expand_message_xof, because it is a part of RFC 9380. At the same time the said RFC doesn't explicitly specify BLS12-381+ SHAKE combo...

[bellebaum]

Hi, thanks for your response :)

I don't see how it would help. I mean what will you do with the said fp element?

Basically get two of them and hand them to blst_map_to_g1. I would also be fine with a function taking 128 bytes of hash output and turning them into a blst_p1 via this map.

One can override expand_message_xmd by compiling with -Dexpand_message_xmd=custom_expand_message_xmd

That is interesting. I ultimately want to simultaneously support both Cipher suites, differing in the hash function (SHA256 vs SHAKE256) and the particular random-oracle-glue code (XMD vs XOF). That means I would have to compile the code twice?

[bellebaum]

Still that would leave a problem for me: I have to hash a virtually unbounded amount of stuff into the element with limited space available, so I am using incremental hashing currently, which I could not do with a standalone one-shot expand_message_xof.

Edit: Although this is a solvable problem because the expand_message invocations with a lot of inputs are distinct from the ones used to generate group elements. So technically I could have 4 implementations of expand_message lying around. Sounds ugly though...

[dot-asm]

I don't see how it would help. I mean what will you do with the said fp element?

Basically get two of them and hand them to blst_map_to_g1

Ah! Fair enough. Let me think...

[dot-asm]

Check out #272.