4
$\begingroup$

Most modern algorithms require relatively large amount of resources. Is there any recent (and freely usable) encryption/decryption algorithm which is specially designed for low-level microcontrollers in mind? This means it has to run fast, (on a very simple, 8 or 16 bit, 10-20 MHz processor), be small (few hundred bytes to few kilobytes) and use as little RAM as possible.

The key is "modern" because if I took something designed in the 1970's (which would satisfy the requirements for a simple and low-level processor) it might have big security vulnerabilities.

If only the decryption part satisfies the requirements, it's also enough.

$\endgroup$
10
  • $\begingroup$ What kind of algorithm do you need? Symmetric encryption? a hash function? key-exchange? signatures? MAC? Authenticated encryption? $\endgroup$ Commented Jul 19, 2012 at 9:33
  • $\begingroup$ It doesn't have to be symmetric. I intend to have a PC program send a file to a microcontroller, but the user of that PC program should not be able to access the data in that file or edit its contents in a meaningful way. I intend to place the decryption part into the microcontroller, to deny the possibility to read the data by tapping the wire between it and the PC. $\endgroup$
    – vsz
    Commented Jul 19, 2012 at 9:39
  • $\begingroup$ Where does the plaintext come from? Does it get generated by the PC program? $\endgroup$ Commented Jul 19, 2012 at 9:46
  • $\begingroup$ No. The plaintext is generated at a time and place inaccessible to the user of the PC program, so it can be released already encrypted. $\endgroup$
    – vsz
    Commented Jul 19, 2012 at 9:47
  • $\begingroup$ Does the plaintext need to be authenticated? $\:$ $\endgroup$
    – user991
    Commented Jul 19, 2012 at 10:11

2 Answers 2

6
$\begingroup$

In the context, one option would be AES in CTR mode with the XOR between ciphertext and keystream on the PC side (saving most of the bandwidth in the PC to Low-level processor direction). CTR mode allows direct access to any portion of the plaintext. AES is easy to implement on an 8-bit CPU, reasonably fast, and low on resources. As a bonus, protecting AES against side-channel attacks is well studied (although the weakest point likely will be different: obtaining the whole plaintext or keystream once, and storing that).

If AES is not fast enough, and about 260 bytes of RAM are available, and the plaintext can be divided into relatively large blocks (like 1024 bytes or more), and we replace recent by tried and tested, there is RC4 with an appropriate key setup (e.g. append 32-byte key to 8-byte block address, use that as the RC4 key, discard the first 256 bytes produced by RC4).

Update: beware that both methods allow the user to change bits of plaintext just by flipping the corresponding bits of ciphertext; see that other answer if the integrity of plaintext is required (this also requires assuming the program on the PC is not altered).

$\endgroup$
1
  • $\begingroup$ Concerning the "recent algorithm" aspect, ChaCha seems to be a growing alternative to RC4 suitable for embedded devices. $\endgroup$ Commented Apr 24, 2015 at 14:30
5
$\begingroup$

In the comments, you write:

"I intend to have a PC program send a file to a microcontroller, but the user of that PC program should not be able to access the data in that file or edit its contents in a meaningful way. I intend to place the decryption part into the microcontroller, to deny the possibility to read the data by tapping the wire between it and the PC."

To accomplish that, what you want is an authenticated encryption (AE) scheme, which is a type of symmetric encryption scheme that also protects the message against modification. To implement such a scheme, you basically have two options:

  1. use a purpose-built AE scheme such as OCB, EAX or GCM, or
  2. combine a standard non-authenticated block cipher mode such as CBC or CTR (or a stream cipher) with a message authentication code using the Encrypt-then-MAC construction.

In either case, you will typically need a block cipher such as AES as the fundamental building block upon which these schemes are based. (This is not strictly true — for instance, you could combine a dedicated stream cipher like RC4 or Trivium with a non-cipher-based MAC such as HMAC — but most AE schemes are indeed based at least partially on block ciphers.)

As fgrieu notes, AES is a good choice for a block cipher: it's modern, extensively studied, pretty well suited for the task, and it's very likely that a secure implementation of it already exists for your microcontroller. Besides, AES is as close to the universally accepted standard cipher as there currently is: nobody's going to get fired for using AES.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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