6

I need to securely encrypt data we are storing, but for each client I need the same plaintext to encrypt into the same cypher text. The reason for this is the data is still required for a pattern matching algorithm we apply to it, and so it wouldn't work if the cypher text was always different for the same plaintext.

Given this requirement, I am using AES encryption with 256-bit key, creating a random MD5 hash as a password and a hardcoded salt & IV for each client. I don't mind if people can spot patterns in the data due to matching cypher texts, but I do care that they can't retrieve the key to decrypt all of the data for that client's key.

If the was a portion of data that had both the plaintext and corresponding cypher text, how easy is it to crack the key? Is it still 2^(n-1) for n-bit key or thereabouts, or is this now a security risk having a fixed salt and IV?

I read that every known matching cypher text and plain text can reduce the cost of attacking the key by N times, as they can attach more simultaneously... is this true / how many known pairs would it need to be significant?

Improve this question
5
  • Why not just encrypt each client's data properly (i.e. without compromises for the pattern matching), but also generate and store a separate hash for the stuff that needs pattern matching?
    – R15
    Dec 14, 2015 at 14:31
  • Unfortunately all of the data uploaded is required for pattern matching, everything stored is a single word or email address, e.g. "car", "blue" "[email protected]", and we need to be able to increment counts for when these occur. We also need to decrypt these client side, so would need to store both hashed text and cypher text for each. How susceptible is hashing to attacks, I presume it is down to the hashing algorithm used?
    – moatak787
    Dec 14, 2015 at 14:51
  • So the client does all the encryption/decryption, or it's done by the server? Are you trying to keep the data secret from the person running the client end? Also, why don't you use AES-ECB mode, which is the intended solution for what you want to do, and is going to be better studied than using a fixed IV.
    – Steve Sether
    Dec 14, 2015 at 15:49
  • Yeah so the encryption/decryption is all done client side, our server doesn't know the key. Our requirement is to upload data from a client to our servers (as single words or email address) and have it as securely encrypted as possible pre-uploading with 2 conditions: the same plaintext gives the same cyphertext for each client in order to increment counts for them, there is no serious risk if in some cases the database holds plaintext and cyphertext for N number of words/addresses
    – moatak787
    Dec 14, 2015 at 16:07
  • The keyword you want here is searchable encryption. There's a good series here.
    – Polynomial
    Dec 14, 2015 at 23:54

1 Answer 1

Reset to default
2

If I understand your question correctly, someone may know some plaintext corresponding to the cryptotext and you are worried that this may weaken your key.

If so, AES is not susceptible to known-plaintext attacks. It means that knowing the plaintext corresponding to the cryptotext does not help to guess the encryption key.

You just need to have a good enough key, MD5 is 128 bits so it will take forever (which is an approximation of "(much)^(much) longer than the lifecycle of the encrypted information")

Improve this answer
4
  • Yes, we are implementing a client-side encryption (which is why we can't solely hash), but for some portions of the data the plaintext will also be stored in the same database as cyphertext. We also need to pattern match all the data, i.e. increment counts, and so same plaintext must always result in same cyphertext. Should this still be okay, or is it much better to implement a hashed value for the matching as well as normal AES with varying IV for decrypting client-side?
    – moatak787
    Dec 14, 2015 at 14:56
  • The encryption is predictable, so, for a given key, a plaintext will always result in the same cryptotext. What worries me is that you will be encrypting client-side, so you will need to distribute the same key to all clients? This does not sound good.
    – WoJ
    Dec 14, 2015 at 14:59
  • No for each client we will generate a different key and IV, since the matching only needs to be done at a client level. However, if someone knew that we were using the same key and IV for a set of data, and had say 1bn examples of known plaintext / cyphertext, would this enable them to get the key and decrypt the rest of that client's data?
    – moatak787
    Dec 14, 2015 at 15:07
  • No (this is the essence of my answer): AES is not susceptible to such an attack.
    – WoJ
    Dec 14, 2015 at 16:29

You must log in to answer this question.

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