> On Nov 17, 2016, at 5:33 PM, Eric Smith <space...@gmail.com> wrote:
>
> I'm not looking forward to trying to reverse-engineer 48-bit and 56-bit ECC
> polynomials. However, they usually tried to choose polynomials with
> relatively few terms, to minimize the number of XOR gates needed in the
> hardware.
>
> The common "Glover" 32-bit polynomial was:
> x^32 + x^28 + x^26 + x^19 + x^17 + x^10 + x^6 + x^2 + x^0
>
> WD's 56-bit polynomial was
> x^56 + x^52 + x^50 + x^43 + x^41 + x^34 + x^30 + x^26 + x^24 + x^8 + x^0
>
> Assuming that National's 56-bit polynomials don't use any fewer terms than
> the 32-bit, nor any more terms than the WD 56-bit, there are not quite 8
> billion possibilities to brute-force. x^n and x^0 are always used, so the
> size of the search space is comb(55,9) + comb(55,8) + comb(55, 7). That
> would take to long to brute-force search in software on a general purpose
> CPU, so I think I'd have to code it for a GPU or FPGA.
>
> There might be some other short-cuts to reducing the search space, but I
> haven't yet given it a lot of thought.
I don't know enough math to do the work, but a little rubbed off from listening
to those who do.
CRC polynomials have special properties, they aren't arbitrary polynomials.
That reduces the number of possible choices dramatically. In fact, I remember
that finding a good one is hard work; a mathematician at DEC who specializes in
this stuff spend a big chunk of time (weeks if not months) finding a 64 bit CRC
polynomial that was proposed for the HPPI high speed channel standard. (I
don't remember if it was adopted, but some technical details do exist.)
The other key property of CRCs is that they are linear functions. This is why
you can compute the change to the CRC for a given data change easily -- which
means that a CRC is never useable as a cryptographic data integrity code, even
though WEP abused it that way. I would assume this means you can deduce the
CRC polynomial by straightforward math from a few well chosen test data blocks.
Not sure which ones; perhaps all zeroes plus single bit set at each of <width>
different bit offsets.
In other words, exhaustive search, which would be somewhat painful though
obviously doable these days, should not be needed.
paul
