Repurposing cryptographic hardware for compression?????....... - Page 1
Forum section: electronics / general

author: Smokey
author_rank: Super Contributor
timestamp: February 26, 2022, 07:57:50 pm
content: Question: Is it possible to repurpose the cryptographic hardware accelerators (AES/MD5/SHA/ECC) to make a simple compression encoder/decoder for simple animations?I have a micro that has hardware cryptographic accelerators (AES/MD5/SHA/ECC) but no compression codecs or other DSP. The application needs to store and play a 320x240 animation and I'm looking for a more efficient way to handle all that data since it takes up a bunch of flash. I don't need full on H.264, just something smaller than raw BMP. Is it possible to use any aspects of the above crypto hardware accelerators to encode/decode the images?I'm trying not to add any extra parts to the BOM, but I realize a small FPGA would be able to solve this problem if I have to go that way.If that's not possible, is there a simple software decoder algorithm that can do basic compression and keep up with ~10fps 320x240 frames?

author: hans
author_rank: Super Contributor
timestamp: February 27, 2022, 12:12:26 pm
content: Cryptographic routines do the opposite of compression. Basically many symmetric ciphers at it's core are a pseudo-random number generator. The pseudo-ness is only repeatable with the correct key. A perfect RNG will never repeat itself: i.e. every new bit is unpredictable and has an entropy of 1 bit. Practical RNGs are finite though, for example a (maximum length) 7-bit LFSR will repeat itself every 2^7-1 = 127 bits. If you were to sample 127000 bits from that LFSR, a good compression algorithm would be able to compress this down to some compressed form e.g. "repeat 1000 [127 bits]". So in that sense it's possible to compress "random data", but only because we had far more samples (127kb) of the RNG stream than the maximum sequence length (127b).However, a 7-bit LFSR is a very low quality RNG.. a modern cipher will want to use something that practically never repeats itself. E.g. if you look at AES with 16 byte blocks (128 bits), then ideally the AES algorithm will only repeat itself once every 2^128-1 bits. We're currently in theZettabyte era, 2^70 or so, so we're far off even recording a raw AES stream (for 1 specific key).If you look at uncompressed data, it can only be compressed if the (average) entropy is less than 1. However, if you encrypt the data, then you mask the data's entropy using the RNG, and therefore the encrypted data is not compressable anymore.This is a common trick to see if a firmware binary is raw instructions or not. If you have a raw firmware file, then try to compress it. If it barely gets smaller (or even grows because of compression format overhead), then you can be certain it's either encrypted or compressed already.Back to a specific answer for your image question:You could search for embedded image compression libraries. I found an interesting (surprisingly simple) compression algorithm a few months ago, but unfortunately I can't find it at this very moment. I did find some alternative open source libraries, e.g:https://github.com/igvina/ArdBitmapIt's impossible to say whether the MCU can keep up with that framerate/resolution. For all I know, you could be programming on a 32MHz Cortex-m0 or a 480MHz Cortex-m7 right nowedit:the quite-ok image library is indeed the one I had in mind, but couldn't memorize the name/link bookmark.

author: mariush
author_rank: Super Contributor
timestamp: February 27, 2022, 04:25:44 pm
content: Probably thinking of QOI (Quite OK Image format) :https://phoboslab.org/log/2021/11/qoi-fast-lossless-image-compressionConsidering it's an animation, you could probably split your 320x240 image into 32x32 or 16x16 chunks and compare frames and store only chunks that have differences.

author: Marco
author_rank: Super Contributor
timestamp: February 27, 2022, 04:40:40 pm
content: You'd think someone would have made a microcontroller decoder based on something like Block Truncation Coding or it's successors (and maybe block motion compensation, since for the decoder it's pretty simple on integer samples).

author: Smokey
author_rank: Super Contributor
timestamp: February 28, 2022, 02:22:31 am
content: Cool. Great feedback. I figured it was worth a shot asking the question. It was more of a generic conceptual idea, repurposing the computational blocks for something else. I didn't think actually encrypting the images would help, but more along the lines of seeing if there was a chance the underlying fast math hardware could be tricked into manipulating data in a way that would be useful for decompression (sorta like how graphics cards weren't designed to do crypto hashes, but are still pretty good at it).But in this specific case I'm running a 96MHz Cortex-M0. I found QOI last night and have it on the list to evaluate.