I see. Which would be kind of similar to how you do it in C; the destructor is actually guaranteed to run when it goes out-of-scope?

But what I'm a bit more worried about is how the secret data gets in there, and what happens while I'm working with it: expansion, cipher state, key setup, all the little adds and xors and rots (dammit, why doesn't ROT ever get some real operator love? It's got first-class instructions… :() - all that stuff you'd do in u32 and u64. Temporary copies may still be a problem, if you look at the object that actually comes out of compilers sometimes.

Does using an opaque type actually deal with that issue here?

I know nothing about writing crypto core code. But... Rust supports inline assembly, so after you're done, you could always zeroize every register, right?

Since the compiler can do whatever it wants, you can't be sure it hasn't put any part of the key anywhere on the stack, and there isn't sufficient information for the asm to know which registers contain tainted values.

Unless you can actually prove all parts of the compiler's data transforms going down to assembly I think the safest thing to do is sandbox your key-handling process so nobody else can examine it.

Great. Now your sandbox needs secure zeroisation.

Yes, actually proving all parts of the compiler's data transforms going down to assembly kind of is what I'm after, if we can get it…