On 2023-05-09, Stuart Henderson <stu.li...@spacehopper.org> wrote:
Ed25519 is used for signing not encrypting. But Ed25519 keys can be converted and used for encryption; "age" has convenience support for doing this with Ed25519 ssh keys, and might generally be something that works for your use case. It's not in base though.
https://words.filippo.io/using-ed25519-keys-for-encryption/
Another possibility is libsodium's crypto_box API but will need more self-assembly as afaik there's no standard CLI tool using this.
That doesn't meet their requirements. They want to avoid storing any private key material on the "remote server", and Diffie-Hellman (which is what X25519 is based on) requires access to the private key. Personally, I don't think this makes all that much sense. E-mail is not very secure. If you can't guarantee communication is E2EE, then this seems like false security/privacy to me. Not only does the other recipient likely use a service like Gmail which means your communication is in Google's hands; but unless you strictly enforce encryption in transit- most MTAs only use _opportunistic_ encryption-every device your e-mail traversed possibly has access to the content as well. This is why applications like Signal are gaining popularity especially in the crypto/infosec crowd. Last, if you are worried about the "remote server"; then why not just host the MTA at your house along with your "home mail server"? Simply configure the "remote server" to be a router that routes traffic through a WireGuard tunnel to your house. Then your e-mails will be "at rest" at your house. As an added benefit, you can route local traffic destined to your MTA to be routed directly to your server and avoid the traffic from ever leaving your house. Zack
