decentralized-identity / bbs-signature

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

Message Encoding #40

Closed mikelodder7 closed 2 years ago

mikelodder7 commented 2 years ago

Data can be encoded multiple ways depending on how it will be used with other ZKPs. For example, it will not be useful to hash an integer to a 32 byte value using SHA256 and expect it to work properly with Range Proofs. The following is a list of encodings and the use cases they can be used:

  1. Hashed: for aribitrary length data fields that will not fit in the base field e.g. images, strings, biometrics, blockchain transaction info. Use hash2field or some other method to hash the data into a 32 byte base field value.
  2. Bytes: a value that is already in the base field
  3. Numbers: for range proofs. The value is zero-centered by take computing the base field modulus z=q / 3 integer division as the zero center and adding the positive number or substracting the negative number. To support complex numbers like decimal, the number is converted to fixed point arithmetic. The Q format is used for these numbers as Q64.160. This leaves two bytes to avoid numbers greater than q. While it does not represent the full breadth of IEEE754 numbers, it does give a considerable resolution -263 to 263-2-160 signed and 0 to 264-2-160 unsigned or about 48 decimal places of precision. If decimals are rounded to the nearest integer, then Q format is not necessary.
  4. Null: Hard coded as 5. Means the value is not included or not used.
  5. Empty: Hard coded as 11. Means the value is included but is an empty string or zero bytes. For example, a person does not have a middle name but a value is required to be entered.
  6. Ignored: Hard coded as 23. For data fields that were ignored or not answered by the person. This is different than empty where the person's answer is literally nothing vs they chose not to answer it at all.

Small safe primes were used for the last three but can really be any value that is not 0 or 1.

Comparing numbers to Null, Empty, Ignored

No DLEQ proof is needed to check for this since the verifier gets to pick the bounds and in theory this could be done but isn't meaningful

BasileiosKal commented 2 years ago

I’m fine with the encodings. I was thinking about the scope though, i.e., is the bbs+ spec the best place to define them. To my knowledge crypto specs don’t usually define data representations.

From the bbs+ perspective will it make a difference If 5 means Null or something else?

mikelodder7 commented 2 years ago

I don’t think so as long as we agree what means what

tplooker commented 2 years ago

Being addressed in #61

tplooker commented 2 years ago

Addressed in #61, closing