Encryption for a few bytes ? (with VirtualWire).

Hi,

I use VirtualWire with 433MHz modules to send a few bytes.
Is it possible to encrypt a few bytes ?
I would like to send each time different data, even if the original data was the same.
The data is about 4 to 8 bytes. The encoded messages must also be that short.

I want the messages that short, because I don't want to interfere with RCSwitch transmission. RCSwitch uses repeated messages, so if I keep the VirtualWire message very short and repeat them with a few seconds in between, both transmissions can be used together.

I found this, Arduino Playground - HomePage
But I don't know how to use it.
Modern car keys with 433MHz seems to use 'rolling code'. I guess I need something like that.

Is it possible to encrypt a few bytes ?

yes.

I would like to send each time different data, even if the original data was the same.

make the encryption dependent on time or previous data something like

DataToSend = encrypt(prevData, newData);
prevData = newData;

a simple function can be adding the data per byte (modulo 256)

The data is about 4 to 8 bytes.

you can always pad with empty bytes to get same size datablocks.

I have thought about that.
Using time: I cannot send the time to the remote Arduino. And after a while it is no longer in sync with the main Arduino (the VirtualWire receiver).
Using previous data: If a transmission is missed, all the next transmissions would go wrong.

This has been solved in car keys and other commercial devices, is there a library for it ?

VirtualWire already uses Manchester encoding of the data.
You can add another byte to your message that you increment by 1 with every sending, that will cause the encoding to be slightly different.
On the receive side, just ignore the extra byte.

Erdin:
I have thought about that.
Using time: I cannot send the time to the remote Arduino. And after a while it is no longer in sync with the main Arduino (the VirtualWire receiver).
Using previous data: If a transmission is missed, all the next transmissions would go wrong.

instead of time you can use a random generator on both sides that uses the same seed and uses the next value of the random generator every time.
Still the syncing problem exists, a first order way to solve is to add a CRC of the message so after decryption you can check if the value is valid.
Note that if data received looks valid does not mean the data is valid.

The best way is to use a handshake to make it robust. (like the diff between TCP and UDP, google it if necessary)

A simple handshake is that the master sends a challenge (for which it knows the response) and the slave sends the data encrypted with the response.
e.g. the formula is response = challenge + 10 (this formula is the secret and in reallity more complex).

M->S: 123

S: response = 123 + 10
S->M: senddata = encrypt(data, response)

M: response = 123 + 10
M: data = decrypt(receiveddata, response) // not it knows the formula so it can calc the response

The M and S cannot get out of sync as there will be a new encryption password every time data is requested. It is secure as the formula is secret.
and yes it can be as fast as your CR-formula + encrypt/decrypt function (typical xor)
and yes it can be broken

CrossRoads, I know the encoding, but anyone with an Arduino and VirtualWire can read it. So it is not a real encryption.

robtillaart, That is straightforward, but requires a serious two-way communication. I would like to work with what I have (ATmega8's at 8MHz and Pro Mini clones and Ebay 433MHz modules).

Perhaps I could start with 4 bytes + 2 counting bytes. I can encrypt those 6 bytes with a formula and a key. The receiver decrypts it with the reverse formula and the same key. It can check the counting bytes to see if messages have been missed or if a repeated message is received. I could log the event that a message is missing to a file on an SD card.

Erdin:
I have thought about that.
Using time: I cannot send the time to the remote Arduino. And after a while it is no longer in sync with the main Arduino (the VirtualWire receiver).
Using previous data: If a transmission is missed, all the next transmissions would go wrong.

This has been solved in car keys and other commercial devices, is there a library for it ?

I did something similar in a remote control for an electric garage door:

Don't know what to call it but it's a rolling code with a window of valid codes to allow some missed transmission without going out of sync.

Thanks!
Nice to see a finished project combining all that.

So if you click the transmitter 50 times while being out of range, you have to pair it with the receiver again.
Perhaps I will select a simpler encryption, to make it fit in an ATmega8.

Your baudrate of 200 for VirtualWire is slow. I read the a value below 1000 does not increase the range.

You start to sleep after an EEPROM write without an delay to let the EEPROM finish.
I read that could be a problem somehow, making the avr chip not going into sleep.

Thanks,
It has been running on AA batteries for a year now so I'm pretty sure the sleep works. I'll try to remember adding a delay before going to sleep just to be sure if when/if update the code again.

Where did you read that the range doesn't improve below 1000bps?
The baud rate isn't critical in my case so I used a very slow rate just to be sure because I hadn't seen any specifications about baud rate/range/reliability.
It takes about a second for the transmitter to send the bytes and for the receiver to hash a number and compare the hashes.
The MD5 algorithm is not that fast so it takes a bit longer when the sequence is out of sync and the receiver must hash several numbers before it finds a match.
These speeds could be improved if the receiver calculated the next 50 or so hashes in advance so that it only has to match the hashes once it receives a hash from the transmitter.

The pdf document at the bottom of the page writes about the range.
http://www.airspayce.com/mikem/arduino/

I was my understanding that the cheap Ebay modules are not good with high baud rates. The receiver has a filter, so 4000 baud would be too high. Between 1000 and 2000 would be best for those modules as far as I know.

For what I know, if the modules can keep up with the baudrate, it has no use to make the baudrate lower.

Suppose the receiver and transmitter have good antennas and both can do very high frequencies. Why would the range be different with a higher baudrate ? Only when the 433MHz gets disturbed by the modulation.

It doesn't say that range isn't improved below 1000bps, it just doesn't show any more test results below 1000bps.
And besides that it doesn't actually show that there are no difference between 1000bps and 2000bps either. It just lists them both as being >150m which doesn't necessarily mean that they are equal.
The tests made by the author applies to the modules he tested with and it doesn't necessarily mean that all cheap eBay modules have the same characteristics.

Erdin:
For what I know, if the modules can keep up with the baudrate, it has no use to make the baudrate lower.

Suppose the receiver and transmitter have good antennas and both can do very high frequencies. Why would the range be different with a higher baudrate ? Only when the 433MHz gets disturbed by the modulation.

You may be right but why is there a difference in range between 2000bps and 5000bps in that PDF when it works fine at speeds up to 7000bps in the authors tests?
I don't know if they get more sensitive to interference at higher rates or something but the tests show that the range is better at lower speeds.

Well, it is a lot of guessing and assuming :cold_sweat:

I use 2000 for baudrate myself, because I want my messages to be very short. The range is okay for me with a piece of wire as antenna and 5V power for transmitter.
There is a schematic of those very cheap Ebay 433MHz modules. I can't find it right now. It filters high frequencies with 1 capacitor as far as I can remember. That would explain that 7000 still works.

I know this is an old post. But just to add to the knowledge base. One can use Keeloq library for encryption. I have used it for one of my projects and it works perfectly fine.

For an example sketch Please see

Hope this helps someone! :slight_smile:

is keeloq NSA proof ? :slight_smile:

I don't know about it being NSA proof :P. But in the encrypted communications, I tend to send one key randomly generated (either Key_High or Key_Low) along with the message. The other key is known at both ends. Since the random key transmitted changes every time. It is difficult to predict unless one knows the exact key stored at both ends.

To decrypt one needs both keys making it cool enough for encrypted communication between 8-bit uCs.

Now robustness of this depends on guessing the stored key right or generating the random sequence correctly :slight_smile: