Point I was making is if you have 100 bytes and you block that data every 10 bytes and hash those block and use those 10 block hash's to make the final hash value for those 100 bytes then if you only change data in one block then you would only have to modify that block until you got the same hash for that block knowing that the final hash will be the same.
Now having thought this thru I concluded that if you blocked in a striped fashion every Nth bytes then you could still have the ability to paralise the hashing without compromising security. So in the same example of 100 bytes you would have in block 1 bytes 1,11,21,31,... and in block 2 it would be 2,12,22,32,42... etc. In this way the ability to modify the data/program in a data/program meaningful way and maintain the overall hash would be as hard as hashing the entire lot of 100 bytes.
However having said that a quick look at the skien hash it would appear it uses threefish for its blocking and from what I can tell the aspect of striping the blocks or using contiguase blocks is something that is not defined and down to how it is implemented and in that I suspect they don't strip the data blocks as that appraoch would not be conducive to hashing small communications or rolling data like streamed data were you only know the block of data you have and in that without padding the data you have little scope of breaking it up into procesable blocks as it already is the block size. But that is a issue that stands currently, it is only for example say a fat Linux.ISO say with nice hash check were the approach of striping the data blocks would be benificial to negate the ability to work on just the blocks you are changing to maintain the overall same hash value for the entire file.
I hope that explains the point I was trying to make, nothing to do with cyptoanalysts vs programmers at all. But if programmers don't know about such issues then they will feed the data a block at a time contigiously. I agree that data in and data out is all a programmer should need at API level as anything else is adding the role of cryptographer to a job which is paid at programmer rates.
If I understand what you're saying, it's that a hash defined as e.g. (with b1, b2, ... standing for blocks) H(b1, b2, b3) = H(b1) ^ H(b2) ^ H(b3) is not very secure because it allows one to recover b2 from H(b1, b2, b3), b1 and b3 in time 2^(|b2|) ("2 to the power length-of-b2"). This is obviously true, but no sensible hash function is defined in this way, and I don't think any of the SHA candidates use blocks of a size that can easily be bruteforced.
Just to put this in perspective: SHA1 has a 512 bit block. Nobody is brute forcing 2^512. MD5 has an output size of 128 bits; nobody is brute forcing 2^128 either.
Comments
Point I was making is if you have 100 bytes and you block that data every 10 bytes and hash those block and use those 10 block hash's to make the final hash value for those 100 bytes then if you only change data in one block then you would only have to modify that block until you got the same hash for that block knowing that the final hash will be the same.
Now having thought this thru I concluded that if you blocked in a striped fashion every Nth bytes then you could still have the ability to paralise the hashing without compromising security. So in the same example of 100 bytes you would have in block 1 bytes 1,11,21,31,... and in block 2 it would be 2,12,22,32,42... etc. In this way the ability to modify the data/program in a data/program meaningful way and maintain the overall hash would be as hard as hashing the entire lot of 100 bytes.
However having said that a quick look at the skien hash it would appear it uses threefish for its blocking and from what I can tell the aspect of striping the blocks or using contiguase blocks is something that is not defined and down to how it is implemented and in that I suspect they don't strip the data blocks as that appraoch would not be conducive to hashing small communications or rolling data like streamed data were you only know the block of data you have and in that without padding the data you have little scope of breaking it up into procesable blocks as it already is the block size. But that is a issue that stands currently, it is only for example say a fat Linux.ISO say with nice hash check were the approach of striping the data blocks would be benificial to negate the ability to work on just the blocks you are changing to maintain the overall same hash value for the entire file.
I hope that explains the point I was trying to make, nothing to do with cyptoanalysts vs programmers at all. But if programmers don't know about such issues then they will feed the data a block at a time contigiously. I agree that data in and data out is all a programmer should need at API level as anything else is adding the role of cryptographer to a job which is paid at programmer rates.
If I understand what you're saying, it's that a hash defined as e.g. (with b1, b2, ... standing for blocks) H(b1, b2, b3) = H(b1) ^ H(b2) ^ H(b3) is not very secure because it allows one to recover b2 from H(b1, b2, b3), b1 and b3 in time 2^(|b2|) ("2 to the power length-of-b2"). This is obviously true, but no sensible hash function is defined in this way, and I don't think any of the SHA candidates use blocks of a size that can easily be bruteforced.
Just to put this in perspective: SHA1 has a 512 bit block. Nobody is brute forcing 2^512. MD5 has an output size of 128 bits; nobody is brute forcing 2^128 either.