Consider adding `Eq` where possible about orion HOT 5 OPEN

The additional semantic requirements for Eq are laid out in the trait's docs. I think this is okay to implement at least for any of our types that are just "bags of bytes". The three relevant properties are:

• reflexivity: a == a
• symmetry: a == b implies b == a
• transitivity: a == b and b == c implies a == c

The type system will enforce that the bag-of-bytes types can only be compared with the same type, which guarantees that the underlying bytes semantically mean the same thing and that we're not, for example, comparing a private key and a hash. That's the only thing I can think of that might break one of the above properties, and it's not an issue.

from orion.

Just for reference, clippy suggests the additional Eq on the following types:

• X25519 PublicKey + PrivateKey + SessionKeys (high-level API)
• BLAKE2b Hasher enum

Good points @vlmutolo. Seems like this shouldn't be too much of an issue then.

from orion.

In the const generics refactor, the byte containers will all look like Public<C, D>. I think we can derive Eq on PublicData and the various D storage types (e.g. ArrayData). This means that Public will implement Eq if and only if the context parameter C implements Eq. So we can control which types implement Eq just using the context parameter, which is in line with the spirit of the refactor: pushing logic (such as min, max sizes) into the context parameters and letting everything else be the same.

I imagine we'll want to implement Eq for all the current byte container types, but it's good that we'll have the option to not implement it selectively.

from orion.

Do you think it'd be better to postpone this to post const-generics, that you've been working on @vlmutolo?

from orion.

I think we can go ahead and add this in the current implementation. I'll also make sure to add it in the const-generics branch.

from orion.