2

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?

Improve this question
5
  • 2
    How sensitive is the data? For how long will it be sensitive — is it a problem if it’s decrypted in forty years’ time?
    – Mike Scott
    Commented Jul 1, 2019 at 5:19
  • 1
    "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." - The difference between symmetric and asymmetric encryptio is not about falsifying data (integrity) but to allow a public key for encryption but to have a secret key for decryption. And asymmetric crypto is usually used combined with symmetric crypto - allowing different symmetric keys while keeping the public/private key the same. As for known plain text attacks: that's what random IV are for.
    – Steffen Ullrich
    Commented Jul 1, 2019 at 5:49
  • @MikeScott It is GDPR user data, so profile, email address, etc. Not sure how GDPR deals with decryption after 40 years, probably the application won't exist that long. :D
    – inf3rno
    Commented Jul 1, 2019 at 6:27
  • @MikeScott I can change the algorithm and decrypt + encrypt the whole database again, but it takes a lot of effort, so I would do it maybe once in 5-10 years if it is really needed. I can save the key id along with the encrypted data so I can use multiple keys and change keys frequently to avoid overusage if I need to do that.
    – inf3rno
    Commented Jul 1, 2019 at 6:34
  • 1
    Most modern salted symmetric encryption like AES wouldn't be vulnerable to known plaintext attack. As long as the salt is unique for each data and the plaintext and encrypted text doesn't have a uniquely identifiable data sizes. You can add some paddings to limit your data sizes to fixed sizes at the cost of larger encrypted data size.
    – Lie Ryan
    Commented Jul 1, 2019 at 6:56

1 Answer 1

Reset to default
3

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.

Improve this answer
2
  • Isn't adding a padding dangerous? I remember reading about some sort of padding related attack maybe a year ago.
    – inf3rno
    Commented Jul 1, 2019 at 15:14
  • 1
    @inf3rno , you’re probably thinking of a “Padding oracle attack” en.wikipedia.org/wiki/Padding_oracle_attack which uses tests against compression to check the output length. This is similar to the type of attack that Lie Ryan was referring to. A defense might include fixed size records, and possibly using relationships to data in other tables. You also have to consider your threat model-outsiders might not have the same visibility to the database as insiders.
    – John Deters
    Commented Jul 3, 2019 at 15:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .