4 ms·
I agree. This sort of thing would also be useful when performing client-side decryption of encrypted content. If it's not possible for the page to perform any
by jstanley 8y ago
I agree. This sort of thing would also be useful when performing client-side decryption of encrypted content.
If it's not possible for the page to perform any lasting global state modifications, you wouldn't have to trust that the server is not shipping malicious code to exfiltrate the key or plaintext. It wouldn't be able to do so.
- onion2k 8y agoWouldn't there need to be some sort of way to verify the client hasn't been modified in order to trust that? That's not really possible, because you'd be asking something to verify itself.
- jstanley 8y agoIf you configure your browser not to allow the client to leak anything, it doesn't even matter if the client has been modified because it can't leak anything anyway. EDIT: I'm speaking from the position of an end-user. I'm downloading ciphertext + a decryption tool from an untrusted server and executing the decryption tool locally, with a key which I input locally. I want to make sure that the plaintext and key do not get leaked back to the server. Situations where this arises include encrypted pastebins, bitaddress.org, Ian Coleman's BIP39 tool, anything else that generates or handles bitcoin keys, etc.
- Franciscouzo 8y agoI wouldn't trust such a set up for cryptography, the page could either use a bad RNG, or generate your private key by encrypting it with a public key for which they control the private one, so when you release your public key they are able to generate the private one.