National Semiconductor 48-bit and 56-bit ECC polynomials

dwight dkelvey at
Thu Nov 17 16:59:46 CST 2016

Do you have working hardware?

A lot can be deduced by using simple data, like all 0's

and different data lengths.


From: cctalk <cctalk-bounces at> on behalf of Eric Smith <spacewar at>
Sent: Thursday, November 17, 2016 2:33:36 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: National Semiconductor 48-bit and 56-bit ECC polynomials

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

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.

More information about the cctech mailing list