[Rust] Optional clear_on_drop

Question

[Rust] Optional clear_on_drop

Closed this issue 6 years ago · 12 comments

I am trying to compile to wasm32-unknown-unknown and get the following error:

rust-lld: error: unknown file type: hide.o

I read that I can't compile clear_on_drop to wasm.

So it would be nice it could be excluded optionally.

Answer 1 · 2018-12-14T23:28:23.000Z

I'd be curious about finding a zeroization solution for wasm.

Answer 2 · 2018-12-15T11:21:47.000Z

Set it to all zero?

Answer 3 · 2018-12-15T14:40:28.000Z

Well more specifically, I've recently written a zeroize crate which I have largely switched to in other projects and I think it'd be interesting to figure out a "best zeroization strategy for wasm" there, even if it is "a for loop setting it to zero" provided there is no better alternative.

Answer 4 · 2018-12-15T14:46:13.000Z

I meant just set the key to [0, 0, 0, 0, 0, 0, ...] wouldn't that work? And if the aes instance gets out of scope it should be deleted anyway, right?

Plus wasm means that it passes through js, which is garbage collected and has access to the memory of wasm anyway (My key comes from js).

Answer 5 · 2018-12-15T14:53:43.000Z

Yes, that "works", and is what e.g. the TypeScript implementation of Miscreant does:

https://github.com/miscreant/miscreant-js/blob/master/src/internals/wipe.ts#L23

It doesn't quite meet the on-the-label requirements, but like the comments above note, it is probably the best you can do for something like wasm.

Answer 6 · 2018-12-15T14:55:41.000Z

It would be a good idea to implement this as feature, so you can use that, if clear_on_drop is not available for you.

Answer 7 · 2018-12-15T14:56:09.000Z

something like soft-wipe

Answer 8 · 2018-12-15T15:01:47.000Z

Personally I'd rather avoid the use of cargo features for this and have it "just work"

Answer 9 · 2018-12-15T15:04:25.000Z

Wasn't there some thing to select by toolchain? Like "if <this platform> <do that> else <do that>"?

Answer 10 · 2018-12-15T15:06:56.000Z

Enable the nightly cargo feature to take advantage of the Rust intrinsic rather than using FFI to invoke OS intrinsics (requires a nightly rustc):

Wouldn't that work?

Answer 11 · 2018-12-15T15:09:38.000Z

Then the only thing would be to tell anyone who compiles to wasm to use nightly rust

Answer 12 · 2018-12-18T02:22:14.000Z

My personal inclination on this matter:

We shouldn't feature gate zeroing memory, or add an insecure fallback. That introduces additional complexity in a security-critical area that is presently otherwise straightforward
We should try to support both stable and nightly WASM targets

I've opened an issue on the zeroize repo (which miscreant.rs has been updated to use) about supporting both stable and nightly WASM targets with what I hope are reasonable guarantees in both cases (although one stable solution would only presently work in browsers via the JS bridge):

iqlusioninc/crates#141

I'd prefer to continue discussion there, so I'll close this issue for now.