2
$\begingroup$

A=0100 0001, B=0100 0010, X=A^B=0000 0011. If I have X only, is it possible to obtain A and B? How many combinations it will take a computer to find the correct values, if A and B can have all characters of values between ASCII 32 and ASCII 126 (i.e it can have lowercase, uppercase,symbols and numbers and space)? ('^' is XOR operator)
What I am doing:I am trying to encrypt a password in a program for my school project. 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 required for the brute force attack.

$\endgroup$
16
  • $\begingroup$ If you have only $X$, any value of $A$ will give a corresponding value of $B$, with $B=A\wedge X$. Notice that $A \wedge (A \wedge B)=B$ for all $A$ and $B$ $\endgroup$ – Jean-Claude Arbaut Oct 11 '16 at 6:25
  • $\begingroup$ No, $95$, because between $32$ and $126$ included, there are $126-32\mathbf{+1}$ values. $\endgroup$ – Jean-Claude Arbaut Oct 11 '16 at 7:18
  • $\begingroup$ thanks, let us assume that I have n pairs of correct order of A and B, will it take 95 raised to power n combinations ? $\endgroup$ – Dr.Paradox Oct 11 '16 at 7:23
  • 1
    $\begingroup$ Not really. Notice that many keys will yield the same value. I don't quite understand one thing: if the file is not accessible without a password, why do you need to encrypt keys at all? They could be stored in an unencrypted file that won't be accessible either... Or if you want to hash passwords, why not use a more common (and more robust!) hash function, like MD5, or SHA, or Whirlpool ? Also, beware rainbow attacks, there are also workarounds for this. $\endgroup$ – Jean-Claude Arbaut Oct 11 '16 at 8:48
  • 1
    $\begingroup$ If, given a hash password according to your method, you want to know the complexity of finding a possible hashkey, then it's very easy. Take a 4 bit key "abcd", with hash value "1001", then you simply have to choose bits "a" and "d" with different value, and "b", "c" with the same value. Not more complicated for a longer password: it's thus O(n), where n is the password length. If you want the extra constraint that password are represented by valid characters, you will simply have to choose carefully the chosen bits, but it's easy. So the hash is not secure at all. $\endgroup$ – Jean-Claude Arbaut Oct 11 '16 at 9:49
0
$\begingroup$

It sounds like what you want is a hash-function. You want a way to authenticate a password without storing the actual password and comparing to that. In the procedure you described it is correct that we can have $95^n$ passwords $p$ of length $n$. This does not imply that your procedure can output $95^n$ different hash values $e$.

It might be the case that different pairs of ASCII-characters in the given range yield the same $\operatorname{XOR}$-value. You can create a $95\times 95$ table to check this: $$ \begin{array}{|c|c|} \hline \operatorname{XOR}&32&33&...&126\\ \hline 32&&&&\\ \hline 33&&&&\\ \hline \vdots&&&&\\ \hline 126&&&&\\ \hline \end{array} $$ If two entries in this table, say $(A,B)$ and $(C,D)$, coincide, one could interchange letters $A,B$ found in symmetrical positions from each end in $p$ by $C,D$ and nobody would notice.

For one thing, one can always swap $A,B$ at positions $i,n-i$ of $p$ and still have the same hash value of $p$. So the number of passwords yielding a given hash value $e$ can be huge. For instance if $p$ has length $10$ and consists of pairwise distinct characters at positions $i,n-i$, then you can swap any pair at positions $i,n-i$ of $p$ to have another password with the same hash value $e$. This gives at least $2^5=32$ such passwords for that case.

One other problem is that the length of $e$ reveals the length of $p$, so someone gaining access to the file with hashed passwords can at least learn the length of those passwords from that file.

Finally, it makes no sense to me that you call it an encryption of the passwords. How would one decrypt $e$?

$\endgroup$
3
  • $\begingroup$ Thanks it solved my problem. There is no need to decrypt e. Let's say when the user enters the password to access the file it is stored in string x. Now the string x go through the same process and in the end if it is equal to e access is granted. Thank you very much. $\endgroup$ – Dr.Paradox Oct 11 '16 at 9:20
  • $\begingroup$ @Dr.Paradox: BTW, anyone could easily create that $95\times 95$ table and find some password matching a given hash value $e$. So a very fast algorithm can be made to break your system. They only have to store less than $95^2=9025$ $\operatorname{XOR}$-values in a lookup-table pointing to a pair of letters that will work for the given positions in $p$. $\endgroup$ – String Oct 11 '16 at 9:27
  • $\begingroup$ What if I store the values of XOR as binary. Then the length of the password will not be known (coz 0000 0011 is same as 11). $\endgroup$ – Dr.Paradox Oct 11 '16 at 9:33

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.