A malicious attacker sending a small point could lead the server / user to leak private information.
The check avoiding mixed order points (rather than just small) is prohibitively expensive, and I don't know how an attacker would extract any data from that => we focus on a small order check.
Fixes#34.
We used to have three problems:
- overuse of the <Sha256 as Digest>::OutputSize, which is just, well, U32. Sometimes used as a parameter (as in generate_oprf1), sometimes as a constant (as in generate_oprf3).
- the `hash_to_curve` operation for `RistrettoPoint` which requires 64 bits of input entropy, is fed 64 bits of which the last 32 are zero,
- the `hash_to_curve` operation for `Curve25519Point` which requires 32 bits of input entropy, is fed 64 bits of which the last 32 are discarded,
This corrects all three and uses U32 where the size of the digest is not meant to be a constraint.
Addresses #15 partially.
This brings the `Group` and `SizedBytes` traits into some sort of name
coherence (they both return a GenericArray). This also uses
`&my_generic_array[..]` (i.e. the `Deref` impl) over
`my_generic_array.as_slice()`.
Kevin Lewi