Have everyone who wants to share and recieve potentially exfohazardous ideas/research send out a 4096-bit RSA public key.
Then, make a clone of the alignment forum, where every time you make a post, you provide a list of the public keys of the people who you want to see the post. Then, on the client side, it encrypts the post using all of those public keys. The server only ever holds encrypted posts.
Then, users can put in their own private key to see a post. The encrypted post gets downloaded to the user’s machine and is decrypted on the client side. Perhaps require users to be on open-source browsers for extra security.
Maybe also add some post-quantum thing like what Signal uses so that we don’t all die when quantum computers get good enough.
Should I build this?
Is there someone else here more experienced with csec who should build this instead?
I don’t think e2e encryption is warranted here for the first iteration. Generally, keypair management is too hard, today, everyone I know who used encrypted Element chat has lost their keys lmao. (I endorse element chat, but I don’t endorse making every channel you use encrypted, you will lose your logs!), and keypairs alone are a terrible way of doing secure identity. Keys can be lost or stolen, and though that doesn’t happen every day, the probability is always too high to build anything serious on top of them. I’m waiting for a secure identity system with key rotation and some form of account recovery process (which can be an institutional service or a “social recovery” thing) before building anything important on top of e2e encryption.
Possibly incidental, but if people were successfully maintaining continuous secure access to their signal account you wouldn’t even notice because it doesn’t even make an attempt to transfer encrypted data to new sessions.
Idea:
Have everyone who wants to share and recieve potentially exfohazardous ideas/research send out a 4096-bit RSA public key.
Then, make a clone of the alignment forum, where every time you make a post, you provide a list of the public keys of the people who you want to see the post. Then, on the client side, it encrypts the post using all of those public keys. The server only ever holds encrypted posts.
Then, users can put in their own private key to see a post. The encrypted post gets downloaded to the user’s machine and is decrypted on the client side. Perhaps require users to be on open-source browsers for extra security.
Maybe also add some post-quantum thing like what Signal uses so that we don’t all die when quantum computers get good enough.
Should I build this?
Is there someone else here more experienced with csec who should build this instead?
I don’t think e2e encryption is warranted here for the first iteration. Generally, keypair management is too hard, today, everyone I know who used encrypted Element chat has lost their keys lmao. (I endorse element chat, but I don’t endorse making every channel you use encrypted, you will lose your logs!), and keypairs alone are a terrible way of doing secure identity. Keys can be lost or stolen, and though that doesn’t happen every day, the probability is always too high to build anything serious on top of them. I’m waiting for a secure identity system with key rotation and some form of account recovery process (which can be an institutional service or a “social recovery” thing) before building anything important on top of e2e encryption.
I mean, Signal messenger has worked pretty well in my experience.
Possibly incidental, but if people were successfully maintaining continuous secure access to their signal account you wouldn’t even notice because it doesn’t even make an attempt to transfer encrypted data to new sessions.
This was probably a typo but just in case: you should never send a private key off your device. The public key is the part that you send.
Oh no I mean they have the private key stored on the client side and decrypt it there.
Ideally all of this is behind a nice UI, like Signal.