💾 Archived View for bbs.geminispace.org › s › Gemini › 12756 captured on 2023-12-28 at 16:00:22. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
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.
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 thinks about it.
The gemini protocol and its restriction forces us to go back to a philosophy similar to Linux / Unix. Do only one thing and do it well. This philosophy already lead to the creation of the addon protocol titan:// for larger upload and spartan:// for a more stripped down version of Gemini. We think we are missing something: client side encryption.
The easiest and most dismissive answer would be to simply use an external tool like PGP, similar to how we can use FTP and HTTP to update and create content for Gemini. Sadly in many case this uncesseraly increase complexity. Similar to how HTML makes creating a simple webpage an impossible task, most encryption software do not offer a gemini experience. They are complex and prone to multiple potentially critical error from users.
To keep things simple we only need to cover a handfull of scenarios
A gmi document can contain encrypted data that must be decrypted by the client / gemini browser. The encrypted data is line based (similar to how gemini handles it). They are wrapped inside dragonlady:// links. The data is encoded in base64. To avoid distraction and unnecessary clutter the following human readable string must be specified: [Dragonlady Encrypted Data]. A client not supporting the protocol will safely display the line without disrupting the user view:
Decrypting the data requires the client to have a local certificate and a private key and to be authenticated to the server.
Once authenticated, the local client will extract from the dragonlady url they key fingerprint to check if they can decrypt the data. Based on this the following results are possible:
When the data can be decrypted, it should be displayed in a specific style to indicate it is encrypted and secure data.
In gemini fashion, this is left to the client. It should be done in a very specific way that cannot be faked by a capsule (to avoid confusing an user). The lines themselves should be considered as valid individual gem lines. They can contain headers, quotes, etc.
We need to be able to send encrypted input to a server. Similarly we use the dragonlady protocol, with the data in the base64 being the gemini url to send the data to.
Will be decoded to the URL to send to. The browser will open the input dialogue with a specific theme (again indicating its a secure and encrypted input) to get the data from the user, encrypt it and send it along with the key fingerprint to the gemini server.
To keep things simple we derive the symmetrical encryption key from the private key used to identify the user. This avoid adding unnecessary complexity to gemini clients. No need to backup yet another file. The keys can easily be recreated when an user restore their identity. Users can be tracked by the key fingerprint but this is a minor inconvenience, since its already possible to do it with certificate. New identities can easily be created if this is a concern.
[dragonlady://] | [in/out] | [sym/asym] | [4544cf] | [ZctqsFy8U7dIl/k4ovX6pw==] 1 2 3 4 5
The data itself is encrypted using AES256. There is no version specified in the protocol to avoid any downgrade attack. We believe if an upgrade is required, its better to simply create a new protocol. We think once agreed, the protocol should be mostly left untouched.
. .-~\
/ `-'\.' `- :
| / `._
| | .-. {
\ | `-' `.
\ | /
~-.`. \| .-~_
.\-.\ .-~ \
`-'/~~ -.~ /
.-~/|`-._ /~~-.~ -- ~
/ | \ ~- . _\ ~~~ Dragonlady
Dec 18 · 11 days ago · 👍 Minko_Ikana
We think we are missing something: client side encryption.
Sorry if I missed it, but could you explain more about why we need this? Some concrete use cases, perhaps.
All Gemini requests are already encrypted thanks to TLS, and may even require a specific client certificate for additional security. Why add another layer of encryption?
Previously it has been discussed that (PGP) signatures could be used to validate page contents, but integrating that into clients does not seem worth the complexity.
I'd be surprised if this proposal were being made in good faith. All unmoderated Gemini discussion forums attract disproportionate levels of anti-Gemini agitation.
The sideswipes at HTML, Unix and Gemini's lack of an upload mechanism all suggest bad faith.
As has been observed, the substance of the proposal is largely otiose due to the availability of client certificates. I'd note that Gemini servers can choose to trust client certs on the basis of the cert *issuer* rather than *subject*, affording a sort of "trusted group" that can access a subset of documents.
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.
@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.