On Fri, 27 Jun 2003 10:29:00 +0200, Michael Hofmann
<westbound@gmx.net> wrote:

For lower security, you could just use a fixed code. Rolling code
requires that the transmitter and receiver have non-volatile memory to
maintain a state counter. A fixed code does not require non-volatile
memory, and is therefore easier to implement.

Basically, a rolling code can be made out of any encryption algorithm.
The transmitter encrypts the current state count and sends it. The
receiver decrypts the count. If it is in sequence with what was sent
before, or nearly so, it unlocks the door.

One of the practical problems that any rolling code implementation
needs to address is failure of syncronization. If the transmitter
button is pressed when it is out of range of the receiver, then the
transmitter state counter gets advanced while the receiver does not.
(This is especially a problem when kids play with Daddy's garage door
opener on a cross-country trip. By the time they get home, the
transmitter and receiver can be out of sync by a large amount.) In
addition to defining an acceptance window of maybe 16 counts into the
future, the receiver also recogizes two successive transmissions with
sequential counts to resyncronize to practically anywhere.

If you still want to implement a rolling code, then I suggest you
forget about the Microchip algorithm and use something like Skipjack.
It was once part of the Clipper Chip initiative, but has since been
declassified and info is available on the net. Skipjack is
well-suited to small microcontroller implementations.
-Robert Scott
Ypsilanti, Michigan
(Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

Robert Scott wrote:
Fixcode only IMHO is too easy to compromise. I'd like to employ at least
some sort of alternating code.

I am familiar with this as I used to be part of a remote keyless entry
SW group a few years ago. It's just that I never dealt directly with the
encryption algorithms.

Thanks for the pointer. The Skipjack algorithm specification is a bit
over my head, I was hoping for a simpler explanation, but it's a start :-)

Michael

On Fri, 27 Jun 2003 11:56:18 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:

I don't know. It seems that the major investment for an attacker is
putting together a receiver and a recording device. Once you have
that, it is not much harder to record 20 events than to record one
event. And if you suspect they are using a LFSR, it really takes very
few events to determine the taps on the LFSR. Someone could explore
the possibilities off-line using software at their leisure, then come
back days later and break in.

-Robert Scott
Ypsilanti, Michigan
(Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

Robert Scott wrote:
Ok, you gave me a recorder and I got the following results...


0 216D
1 50CA
2 B085
3 611B
4 D026
5 A14C
6 5180
7 B001
8 6102
9 C014
10 8138
11 1160
12 20C0
13 4081
14 8013
15 0136
16 006C
17 10D8
18 30B1
19 6063

BTW, recording this cost you a bunch of bucks since the code is only
used once a day and I had to record it over nearly a month.

I understand your point, but if you are going to get past such an
operation, recording the transmission is the first step and will have to
be done for *any* of the security methods. It really is not a big deal
since the data rates are typically pretty low. If you want, I can sell
you some gear...

But to crack a code, the first thing you have to do is figure out what
code it is. Even the low tech codes provide a reasonable amount of
security since there are so many to choose from. For example, you don't
know if the sequence above is an LFSR, or if it is something subtly
different. You tell me. And don't forget there may be reception bit
errors...

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3EFC958F.D0EE4EFA@yahoo.com...
Only 16 bits, just use brute force.

Ralph

Ralph Mason wrote:
Please show me...

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

You can't use brute force. Even the most simple systems usually require
some time delay between succesive code attempts, and definitely after 2
or 3 failed sequences most will shut down for a period.

Al

Ralph Mason wrote:

On Fri, 27 Jun 2003 15:05:51 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:

You are not seriously questioning the fact that LFSRs are crackable
with this few number of samples are you? But I understand your point
that unless I know it is an LFSR, I'm not likely to even try to crack
it. Certainly for one person making a homemade rolling code scheme,
this is adequate security. But as long as you are going to the
trouble to make any such system at all, why not use some real
encryption? There are encryption algorithms that are not much harder
to implement than an LFSR. See Schneier, "Applied Cryptography" for
examples.


For a one-of-a-kind homemade system, this is a real problem for the
attacker. But if anything is mass-produced, then you have to assume
that the bad guys will find out, one way or another, what the code is.
They will be able to amortize their initial efforts over many cracked
systems.


-Robert Scott
Ypsilanti, Michigan
(Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

On Sun, 29 Jun 2003 14:56:56 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:

Right now the incentive is not high enough for anyone here to bother.
I know that 20 samples is enough to crack a 16-bit LFSR, and if I were
using it to break into your garage, maybe I would get enough
merchandise to make it worthwhile.


-Robert Scott
Ypsilanti, Michigan
(Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

Hi, Rick & all -

Your example code sequence appears on cursory inspection to have the bytes
swapped and the nybbles swapped within them. The lower 13 bits are used.
That's by looking at the first few entries; a simple C program can verify
or correct that. Still less obvious than simpler codes, as you say.

Great discussion, folks - I've been learning a lot. Thanks!

Jim Horn, WB9SYN/6

James Horn wrote:
Good job. I figured I would toss it out there and see if anyone felt
strongly enought to crack it. I agree that it is not hard to do. My
only point is that it is another step beyond just recording a fixed code
and the fact that it took several days for anyone to get around to doing
it proves my point.

How did you determine this? Did you just look at the movement of the
bits from one sample to the next? I expect swapping the bits more
randomly would have made this a bit harder, but not a lot. I have seen
software that can do a good job of showing patterns in the data like
this. Once you see the pattern you can see the extra three bits are
doing nothing which gives you the LFSR size. Then it is not hard to get
the taps. I expect a formula can be found for finding the taps.
Manually you could use something like a Karnaugh map.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX