# Is there any recent cryptographic algorithm especially designed for low-level processors?

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.

-
What kind of algorithm do you need? Symmetric encryption? a hash function? key-exchange? signatures? MAC? Authenticated encryption? –  CodesInChaos Jul 19 '12 at 9:33
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. –  vsz Jul 19 '12 at 9:39
Where does the plaintext come from? Does it get generated by the PC program? –  CodesInChaos Jul 19 '12 at 9:46
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. –  vsz Jul 19 '12 at 9:47
Does the plaintext need to be authenticated? $\:$ –  Ricky Demer Jul 19 '12 at 10:11

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).

-
Concerning the "recent algorithm" aspect, ChaCha seems to be a growing alternative to RC4 suitable for embedded devices. –  WhiteWinterWolf Apr 24 at 14:30