Considerations about doing the decryption server side

[agnosticlines]

Hey, big fan of Lumen. Just looking at the implementation for encryption seems the goal is to prevent unencrypted files from being on disk, but the encryption/decryption process is still done on the server. Just wondering if there's any thoughts/interest in other ways of doing this as a malicious server could log the unencrypted files or decryption keys.

This may not be an issue for you I'm just curious if there's interest in exploring other more secure options :-)

[ChecksumDev]

I'm also annoyed that the encryption is server side, but ShareX to my knowledge doesn't have a way to perform an encryption before sending it to the server, making end to end encryption impossible. I'm all ears for any ideas though.

[ChecksumDev]

I do believe the server side encryption is better than nothing but there really is nothing stopping this from happening, which is why it's good if you trust your host.

[agnosticlines]

ShareX has native support for Up1 and a few other encrypted uploaders, may be worth piggybacking off that or PR a custom encryption plugin to ShareX, they seem fairly receptive to that.

The bigger issue security wise imo is the decryption being done server side

[ChecksumDev]

Oh! I had no idea about that native capability, I would support doing this and see if that's a possibility. Maybe with a more rounded out framework, I'd consider sending a PR into ShareX. I don't necessarily believe Lumen is that rounded at the moment, and there are some implications I need to consider beforehand.

The bigger issue security wise imo is the decryption being done server side

Also, I was just waking up when reading this, I do believe it's ridiculously easy at the moment to turn a server malicious because of this. I was only saying that if you trust and or are self-hosting Lumen, it's alright.

A slight problem would be links that can embed for platforms like Element and Discord. It would have to be a separate operating mode, like what we have now with encrypted vs. unencrypted. Since the server would obviously not be able to embed the image since the decryption cannot be performed server side. It would likely be an option to enable E2E encryption vs. server-side encryption.

[agnosticlines]

Oh! I had no idea about that native capability, I would support doing this and see if that's a possibility. Maybe with a more rounded out framework, I'd consider sending a PR into ShareX. I don't necessarily believe Lumen is that rounded at the moment, and there are some implications I need to consider beforehand.

Makes sense! I still think there's value from working from the lumen base honestly, I don't want to discourage you or say it's all broken, it's not, just different considerations for different users, if you came up with a plan for supporting native end to end encryption I'd be happy to help implement it :)

The bigger issue security wise imo is the decryption being done server side

Also, I was just waking up when reading this, I do believe it's ridiculously easy at the moment to turn a server malicious because of this. I was only saying that if you trust and or are self-hosting Lumen, it's alright.

Yep makes sense

A slight problem would be links that can embed for platforms like Element and Discord. It would have to be a separate operating mode, like what we have now with encrypted vs. unencrypted. Since the server would obviously not be able to embed the image since the decryption cannot be performed server side. It would likely be an option to enable E2E encryption vs. server-side encryption.

Yeah, perhaps the user could choose if they wanted an embeddable image or encrypted image at upload time or something