John Payson wrote:
>
>
> Hmm... I'd think a 16F84 both places would probably be a better choice.
> You don't want your transmitters to go dead when you switch batteries,
> after all, and the memory of the 12C5xx is rather limitted.
>
> Also, since I've not looked in detail at the Keeloq systems I have no idea
> what claims their patents make.  I do know that the method[2] I described
> has been published for quite some time in the computer/networking world.


   I choose the 12C5XX because of its small pin count.  I'll be
modifying an existing remote transmitter so a 8 pin IC is better
than a 18 pin.  I think 1K of code is plenty (I hope anyway) for
what I'll be doing.

>
> There are a number of good hash functions in the mathematical and computer
> science literature.  I do *not*, off hand, remember any in sufficient
> detail to implement them and would not presume that any which I could
> invent would be even remotely strong against cryptographic attack.
>
> Note that your requirement (the 50% probability one) is necessary to a
> good cryptographic hash, but is not at all sufficient.  Many popular hash
> functions (such as CRC) pass your 50% test (as well as more stringent
> statistcal tests) with flying colors and yet are woefully inadequate for
> cryptography.
>
> While I don't have complete specs for any good has functions, one which
> you might consider would be a variation on the Unix password encode
> function:
>
>   If h[n] is the n'th hash function, compute h[n+1] by
>     h[n+1] = DES(DES(DES(0x0001000100010001 * n, h[n]), h[n]), h[n])
>         [use the low 40 or 56 bits]
>
> where DES(x,y) is the result of encrypting text 'x' with key 'y'.  Note
> that DES is probably a little slow to compute on the PIC (you *DON'T* want
> to have the PIC compute h[65536] if you can have a PC pre-compute it!) but
> I don't know of anything easier to compute which would not be weaker.


   Thanks for the hint.  Forgive me for sounding like an idiot, but
without knowing the algorithm of DES(), I'm afraid I don't follow
you.  How does having the PC pre-compute h[65536] help the PIC?  Are
you referring to the fact that 65536 might be too big of a number
for the PIC to handle or are you inferring that h[n] for all n < 65536
can be derived, without much computation, from h[65536]?
   This is really interesting.  I'll do more reaserch on PKC on
www.rsa.com?

Thanks

Andy
-----------
bikejog@bellatlantic.net
http://www.mcs.drexel.edu/~uachang