Favorite cipher for uC implementation

[Harvs]

Anyone like to share what cipher(s) they find is particularly suitable for implementing on microcontrollers for "low speed" comms or file storage?

Personally I'm most interested in anything that would be suitable for CM0 to CM4 with >=4k RAM.

Bonus points if it's already got C implementations, and even better if it's also already implemented in higher level PC languages (e.g. Java/C# etc.)

No I don't have a specific application I'm working on, I'm just interested for future projects...

Edit: spelling corrected...

[Balaur]

s/cyper/cipher/g ?

[jeremy]

A bunch of micros have hardware AES built in. STM32F4 series comes to mind but I think you need to sign an export license to get the ones with crypto.

[Kjelt]

If you want a symmetric cipher:
AES-128 without contest if you want it to be very secure (up till 2030 according to latest NIST).
As mentioned above there are HW versions but then you are stuck to very limited devices.

Software code is widely available (for instance the original code called Rijndael or better optimised versions in OpenSSL but also in other places).
You also have the choice between speed and larger code or slower and smaller code (for speed you pre-calculate more tables and store them in ROM).

[nctnico]

RC6 is nice and compact.

[kfitch42]

s/cyper/cipher/g ?

http://english.stackexchange.com/questions/147965/cipher-vs-cypher

[Kjelt]

If you want less security but size and speed are the most important there is also XTEA but as said before AES is the defacto standard at the moment.
http://en.wikipedia.org/wiki/XTEA

[ve7xen]

I would probably stick to AES (Rijndael). It's well studied, lots of implementations are available, it's quite simple, and is small and fast on 8-bit CPUs. I don't see any reason not to use it unless you're seriously constrained in one parameter or another. Many micros you may choose to target will have a coprocessor for it too, which you might be able to make use of at one point or another in your system.

TEA/XTEA/XXTEA are simpler and maybe faster/smaller but much less well studied (and have more serious known weaknesses) and for modern CPUs probably don't offer a huge performance gain over Rijndael.

My understanding from the AES process was that RC6 was both larger in RAM and slower than Rijndael and possibly difficult/slow to implement in constant-time (at least on small 8-bitters) without exposing timing attacks due to variable rotation and multiplication. This might be well out of date now, from Schneier's papers during the AES competition.

[nctnico]

In my experience AES is either big and/or slow. There is a reason that AES is usually implemented in hardware if a lot of information needs to be processed...

[GiskardReventlov]

Is the criteria a cypher for mcu or is the criteria something else? You say for "comms or file storage".
Comms == end-to-end encryption?
file storage == after the data is stored, when the file is created and while it's stored and after it's stored?

How much time do you want your mcu to spend with encrypt/decrypt?

Look at all the ones that NIST, NSA have blessed and market, then use different one?

Gibson at grc wanted to write his own end-to-end secure VPN but never started because he knew the feds would insist on a back door.

[dannyf]

particularly suitable for implementing on microcontrollers for "low speed" comms or file storage?

Parity? CRC? particularly on a chip with hardware parity / CRC generator.

[Harvs]

Comms == end-to-end encryption?

As in encrypt on send and receive of packets between a uC and a PC.  I'm thinking of giving some degree of protection to totally open RF interfaces like I've used in the past.

file storage == after the data is stored, when the file is created and while it's stored and after it's stored?

More thinking of encrypting the data prior to storage, and decrypting on read.  Say something like encrypting passwords and contact info on an SD card that's loaded into the system.

How much time do you want your mcu to spend with encrypt/decrypt?

Hard to say... How long is a piece of string?  The less processing power it takes to do, the more inclined I'd be to use it more often.

Having a browse around I found these benchmarks for AES on CM0
http://realtimelogic.com/products/sharkssl/Cortex-M0/

This is a commercial library and won't include any of the overhead that goes with shifting data around, but even still I'm actually surprised that @ 24MHz they're getting >200KB/s through AES.  I thought it was going to be a lot worse than that.

[westfw]

Don't forget that a block cypher like AES needs quite a bit of additional "intellectual infrastructure" around it before you have a secure file or data stream encryption technique.  Do any of it wrong, and you render the scheme "useless" for security.  (That's "useless" by cryptographer's measures.  IMPO, there's a lot of use to be had in between "I sent plaintext" and "I implemented a cryptographically provable secure algorithm."   Just be aware that if your scheme will end up used in something that is likely to be an "attractive target", then eventually there will appear a "tool" that does all the hard work for would-be "crackers."  (Even embarrassingly awful crypto algorithms can be useful.))

[theatrus]

AES should be your default for a symmetric cipher. Absolute worst case RC4 with all of the known caveats.

However preshared keys are terrible. Using ECC for key setup (ECDHE with ECDSA, a well seeded AES RNG, SHAxxx for diffusion) is going to add a lot of capability. Unlike RSA, ECC at 256bit sizes is quite doable. I've ported implementations from TinyECC to vanilla C (watch out for bugs in ECDSA mode)

