How it Works:
+The first thing to understand is how public key cryptography works.
+Essentially, you generate a pair of keys that can undo the operations of each other. If you encrypt a message + with your public key, it can only be decrypted by your private key.
+
This is why you're safe to share your "Request URL" out in the open. Anyone who + accesses this URL will receive your public key, and encrypt the message with it along with their own private + key. When you receive the URL with their encrypted message, you take their public key and your private key to + undo the operations of their private key and your public key. +
+But of course it's not as simple as that
+Traditional public-key cryptography like RSA is limited in the messages it can encrypt by the size of the + public key. To overcome this limitation, we use ECDH for short public keys that can encrypt an arbitrary + amount of data by establishing a shared "symmetric" key for encryption/decryption, which is beyond the scope + of this explanation. But the following chart should give you a general idea of how the process works.
+
FAQ
-
-
- Each client generates an ECDH keypair, consisting of a public key and a private key. -
- Your private key is kept in localStorage, and never leaves your device. -
- Your public key is embedded in the URLs you generate. This key can be safely shared anywhere without - compromising security. -
- When another client opens your generated URL, they will find your public ECDH key. They then generate a - random IV for this specific message, and use it, along with their private ECDH key and your public ECDH key, - to derive a shared secret (AES-GCM). -
- This derived shared secret never leaves their device. It is used to encrypt their message to you. - The encrypted message, along with their public key and the IV for this message, are embedded in the URL they - generate. -
- Upon opening the response URL, your device uses your private ECDH key, along with the public key and IV - from the URL, to recreate the shared secret. This secret is used to decrypt the message. If the message was - properly encrypted using the expected keys, it will be successfully decrypted and displayed to you. -
- If you clear your browser's local storage, you will not be able to decrypt any response URLs generated - with your previous unique URL. +
-
+ What is this?
+
+ SURE is a system for securely sending information via a URL request. It uses the Elliptic Curve + Diffie-Hellman algorithm to generate a shared secret between the sender and recipient, which is then used + to encrypt the message in a response URL. The device that generated the URL request can then decrypt the + message in the URL sent back to them using their private key. +
+
+ -
+ What if I want all of my devices to be able to decrypt messages from the same request?
+
+ If you want to be able to decrypt messages from the same request on multiple devices, you'll need to + export the keypair from the device that generated the request, and then import it into the other + devices. You can do this by clicking the "Manage Keys" link at the bottom of the page, and then clicking + the "Export Keys" button. This will give you a JSON file that you can import on other devices via the + "Import Keys" button. +
+
+ -
+ What if I lose my keys?
+
+ If you lose your keys, either from clearing your localstorage or losing your device, you won't be able to + decrypt any messages sent to you. You'll need to send over the new request URL from your device to anyone + who wants to send you a message. +
+
+ -
+ Why was this built?
+
+ This was built as a proof of concept for a secure messaging system that doesn't require a user to sign up + for an account or download an app. It can even work entirely offline if you build the app from source and + open the HTML file in your browser. You can also manage your keys so that all of your devices can decrypt + messages from the same request URL. +