|
|
|
|
|
|
by Shendare
2249 days ago
|
|
|
Why can't somewhere.com have the public key for user@somewhere.com and serve it to other e-mail providers on request? Letting one's provider hold onto the private key doesn't provide the same level of security as the user being the only one with it, but it's a helluva lot better than not bothering with encryption at all. Private keys can also be protected with a password, right? So the provider could have a copy of the private key but not the password to utilize it. The user would just have to never forget the password as opposed to never losing their private key to a hard drive failure or whatever. |
|
|
They could, but then somebody would have to deliberately request it. That would also mean adding a separate transmission/protocol different from the email protocols routing the messaging. That is a more streamlined process, but still not fully automated.
The only way to ensure adoption is to force onto users as an automated check of the primary protocol like the handshake of TCP. Even then you should still have to account for SPAM and anonymous users you don't want to exchange keys with.
Yes, private keys can be issued with a password. That is not an excuse to disperse your private keys though, because that password can be brute forced and then a criminal can access any account using that key set provided they aren't further blocked by something like 2 factor authentication. The password is just there as added security for things unintentional disclosure or unintended access, but not as a primary means of security.