> Are sensitive values set to zero after being used? In Rust this may be done using the Drop trait rather than explicitly.<p>A zeroing Drop is theater unless the sensitive data is Pinned too. Rust likes to copy things around.
It's a bit surprising that the article didn't mention ensuring constant time algorithms are used. If latency or the emissions of the CPU (etc. externally observable) are data dependent on something secret, that secret might leak through the side channel.<p>One way to combat these side channels is to use constant time multiplication, loop conditions (including functions that might return early, like memcmp), etc.<p>Is it possible for Rust to have any new or surprising mechanisms that cause loss of constant time execution?<p>(Of course also other aspects can leak than the CPU instruction execution latency itself. For example cache effects might be measurable.)
> Look for any recursive function calls and see if they could be abused to overflow the stack.<p>This isn't an exploitable vulnerability in Rust, though? I thought the program would just abort if it overflowed the stack.
Looking at the article, I like the Drop trait, as a way to ensure memory are cleaned before being released.<p>What is the preferred way in Rust to say "If at all possible, please do not allow this value/object/whatever to be paged out of RAM?"
Sorry if too off-topic, but I figured this was a good place to share my experience with trying to use the Rust `crypto` library, which I recounted in this comment [1]. It's not a security concern, but it does affect usability.<p>I had the simple task[2] of encrypting bytes with AES using the library. But (as detailed in the post), they didn't expose a simple, "give us plaintext bytes, give us key bytes, give us options, we'll spit back the ciphertext bytes". Instead, you have to delve into the irrelevant details of constructing mutable buffers (which require special care in Rust), so it can read from and write to them, and without even any good examples in the docs for how to construct those buffers.<p>It seems designed from the perspective of "I have extremely limited memory" -- which is fine, but why not have a simple wrapper on top of that for the common, non-embedded use case, and some example code?<p>[1] <a href="https://news.ycombinator.com/item?id=18943940" rel="nofollow">https://news.ycombinator.com/item?id=18943940</a><p>[2] for the Matasano/cryptopals challenge. Interestingly, I found that the hardest parts weren't figuring out the vulnerabilities, but in implementing a spec (every writeup was poor) or getting "off-the-shelf" software to behave as expected so I can have a utility function for it and forget about it from then on!
> Review the dependencies listed in Cargo.toml: Will the latest version be used? (preferable but not always the right choice) Are these established, trustworthy packages?<p>The author seems to have forgotten about Cargo.lock....