[tonyarkles]

Something like Salsa20 might be a good choice. Super simple implementation, http://en.wikipedia.org/wiki/Salsa20

[Kjelt]

However preshared keys are terrible.

You will need a decent keyderivation algorithm and both sides should dynamically share a partially random number in the protocol but you already know that. Since PSK is a standard ciphersuite in TLS and DTLS I see no real problem in terms of terrible. It saves a lot of time/uC cycles and in the domain of the IoT, resource constrained devices, it can be the difference between using security in the first place.

Using ECC for key setup (ECDHE with ECDSA, a well seeded AES RNG, SHAxxx for diffusion) is going to add a lot of capability. Unlike RSA, ECC at 256bit sizes is quite doable. I've ported implementations from TinyECC to vanilla C (watch out for bugs in ECDSA mode)

Yes you are right but AFAIK at a huge cost in RAM/ROM size. If you can, will you please share some RAM/ROM and time benchmarks for your ECC implementations?

[Kjelt]

Having a browse around I found these benchmarks for AES on CM0
This is a commercial library and won't include any of the overhead that goes with shifting data around, but even still I'm actually surprised that @ 24MHz they're getting >200KB/s through AES.  I thought it was going to be a lot worse than that.

Those are probably optimized for speed so large AES code.
I have implemented a very small AES version and then it takes much more time, I calculated 1kB encryption at 11ms and decryption at around 12 ms on an 120MHz Cortex M3, so about 90kB/s.
I timed an OpenSSL AES implementation 2 years ago at around ten times faster 1,1ms for 1kB so about 900kB/s on the same 120MHz Cortex M3.

As previously said it is all a balance between ROM/RAM size and speed, five times larger code: ten times the speed 

[nctnico]

More thinking of encrypting the data prior to storage, and decrypting on read.  Say something like encrypting passwords and contact info on an SD card that's loaded into the system.

If that is your goal look at the sha1 hashing algorithm. That way you can sign the data to check it's authenticity. Passwords don't need to be stored in a way they can be decrypted. Just test if the sha1 hashes of the stored password and entered password are identical.

[DrGeoff]

AES or Twofish. Both work very well in small 8-bit micros, either in C or assembler.
The security value will depend on your entire system implementation, not just the algorithm.

[Kjelt]

I would not recommend DES or 3DES for new designs unless they have to be backward compatible such as the case with banking systems.

[theatrus]

However preshared keys are terrible.

You will need a decent keyderivation algorithm and both sides should dynamically share a partially random number in the protocol but you already know that. Since PSK is a standard ciphersuite in TLS and DTLS I see no real problem in terms of terrible. It saves a lot of time/uC cycles and in the domain of the IoT, resource constrained devices, it can be the difference between using security in the first place.

Using ECC for key setup (ECDHE with ECDSA, a well seeded AES RNG, SHAxxx for diffusion) is going to add a lot of capability. Unlike RSA, ECC at 256bit sizes is quite doable. I've ported implementations from TinyECC to vanilla C (watch out for bugs in ECDSA mode)

Yes you are right but AFAIK at a huge cost in RAM/ROM size. If you can, will you please share some RAM/ROM and time benchmarks for your ECC implementations?

CM3 ROM of ECC-256+sha256+ECDHE+ecdsa+protocol bits for wireless was ~10k. RAM I don't remember. Runtime for the slowest operation (final AES shared key agreement) was 20-30 seconds @ 14MHz. Note that all communications used AES (as in TLS), but with an agreed upon ephemeral key.

RNG was using AES-CTR mode with whitened seed from the radio's RNG. In order to use ECDHE and ECDSA a very high quality RNG is a must.

Sadly I don't work there anymore, but it was a derivation of TinyECC.

[theatrus]

More thinking of encrypting the data prior to storage, and decrypting on read.  Say something like encrypting passwords and contact info on an SD card that's loaded into the system.

If that is your goal look at the sha1 hashing algorithm. That way you can sign the data to check it's authenticity. Passwords don't need to be stored in a way they can be decrypted. Just test if the sha1 hashes of the stored password and entered password are identical.

Straight hashes are terrible. Rainbow tables and even GPU hashers can make mincemeat out of that.

Using PBKDF#2 with a salt and as many rounds as you can tolerate is a must.

If your goal is authentication then use HMAC. Crypto is very nuanced.

SHA1 is currently "wounded", so a newer variant or even a djb hash should be looked at.

[GiskardReventlov]

It's a many faceted decision.  "How long is string?" Good one.

Who's eyes do you want to keep away from your data?

Locking your bike up keeps the honest people honest.

Come up with your own scheme, then alter once in a while? Will you store your code on github?