# Number of combinations required to brute force

I am trying to encrypt a password in a program. Here is the process:

Let us assume that I have a string $p$ ($n$ characters long) which contains the password. Now the program reverse the string and stores it in string $r$. After that it takes each character of $p$ and $r$ applies the XOR operator and stores it in string $e$.

Next time the user want to access the file he/she will be asked to enter the password. The entered password will go through the process explained above and will be compared to string $e$. If both are not equal access will be denied.

I want to know the number of combinations of it will take a computer to brute force the password ("just to show if the encryption is mathematically effective or not, during the presentation"). Thanks

• Hints: 1) If ASCII encoding of characters is used and the password is BAT (42h 41h 54h), the password red (72h 65h 64h) will work just as well. 2) People choose easy to remember passwords, and that can be used to reduce the number of combinations it will take a computer to brute force the password. 3) If the string comparison is per the standard operator of most languages, a timing attack might make brute force linear with the number of characters, rather than exponential, even assuming random choice of password. – fgrieu Oct 11 '16 at 10:58
• ... 4) If the file itself is not encrypted etc., the attacker can access it directly instead of using the program. – deviantfan Oct 11 '16 at 11:52

This attack will only take $$\Omega(n*logn)$$ steps of precomutation (for sorting the words file). And then $$2*n*logn$$ time for 100% guaranteed reversal of each hash. For a cryptographic hash (or one-way-function), you want a hash scheme to be secure in an exponential ratio to the number of bits, such as $$\Omega(2^n)$$, so this scheme is insecure.