Hello all, This is the deal: 2 identical controllers of type C167CS. The requirement is that one product cannot be used without the other, so I devised a simple authentication protocol:
R(n) = ( (A * R(n-1) + C) mod M)
is computed on both products, where R(n) is an 32 bit integer, and A = 1366, C = 150889, M = 714025 the seed R(n-1) is selected by assigning the clock value to it. The clock value is added or subtracted from the constants A, C and M depending if it is add or not. One product sends the clock value and the selected offset over a CAN bus and the other reconstructs the answer and sends it back. If the answers match - product is authenticated. I wrote the code about 2 weeks ago, tested it and checked in. But today, the same code did not function anymore. I managed to get it to work, but only after making the following modifications: * working with constants that limit the range of the intermediate results to 16 bit width. * remove the modulus operator.
I also encounter problems with comparing two 32 bit integers. I had to compare these numbers in 2 stages, 16 bits each. I admit that I did not thoroughly check the generated assembly. Can you offer an explanation? How come it worked over the course of several hours and then - not anymore? (for clarity: the product's answers did not agree anymore). Are all the assumptions of all moderns computing false :-) ?
Hans, Thanks for your reply. I will try answer all you comments:
You're aware that whatever security by obscurity your little protocol might have had is null and void now that you've posted it here, right?
as long as you know anything about the product (maybe it a a washing machine that can dial a mobile :-) ) - it's cool...
You're not making terribly much sense there. What do you use that "clock" for: the (inappropriately named) R(n-1), or for fudging the parameters? Or were you actually telling us that you used this same number for both things? If you were, that can't be good.
the seen, or R(n-1), is assigned the clock value.
One product sends the clock value and the selected offset
here I meant that the product that requires the presence of the other sens 2 bytes over the CAN bus: the seed or R(n-1), and another number which is used to decrease or increase the constants value. I thought it would make the entire thing a little less predictable. the clock is the processor clock, which ticks at 12MHz.
Possibly because your implementation can't handle large values of that "clock" of yours, but your original tests didn't run long enough to reach sufficiently large numbers. I don't this is the case as the authentication occurs immediately after startup. This used to work without a problem when the data types involved with "unsigned long" and the constants were much larger.
Since you failed to show any actual source code I'll have to guess: you implicitly expected computations on 16-bit numbers to yield a 32-bit result. Well, sorry, C doesn't work that way. as I stated, all the variables involved were 32 bit wide.
Any ideas?
I meant of course: as long as you know nothing about...
I thought it would make the entire thing a little less predictable.
Sorry, but that's not gonna do. I think it was Knuth himself who stated that pseudo-randomly designing a pseudo-random number generator (which is what you're doing) has a negligible probability of yielding a good one.