Encryption For Arduino With Spritz

Hackaday.io user [Abderraouf] has written an implementation of the new(ish) Spritz cipher and hash for Arduino. While we’re not big enough crypto-nerds to assess the security of the code, it looks like it’s going to be pretty handy.

Spritz itself is a neat cipher. Instead of taking in fixed blocks of data and operating on them, it allows you to process it in (almost) whatever chunks it comes in naturally, and then extract out the encrypted results piecewise. It works both as a two-way cipher and as a one-way hash function. It looks like Spritz is a one-stop-shop for all of your encryption needs, and now you can run it on your Arduino.

In case you are afraid of new implementations of new ciphers (and you should be), Spritz’s pedigree should help to put you at ease: it was developed by [Ron Rivest] to be a successor to his RC4 algorithm, and it incorporates a lot of the lessons learned about that algorithm over the past. This doesn’t exclude subtle flaws in the implementation of the library (no offence, [Abderraouf]!) or your work downstream, but at least the underlying algorithm seems to be the real deal.

[Abderraouf] links it in his writeup, but just for completeness, here’s the Spritz paper (PDF). What crypto libraries do you currently use for Arduino or microcontroller projects? We’ve been fans of XXTEA for ages, but more because it’s simple and small than because it’s secure. Spritz may be simple enough to implement easily, and still more secure. Sweet.

4 thoughts on “Encryption For Arduino With Spritz

  1. Spritz looks relatively complicated and (like RC4) uses a large RAM array to maintain state (256 bytes, a lot for an Arduino). It’s also slower than RC4. I don’t see its attraction compared with something like Salsa20.

    1. Sacrificing 1/8th of an UNO’s RAM is a perfectly acceptable trade off I think. (1/32nd for a mega)

      A hint for those running web-servers on the Arduino: using f() on a string stores the string in flash without consuming ram. This DRAMATICALLY reduces the memory consumption, as all the HTML is then stored in program memory.

      As for this thing’s strength, I figure it’s probably strong enough that if someone goes to the trouble of cracking it, the effort involved will mean I have a much bigger problem on my hands (especially consider it’s running on an Arduino UNO, which I don’t tend to use for ultra-sensitive stuff (or really, any sensitive stuff; is my house’s temperature/humidity really that important?)).

    1. It’s less an appeal to authority as it is a trust issue. Someone with a track record of producing a strong encryption algorithm is more likely to be able to produce other strong ones than someone who is unknown. Vetting helps, but it’s only deferring the trust issue because you need to trust the vetters.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.