Messages to Scalars

[BasileiosKal]

Messages need to be mapped to scalar values before they are signed. The criteria on the procedure to do so are flexibility and security.

To allow for predicate proofs, blind/ bound signatures etc, we need to allow for messages to be already scalars before passed to the core operations. An approach is the following

                           + --- msg, if msg a scalar 
                          /
message_to_scalar(msg) = <
                          \
                           + --- hash_to_scalar(msg), if msg an octet string

This is not ideal. Assuming that the prover is relaying to the verifier the msg type, for a given octet-string msg m, they could reveal octets: m or scalar: hash_to_scalar(m) and both would validate.

Option A

Integrity protect a map between msg index and msg type (octets/scalar). This is inspired by U-Prove that does something very similar, as noted by @christianpaquin here.

Specifically, let the bit array enc = enc_1 || enc_2 || ... || enc_L where enc_j := msg_j is a scalar. Then enc will be computed in Sign, Verify and ProofGen and added to the domain.

In ProofVerify, the enc value cannot be computed (not all messages will be known). There are 2 options,

• Add enc to the proof value.
• Add enc as an input to ProofVerify.

In any case, in ProofVerify, the disclosed messages type should be checked against enc.

Advantages

This avoids the above issue of the prover revealing msgs as scalars that they where signed as octets.

Disadvantages

A breaking change. It will add a fare amount of steps for something that is an extension point. It will require changes to the proof value or the ProofVerify api.

Option B

Similar to option A but layered on top of the current core operations. Allow for higher level applications to define schemas that will be passed to the header (instead of the domain as in option A).

We can pass the header (that will encode the schema) to the messages_to_scalars and map_to_scalar operations.

Assume the schema is encoded as the enc bit array defined above, we can set header = enc || old_header. Then we will map a msg like

scalar_value = map_to_scalar(msg, idx, header)

Procedure:

1. if header[idx] == 1 and msg a scalar: return msg
2. else if header[idx] == 0 and msg an octet string: return hash_to_scalar(msg)
3. else return INVALID

Advantages

Solves the issue. Not a breaking change. Minimum updates in general.

Disadvantages

We can't define the above map_to_scalar in the core draft, if we don't want to define the concept of a schema (i.e., of the enc bit array that will be added to the header).

[BasileiosKal]

Couple of alternatives:

• Relax the requirements of map_to_scalar to be 1 to 1, and describe that in case that property does not hold, it needs to be clear which message corresponds to a scalar value using external mechanisms (i.e., a schema).
• Define a map_to_scalar that only accepts scalar values and manage the mapping to higher level documents/extensions.

None of this will require a breaking change (or even a change to a procedure step).

[BasileiosKal]

Closing after #287 was merged