The short of it: EAX seems roundly superior to the CCM cryptography used by the likes of WiFi and ZigBee. For years I have been investigating different approaches to cryptography in order to find ones suitable for Internet-of-Things applications. With IoT, you cannot guarantee that a device in the network has a lot of memory, processing, or energy resources, so when you can find a more efficient way to do the same thing as before, it is a good day. Here is some more information about implementing EAX for embedded targets, and a little bit about cryptography in general.

## Symmetric Key Cryptography is the Topic at Hand

You may have a little bit of knowledge of cryptography, enough to know that there are basically two kinds of basic algorithms: public key (asymmetric key) and private key (symmetric key). There are some nice advantages of public key cryptography when it comes to exchanging keys, but these algorithms are much less efficient than are private key algorithms when it comes to simply encrypting or decrypting data. In fact, most practical applications of public key cryptography involve using the public key element just for the purpose of negotiating a channel for encrypting the bulk of the data via a private key method.

## AES is Just the Beginning

For over a decade, AES (thusly dubbed, “Advanced Encryption Standard”) has been the practical standard for private key cryptography. It offers a high level of encryption and a relatively low amount of overhead. Technologies like EAX and CCM both utilize AES as a fundamental “cryptographic primitive.”

The thing is,* a great many* data security models use AES as their cryptographic primitive, and yet not all are created equal. There is more information on why exactly this is the case (e.g. 1, 2, 3), but for the purpose of this article there are only a few important concerns:

- Does it encrypt the data sufficiently?
- It is able to authenticate the integrity of the data?
- Does it cause no expansion of data transferred?
- Can it be used
*streaming*? - Does it run fast and light?

## Performance

With EAX, there is a security proof to validate the first two points (*Note: EAX’, or “EAX-Prime” is actually a different spec*), and the same specification can show that EAX meets points three and four — it adds no additional data and it can be used iteratively with streaming input/output. With CCM, you can find that it also succeeds on points one and two (although there are some criticisms), and that it fails on points three and four. All of this can mean nothing, however, if one method is fast and the other is slow.

Some takeaways in EAX vs. CCM performance:

- The “scheduling” (initialization) of the decryption key is typically faster in EAX than it is in CCM.
- The amount of code is quite a bit less.
- The authentication stage is one pass instead of two.
- Most importantly, EAX is a streaming cipher, so it can be started before the entire packet is received:
*extremely important for low power and/or low-data rate IoT MAC encryption*. In other words, I can start decrypting and kill the packet if I find it is not addressed to me, and all this can happens way before the whole packet is received.

## API Breakdown

Another important attribute is the simplicity of the programmers’ model, because a naïve implementation of client code can be just as significant of a vulnerability as can be a lousy implementation of cryptography. EAX is much simpler to use as a programmer — it can be done in-place with single buffering, no true-random numbers are required, the operations are essentially atomic, and the order of operations is essentially identical in encryption and decryption. CCM isn’t terrible by any means, but it is different in the way it is initialized for encryption and decryption and it adds some complexities to buffer alignment as it may only operate on 128 bit boundaries.

## Open Source EAX Implementation

Brian Gladman’s AES cryptography suite is easily the finest implementation of all types of AES — EAX, CCM, and plenty of others as well. It is written in a very clean style of C and the API is about as transparent as I have encountered. On top of these things, it is also fast, compiles small, and has an unrestrictive BSD-style open source license. I have gone to the trouble of stripping-out EAX from this package and doing as many EAX-specific optimizations as possible. The project is called OTEAX. I have also ported it to OpenTag, which is generally expected to compile and run on ARM Cortex-M processors, so I’ve added those optimizations where possible.

You must log in to post a comment.