11

Looking for recommendations and some reference code for encrypting byte array in C. The problem is that I have to fit into 1KByte memory along with other routines and MCU is only 8MHz. So the size and speed is the key. I've checked Rijndael but it has huge tables for my MCU. Basically I am going to encrypt intel hex format on PC, probably only data area, then decrypt in MCU.

Using dynamic memory allocation routines is not desirable.

My google search brings me all to C# implementations, using libraries.

UPDATE:

decryption side constraints:

RAM: 512 byte
MAX code size: 512-1024 words
CPU: 8 bit, 8MHz
Pablo
  • 28,133
  • 34
  • 125
  • 215
  • would you like to use `XOR`, more commonly use in Polymorphic Malware encryption. Its just an idea! – Grijesh Chauhan Jan 03 '13 at 10:43
  • 2
    @GrijeshChauhan : XOR is not an encryption method unless you use it as one time pad. – Kris Jan 03 '13 at 15:49
  • Tables are normally not an issue, as long as they contain constants. Constants may be stored in persistent memory (ROM, EEPROM, Flash) instead of RAM. The only part that needs to be stored in RAM is the *state*. There is no such thing as "hex format" within cryptography, only binary data. Hex(adecimals) is a representation using an [tag:encoding] in characters of that binary data. Seems like nitpicking, but if you don't get this right you *will* run into trouble. – Maarten Bodewes Jan 03 '13 at 16:03
  • @owlstead: There is [Intel HEX format](http://en.wikipedia.org/wiki/Intel_HEX) I was talking about. I mentioned that in case there will be some ideas based on that data format. This program will run from Bootloader area of the Flash and program the rest of Flash chip AND EEPROM. The Bootloader is limited with 512-1024 words. I don't have anywhere else to store those tables, hence it IS an issue. I am very well aware of hexadecimal representation and encoding, thanks. – Pablo Jan 03 '13 at 16:09
  • OK, so please make sure that your question contains both the persistent and transient memory limitations. Please perform your encryption/decryption on the data before storing it in the Intel HEX encoded file - the format of the file itself should be inconsequential. – Maarten Bodewes Jan 03 '13 at 16:17
  • @owlstead: the original data is in Intel HEX format, so I have to read data area, convert it to byte array, perform encoding, put it back to intel hex format, adjust checksum and send over to device bootloader. So I will encrypt/decrypt only chunks of data. This should give some error checking and I could retransmit data in case of chunk is corrupted. Device buffer(RAM) is not that big to hold all data at once. But I am open to any other methods. – Pablo Jan 03 '13 at 16:20
  • That is fine. Decode HEX, encrypt, re-encode into HEX, no problem. Symmetric encryption is oblivious to the format, it operates on binary data, and returns binary data. Encoding/decoding is outside scope of the cryptographic algorithm. – Maarten Bodewes Jan 03 '13 at 16:22

4 Answers4

14

A very simple encryption algorithm that I saw being used in the embedded world is XXTEA

sellibitze
  • 27,611
  • 3
  • 75
  • 95
  • I've just tried XXTEA and looks pretty fast and tiny. If nothing better comes out I will go for it and accept this answer. – Pablo Jan 03 '13 at 11:47
  • I used XTEA (the precursor of XXTEA) in a bootloader and it's really easy to implement, fast and with a small footprint. And XTEA/XXTEA should be secure enough for a cheap product. I can recommend it. – jeb Jan 03 '13 at 17:53
4

All the tables in Rijndael are defined as simplish operations in GF2. As such, I'd be tempted to say it's possible to write eg. 128-bit AES in 1k.

See also: https://electronics.stackexchange.com/questions/13275/smallest-aes-implementation-for-microcontrollers

But any chosen algorithm is a minor factor in security eg. if the key is distributed with the binary. In that case, the simplest mechanism to unveil the original binary is to run the code through emulator and store the memory.

Community
  • 1
  • 1
Aki Suihkonen
  • 19,144
  • 1
  • 36
  • 57
  • +1 for the link and suggestion. The key is not distributed but it's in bootrom of device itself, which is hard to break(but possible). Decryption should run from bootrom. – Pablo Jan 03 '13 at 15:59
0

Have a look at my mofified version of XTEA I called Simple Tea:

#include <avr/io.h>
#include "simple_tea.h"

uint8_t secret_data[] = {0xFE, 0x67};
SimpleTEA<sizeof(secret_data) / 2> tea;

int main()
{

    unsigned int rounds{16};
    uint8_t key[] = {0x45, 0x74, 0x32, 0x11, 0x98, 0x94, 0xAB, 0xCF, 0x90, 0xAE, 0xBA, 0xDC, 0x06, 0x16, 0x81, 0x95};

    secret_data[0] = PINB;
    tea.encrypt(rounds, secret_data, key);
    if (secret_data[0] & (PINB))
    {
        PORTC = 0x05;
    }
    secret_data[1] = PINB & (1 << 2);
    tea.decrypt(rounds, secret_data, key);
    if (secret_data[0] & (PINB))
    {
        PORTC = 0x50;
    }
}

produces <250 bytes of opcode on AVR (the ifs here are only needed to avoid the compiler optimizing the encrypt and decrypt out completely):

➜  Encryption git:(master) ✗ avr-gcc -std=c++17  -Os -mmcu=atmega328p  main.cpp -o main
➜  Encryption git:(master) ✗ avr-size main                                             
   text    data     bss     dec     hex filename
    214       2       1     217      d9 main
➜  Encryption git:(master) ✗ avr-nm --size-sort -C -r --radix=d main
00000044 T main
00000022 T __do_copy_data
00000016 T __do_clear_bss
00000002 D secret_data
00000001 B tea
Mihai Galos
  • 1,707
  • 1
  • 19
  • 38
-1

I have read that Elliptic curve crypto (ECC) is the new thing intended to bring strong crypto to tiny processors.

A Google of:
elliptic curve cryptography microcontrollers
yields discussion of implementations on 8-bit micros at the top of the list.

But maybe consider moving to Stack Exchange. For example, this may be useful:

Stack Exchange Crypto - Types of Cryptography for a 4-8 bit microcontroller

Community
  • 1
  • 1
jdr5ca
  • 2,809
  • 14
  • 25
  • 2
    You wouldn't use ECC for encryption by itself. You use it as key-exchange mechanism together with symmetrical encryption. The OP gave no indication that he needs asymmetry. – CodesInChaos Jan 05 '13 at 09:15