I need to encrypt transmission between my device (with AVR processor) and base. I create packet data - it will be encrypted into string:

PacketData {
  int packetN;
  string data;
  CRC16 checksum;
  string nextKey;

As you can see, key will be changing after each packet.

First, I tried to use XOR encryption, but I forgot that if attacker know plaintext, all encryption will be without sense.

Now, I have an idea - first, use RC4 on data with key, and XOR result with same key. I see bad side of this solution - key will be same for both operations, and I want key length ~64 bits. Handshake will be written on device (8 characters), and connection will be made when base sends encrypted packet with handshake. Also, data size will be usually between 4 and 32 bytes, sometimes more.

Is this encryption give me sufficient safety? After reading about RC4 in WPA, I see that is problem in WPA implementation. Maybe I should use (when connected) two keys, for RC4 and XOR, both sended in encrypted packet?

Please, tell me what do you think about it. It must be light solution (because tiny processor) so I can't use AES. My solution is right?

  • $\begingroup$ First, AES is really not very demanding on hardware, so unless you verified that it doesn't work on your exact hardware I'd take another look at it. Second, why not just use RC4? Why add in an XOR with the key? $\endgroup$
    – cpast
    Jan 21 '15 at 15:37
  • 2
    $\begingroup$ Incidentally, you probably won't want 64 bit keys; those are a bit too short for comfort. $\endgroup$
    – cpast
    Jan 21 '15 at 15:56
  • 3
    $\begingroup$ If you haven't tried AES, I'd highly recommend trying it; the limit on code size is actually the only possible issue I see, but there are small implementations of AES available (embedded system performance was a requirement of AES candidates). Otherwise, I'd still strongly caution against combining a Vigenere cipher and RC4 - combining two insecure systems normally doesn't result in a secure system. $\endgroup$
    – cpast
    Jan 21 '15 at 16:10
  • 3
    $\begingroup$ This isn't authenticated (a CRC16 is nowhere near strong enough to prevent someone from even just trying all possible values for a packet), so an attacker can almost assuredly flip arbitrary bits at will. $\endgroup$ Jan 21 '15 at 16:42
  • 1
    $\begingroup$ For AVR specifically, this page seems to have an AES implementation with code size of 1570 bytes and encryption at ~93.5 kB/sec (decryption is only 71.5 kB/sec, but you'd be decrypting on the base station). Would that be too big for your needs? $\endgroup$
    – cpast
    Jan 21 '15 at 17:36

Disclaimer: the only reason to go this way is if you have an 8 bit CPU. Otherwise, select AES.

Sending nextKey in the data packet is silly. What you want is key + iv. Look up the CipherSaber 2 variant of RC4. This covers the attack used on WEP just fine. Bear in mind though this wants a good RNG (probably hardware RNG) and 10 bytes of iv. Unless you can store the iv counter, there's no good way to reduce it. There are other possible attacks on RC4 though, the most worrying is the one that can be used against 1 billion messages to reveal the first 128 bytes of message. A plausible workaround is simply eating the first 256 bytes off the stream (don't bother sending just discard).

Your key length here won't be 64 bits though. That's too small. You need at least 128 bits.

We do have to keep in mind that RC4 and all its variants are weakening. There is simply no good explanation for the fact it is as strong as it is today. It really should not be. The next attack might doom it.

EDIT: Answer no longer good. A recently published attack against RC4 is no longer mitigated by the CS2 variant. I was not expecting this.

  • 5
    $\begingroup$ AES works fine on 8-bit CPUs. That was an explicit design goal. $\endgroup$
    – cpast
    Jan 21 '15 at 17:34
  • $\begingroup$ Hm, thanks for explaination, seems that I must use AES for good privacy, RC4 is too weak, eh. $\endgroup$
    – aso
    Jan 22 '15 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.