3 ms·

Aside from the things you mentioned, I have started moving to self-hosting everything on a VM with an encrypted disk and https for all app interactions. For co

Aside from the things you mentioned, I have started moving to self-hosting everything on a VM with an encrypted disk and https for all app interactions. For code I use gitea/gogs + self hosted drone. I have OpenVPN running their as well and use it even at home since Comcast is my ISP. Backups are done via Borg and shipped to another VM also with disk encryption. I use pass for password management and push it to my gitea repo. The one area I haven't solved 100% is email. I tried self-hosted but the majority of my outgoing email was being flagged as spam, even after doing all the suggested things to prevent that. I am using proton mail now and just have to trust they are legit. For texting I am using signal and have managed to get most of my frequent contacts to start using it as well. For online communities I use different handles and email aliases. Not sure if that helps or not though.

pasbesoin 10y ago
I haven't done it, but some years ago a Mike... C.? published a description of how he did email, then. Public/private keypairs. Inbound email would arrive at his server and immediately be encrypted using a public key. It would sit on his server encrypted. When he pulled it off, he would decrypt it at his client using the private key. If the server was compromised, at that point in time, all the adversary would get would be a bunch of encrypted messages to which the relevant key for decryption was not present on the server. Just to be clear, this was his keypair, used to keep incoming email at rest on his server encrypted with no local means to decrypt. Irrespective of whether the sender did or didn't use encryption when sending the email to him. I presume one would want some sort of canary to warn of compromise with respect to further messaging that might arrive or be sent. Outbound, I presume he was not retaining copies on the server and was using whatever degree of encryption the recipient could handle and the situation warranted. P.S. I realize this doesn't solve your "you're SPAM" labeling by an ever more differentiating Internet email network. P.P.S. I'm pretty sure this is it. Site/page design may have been redone a bit. Just if and as this interests anybody -- I haven't taken the time to reread it, right now. https://www.grepular.com/Automatically_Encrypting_all_Incoming_Email https://www.grepular.com/Automatically_Encrypting_all_Incomi...

pasbesoin 10y ago

I haven't done it, but some years ago a Mike... C.? published a description of how he did email, then. Public/private keypairs. Inbound email would arrive at his server and immediately be encrypted using a public key. It would sit on his server encrypted. When he pulled it off, he would decrypt it at his client using the private key. If the server was compromised, at that point in time, all the adversary would get would be a bunch of encrypted messages to which the relevant key for decryption was not present on the server. Just to be clear, this was his keypair, used to keep incoming email at rest on his server encrypted with no local means to decrypt. Irrespective of whether the sender did or didn't use encryption when sending the email to him. I presume one would want some sort of canary to warn of compromise with respect to further messaging that might arrive or be sent. Outbound, I presume he was not retaining copies on the server and was using whatever degree of encryption the recipient could handle and the situation warranted. P.S. I realize this doesn't solve your "you're SPAM" labeling by an ever more differentiating Internet email network. P.P.S. I'm pretty sure this is it. Site/page design may have been redone a bit. Just if and as this interests anybody -- I haven't taken the time to reread it, right now. https://www.grepular.com/Automatically_Encrypting_all_Incoming_Email https://www.grepular.com/Automatically_Encrypting_all_Incomi...