I'd like to encrypt some sensitive data, which will be stored in an event storage. A few of the event types will require encryption and the data is in the 10 byte - 100 kbyte range. I think the main danger here that the database can be stolen and not that somebody falsifies the data, so symmetric encryption is fine, we won't need different keys for read and write. What I am worried about that the too many small, possibly repeating texts might make it easier to do known plaintext attack. Is that a real danger by nowadays algorithms? Which algorithm to choose to avoid that? Should I change the keys frequently? Are there other dangers by encrypting these events I did not think of?
It’s not the algorithm you should be concerned about as much as the encryption mode. Sure, you need to use a strong algorithm such as AES, but there are several you could choose from.
What you really need is to use it in a secure mode (not ECB!) with a unique IV. As long as each message has its own IV, it won’t encrypt to the same ciphertext. That way an attacker can’t correlate different encrypted messages to see if they’re the same.
There are no known attacks against related plaintexts in any strong, fully implemented block cipher. (There are some reduced-round attacks against some ciphers, but that’s one reason the algorithms specify more than enough rounds to defend against them.)
EDIT: Lie Ryan raises a good point. Make sure that message length doesn’t betray any secrets. For example, if you have a field such as “VIOLATIONS”, I might infer that a a 16 byte cipher text means “N/A” or “no data”, while a 19K ciphertext might mean the client often violates rules.