retriever.corgea.io
Read more on why we built it here: https://retriever.corgea.io/why.html
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).
I only took a glance at their "why we built this" page, but it seems sound to me. Also, it seems to serve a different purpose to wormhole.
Wormhole allows you to easily ans securely transfer files between two machines, if I understand correctly.
This is a convenient way to generate a public / private key pair and share your public key with someone encoded in a URL. In turn they can conveniently encrypt a short message using your public key which is also encoded in a URL for sending back over an insecure channel.
Being in the browser and having to trust it is not sending anything online, is not ideal. But on paper the concept seems pretty sound to me. I think it's a cool idea and can imagine it could come in useful.
This seems contradictory. If the main thing that's useful is that it uses URLs/browsers, but using URLs/browsers breaks the security of the system, what part of it seems pretty sound?
If your browser is compromised or can't be trusted then you have bigger problems.
But if we assume this site can be trusted not to send secrets online (which is easy to verify) and they are not rolling their own crypto primitives in javascript, then the idea is pretty sound imo.
Personally I would use gpg or openssl for this, but it's not that easy for non-technical users.
This would require every sender and recipient to read and understand the JavaScript on every page load, because there’s no guarantee that the server is sending every request the same content. It is in fact not easy, especially for non technical users.
If we’re just assuming the site is trustworthy, the public key crypto isn’t necessary. If the site isn’t trustworthy, the public key crypto isn’t secure, because the site is in a position to compromise the private keys.
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.
See: https://github.com/Corgea/retriever/blob/main/js/crypto.js
Retriever.corgea.io is actually hosted on Github pages (do a CNAME check to see).
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 :)
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.
But I think the cryptography is not entirely performative, and your suggestion of a UUID KVS is not the same model.
In Retriever's model, as I understand it, Alice generates the keypair which Bob will use to send data to Alice. Alice sends the pubkey to Bob (via URL) and Bob encrypts and submits. Bob then sends a new URL to Alice to decrypt and read. (Not sure why this second URL exchange is necessary, unless it contains the encrypted data?).
Only the original receiver (and Retriever/page host) can decrypt the data. Neither of the URLs are secrets, although possession of the first URL would allow an attacker to encrypt arbitrary messages for Bob, and maybe that's why Bob waits for Alice to send the second URL.
That said, it's a fun experiment but too awkward for anything but ad hoc secret sharing between strangers with no better comms channels. Which is not something I do.
Agreed, not practical but a bit more involved (both simpler and more complicated) than a UUID KVS.
A sound foundation for managing my secrets
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.
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.
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?
> and I'm not sure everyone is comfortable with E2E encrypted comms as a way to share secrets.
I'd live to know what would make people uncomfortable with this, because your system is, in practice, exactly that :)
> 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.
I love that this can be used over any channel, secure or not, but I would prefer if we all just switched to proper secure communications everywhere. In 2024 there is no good reason not to anymore.
And if I take your point and consider self hosting this, then it's much easier and better to install proper secure communication with my peers.
Again, I'm not against the idea of allowing secure exchange of secrets in an insecure environment, but as engineers if we really want to solve problems we should look at the real one: why are communications not secure, and how to fix this. This is not a technical problem, it's a societal one, and the solution might be societal. Unfortunately as engineers we tend to suck on the social level so we don't want to see it, but it's height time we take the plunge.
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.
A tool like Bitwarden Send lets me share a link that references a secret, limit the number of times it may be accessed, and validate out of band (using the secure channel you mention) that the single access I saw was indeed the intended recipient. I can -- and do -- confirm receipt and clear the shared value before putting the secret into whatever system it's intended for.
This seems to have similar properties. I still want an E2E channel for passing the links around, but once the exchange has been verified there's no permanent record of the actual value being exchanged in our chat history.
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?
https://retriever.corgea.io/#eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJ...
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).
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.)
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.
How do you prevent the URL from becoming something which needs to be kept secret?
For example, here's a secret I just put into Retriever. Are you able to see it? https://retriever.corgea.io/#eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJ...
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?
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.
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.
Am I missing something?
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.
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.
Now if you intercept and replace the URL, they may be in trouble.
[0] https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
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.
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.
> Retreiver lets you request secrets from anyone without any of the data going to a server.
the sender themself cant even read the returned message from a private window. its just another webapp that invades and disrespects privacy.