Just FYI
I adapted some C code I had on hand from a prior project, where that code ran on a Windows PC and an ARM7 that communicated via short range wireless + internet. (end to end encryption).
I ran the (US) NIST test data sets (test vectors), where NIST specs say, for encryption, that for these particular bytes going in, the encrypted bytes must be, and vice-versa for decryption.
The speed was way faster than I expected based on prior work.
The NIST tests use a set of of 32 bytes.
For embedded systems, I've used AES128 and the CCM option. That makes the encrypted bytes be the same number as the unencrypted (plain text). The last encryption block is truncated so that pad bytes aren't needed. This is important for wireless links where the MAC/PHY frames are a small size at max, like IEEE 802.15.4 and about 100 bytes max. The AES scheme uses a message authentication (and integrity) check which is about 4 bytes. With these, and a mutual agreement on the "nonce", one can do mutual authentication and avoid using shared key. This means that if a key is stolen, only one device is affected, unlike shared key systems (like 802.11/WiFi). Really important when the are dozens/thousands of devices communicating with a host and these are embedded systems/unattended. A lost/stolen key can be revoked in the central server and all other nodes press on, each with their unique key.
So the speed results for the NIST 32 byte data (one can extrapolate) is measured at 2.4milliseconds for 10 iterations of encryption, or about 0.24mSec for 32 bytes. Decryption is about the same. I'll try 100 bytes but it should scale with no big surprises.
These numbers are with a Teensy 3.1. The 3.0 would be somewhat slower.
I adapted some C code I had on hand from a prior project, where that code ran on a Windows PC and an ARM7 that communicated via short range wireless + internet. (end to end encryption).
I ran the (US) NIST test data sets (test vectors), where NIST specs say, for encryption, that for these particular bytes going in, the encrypted bytes must be, and vice-versa for decryption.
The speed was way faster than I expected based on prior work.
The NIST tests use a set of of 32 bytes.
For embedded systems, I've used AES128 and the CCM option. That makes the encrypted bytes be the same number as the unencrypted (plain text). The last encryption block is truncated so that pad bytes aren't needed. This is important for wireless links where the MAC/PHY frames are a small size at max, like IEEE 802.15.4 and about 100 bytes max. The AES scheme uses a message authentication (and integrity) check which is about 4 bytes. With these, and a mutual agreement on the "nonce", one can do mutual authentication and avoid using shared key. This means that if a key is stolen, only one device is affected, unlike shared key systems (like 802.11/WiFi). Really important when the are dozens/thousands of devices communicating with a host and these are embedded systems/unattended. A lost/stolen key can be revoked in the central server and all other nodes press on, each with their unique key.
So the speed results for the NIST 32 byte data (one can extrapolate) is measured at 2.4milliseconds for 10 iterations of encryption, or about 0.24mSec for 32 bytes. Decryption is about the same. I'll try 100 bytes but it should scale with no big surprises.
These numbers are with a Teensy 3.1. The 3.0 would be somewhat slower.
Last edited: