Message to Scalar flexibility

[BasileiosKal]

Fix #245

Define input messages as octet strings and explicitly call messages_to_scalars in each operation.

Note this makes #266 obsolete, since it enforces consistency on the input arguments (everything are octets now).

Based on #267 to avoid the extra explicit checks (would be couple of steps)

[BasileiosKal]

Discussed on the WG call on the 19th of June, will define the Input of messages_to_scalars to be typed elements instead of octet strings.

[BasileiosKal]

Updated the PR as discussed om the WG call.

A message can now be a scalar or an octet string.

Did not allow a message to be an integer. Reason is that if a msg is an int > r, then what would essentially get signed would be msg' = msg mod r, meaning that the signature would be valid for both msg and msg' (< msg), which seems wrong (especially taking into account range proofs).

If there is a need to sign an int > r, one could scale it down to make it a scalar. You could still use range proofs that way.

Differentiating between a scalar like a SK, and a date intended to be used in range proofs would only be possible on the basis of those messages indexes.

Also I don't think signed ints are needed either but I opened #270 to discuss this further.

c.c @andrewwhitehead 🙏

[andrewwhitehead]

I put in some suggestions for using MESSAGES_TO_SCALARS_ID, but perhaps OCTETS_TO_SCALARS_ID would make more sense and avoid overuse of the term 'messages'?

[BasileiosKal]

Updated the operation. As discussed in the WG, added a map_to_scalar operation, that will map a (msg, idx) pair to a scalar.

1. Turns out that if a msg is a scalar, simply returning it (while hashing the octet strings) is not secure. There is no way to know that what was signed is the octet string msg and not the scalar = hash_to_scalar(msg).
2. Did not use octet_to_scalar for the same reason.

cc @andrewwhitehead i think the PR is ready for re-review!

[christianpaquin]

As mentioned in the discussion in today's WG call: U-Prove allows both direct encoding and hashing the attributes. This is useful, within one ciphersuite, to allow encoding attributes of different types in one credential (e.g.: hash name, address, etc., but encode directly age and expiration to allow range proofs). See the e values in the Issuer params (section 2.3.1 of the crypto spec).

[BasileiosKal]

Discussed on the WG call on the 10th of July. Merging and will open an Issue to keep track of the conversation.