Like Encrypt Algorithm problems.

[acepilot3000]

This algorithm adds collisions for safety reasons, which can result in a reverse result of 1: N. This may result in different plaintext encrypted ciphertexts being the same, for example, A encrypted result is C, and B encrypted result is also C. In this case, when querying A, there should be both A and B in the query result, and the normal result should not have B.

[acepilot3000]

10 and 12 using CHAR_ DIGEST_ LIKE encrypt algorithm, all results are 01. When querying 0, the encrypted result of 0 is 1, and both 10 and 12 will be queried.

[RaigorJiang]

10 and 12 using CHAR_ DIGEST_ LIKE encrypt algorithm, all results are 01. When querying 0, the encrypted result of 0 is 1, and both 10 and 12 will be queried.

If a 1 -> N digest algorithm is used, this may be unavoidable. For short texts, should another hash algorithm be designed?

[jay-youngn]

try using it

mask=2047
delta=5

[acepilot3000]

try using it

mask=2047
delta=5

Using the above configuration, the encrypted result of string 'U' is' Z ', and the encrypted result of string' Z 'is also' Z '. I reckon this issue is down to encryption algorithms. Just tweaking the config values won't fix the root of the problem.

[jay-youngn]

try using it

mask=2047
delta=5

Using the above configuration, the encrypted result of string 'U' is' Z ', and the encrypted result of string' Z 'is also' Z '. I reckon this issue is down to encryption algorithms. Just tweaking the config values won't fix the root of the problem.

You're right, I try to using originalChar * 31 or increase mask / delta... I'm just reducing hash collisions. The flaws of the algorithm itself still exist.