decentralized-identity / bbs-signature

The BBS Signature Scheme
https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html
Apache License 2.0
78 stars 26 forks source link

Elements to be hashed update #185

Closed BasileiosKal closed 2 years ago

BasileiosKal commented 2 years ago

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:

  1. Define a helper encode_for_hash function (see @andrewwhitehead's comment here)
  2. Say something like 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.
andrewwhitehead commented 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.

BasileiosKal commented 2 years ago

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.