Viewing a single comment thread. View all comments

resisting_a_rest t1_j0rliqb wrote

Is there any such service where you can query a "DNS-like" server with an email address and it will give you back that email addresses' public key. Then you could encrypt a message using the public key and send it to the email address. Something like this should be easily implementable in all email clients, both web based and others.

Seems like a relatively simple thing to do. I guess that hardest part is getting people to make sure they save a secure copy of their private key/seeds, as if they lose those, they will be unable to read any of the encrypted emails sent to them and there would be no way to recover them.

4

ColgateSensifoam t1_j0s3bn7 wrote

You're describing PGP key repositories

Very few people actually use PGP unfortunately

7

resisting_a_rest t1_j0s6zf5 wrote

Maybe because no popular web based email services support it (or if they do, do not advertise it)?

Gmail, for instance, could easily allow you to enter your public key and then advertise it on a public repository, then have you enter your private key and store it locally (not transmit it to the server). I guess you'd have to trust Google with that though.

But then whenever you press send to send an email, it would check the repository and if that email has a public key, if so, encrypt the message and send it (otherwise just send it in the clear). For incoming messages, just automatically detect if it is encrypted, and then use your private key to decrypt it and display it. It would be pretty much transparent once you supplied Gmail with your private and public keys.

1

Epistaxis t1_j0tk95w wrote

Why would a popular, i.e. free, web-based email service offer an option that prevents the provider from seeing your messages? That's the whole business model.

2

resisting_a_rest t1_j0tnb4u wrote

You're right, but it doesn't have to be for all emails, just have the option to send certain emails encrypted using "the standard" for sending encrypted email.

But again, yes, there is a big incentive to not have this feature.

1

edman007 t1_j0sy2at wrote

S/mime works better honestly..we use that where I work. But it's hard getting people to set it up, and certs are a little more difficult to generate.q

1

uzlonewolf t1_j0sv64t wrote

The issue with that is it tells scammers the email address is real and valid while also allowing them to completely bypass all spam/phish protection.

3

resisting_a_rest t1_j0t2lmb wrote

If I send an email to a non existent address today, don't I get an email back saying it doesn't exist? Or is that not a thing anymore?

I suppose spam/phish protection would have to move to the client (javascript on web-based email systems), which I suppose could overwhelm the browser if you get too many spam messages.

An alternative may be to have a whitelist of addresses that are allowed to send you an encrypted email. If the email server receives an encrypted email from an address not on the whitelist, then just discard it. Use something like SPF to prevent email address spoofing. This whitelist could be a global list as well as a personal list.

But I can understand why people might not want to attempt to implement something like this, there may be many potential ways to circumvent it, and people just don't want that kind of liability.

2

uzlonewolf t1_j0t9e8y wrote

> If I send an email to a non existent address today, don't I get an email back saying it doesn't exist? Or is that not a thing anymore?

Depends on how the server is configured. Most still do this yes, however it is rate limited so someone can't try thousands of random addresses per second. You can't really rate limit DNS like that.

The "whitelist" option is similar to what people do now with PGP/GPG keys, no special server needed.

2

resisting_a_rest t1_j0tn0fc wrote

I'm talking about making it something that the average person would use, not the person that is going to be managing public keys manually.

It could even just be an option to "send this email encrypted" for only one-off emails, and most receivers that deal with sensitive information (banks, brokerages, insurance, etc.) would be able to receive encrypted email this way. It would be the standard way of sending encrypted messages.

Currently, the way I need to do this now with my broker is to either log in to their website and send a message through it, or use a special web-based encrypted message service. It's not a nice way of doing things.

1

uhoreg t1_j0s85ch wrote

There is OpenPGP Web Key Directory, or key servers. One of the issues is that unless you trust the server that you're querying (and if you're doing PGP, you should probably not be inclined to blindly trust servers), you need to verify that the key actually belongs to the other users.

2

resisting_a_rest t1_j0sdfie wrote

Why is that? If you are sending an email to a specific email address, and you encrypt the message using an incorrect public key, that address just gets sent an encrypted message that they cannot decrypt.

I suppose if their email is already compromised, that could be a problem, but this would require both the Key directory and the email account to be compromised.

If only the key server is compromised, I would think the best you could do is a denial of service.

1

uhoreg t1_j0w26gb wrote

> I suppose if their email is already compromised, that could be a problem, but this would require both the Key directory and the email account to be compromised.

How does the key directory get the keys, and how does it ensure that the keys are valid? Traditionally, key servers accepted any keys that were uploaded to them, and told people to verify them before trusting them. Some key servers will try to verify keys ... by emailing you. But, of course, if an attacker has compromised your email account, that doesn't help much.

With WKD, you contact the domain that owns your email account (e.g. if you are something at emailprovider.com, you would fetch the key from emailprovider.com). But if someone compromises emailprovider.com, then they could just serve the wrong key.

One of the goals of end-to-end encryption is that you don't want your service providers to be able to read your things. Both of the existing systems are vulnerable to attacks from your service provider (either if they become malicious, or have a rogue employee) unless you verify the key in some other way.

1