0

We are considering using the Soundex algorithm to improve our search capabilities in our app. Our app data are encrypted in the DB. (EAS256) The Soundex result will be stored in clear next to our encrypted data. In fact, the Soundex calculation will be done at the same time of the encryption.

I would like to know if the Soundex output will add any security breach to our application. Does this mean that with the Soundex value and the cypher data can an attacker have a chance to calculate the original value?

I'm pretty sure that it's safe, but I would like to double-check.

Improve this question

1 Answer 1

Reset to default
1

This sounds like a security breach that would defeat row-level encryption.

Soundex is an algorithm for indexing words by their approximate sound. You can think of it as a lossy compression approach. As a lossy transformation, it is not reversible in the sense that you can directly extract the original input. However, it is very much reversible in the sense that you can generate plausible inputs. Since the Soundex index would disclose a lot of information about the plaintext

  1. an attacker could use this to crack the encryption far more efficiently
  2. an attacker might not even need to crack the encryption to make inferences about the plaintext content. Indeed, that you are creating this index means that you want to be able to search the plaintext contents without having to perform the decryption first.

So storing encrypted text next to a Soundex-index of that text will likely break your security goals.

In contrast, such a Soundex index would not be a problem if both the actual text and the index are given the same protection level, e.g. if your encryption works at the disk or database level.

It might be a good idea to take a step back and think about your actual security goals and your threat model. What is the encryption supposed to achieve? Which attackers with which capabilities are you defending against? Is row-level encryption even necessary or helpful in that threat model? Do you really need an unencrypted Soundex index? Some problems cannot be solved though – there is often a security–convenience tradeoff when it comes to things like E2EE and server-side search.

Improve this answer
5
  • thanks a lot. That's exactly what I was looking for! It's crystal clear now. What about if I hash (HMAC SHA256) the soundex index AND (if not enough) I "uncorrelate" this (hashed) index and its cypher by positioning them if two separated places (tables) ? It will be enough to avoid any attacker to get the clear soundex data AND to know for which cypher it's the index ? What do you think ?
    – Marc Alves
    Commented Mar 13, 2022 at 10:15
  • @MarcAlves That may or may not help depending on your specific threat model. I'm sceptical about hashing because hashes of low-entropy data is trivial to crack. Classic Soundex only produces ~5500 possible values per input word, and those hashes can be trivially precomputed. A HMAC would change this since it also includes a key, but then the question is how that key is managed so that your application can use it but an attacker would not be able to obtain it.
    – amon
    Commented Mar 13, 2022 at 10:49
  • our threat model is pretty clear. Totally agree with you, that's also why we are using the HMAC with a key. In fact, our application is already dealing with the key management. So it's a concrete option to use that key and hash this soundex index. Assuming that the key is properly managed, do you confirm in your opinion that going to an HMAC SHA256 hashing will be a good solution for this soundex feature ? And also what about my second point on the fact to store the hashed soundex in a other place than the cypher ?
    – Marc Alves
    Commented Mar 13, 2022 at 11:31
  • @MarcAlves I don't feel comfortable saying that your approach is secure without understanding all of the details, in particular without understanding your exact security goals. I also don't understand what kind of searches you want to perform on the Soundex data. But discussing this properly would require way more space than these comments can offer. Depending on how you reuse your HMAC keys, classic cryptoanalysis techniques like frequency analysis would still be possible. Separating/unlinking records can help to make unintentional inferences unlikely, but might not offer actual security.
    – amon
    Commented Mar 13, 2022 at 12:09
  • @aman I totally understand your position, it's in fact not simple to validate this kind of model like that. The purpose of this post was initially to better understand how to deal with Soundex and Encryption in general. I think that I have enough element to assess the final solution. Without being a cryptographist, it's really hard to be fully sure that the security is 100% safe, but at least we are doing our best to reach this goal :) Thx again for you help !
    – Marc Alves
    Commented Mar 13, 2022 at 12:44

You must log in to answer this question.

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