What sample rate of data?
100MHz clock speed is irrelevant to the ability to perform encryption; but to do it in real time, that's where the interesting questions lie!
If it ends up taking 10k cycles to encrypt a sample, and the sample rate is, say, 44.1kHz, you have a bit of a problem there. If it's a few lazy samples per second, it seems unlikely to me that an even more aggressively simplified ALU would have difficulty doing it (maybe not a SUBLEQ machine, but other than that..).
What about physical access to the chip? If the key is transmitted in the clear via I2C, that's rather counterproductive. A hard coded key provides security (the chip itself must be reverse-engineered*), but once the key is discovered, it's all over (say by brute force, cryptanalysis, or reverse engineering).
*Unless a buggy command allows leaking/dumping the address space, or something like that. Which is a very common means of access to OTP and mask ROM devices, so it's worth investigating.
Also, if it's OTP instead of mask ROM, an attacker could write additional bits into the program, with unpredictable (potentially insecure) results. Erasing OTP would be much harder, though, on a similar scale as decapping and reverse-engineering I think. Write attacks aside, OTP should be pretty good.
What's the threat model? Are critical backend systems exposed to the sensors, so that an attacker spoofing a sensor is dangerous? Or is it a data privacy thing, where the breech of a single sensor is an individual privacy problem, but not a global one, while a breech of all sensors would be very bad?
The sensors could be made with individual (
non sequential!) serial numbers, and that used as a keyphrase for the encryption. The serial number could be hashed, then transmitted as a passphrase, to the backend. You'd need a record of every serial number produced, but that's not a big burden of data, these days. This would help limit the extent of privacy breech.
Tim