Say I have strings: stringA, StringB, stringC.
And I make two hashes: HashA = sha256(stringA + stringB) HashB = sha256(stringB + stringC)
For the sake of the argument I'm suggesting sha256 but answering the question generically is just as good.
I'm not a strong mathematician, but suppose I were, and am trying to reverse the above hashes, and knew from an algorithm in code that there is a stringB (still unknown to me) that is the later part of the string going into HashA and the earlier part of HashB.
Can I reduce the number of permutations required, in order to figure out what stringB might have been, since in order for the two hashes to give the answers they do, from overlapping input, should it not reduce the input-space I need to bruteforce?
i.e. are the hashes weaker because of this behaviour of having the data within them overlap.
For clarity: If stringA, stringB, stringC, and stringD are secrets.
And an attacker gets all the code / algorthm etc except for the strings, and has:
case A: hashA=sha256(stringA+stringB) and hashB=(stringB+stringC)
or case B: hashC=sha256(stringA+stringB) and hashD=(stringC+stringD)
I have a suspicion that in case A it's easier to construct source data to match the hashes than in caseB, but I don't know enough maths to back up my suspicion.
Further clarity: Assume the strings are salted, though with the same salt per record and hashes for that record, and that the attacker knows the salts. The salts can be assumed prepended before the 'stringx+stringY' throughtout my text if you like.