Sybren Stuvel wrote: > I'm curious. Can you give me an example? AFAIK you need to know who > you're talking to before transmitting sensitive information, otherwise > you could be talking to anybody - and that's just what you wanted to > prevent with the encryption, right?
Encryption has multiple meanings. In the general sense, it encompasses all of cryptography and the information security properties crypto provides. This meaning is rather imprecise and you run into problems using it to answer questions like yours. I won't encryption this way again in this post. In a more specific/technical sense, encryption protects the privacy of transmitted information, preventing third-party eavesdropping. It makes no guarantees who's on the other end of your encrypted pipe. Block cipher modes (CBC-DES, CTR-Rijndael/AES, etc) and asymmetric cipher modes (RSA-OAEP) are examples. Integrity guarantees that the data sent is the same as the data received. Authentication verifies the party on the other end of your pipe. This is the primary purpose of SSL certs, authenticating web sites to browsers (you get data encryption too, but that's somewhat less important). Note that it doesn't verify the party's identity or trustworthiness, only that they know a particular secret. The assumption is that if the certificate system is setup correctly, possession of that secret makes them trustworthy (or rather, you can trust the site because their secret proves that a cert authority somewhere trusts them in some fashion). Trustworthy for what is never defined. If that sounds convoluted or illogical, it is. "Ten Risk of PKI" is a good intro to why this chain of trust isn't all it's cracked up to be. It's good reading to understand exactly what you benefits you get from an SSL connection. http://www.schneier.com/paper-pki.html So in a long-winded way, I've answered your question. The short and sweet of it is, yes, SSL is meant to prevent you from "talking to anybody". In that it succeeds* -- but only so far as making sure the site you're talking to paid some money to one of the dozens of cert authorities for a minimal background check. You've gone from "anybody" to "anybody with a couple hundred bucks and spare time to blow". *at least, until the end user completely ignores the warning dialogs and accepts whatever invalid cert he's presented with. Of course if you control the server and serve a small clientele who already trust you, you can have clients import your own cert so they really can be sure who they're talking to -- as long as your master key remains secret. Watch out for hackers and disgruntled employees. The moral of this story is: computer security is an ugly, complex business. -- http://mail.python.org/mailman/listinfo/python-list
