The story
A few months ago my team and I were on a customer call, and we needed to get some secrets from them. We went through the typical process where they shared their secret through their password manager. The process took 15 minutes, and it felt heavy. Adam from our team realized that he hadn’t seen a way to request secrets from someone. Most people send passwords, but what if you could ask for one? What if it could also be done without a server in the middle? Shouldn’t secret sharing really be secret? Also, what if it was a light and easy experience?
The experiment
This is why we developed Retriever, an open-source research project to help users receive secrets and sensitive information without needing a server in the middle. It works by using Public-key cryptography to coordinate the message sharing between the two devices. The requesting user visits https://retriever.corgea.io/, which generates a URL with the public key, and a private key is then stored in the browser. The URL can be shared with anyone so that they can enter their secret. When a secret is filled in, it’s encrypted with the public key, and the user can send the final link back to the requester. Using the private key, the requester can see the secret on their machine.
Here’s a diagram that shows the flow:
What makes this better and unique?
Interestingly, most services like LastPass, 1Password, and others don't offer a way to request a secret from someone. In most cases, sharing secrets requires the initiator to have a password manager. Retriever addresses the scenario where a user wants to share confidential information but lacks a secure method, or when the parties use different secret management systems.
One of the most significant challenges with many solutions is the exposure of URLs. If someone gets hold of a secret URL, they could essentially have access to the secret it contains. This new system acknowledges this flaw and encrypts the secret within the URL. Only the intended recipient, with the decryption key, can access the secret, ensuring an added layer of security. Anyone who wants to get access to the secret in the second link needs to get the private key from the browser and the link itself.
Traditional methods of sharing secrets often involve a third-party server that orchestrates the transfer. While this might seem convenient, it poses a significant risk. Users have to trust that the third party will delete their data after the transfer. This new system ensures that data is transferred directly between the sender and receiver, reducing potential points of failure. Retriever does not store or log any secrets or data about the parties involved in the sharing process. See the open source project for more details: https://github.com/Corgea/retriever. We’ve also gotten asked, why not use WebRTC? Yes, this can be achieved with WebRTC, but you still need a signaling server to make this work.
Another big issue with most open-source projects is just because a project is open source doesn't mean it's hosted openly. This new system ensures that while the codebase is open for everyone to see and contribute to, the hosting remains open. Retriever.corgea.io is actually hosted on Github pages (do a CNAME check to see).
Finally, the system's backbone lies in its use of standard web cryptography. By leveraging these standards, the system ensures that the encryption and decryption processes are not only secure but also fast and efficient.
Who are we? 
We are the team behind Corgea. A passionate bunch of engineers, designers, and product builders that like to tackle the most urgent and stimulating problems in security. In our prior roles, we designed, secured and built software products for the likes of Coupa, Autodesk, and PlanGrid.
A big thank you to Adam Bronte for authoring Retriever and Tamara for putting the finishing touches on usability and design.