[HN Gopher] Show HN: Retriever - Securely share secrets over the...
___________________________________________________________________
Show HN: Retriever - Securely share secrets over the internet
Retriever (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
Author : asadeddin
Score : 124 points
Date : 2024-01-23 16:26 UTC (1 days ago)
(HTM) web link (retriever.corgea.io)
(TXT) w3m dump (retriever.corgea.io)
| brianoconnor wrote:
| Love it. Always wanted to have exactly this for password sharing.
| Simple yet secure.
| asadeddin wrote:
| Thank you! Glad that you love it, and hope you'll use it :)
| illegally wrote:
| Nothing new here. Sites like privnote.com have been around much
| longer. PGP, end-to-end encryption is everywhere now.
| tholdem wrote:
| I 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 wrote:
| The 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 wrote:
| > 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 wrote:
| The 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/#eyJhbGciOi
| JSU0EtT0FFUC0yNTYiLCJ...
| Semitangent wrote:
| Looks 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 wrote:
| Thanks! Yea, that's all you need to do really. It's pretty
| simple to get it up and running :)
| bvrmn wrote:
| It seems key-pair is generated only once. Could be great to get
| fresh for every request.
| asadeddin wrote:
| Totally! 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 wrote:
| A 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.
| rakoo wrote:
| I 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 wrote:
| You 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 wrote:
| No, 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?
| doublerabbit wrote:
| People claim E2E yet unless the code is actually open source
| your believing in faith.
|
| Call me cynical, paranoid but I do not believe the E2E with
| WhatsApp truly is. It claims to be, yet now owned by the
| biggest data mining company in existence. How can I trust that?
|
| And don't give me any "three ticks" bullshit. Show me source.
| 0xdeadbeefbabe wrote:
| The source for bash was open for years (maybe even 40) before
| shellshock.
| minitech wrote:
| Remember: no matter how big the improvement, it's not
| worthwhile unless it achieves absolute perfection.
| Luctct wrote:
| I suppose generic communication channels have a lot of noise
| for Big Brother monitors. When someone exchanges Retriever
| links though, monitors will know that some "secret" is being
| shared and can focus on potential targets more easily, with a
| noise filter.
| taffit wrote:
| I'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 wrote:
| Great 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 wrote:
| great, my browser history is going to be full of secrets now
| asadeddin wrote:
| Your 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.
| forty wrote:
| Doing 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 wrote:
| The 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
| paulgb wrote:
| Right, but how do we know that https://retriever.corgea.io
| faithfully returns the code in that GitHub repo? We still
| have to trust corgea.io.
| asadeddin wrote:
| Totally valid concern!
|
| Retriever.corgea.io is actually hosted on Github pages (do
| a CNAME check to see).
|
| https://mxtoolbox.com/SuperTool.aspx?action=cname%3aretriev
| e...
|
| 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 wrote:
| Right, 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.
| jackson1442 wrote:
| You can look at the code in your browser's debugger. It's
| not minified, and is actually quite simple. You can also
| watch the network inspector to see that it's not sending
| data back to the server.
| tptacek wrote:
| Performing a cryptographic penetration test every time
| you (or, behind your back, your browser) loads a page is
| a problematic strategy for deploying cryptography on the
| Internet.
|
| I think the previous comment came across as snark, but
| it's not snarking; it's a genuine suggestion. The thing
| they're trying to build can work, and find users, without
| the performative cryptography.
| MattPalmer1086 wrote:
| Interesting. 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.
| prophesi wrote:
| This 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 wrote:
| That's a great idea, I think something like this would work
| very well as a installable PWA even.
| asadeddin wrote:
| That'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!
| tptacek wrote:
| People 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
| city41 wrote:
| Minor nit: retriever is misspelled
|
| > Retreiver lets you request secrets from anyone without any of
| the data going to a server.
| asadeddin wrote:
| Thanks for sharing that! We got a couple of PR's from very kind
| folks to fix that. We'll merge them soon.
___________________________________________________________________
(page generated 2024-01-24 23:01 UTC)