3 ms·

An email provider would need a "to" code from you when you registered with them. Then with each request to download your mail, they send you a randomly generate

An email provider would need a "to" code from you when you registered with them. Then with each request to download your mail, they send you a randomly generated number encoded with your "to" code, and you respond by decoding it and sending the number back encrypted with another number they give you. They don't have to know where the mail is actually going, or what is in it. Just that they are getting a request from a person who owns that mail. It gets more complicated than that, for the wonderful reason that there are so many more great things you can once you have standard primitives for encryption and cryptography. For instance, instead of a general email address, you can also give unique addresses to people so that only people you want can send you anything, and you can verify who its from. You can still have a public address just by creating and publicizing an address for that purpose. Once their is a standard library that developers can take for granted there are so many other things that can be easily done. Today many of those things are difficult simply because there is no standard library, and everyone rolling their own implementations creates a nightmare. It is the vetting and fixing every single vulnerability from each implementation that is too difficult for most developers, even very good ones. That is one reason why everything is so insecure today. A first draft of how the encryption works for email would probably one day's white boarding, since the primitives for this kind of thing have been around a long time. And people have done this kind of thing many times before in small contexts. The actual implementation, to be very fast, extremely vetted (even formally verified) for correctness and after iterating many times of possible use cases and corner cases, would take some time. There wouldn't need to be a single code base, but the point is to have very few implementations that are extremely well vet. So few implementations creates better security. That way most applications and users can forget its even there.

bawolff 5y ago
> An email provider would need a "to" code from you when you registered with them. Then with each request to download your mail, they send you a randomly generated number encoded with your "to" code, and you respond by decoding it and sending the number back encrypted with another number they give you. I agree you could do schemes like this (although some of the details here would need finessing), i just don't really think it fits the description of at a low enough protocol level its transparent. Like this is custom application logic - it doesn't get much higher level than that. How could an application forget its there if it has to keep track of storing numbers and finding/sending/decoding the right ones. If this generalized to something that fit every application, i'd say fair enough, but it seems incredibly specialized to the example at hand. If all we're imagining is a standardized set of primitives, we already have that. AES, SHA-256, HMAC are all very well studied and well supported (the public key world doesn't quite have as much of a clear "winner", but there are still very standardized well studied options). All of these things are very secure when used correctly. People however invariably use them incorrectly. Composing primitives (incorrectly) is one of the big ways people get into trouble with crypto. I guess what you're suggesting is an opinionated library that has a bunch of safe options to make it less likely to shoot yourself in the foot? I mean, i certainly agree we could do better when it comes to usability of crypto libraries. Ultimately though, no library is going to prevent a programmer from (for example) giving the secret key to the attacker. By extension, we're never going to have a library that takes the thinking out of using crypto. A big portion of computer security problems are simply the programmer accidentally telling the computer to do something silly, and the computer blindly following orders. I don't think its possible to get rid of that if the programmer is the one calling the shots. Which is why i find the idea of automatic encryption on the tcp or ip layer so enticing - your average programmer would have no influence over it - but the idea also seems to have severe technical limitations (or at least it needs someone smarter than me to figure it out)

bawolff 5y ago

> An email provider would need a "to" code from you when you registered with them. Then with each request to download your mail, they send you a randomly generated number encoded with your "to" code, and you respond by decoding it and sending the number back encrypted with another number they give you. I agree you could do schemes like this (although some of the details here would need finessing), i just don't really think it fits the description of at a low enough protocol level its transparent. Like this is custom application logic - it doesn't get much higher level than that. How could an application forget its there if it has to keep track of storing numbers and finding/sending/decoding the right ones. If this generalized to something that fit every application, i'd say fair enough, but it seems incredibly specialized to the example at hand. If all we're imagining is a standardized set of primitives, we already have that. AES, SHA-256, HMAC are all very well studied and well supported (the public key world doesn't quite have as much of a clear "winner", but there are still very standardized well studied options). All of these things are very secure when used correctly. People however invariably use them incorrectly. Composing primitives (incorrectly) is one of the big ways people get into trouble with crypto. I guess what you're suggesting is an opinionated library that has a bunch of safe options to make it less likely to shoot yourself in the foot? I mean, i certainly agree we could do better when it comes to usability of crypto libraries. Ultimately though, no library is going to prevent a programmer from (for example) giving the secret key to the attacker. By extension, we're never going to have a library that takes the thinking out of using crypto. A big portion of computer security problems are simply the programmer accidentally telling the computer to do something silly, and the computer blindly following orders. I don't think its possible to get rid of that if the programmer is the one calling the shots. Which is why i find the idea of automatic encryption on the tcp or ip layer so enticing - your average programmer would have no influence over it - but the idea also seems to have severe technical limitations (or at least it needs someone smarter than me to figure it out)