Mangled CRC8 is superior to SHA-1??

[globa...@gmail.com]

I read about a new security device from Intersil on EETimes which
makes a preposterous claim about it's algorithm's superiority to
SHA-1. I checked all the major advisories to see if they had
anything about it yet, but I couldn't find anything relevant.

The device, known as the FlexiHash for Battery Pack Authentication,
uses a proprietary CRC8 algorithm... In there algorithm, they shift
an XOR and an XNOR around in the CRC8 to generate a mangled result
based on a secret. I have to say that I wasn't very impressed. But,
their website actually claims that it is "Superior to SHA-1", which I
found quite interesting.

Looks a bit like snake oil and i was just wondering if any security
folk were taking a look at it.

http://www.intersil.com/cda/deviceinfo/0,0,ISL6296,0.html

You can find a full C source code implementation of their algorithm
at the above link.

Scott Hughes

[Gregory G Rose]

In article <1116092944....@z14g2000cwz.googlegroups.com>,

globa...@gmail.com <globa...@gmail.com> wrote:
>I read about a new security device from Intersil on EETimes which
>makes a preposterous claim about it's algorithm's superiority to
>SHA-1. I checked all the major advisories to see if they had
>anything about it yet, but I couldn't find anything relevant.

Well, it can't really be superior to SHA-1, its
inputs and outputs are too small.

>http://www.intersil.com/cda/deviceinfo/0,0,ISL6296,0.html

This looks like "low-hanging fruit" to me... good
for someone to cut their teeth on.

The fact that they use the two parts of the 64-bit
key in completely different ways is pretty much a
giveaway that there will be a divide-and-conquer
attack of order 2^32 where you guess one of them,
and solve for the other, given enough
challenge-response pairs. The "M" variable is the
one to guess, I think, because all the
complications come from it; the configuration of
the connections between the registers and the CRC
polynomials are the only non-linear parts. I'm
pretty sure that given a guess for M, you can
solve linear equations to recover N (or determine
that it can't exist, so try another M).

I'll also note that there are many terrible
choices for the value of "M". For each byte of
it, if the bits 2..0 are equal to the bits 5..3
(probability 1/8 if M is selected randomly), the
unknown CRC taps cancel out and it degenerates to
a rotation of its input. In fact, if I've
understood their flow charts and diagrams
correctly, there's a set of M key values
({MA..Md} = 0x004080C0 is one) for which the
output is always zero, independent of the N key
or the challenge.

I'd call it, and its claim, snake oil.

Greg.
--
Greg Rose
232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Qualcomm Australia: http://www.qualcomm.com.au

[Gregory G Rose]

In article <d65kiu$q...@qualcomm.com>, Gregory G Rose <g...@qualcomm.com> wrote:
>I'll also note that there are many terrible
>choices for the value of "M". For each byte of
>it, if the bits 2..0 are equal to the bits 5..3
>(probability 1/8 if M is selected randomly), the
>unknown CRC taps cancel out and it degenerates to
>a rotation of its input. In fact, if I've
>understood their flow charts and diagrams
>correctly, there's a set of M key values
>({MA..Md} = 0x004080C0 is one) for which the
>output is always zero, independent of the N key
>or the challenge.

Oops, I overlooked something when the 4
byte-sized CRCs are XORed, there are rotations
there. Instead of always being zero, it will
always be a constant (and simple) function of the input. I'll
leave the details to the student...

[globa...@gmail.com]

I accidentally stumbled upon this "constant" function. I compiled
their sample source code to play with and I used a couple of randomly
generated secrets and noticed that, regardless of the input, the output
was always the same. At first, I thought it was a bug in the source
code. But your explanation analysis is much better than my
"ghetto-stepping-through-the-source".

Scott Hughes