One very delicate subject is how to send data commands over radio or wire, for example.

I know this subject has been rehashed for decades now and "rolling codes" are the norm, or should be at least.

Usually, a data packet is sent over a serial link with a fixed structure, in order :

1. preamble
2. a sequence number
3. data packet type, or other meta-information
4. size field, if the payload is variable
5. payload
6. CRC

Often, a scrambler is applied over the digital signal to spread its spectrum, that is : avoid long runs of constant states.

Each field has a role. Now, let's totally reconsider them and simplify all this !

1. The preamble is optional but for Ethernet for example serves to
   1. syncrhonise the PLL
   2. detect the real beginning of the packet

   In this log, we will consider this framing to be external, we simply deal with a number of bytes that have been handled by the appropriate circuit (might be a simple serial port for example).

2. The sequence number is usually sequential. This it is predictable and monotonous and there, the PEAC generator is ideal.
3. Meta-information is application dependent and not covered
4. Payload size : depends on the framing system.
5. Payload ...
6. CRC field, or checksum : can be replaced by the PEAC checksum.

But wait !

Let's not forget the scrambler : this is another layer that could use the PEAC scrambler.

But wait again !

Why use both a PEAC checksum and a PEAC scrambler ? This is redundant ! (at least for certain cases).

Now let's consider the case of digital radio packets, like your door opener. The airwaves contain all sorts of noises and other transmissions, and this creates all kinds of troubles for the data integrity, authenticity, and many other potential problems. It becomes a combinatorial problem and the receiver must reject any packet that is malformed, yet with minimum complexity. The protocol must not allow packets to be easily forged, not just because of possible intrusions, but also because trivial technical problems (reflections ? repeats ? slight alterations ?) become easier to spot.

From there, a different approach is possible, that differs from the classic one. The scrambler becomes integrated in the process to serve also as checksum. This changes the packet structure a bit :

1. pseudo-random sequence number : ensures that the rest of the packet has more randomness from packet to packet
2. payload (fixed size determined by explicit or implicit framing)
3. constant field : with a size proportional to the desired collision probability

And ... that's it ! Well, almost, because I can't write 0. : the scambler is initialised by a constant that also depends on the packet type. Or canal. Or address... Or whatever you like : change the init value and you get a totally different "world" !

In a radio system with several receivers, those that don't have the appropriate init value will reject the messages. Broadcast messages can be managed at the framing level, with a different size for example, which implies a different init value.

The Pseudo-Random Sequence Number helps because it gets caught in the scrambler, and ensures that the rest of the packet gets mixed even if the data are similar. The PRSN is mixed with a constant init value because it is the first data to be scrambled, so it is almost like it is not mixed and could be precomputed if needed.

The Constant Field is a "known value" that replaces the CRC/Checksum field. This constant gets scrambled with the rest and will catch any error that was propagated by the descrambler. It could even be an address field as well, because any mismatch will cause rejection ! Its size can be as large as both the address field and the checksum field of a classic packet. It can be extended at will to prevent any collision, without increasing the size of the scrambler !

Any new message will seem to vary wildly from the previous, even if very similar data are transmitted. The "init value" might even look like a key but the system is not even remotely considered as cryptographic, it can only fool a superficial observer.

I have made such a system with some basic microcontrollers and HC12 radio modems, based on PEAC16, and the result is very good. It's a great compromise between simplicity (no external library), compactness (only a few simple functions and very little RAM), speed (only some basic operations) and safety. I'd say it is way better than LFSR-based CRC in this context. This is also how I found out that the scrambler must be well designed since the simplest version has avalanche problems.