> It's not that I forgot that part, it's that that's the hard part. That's the reason PGP is hard to use: They try to make sure you do it securely. And you can't have some third party do that part for you without trusting them, and the whole idea is not to have to trust any third parties. What public servers are you going to use here? Does each email user have to run their own server? Unless you have a single central server, how do you know which server corresponds to which user?
I'm certainly not going to argue with this, it's the basic gist of my original reply. :)
> Automating web of trust could be interesting though. Imagine you get an email from a new user that you've never received any email from before. There is some new P2P network where if you have someone's public key, you ask that user whether they know the new user's public key, and they send back a signed response (either "this is the key I have" or "I don't have a key", signed either way with the known user's public key). Then if all your friends who have the new user's key agree on what it is, it's probably right. If nobody has it, you get encouraged to verify it manually (i.e. in person). And if they don't all agree you get the nasty warnings about something fishy going on.
Exactly. This is similar to what I was envisioning when I was talking about confidence levels. Having different levels such as "I have personally verified (signed)" and "I know of and reasonably trust this key based on people I trust" and making that public in some manner would allow a slew of interesting techniques to verifying public keys to different assurance levels.
Come to think or it, it sounds like what we need is for a social network to adopt this. Google+ with it's real name requirements might make a good fit, but maybe real name isn't what we care about, maybe we just care about email. Alternatively, some alterations to diaspora might work out well (I know little about it other than it's a roll your own social network that I think can work as a node of a larger network).
> That seems like a low-effectiveness method of sending spam, given that the public key is uniquely identifying and tied to a sender address, so once the spam filter realizes everyone is marking all those messages as spam it can just blacklist everything sent using that key. Also, how is it different from existing PGP other than that more people would be using it? If you've infected a machine with a virus you can do whatever you want to it. You could just write the spam directly to the user's inbox, or send it out from their own address and sign it with their actual key. Compromised machine = you're screwed.
I'm imagining a virus that generates one on the infected system for the address the mail client is configured for. That could be a LOT of new keys.
The problem is the thousands or millions of bogus keys that start being sent from addresses that previously didn't have ANY key associated with them (or did, but not through that machine), clog the web of trust if they make it on there. If they are automatically added to mail client/PGP systems on the recipients end, that's a lot of bogus keys in users mail clients (even if it's just the 10% that arrive before spam filters react). If clients end up syncing their known keys to some central repo at some point, that's a LOT of bad data. I can imagine a case where someone generates a legitimate key and gets it personally signed by a few people, only to find that it's verified by hundreds of people on some public servers.
As for low-effectiveness, if it evades more filters by just a few percent, at the scales spam is sent that's a BIG deal.
> This isn't even necessary for a virus. The problem with viruses is that they can stay resident until you type your password and then it doesn't matter how hard the password was.
True. I imagine the really fast spreading and pervasive virus's need to be quicker than that though, but I have nothing other than a hunch to base that on.