Closed BasileiosKal closed 2 years ago
To clarify I think we would change that particular line to something like domain_prime = encode_for_hash(PK, L, gen_octets, Ciphersuite_ID, header)
- although I'm not sure how we want to handle variadic arguments syntactically.
I'm fine with this approach as well. We may not need to handle variadic arguments. We just need to make sure everything is < 72 chars. For example, something like,
7. d_prime = (PK, L, H_s, H_d, H_1, .., H_L, Ciphersuite_ID, header)
8. domain = hash_to_scalar(encode_for_hash(d_prime), 1)
would work just fine IMO (everything is < 72 chars above). Similar for the challenge hash etc. Then encode_for_hash
will take a single argument (like encode_for_hash(input)
) and the procedure will just loop through the elements of that argument (like for el in input: ...
)
Something to note is that the encode_for_hash
function cannot be 100% explicit. We will have to say something like if el is a G1 point
and if el is an octet string
etc. Personally I’m 100% fine with that.
The current Encoding of Elements to be Hashed section needs to be updated. The reason is that elements before they are hashed, they are concatenated with other elements in multiple steps. As @andrewwhitehead noted This is not clearly captured by the section yet.
Some options:
encode_for_hash
function (see @andrewwhitehead's comment here)Each time elements are concatenated together, they must first be turned to octet strings. Every time an element other than a scalar, a point or a non-negative integer is transformed to an octet string, the length of the resulting octet string must be appended to itself.