-2

I have to generate two strings with the same hash code. I worked on it, and the maximum that I reached is to change only the first two chars of the string.

   public static String same(String s) {
            String re = "";
            char c = 0;
            char ch = 0;
            for (int i = 0; i < s.length(); i++) {
                c = (char) (s.charAt(0) + 2);
                ch = (char) (s.charAt(1) - 31 * 2);
            }
            String S = new String(new char[] { c, ch });
            re = S+ s.substring(2);


    return re;
    }

How can I do to make it work with all the string.length()??

exclusive-OR
  • 1
  • 6
  • The thing about hashcodes is that it is supposed to be the same for each equal instance of your object. So only two exactly the same strings are guaranteed to give you the same hashcode. I have no idea what it is you're trying to do in your code though. – Jeroen Vannevel May 10 '14 at 17:38
  • Please read [how to ask a good question](http://stackoverflow.com/help/how-to-ask). It might be useful to know which [method](http://en.wikipedia.org/wiki/Hash_function) is being used to compute the hash. – Jason Aller May 10 '14 at 17:45
  • 2
    Maybe we need an article on how to make a good comment. ;) – Hot Licks May 10 '14 at 17:46
  • 2
    @JeroenVannevel I believe that the OP is trying to find a hash collision. – Gareth Latty May 10 '14 at 17:49
  • 2
    To the OP: Without analyzing the hash algorithm (which you can do, by examining the source for java.lang.String) there is no reliable way to predict which non-equal string will produce the same hash value. All that can be said is that, given that the hashCode value is 32 bits, if you have more than 4 billion different strings some of them will have to produce identical hashCode values. – Hot Licks May 10 '14 at 17:50
  • @HotLicks Remember that Java's hashcodes are not designed to try and prevent intentional collisions - they are designed to be very fast and prevent unintentional collisions - they are simple and generating a collision shouldn't be too difficult either by brute force or inspecting the algorithm. – Gareth Latty May 10 '14 at 17:51
  • @Lattyware - I didn't say different. Was just stating the bounds on the problem. – Hot Licks May 10 '14 at 17:55
  • What are you *really* trying to do? Is this an investigation into hash collisions when `a.hashcode() == b.hashcode() && !a.equals(b)`? If so - why String? –  May 10 '14 at 18:06

2 Answers2

2

The hashCode from String is described in the JavaDocs http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#hashCode()

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

So for each char, you could replace it with any char where s[i]*31^(n-i-1) gives the same value.

kaarefc
  • 206
  • 1
  • 6
0

I wonder why you have to generate 2 strings with the same hash code? You cannot generate an object that hashes to a particular hash code. Hash functions are one-way functions. Hash codes speed up object comparison and maps the object to a particular hash space. Unless you know the inner workings of the method used to calculate the code, you can't reverse engineer it to calculate what object state will generate that hash code.

kevin
  • 2,196
  • 1
  • 20
  • 24
  • 1
    You can always brute-force a hash collision, which appears to be the intent here. – Gareth Latty May 10 '14 at 17:50
  • @Lattyware Yup I agree, but how many iterations would generally be needed to brute force a hash collision? (-: Or perhaps he can build a hash database then look it up later, sort of like how people crack hashed passwords... – kevin May 10 '14 at 17:52