9 ms·
Show HN: Retriever – Securely share secrets over the internet
Retriever (https://retriever.corgea.io/ https://retriever.corgea.io/), 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.
Read more on why we built it here: https://retriever.corgea.io/why.html https://retriever.corgea.io/why.html
- brianoconnor 3y agoLove it. Always wanted to have exactly this for password sharing. Simple yet secure.
- asadeddin 3y agoThank you! Glad that you love it, and hope you'll use it :)
- khaledboqaileh 3y ago[dead]
- _el1s7 3y agoNothing new here. Sites like privnote.com have been around much longer. PGP, end-to-end encryption is everywhere now.
- tholdem 3y agoI don't see how privnote.com is the same as this. Privnote seems to use a database and the links themselves should be treated as secrets as anyone with the link can read the note.
- asadeddin 3y agoThe end result of sharing the secret is the same. We didn't reinvent secret sharing. What's unique here is there's no server keeping record of a secret, a link or the parties involved. It's the truest form of zero-knowledge because the data doesn't exist in Retriever. With Privnote if you have the link to the secret, then you have the secret. With Retriever, only the requester has it.
- lcnPylGDnU4H9OF 3y ago> 2) They add their secret and share the URL Retriever generates. How do you prevent the URL from becoming something which needs to be kept secret?
- asadeddin 3y agoThe private keys are in the requester's browser. So if anyone gets a hold of the URL, they'll see nothing. For example, here's a secret I just put into Retriever. Are you able to see it? https://retriever.corgea.io/#eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlIjoiQVFBQiIsImV4dCI6dHJ1ZSwia2V5X29wcyI6WyJlbmNyeXB0Il0sImt0eSI6IlJTQSIsIm4iOiJ5cGdBRzU1R3B1RE5pcDZEN2otdUUxNUZtbDNSc0t0YnhoVHZqUFh4a1phYVRDbGpZUnVGaWFpTlVfMlBpaXFEcUxsVnNoUklyelp1LVlSemNDWkxGQ2FrdURfdTBaMVJKMmdzVmo0YVJFMUtlbWNxRUxELURPeGREVTk2bHB5TTVxcUU2SEstdEpZN1J1UnBUWG4xdllZTmF6dFcyb2RVVEpiZlBTSVNCVk56MHpDZWdUU2NKdWZIeHBnRGs2WUxfdUdiS3BxTnVXU1N2bHh5SkhsVVlaa3B2dmM1aDkwUjhTbzczMm14VENQMnJ1TWVDazhCc1p1UmhlQjhBVjJKd0NSME8tRGM4Vm1JNVpPcEZEakVDQWZVQXV4LUE4aDhMN0Jua2g0eDJTUnl0SEl3VUl5eHIzeXdZOHczclFUMWRIaVZYY1lMMWxrSTRjZHNYQmxJancifQ==;aANiHWmKlL6iAorKwMzIuj6iCLvLguG7shOzE5rx012XQhy8IZU2k1ctmQCey6ih/0DNWjnop7qr428agy63ixTMvwKvPgoeuDJA28vfBBF04CqJl7jFCc1fFum38mN1Jt8A4dQkfa2w1F6y91JviTTRhMQKtpSHwO1HOlWQ/boq+gnXoj38jVh3rzdPaR4I/tdxjzmMqV65mbR2VPBfut1BbhZvq+gqfQRHzh7HGIhS2Ei9Ea/9LKfaLBe0i40ebDTJ7V/30/fv8KMqenMdcj89KGDqoHVOoS/GW1vQi7Up0l9NRe/lFnuqhdj+SlT1rt4bBIa4KNFs83Y0zAl0MA== https://retriever.corgea.io/#eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJ...
- e12e 3y agoThis is essentially client side TLS, which browsers cut because the ux was bad? Only now you can backdoor/mitm/typosquat a website, rather than attack the major browsers or the os? And as I understand it, there's no way to verify you're talking to the right person, so sharing a secret via signal is strictly better?
- andrewaylett 3y agoShare the URLs via Signal, then you have a validated identity, and the secret won't pop up in your notifications or be retained in your chat history.
- Semitangent 3y agoLooks really interesting and I love the name! So, to deploy it in my (trusted) infrastructure, all I need is to clone it and put it on my server? I'll discuss it with my team
- asadeddin 3y agoThanks! Yea, that's all you need to do really. It's pretty simple to get it up and running :)
- bvrmn 3y agoIt seems key-pair is generated only once. Could be great to get fresh for every request.
- asadeddin 3y agoTotally! Someone was kind enough to issue a PR to allow you to delete the private key and generate a new one. We're going to fold those changes in.
- deoxykev 3y agoA default key expiry of 3 days would be helpful here too, as it would mitigate the threat of someone compromising the endpoint and extracting secrets from browser history.
- prophesi 3y agoCould also see an implementation where you generate a keypair per secret that saves a hashid (or just an incrementing integer) that you add to the URL fragment. The original sender's browser can then retrieve the private key in localstorage by that hashid. Now secrets can be kept or deleted individually, or given separate expirations. The only issue is that you can't magically remove the encrypted data in the URL you sent over, so it's really just removing your _own_ access to the data.
- rakoo 3y agoI don't get it: if you have a canal of communication anyway, why not send the secret directly ? We have many options for E2E encrypted communications, some of which are perfect replacements for whatever you use that isn't. I don't see the need for this.
- asadeddin 3y agoYou can definitely do that. This is just a different mechanism to do so. Your statement could be applied on any secret sharing system that 1password, Bitwarden, Lastpass have. They have a place in the world, and I'm not sure everyone is comfortable with E2E encrypted comms as a way to share secrets. The whole idea around this was an open-source research project that people can use day-to-day or enhance to share secrets with a zero-knowledge system. What makes this unique is that it's minimal work to do this with a big level of security that you can run on your own.
- SamBam 3y agoNo, I think the question is: if you're passing the URLs via email, WhatsApp, or anything else, then if that system is compromised then you've revealed the secret. If you trust that system not to be compromised, then you may as well have just sent the secret plain-text. In what way or in what scenario does this ever grant you MORE secrecy?
- Twisell 3y agoAs per the documentation the secret is never shared unencrypted an the private key to decypher it is never ever in the url. It stay in the receiver local storage.
- rakoo 3y agoThis only means the browser, and the javascript code, are part of the chain. Both of them can also be compromised, have bugs, and leak the secret.
- 3y ago
- taffit 3y agoI'm loving it! So simple, yet exactly the thing needed to share a secret quickly in a secure manner over a non-secure channel, e. g. email. Still a fresh idea I've never seen elsewhere. Congrats and thank you for providing this!
- sherifnada 3y agoGreat tool. Secret sharing always felt needlessly complicated and clunky. I love that this lets you securely share secrets with zero barriers to entry in seconds. No need for "what's your email" or "hey make sure you accept the share on lastpass" or any of that. Just a quick one-two secure envelope exchange.
- bnpxft 3y agogreat, my browser history is going to be full of secrets now
- asadeddin 3y agoYour browser history will be full of URLs that only your browser can access. A contributor was kind enough to build a delete function for this to wipe the private key and generate a new one. This would render all those URL's useless. We'll be merging that soon.
- muchosandwich 3y agoSort of. Malicious browser extensions could look at history and look at local storage before the key is deleted.
- 8organicbits 3y agoA malicious browser extension can steal all sorts of secrets. Is there a unique weakness here in the linked tool? Otherwise, this seems similarly vulnerable to everything else on the web.
- forty 3y agoDoing cryptography in a webapp and saying the server doesn't know the secret doesn't work, as the crypto code comes from the server without any way for the user to check whether it has been tempered with our not.
- asadeddin 3y agoThe crypto in this case doesn't come from the server. Nothing goes to the server for encryption. It's actually the browser that's generating the key pair and encrypting and decrypting. This is what makes all of this unique. See: https://github.com/Corgea/retriever/blob/main/js/crypto.js https://github.com/Corgea/retriever/blob/main/js/crypto.js
- paulgb 3y agoRight, but how do we know that https://retriever.corgea.io https://retriever.corgea.io faithfully returns the code in that GitHub repo? We still have to trust corgea.io.
- asadeddin 3y agoTotally valid concern! Retriever.corgea.io is actually hosted on Github pages (do a CNAME check to see). https://mxtoolbox.com/SuperTool.aspx?action=cname%3aretriever.corgea.io&run=toolpage https://mxtoolbox.com/SuperTool.aspx?action=cname%3aretrieve... You can see the canonical name is corgea.github.io which is the domain for GitHub pages. But, to counter my own argument, does this really prove that this domain is actually pointing to the OSS repo? No, other than we're not here to lie to anyone, I'm happy to show that updates made to the OSS repo show up on Retriever. Otherwise, you can totally run Retriever on your machine and have peace of mind :)
- tptacek 3y agoRight, so you might as well just skip the public key cryptography, which isn't doing anything in your design. Instead, just rely on TLS, and give each piece of content a UUID. Then you can just promise not to read it, the same way you're promising not to steal keys.
- MattPalmer1086 3y agoInteresting. I guess the only weakness I can see is that there is no way to know that a request genuinely comes from the person you think is requesting it. On the one hand, that is down to how you send and receive the URLs. On the other hand, it doesn't make it clear that you should pay attention to that and that it provides no identity authentication.
- muchosandwich 3y agoThat's a great point. Definitely a human factors improvement that should be implemented.
- asadeddin 3y agoThat's a really interesting perspective. I thought of the anonymity piece as a feature more so than a limitation. For example, you want to share something between two people, but want to "burn after reading". This way no one can associate the message to the two users or get access to the contents. The requester can always clear their local storage of the key. For example, it would be really useful when sharing information between a whistleblower and a journalist. Identity comes from the medium you share really in this case.
- MattPalmer1086 3y agoAlso an interesting perspective. I didn't think of the lack of built in identity authentication as a feature. I guess my only point is that it should be clear that's how it works so people can take appropriate precautions in either case.
- prophesi 3y agoThis is great! Would it be possible for it to be entirely serverless by letting the repo generate a static HTML page with no CDN's that you could send to others? It would add a bit of friction to the process, but each party could append the hash to the URL after they open the file.
- deoxykev 3y agoThat’s a great idea, I think something like this would work very well as a installable PWA even.
- asadeddin 3y agoThat's pretty much what Retriever.corgea.io is doing right now actually. It's hosted on GitHub pages, and serving a static HTML page. There's no other code running it. I'm not sure if they're using a CDN tho!
- za_creature 3y agoSame idea, as a shareable static html page. It never made it to the front page though: https://news.ycombinator.com/item?id=38365892 https://news.ycombinator.com/item?id=38365892
- tptacek 3y agoPeople keep reinventing Magic Wormhole, and nobody has really done it better; most of them don't even reach parity. https://github.com/magic-wormhole/magic-wormhole https://github.com/magic-wormhole/magic-wormhole
- chasingtheflow 3y agoBut you have to have it installed. I could see this solution being useful for dealing with non-technical users.
- meejah 3y agoThere is a Web client at https://winden.app https://winden.app (although it uses different servers than the defaults in the Python CLI, the latter can be easily configured to use the same servers). However, see further discussion in this article about the difficulties of Web / JavaScript security in this context (i.e. you're depending on the people operating the Web server to not serve different JS on each and every visit).
- emptysongglass 3y agoHaven't found anything better than croc, personally. https://github.com/schollz/croc https://github.com/schollz/croc
- city41 3y agoMinor nit: retriever is misspelled > Retreiver lets you request secrets from anyone without any of the data going to a server.
- asadeddin 3y agoThanks for sharing that! We got a couple of PR's from very kind folks to fix that. We'll merge them soon.
- rerdavies 3y agoWhy bother encrypting the fragment of the URL at all? Anyone who has the text of the URL gets the message, whether the fragment is encrypted or not. Encryption is just obfuscation. An even better way to do this would be to use a data: URL instead. That avoids risks associated with a compromised web server. data:,Put your secret message here. Even better still: just put the message in plain text on a piece of paper. That avoids risks associated with a compromised browser. Am I missing something?
- prophesi 3y ago> Encryption is just obfuscation. This is what you're missing. Obfuscation is not encryption, and anyone with access to the encrypted data in the URL would not be able to crack it in a reasonable amount of time unless they know something we don't know about public key encryption and SubtleCrypto's implementation of it. edit: and the problem it's trying to solve are to reach people that you can't just hand a slip of paper of what you want to tell them.
- rerdavies 3y agoIn this case, you crack the encryption by cutting and pasting the URL into your browser's address bar. Navigate to the link, and you get the decrypted message. It is encryption as theatre. Non-functional encryption. Encryption that hides nothing.
- prophesi 3y agoNo, only if your browser has the right private key. Let's say User A goes to the Corgea site. Their browser generates an RSA keypair, and appends the _public key_ to the URL, which is supposed to be visible. When User B accesses that URL, User B's device generates an RSA keypair, and encrypts their message using User A's public key and User B's private key. User B's generated URL will now contain User B's public key and the aforementioned encrypted message. User A decrypts using User B's public key and User A's private key. tl;dr: Each browser client generates a keypair, and their private key is never exposed. You only ever encrypt/decrypt with _your_ private key, and someone else's public key.
- 38 3y agothis is bad, really bad. the sender themself cant even read the returned message from a private window. its just another webapp that invades and disrespects privacy.
- SamBam 3y agoI'm confused. How do you send the request URL, and how do you receive the encrypted secret? If the answer is "email, chat, text, Whatsapp" or whatever, them why not just send the secret plaintext? If anyone can get into any of those systems, then they can easily get your secret from the two urls, so why bother with the encryption?
- nielsole 3y agoIf I glean from the landing page correctly, there will be a private key somewhere in the browser e.g. localstorage. This way the sender can encrypt the secret with the public key of the receiver. Mitm attacks are certainly possible, but eavesdropping is not.
- asadeddin 3y agoYou're correct. While a Mitm is possible, it'll be useless because the actor will have to get access to the private key from the requester'ss browser. They would have to be on the requester's machine
- asadeddin 3y agoYou can send the URL in whatever medium is convenient. However, if someone gets a hold of the URL with the secret, they will not be able to see the secret. For example, here's a URL containing the secret. Can you see the secret? https://retriever.corgea.io/#eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlIjoiQVFBQiIsImV4dCI6dHJ1ZSwia2V5X29wcyI6WyJlbmNyeXB0Il0sImt0eSI6IlJTQSIsIm4iOiJ5cGdBRzU1R3B1RE5pcDZEN2otdUUxNUZtbDNSc0t0YnhoVHZqUFh4a1phYVRDbGpZUnVGaWFpTlVfMlBpaXFEcUxsVnNoUklyelp1LVlSemNDWkxGQ2FrdURfdTBaMVJKMmdzVmo0YVJFMUtlbWNxRUxELURPeGREVTk2bHB5TTVxcUU2SEstdEpZN1J1UnBUWG4xdllZTmF6dFcyb2RVVEpiZlBTSVNCVk56MHpDZWdUU2NKdWZIeHBnRGs2WUxfdUdiS3BxTnVXU1N2bHh5SkhsVVlaa3B2dmM1aDkwUjhTbzczMm14VENQMnJ1TWVDazhCc1p1UmhlQjhBVjJKd0NSME8tRGM4Vm1JNVpPcEZEakVDQWZVQXV4LUE4aDhMN0Jua2g0eDJTUnl0SEl3VUl5eHIzeXdZOHczclFUMWRIaVZYY1lMMWxrSTRjZHNYQmxJancifQ==;kcrl00c7C51XiK024WgIwYShS5P8BFGx6yloQWYxGWeK+AGKMFuF/J2zkEYJSZU3XLB7xfK20au7yYghfZyAZ1kKBDcmUwVgUoGPmVmS7N9D1zL7H8AeSbMKpPhkitizKl0NYqdtB+8KBp5mplWQMFG6CZahUW0xeKQpb7tMlfNPqSdfWUYiNY0S9GD7lo/XgGYXzsXu0QHrNkDk0rhAhYaBlWH83VtHZ1cJVzY54r6tDBpxzW/gyw+s8OvjWNjMc2Vh9VNJDof7tk7wzEP3wR9oIbrpHBpsnChja6Ngj9OJa6CWqAc/LS0aqe4LWMLLbRU3XvokwNiFdijvqSIvGA== https://retriever.corgea.io/#eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJ...
- hashmush 3y agoWe use self-hosted yopass at work. Works great and since the link only works once you can simply send the URL with the decryption key to the receiver. If they can open it, the secret is safe to use! https://yopass.se/ https://yopass.se/
- semi-extrinsic 3y ago> since the link only works once Unfortunately this is an anti-feature for almost all large corporations. There is inevitably a security scanner somewhere that consumes the link before the user can.
- damentz 3y agoYou're right, but yopass let's you send the link and decryption key separately. The link is only destroyed if the secret is decrypted, not if you just reach the prompt to supply the key.
- semi-extrinsic 3y agoThat is definitely a redeeming feature!
- tmoehle 3y agoGenerally a good idea, but it’s implementation is not fully thought through. It’s supposed to be a secure place where secrets are shared, but it comes with Remote Code Executions that are out of the users control. Multiple JavaScript files are loaded from third party hosts to display the page, that would offer a significant attack vectors to your users secrets. You should both reduce the code dependency on large, external frameworks, as well as verify the necessary files and deliver them from the same host, that already serves the rest of the page (because you‘re going to have to trust that host anyway).
- jotaen 3y agoTo be fair, except for vue.global.min.js, all the JS files which OP pulls from third-party hosts are integrity-checked. So unless clients use very outdated browsers that don’t support the `integrity` attribute, the respective third parties wouldn’t be able to start inserting malicious code in the future. That being said, I agree it’s still a cheap security improvement for OP to control the hosting themselves. (Plus to integrity-check the Vue dependency.)
- psd1 3y agoHmm. If we pretend that there are no vulnerabilities today, then the mind turns to what will change in the future. I tolerate js in the Bitwarden extension because it's necessary, funded, supported and necessary. But Retriever sounds to me like a project that would do better to minimise surface area.
- dncornholio 3y agoI will not use this. It loads too many third party domains. It has a tracker. Something like this should not be this leaky IMHO.
- glitchc 3y agoWould like to give a shout out to LANDrop (not affiliated) if the users are on the local network. I use it. It's very good at saturating the link bandwidth and traffic is guaranteed not to exit the firewall. https://github.com/LANDrop/LANDrop https://github.com/LANDrop/LANDrop
- g4zj 3y agoI generally just use GPG. 1. I share my public key (if not done previously). 2. They encrypt the secret and send the result back, all using whichever tools they'd like. 3. Only I (and any additional recipients specified during encryption) can view the secret data.
- asadeddin 3y agoThat's definitely a good way to do it, and if it works for you then awesome! We're kind of doing something similar here with this in a workflow where you don't have to share the key and it requires not technical knowledge of doing this. I actually did this with my dad over mobile phones and he doesn't know how to use public-private key encryption.
- g4zj 3y agoI'd argue that using GPG as the sharer of a secret has nearly the same level of complexity when using something like pgptool.org, assuming there is no need to _sign_ the data as well.
- kreetx 3y agoHow to I know this isn't a honeypot? To build something like this, I'd build it against something people already trust. Since here everything is new, it's difficult to want to paste anything into it.
- asadeddin 3y agoI totally understand that concern, and I'm pretty security conscious too my self. A few things, you can check the console and network logs while you're interacting with the application. You'll see we Retriever doesn't send anything to a server. If that's not convincing, you can also run your own instance of it and see it doesn't send anything.
- alxgsv 3y agoShameless plug: https://bobtoalice.com https://bobtoalice.com is a one-file html program to do the same. It can handle files, too.
- meejah 3y ago"Without needing a server" but both parties have to visit a Web ... server ... to do the exchange. So there _is_ in fact "a server in the middle".