3 ms·
I wonder if you could do the encryption entirely in the client so it was verifiably secure. Front end JavaScript generates a symmetric encryption key that is n
by ALittleLight 5y ago
I wonder if you could do the encryption entirely in the client so it was verifiably secure.
Front end JavaScript generates a symmetric encryption key that is never shared to the server. User enters message. Message is encrypted with the generated key. You create the scrt sending only the ciphertext to the server which doesn't have the key and so couldn't read the message. You click a button to copy both the link to the scrt and the encryption key. You then share both to your recipient. The recipient visits the link and gets the ciphertext and then copies and pastes in the key to see the message.
If it's all done frontend like this then it should be demonstrably secure and only slightly more complicated for the users.
- stophecom 5y agoIt is done entirely on the client. You can check the source code. Read more on scrt.link/security.
- ALittleLight 5y agoBut if the key is added to the link itself then you could be storing the encrypted string and decrypting it after getting a request for a link that contained the key. I'm not accusing you of that - just saying there is no way to prove that's not happening.
- stophecom 5y agoThe part of the URL holding the encryption key is not sent to the server. https://stackoverflow.com/questions/14462218/is-the-url-fragment-identifier-sent-to-the-server https://stackoverflow.com/questions/14462218/is-the-url-frag... Don't take my word for it :) You can check all code that runs in your browser and check all requests made within the network tab.
- ALittleLight 5y agoOkay, nice! I withdraw my comments.