I understand that including a secret/password into WASM is a bad idea since a binary can be decrypted but is there a concept/trick of safely generating salts for creating a secret within the WASM that can't be read by the host and thus exist only for the time of a single WASM execution?
CodePudding user response:
No. This is just the impossible DRM problem again.
Let's walk this through:
- You write wasm that does some task, it needs to run on my computer. I built my computer from the ground up designing the silicon chips myself so that they record what the computer does. I have a record of your "one-time" secret. But that was expensive for me, custom silicon chips aren't cheap.
- You write wasm that does some task, it needs to run on my web browser. I compiled my own browser from chromium source with a patch to make a copy of any wasm to disk, including any inputs and outputs of that wasm. I know what your wasm did and can reproduce it.
- You write wasm that does some task, and your plan is to ask third-party websites to include your wasm. You aren't trying to hide it from the user/CPU/browser, you're only trying to hide the secret from the web page that loads your wasm. On top of that, every time the wasm is loaded from your server, the embedded secret is different. My web page, instead of loading your wasm normally, implements its own wasm interpreter in javascript and does whatever your wasm does, seeing its secret data and recording its actions as it goes.
You can of course, as with all DRM systems, try to concoct any complicated scheme to make these recordings hard for a human to figure out, but ultimately you are trying to give the both give someone information (that secret or salt) while simultaneously denying them that same information. You can raise the "cost" in terms of time or human difficulty to break.
Now, just to be complete, there is a not-yet-practical approach based on fully homomorphic encryption where you can produce a program that someone else can run where they can't understand what the program has done (it's "computationally indistinguishable"), but current implementations require near-gigabyte sized keys and turn milliseconds of computing into minutes or hours, and secondly this has nothing to do with Wasm, if you could do it with Wasm you could do the same with python code or an x86-64 executable. The current best approach that I know of is https://tfhe.github.io/tfhe/ .