Is it possible to have a key for encryption, that cannot be used for decryption?

Question

For example, a server might have some encrypted logs or storage or whatnot, that would only be used for reference later. This way even if the server is hacked, everything is still OK until the hacker comes up with a way to intercept the data before encryption.

Another example is the basic browser HTTPS/TLS model where it needs to securely talk to an unknown server and they have no prior key exchange,, without an eavesdropper getting the necessary keys. I almost had an answer in this question: How secure is SSL?, but I still have more reading to do before I understand, but what caught my attention the most was the last answer (no upvotes or comments, just a high rep user)

Whether it relates to SSL or not, and whether that last answer is correct or not, I also want to know if it is possible to create an encryption-only key that requires brute force to decrypt. I don't see how this is possible yet.

This question was IT Security Question of the Week.
Read the Sep 30, 2011 blog entry for more details or submit your own Question of the Week.

Answer 1

What you are referring to is asymmetric encryption. A key is used for encryption, and a seperate key is used for decryption.

You would use the encryption key, aka public key, to encrypt the incoming log files, while the decryption key, aka private key, is stored on a different server/system/etc so there is no way to decrypt the logs.

Some good primers:

1. Asymmetric vs Symmetric Encryption
2. What's the mathematical model behind the security claims of symmetric ciphers and digest algorithms?
3. What are private key cryptography and public key cryptography, and where are they useful?

Answer 2

I want to add to SteveS' answer...

Simply using a public / private keypair to encrypt your logs can expose you to a lot of potential issues that you wouldn't expect. For example:

• You use the traditional PGP method: the start of the file is a symmetric key and then symmetric encryption is done after that. The log is reversible if the symmetric key is recovered from the application while it is open. Still, this is probably the best option.
• Using only asymmetric encryption, you are at risk if you don't pad your message. Usually with logs, you want to write messages as soon as they come in, so you'll be performing a write for every entry. Without some sort of padding or initialization (and assymmetric encryption almost never has any sort of IV), one can attack log entries by taking advantage of their regular formatting and testing likely entries to determine if they are there.
  • If you pad, all entries are a fixed size. Somebody can judge the likely number of log entries.
  • The same padding issues and information leakage can apply if you use a symmetric block cipher.
    • You can defeat that by storing the last block in memory and rewriting the padding area of old log entries with new log entries and rewriting that block on disk.
    • You can defeat that by using a stream cipher.

I think the simplest case is to use PGP-style encryption with a symmetric stream cipher and a new symmetric key for each log file.