💾 Archived View for bbs.geminispace.org › u › ran-ford › 12763 captured on 2024-03-21 at 21:15:33. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-02-05)
-=-=-=-=-=-=-
Re: "Dragonlady: Client Side encryption for Gemini"
yes everything between you and the server is encrypted however once it reach the server its decrypted and need the user to trust the server. For instance we can imagine a simple journaling app allowing people to create entry everyday to write whatever they want. Currently this highly private information would only be protected during transit but not on the server itself. This would require users to trust the server with their data. If encrypted before sending, the server would just store the encrypted data and do not need to be trusted.
2023-12-18 · 3 months ago
🚀 ran-ford [OP] · Dec 18 at 06:29:
@mk270 this proposal is made in hood faith and we couldn't care less about HTML which also doesn't provide client side encryption and would require a monstrous JavaScript to do it. Furthermore as said the current encryption is only done to our knowledge during transfer not during storage.
Thanks @ran-ford :)
I'm confused about that key handling: is it that I can only decrypt things I uploaded myself, or is there some way to share keys?
Right, so this is really a proposal for "at-rest" encryption, necessitated by using Gemini as a "store-and-forward" protocol rather than for peer-to-peer communication. Such a proposal really isn't advanced by sideswipes at HTML, Unix and Gemini, but let's leave that to one side.
The idea is that sensitive data would be stored at least for a while at intermediate hops between sender and receiver, where at least one of those hops is not trusted by the sender. Zero hops would be necessary were the sender to run his own server.
I would just abandon the idea of inlining the encrypted data, and provide a link to the cyphertext using a URL for an existing protocol (e.g., gemini:// or https://)
🚀 Minko_Ikana · Dec 18 at 11:24:
I understand, and it is actually something I noticed is missing compared to other protocols. Gemini does encrypt the package being sent, but not the data inside that package. This would make the data encrypted at the point of creation and pre-encrypted before putting in the certifiied shipping container. So the whole data environment from local creation to being stored remotely at the destination will all be encrypted completely aside from the shipping container it's self.
If I understand correctly this only allows to decrypt data that I have encrypted previously myself, since I'm the one who has the encryption key and this only covers symmetrical encryption. Or do I have to manually share the key with the recipient?
I just noticed that Morgan mentioned my same point in a previous comment. Ignore mine.
I think this is an interesting idea. What I'm confused about is where the spec for it would live in relation to the spec for Gemini itself. I wouldn't put it in the core transfer protocol, and it doesn't fit with the gemtext spec because it's not gemtext. Are you proposing Dragonlady as a new protocol to live alongside Gemini, like Titan does?
Interesting! Since I don't host my capsule myself, the question of the trustworthiness of a third-party server came up. I would like to see gemini offer the possibility to easily store encrypted data on a foreign server, the approach here sounds exciting.
Dragonlady: Client Side encryption for Gemini — V0.1 Following the tradition of using space themed name, we present "Dragonlady" protocol an addon to gemini to enable client side symmetrical encryption named after the infamous codename used for U2 space spy plane. TLDR This proposal would enable to have client side encryption to gemini with an addon. This is backward compatible with clients not supporting it. We are looking for feedback and we are curious to know what the gemini community...