Assume I am sending you a message. I decide to encrypt it. I send you the message via a device and some network. You receive the message off that network and your device decrypts it.
There are two very different cases:
- You and I are in real-time communication, or
- My message goes ‘somewhere’ and you get it from there later.
In the first case, total security (aside from breaking the encryption via brute force) from eavesdropping is possible.
Let me detail roughly what happens in https (I am a client and you are my bank, say.):
- your website sends a challenge message and mentions your certificate.
- my browser acquires, from a certificate issuer, your certificate and most importantly, your public key.
- my browser creates three random (DES? AES) keys and sends you a message, encrypted in your public key, which includes those random keys. I think it also encrypts a bit in those keys, using one after another in sequence (triple-DES.)
- your website decrypts using your private key. Supposedly only you and the certificate issuer know this key. This ‘proves’ the message was received by the intended target.
- your website responds demonstrating that it was able to decrypt as above, and including a test message encrypted in the three keys my browser made up at random.
- from then on, for this one session, we encrypt/decrypt all traffic contents in those three keys.
This way of exchanging information is rather secure, because:
- Use of the certificate-related public and private keys is restricted to a very short message which is mostly random data.
- The actual secure traffic is encrypted via three keys that were never used before and will never be used again.
- Presumably, both our machines forget those keys after our session is complete.
Note that both my computer and the bank’s website must remember the three keys for the duration of the interchange. However, those keys are not needed thereafter and generally are discarded.
In the second case above, since we are not in conversation when my message is sent, the machine at ‘somewhere’ must know how to decrypt the message for you. There is no exchange of secret key between the end participants, since they are not in a real-time connection. I cannot send you the secret key, as you are not available to me at send time.
In this case, the messages must be decryptable by the ‘somewhere’ machine that stores them for the time between is-sent and is-picked-up.
While both the sending and final forwarding traffic can be protected (via https or similar), the storage in ‘somewhere’, if encrypted, has to be done by a key that ‘somewhere’ remembers for the ‘time between’ sending and receiving by the end participants.
Thus my confusion about Blackberry in India. They claimed that messages ‘on their server‘ could not be decrypted by them.
This is true if the messages are in-flight between active end points that have exchanged random encryption keys.
This is not true if the messages are stored, being sent by one party when the intended recipient is not online at the same time.