28 ms·

Hmm. I think end-to-end needs to remain end-to-end, and you don't need to trust a plethora of third parties if everyone is using the same library/platform for e

• bawolff 5y ago
  I'm not sure how having a single code base would help anything. Sure, interopable standards are needed, but what benefit does a single code base get us? > Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). So the scenario here is we add encryption transparently at either layer 3 or layer 4 and the encryption is end-to-end (the email provider cannot read it, only the intended recipient). How would that work? At the very least the email provider would have to know the application level "to" address to route the email. If its end to end encrypted, they cannot as they are a middle party. Maybe you could say that some metadata is unencrypted, but then the encryption is clearly not happening transparently on a low layer if the application layer turns it on and off for different parts of the message. Not to mention - who are you encrypting it to? (Aka which key are you using). If this is transparently on layer 3/4 one presumes the key is tied to the ip address (and maybe port?) as the only identifier available. If its end to end encrypted through a middle man (email provider) for an eventual destination for whom not only do you not know their ip address, they are offline right now so they literally don't have one, how can you possibly get the right key for that transparently without involving the application layer? > There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today. Personally i think TLS is pretty good all things considered. Its not without trade-offs but most of those trade offs are pretty reasonable given the technical constraints we have. > The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation. Very few security issues are caused by interoperability issues between different crypto implementations. One implementation might have a bug a different one doesn't, but settling on a single implementation wouldn't stop bugs from being a thing.
  • Nevermark 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. 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)