[ozzmotik]

>we can find another string that differs in one byte only, that has the target crc

reading that has me curious; if one can do that for any arbitrary string, and then iterate that process, doesn't that stand to reason that with enough work, one could make any two given strings calculate out to the same crc? I guess maybe not because that one byte constraint isn't specified as far as where it occurs and whether it's an insertion, deletion, permutation etc, but the way I see it if you can do it with one string to another, you could likely keep chaining that indefinitely and get countless strings that come to the same crc.

sorry if this is old news or anything I was just struck by that thought while reading your comment

[cryptonector]

At Sun we had a server with a flaky NIC with very high error rates, but worse, occasionally would introduce two one-bit errors in packets such that all the CRCs involved were defeated. This actually caused some version control history corruption. I forget the details though. Maybe some other ex-Sun'er can chime in with the details.

[dfox]

The amount of bits you need to modify is not “one byte” but the same as the degree of used polynomial.

And producing two strings with same CRC is trivial to the extent that it is how you are originally supposed to use the algorithm. Notice that CRC-32 of every valid ISO9660 filesystem is 0xffffffff ;)

[enedil]

Yes, sorry for the lack of scrupulosity. Of course, it might happen it suffices to change one byte, especially that this byte can be at any position.

[enedil]

It can be done with any byte. In CRC, you encode your input to a polynomial somehow, take an agreed-upon polynomial (dependent on the type of CRC, not the input data) - call it P. Compute the remainder of the input when divided by P, encode it, and that's CRC. So to get any desired CRC, you just need to solve a linear equation (in quite a lot variables, but it doesn't really matter). All in all, it's really easy.