[draft] Constant-time equality checks for sensitive values

[swenson]

We always want to use constant-time and constant-power when doing operations on private keys, and generally we should use constant-time and power operations for hashes and signatures. Sometimes it can be difficult to tell when a given hash is sensitive or not (for instance, if it relates to potential customer code, we don't know how sensitive that code or its hash might be). I think it makes sense to take a cautious approach and protect too many things rather than too few, especially if it doesn't cost us much in terms of code size to protect additional things.

The built-in PartialEq and Eq trait derivations are not constant time or power.

In this PR, I'm removing the PartialEq and Eq derivations from potentially sensitive areas or putting them behind #[cfg_attr(test, derive(PartialEq, Eq))] blocks, and re-adding PartialEq implementations as necessary that use constant-time and constant-power versions.

I ported the OpenTitan hardened_memeq C function to Rust for now, but I'm open to suggestion on that.

Also, when we use type aliases for sensitive values, like type SomeValue = [u32; 48], I'm changing them to a 1-tuple so that they can't be treated as an array accidentally compared insecurely. It's a little more annoying (and makes the PR noisier), but it helps prevent accidental insecure comparisons in the future.

Overall, this should have a small impact on the overall ROM and firmware sizes, mostly due to the new memeq function. I'm hoping to minimize that impact, and possibly reverse it entirely, before merging this.

TODOs:

• Add constant-time ct* functions from OpenTitan to make it truly branchless.
• Check the rest of the code base for digest, signature, and key arrays that are embedded in other structs.
• Evaluate if we need all of the OpenTitan protections, like decoy arrays
• Add tests for OpenTitan-ported code
• Update RandomWalk to use a Gray code to actually do a "random" walk with no randomness.
• Check if inlining the RandomWalk Gray code will save instruction space
• Update the dpe submodule as well with the same mitigations, e.g., for CryptoBuf.
• Update the common cfi submodule, if that is where we want to put the memory comparison
• Evaluate the instruction size impact of core::hint::black_box() vs. doing a simple inline-assembly laundering. (In the memeq function, we only use laundering to force values to be loaded into registers, so we might use a simpler laundering approach).
• Clean up the unsafe code
• Reduce instruction code in places by adding more reuse or with small inline-assembly versions of certain pieces

[swenson]

The Gray code comment I made above is basically changing this to be self.state ^ (self.state >> 1), and going to min_len.next_power_of_two() instead of min_len * 2. This added a few extra bytes of instruction code, which pushed it over the ROM limit, so I've removed it for now, and left this functionally equivalent to the not-at-all random_walk functions in OpenTitan.

[jhand2]

There is also the constant_time_eq crate, although I don't have any reason to believe this is any better than porting the OT implementation.

[swenson]

I looked at the constant_time_eq crate, which we use in dpe. It contains a much simpler set equality check (it doesn't use decoys or random walks), but it would probably be fine if we don't think all of the extra precautions are necessary.

[swenson]

I split off a cfi_launder cleanup PR that saves about 1 KB of ROM and 600 bytes from runtime. #1714

The impact from this PR is an additional ~200-300 bytes in ROM, depending on a few choices (about 150 or so from the hardened memory equality function). But if you count the other PR, then we're still saving hundreds of bytes :)

I'm still digging through the impact of a few choices to try to get this down more.