SUGGESTION - Encrypted Messages?
I have no clue if this is where I should post suggestions but it would be great to have end to end encryption with symposium, I was thinking of implementing something like this on my forum and had an idea with PGP but since I am planning on also implementing symposium when this new beta comes out I backed out on it considering I would have to make it compatible with this plugin too. So @Shade do you think this is something that will be built into symposium one day?
This is surely a valuable suggestion, and I did some research on the topic in the past as I wanted to implement it already even before planning to release the first beta.
I found myself in a slump regarding how to design the whole encryption thing though. Note that Symposium is a PHP/JS application, so it's really out of my current knowledge how to do it, also given some negative feedbacks found on the internet. Suggestions and/or guidance on the topic would be highly appreciated.
I found myself in a slump regarding how to design the whole encryption thing though. Note that Symposium is a PHP/JS application, so it's really out of my current knowledge how to do it, also given some negative feedbacks found on the internet. Suggestions and/or guidance on the topic would be highly appreciated.
My main objective for this is so nobody can view my user's messages even in the event of a database breach/leak.
And well, I wouldn't deem my way the best by any means but what I was thinking of was using the GnuPG extension on PHP (https://www.php.net/manual/en/book.gnupg.php) but you could go with something like libsodium (https://github.com/jedisct1/libsodium-php) but given my experience with GnuPG it was the easiest for me whereas libsodium would probably be the best option for this as it doesn't require downloading a PHP extension. My plan was to generate the private and public keys and store them on the server, storing the private key as a file encrypted with something like bcrypt or argon or maybe even AES with a password the user sets. So the user would enter the password he chose for his inbox and it would use this to decrypt this file and send the private key to PHP who would use this to decrypt all the messages in the user's inbox (We could also just send the user his PGP key so we don't store it but I doubt people want to be carrying these around and in the case they lose it then all messages are lost, so storing in server and encrypting is the best option for now and user only needs to remember a password). *We could maybe store the user's key in server cache/memory or his password in his browser's localstorage for a few minutes or until he logs out so he doesn't have to re-enter it to view every message*
When a user sends a message to another user mybb makes 2 copies because it's a great system lmao and this would allow the user to view his sent messages even though they are encrypted because otherwise he wouldn't be able to see these as they would be encrypted with the recipients public PGP key but we can encrypt the Sent box one with his own public key so its still safe and only he can see it.
For the exact method of storage for the keys I was thinking making a folder not accessible via web ofc with user's UID for example UID 439 would have 2 files 439.public 439.private which would save us mysql space and make it easier to detect if a user has this PGP option enabled. > I was going to make it mandatory, but you could also just make a php check which shows if a user has PGP enabled and show it off on their profiles/postbits if not mandatory.
Oh I just wanted to note, you could by default generate PGP keys for all the users and not have them input any passwords to access their inboxes the problem with this is that you would store their private keys in plaintext so if a hacker has access to the webserver's path he can decrypt the messages himself. You could use their already existing passwords to decrypt their inbox too but that would also require them to re-enter it to view the inbox unless you want to save stuff in memory for the whole session's length which is also a bad practice. I think the best way is to take a look at what other companies like Facebook and Telegram use for end to end encryption and it's quite similar I just have no clue how they store the keys but I feel like it's one of the ways I described or very similar.
And well, I wouldn't deem my way the best by any means but what I was thinking of was using the GnuPG extension on PHP (https://www.php.net/manual/en/book.gnupg.php) but you could go with something like libsodium (https://github.com/jedisct1/libsodium-php) but given my experience with GnuPG it was the easiest for me whereas libsodium would probably be the best option for this as it doesn't require downloading a PHP extension. My plan was to generate the private and public keys and store them on the server, storing the private key as a file encrypted with something like bcrypt or argon or maybe even AES with a password the user sets. So the user would enter the password he chose for his inbox and it would use this to decrypt this file and send the private key to PHP who would use this to decrypt all the messages in the user's inbox (We could also just send the user his PGP key so we don't store it but I doubt people want to be carrying these around and in the case they lose it then all messages are lost, so storing in server and encrypting is the best option for now and user only needs to remember a password). *We could maybe store the user's key in server cache/memory or his password in his browser's localstorage for a few minutes or until he logs out so he doesn't have to re-enter it to view every message*
When a user sends a message to another user mybb makes 2 copies because it's a great system lmao and this would allow the user to view his sent messages even though they are encrypted because otherwise he wouldn't be able to see these as they would be encrypted with the recipients public PGP key but we can encrypt the Sent box one with his own public key so its still safe and only he can see it.
For the exact method of storage for the keys I was thinking making a folder not accessible via web ofc with user's UID for example UID 439 would have 2 files 439.public 439.private which would save us mysql space and make it easier to detect if a user has this PGP option enabled. > I was going to make it mandatory, but you could also just make a php check which shows if a user has PGP enabled and show it off on their profiles/postbits if not mandatory.
Oh I just wanted to note, you could by default generate PGP keys for all the users and not have them input any passwords to access their inboxes the problem with this is that you would store their private keys in plaintext so if a hacker has access to the webserver's path he can decrypt the messages himself. You could use their already existing passwords to decrypt their inbox too but that would also require them to re-enter it to view the inbox unless you want to save stuff in memory for the whole session's length which is also a bad practice. I think the best way is to take a look at what other companies like Facebook and Telegram use for end to end encryption and it's quite similar I just have no clue how they store the keys but I feel like it's one of the ways I described or very similar.
I suppose from the tone this is one of your users speaking. They're all valid points, the main thing is that asking for a password every time seems a bit overkill for such messaging system. WhatsApp and Telegram for example generate and store keys in each physical device (albeit surely more complex than how I explained it, that's why you see keys changing every time someone switches to a new phone), which is of course not viable for a website.
I will consider this don't get me wrong, but it's not top priority due to its intrinsic complexity.
I will consider this don't get me wrong, but it's not top priority due to its intrinsic complexity.
Man, you out here roasting me saying I am speaking from the tone of one of my users. Nah I wrote that myself and it's all I could think of. And yes ofc things like OTR from XMPP and WhatsApp use end to end by storing these keys on your device, they make new keys for every conversation and you can use passwords/codes too on those apps as an additional security. Anyway I told you practically the only way you could do this because of the limitations, using JS and decrypting stuff on the user's browser would be more secure since its all off the server but because of the limitations of it being a website and it's mybb the only thing you can do is what I explained. Generate the private keys and protect them with a password from the user, maybe I will implement this system myself but first I need your plugin to be a little more reliable, symposium has a lot of potential.
lol sorry for that, didn't recognize your writing style from other posts. Anyway, I guess I can implement something like this in Symposium's core in the future.
PS: the fact that MyBB stores two copies of the same message isn't necessarily a bad thing, I thought about exploiting this duplicity for "delete for me or for both" kind of functionality. On the other hand I can see how a single message would be better, especially for big boards.
A nice addition to Symposium would be deleting one of the two copies and relying on the unique conversation ID which is already tied to each message; this would break Symposium's reversibility though (as in, you can go back to normal anytime by uninstalling Symposium). Opinions?
PS: the fact that MyBB stores two copies of the same message isn't necessarily a bad thing, I thought about exploiting this duplicity for "delete for me or for both" kind of functionality. On the other hand I can see how a single message would be better, especially for big boards.
A nice addition to Symposium would be deleting one of the two copies and relying on the unique conversation ID which is already tied to each message; this would break Symposium's reversibility though (as in, you can go back to normal anytime by uninstalling Symposium). Opinions?
I think you should give the choice to the individual, make it an option and let people decide if they wish to remove the dupe. But if you don't have a dupe then you need to make a new encryption key for every conversation instead of 1 per account which will add more complexity in the future if you do ever add encryption or when a user sends a message they won't be able to see what they sent.
Anyway I don't know if you would ever be interested but just so you know if you're ever in need of a paycheck hmu I have plenty of projects and work on my hands that I would pay you for contributing in.
Anyway I don't know if you would ever be interested but just so you know if you're ever in need of a paycheck hmu I have plenty of projects and work on my hands that I would pay you for contributing in.
Fair enough. I guess for encryption the current setup is superior, so I won't change that.
Thank you for your offer, unfortunately I am going to be a doctor soon and I'll have my own paycheck, and I can see my time spent here falling dramatically when I'll be in a residency program. Thank you anyway.
Thank you for your offer, unfortunately I am going to be a doctor soon and I'll have my own paycheck, and I can see my time spent here falling dramatically when I'll be in a residency program. Thank you anyway.