Derive Hash for a bunch of types

[dvdplm]

Some of the types in the crate do not derive Hash which make them difficult to use in hashmaps or sets.

It would be nice to make Checked also be Hash, but that requires dalek-cryptography/subtle#138 so perhaps that can be a separate PR.

[tarcieri]

I'm a little concerned about deriving Hash for potentially secret-containing types. Though the default Hasher is SipHash which is fine when properly keyed, other hashers do not necessarily prevent preimage attacks

[dvdplm]

Do you think documenting the caveats properly is enough? A bigint library that blocks all potential security misuses risks crippling itself a fair bit and it’s not obvious where to draw the line. I’d argue that in this case it’s expected that users know about the security hazards.

[tarcieri]

It would definitely need documentation. This library is documented as being constant-time by default and we are careful to treat each integer as potentially containing a secret, with separate *_vartime methods which act in variable-time so as to make those sort of secret accesses easier to audit.

I would also want to know what a use case is for keying a HashMap with ConstMontyForm.

[tarcieri]

Ditto here re: potentially secret-containing types

[dvdplm]

This library is documented as being constant-time by default and we are careful to treat each integer as potentially containing a secret, with separate *_vartime methods which act in variable-time so as to make those sort of secret accesses easier to audit.

Thinking about this further I now think you are absolutely right. If crypto-bigint's stance is that its integers are all potentially secrets, then its types should not be (easily) usable in hash maps or sets. Users would have to have deep knowledge of how the hasher used in their code behaves wrt CT and pre-image resistance etc (or pick a cryptographic hash, with the perf penalty).

This was a dumb idea. Closing. :)