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?

  • 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 '15 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" "user@firm.com", 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 '15 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 '15 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 '15 at 16:07
  • The keyword you want here is searchable encryption. There's a good series here. – Polynomial Dec 14 '15 at 23:54

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 | |
  • 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 '15 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 '15 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 '15 at 15:07
  • No (this is the essence of my answer): AES is not susceptible to such an attack. – WoJ Dec 14 '15 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.