|Page Name:||Experiment: mmmv_microbot_crypto_t1: Implementation Ideas|
Random Number Generation
Random numbers might be generated by combining some pseudo-random sequence generation function with bitstream from hardware based random bitstream generator. The role of the pseudo-random sequence generation function is to compensate for the slowness of the hardware based bitstream generator. The hardware based bitstream generator might use light, sound, electrical noise (even regular electrical noise, like the 50Hz or some engine noise) for an input to some fast cryptographically relatively strong hash function (not unrollable, has collisions). The hash function output would be the random bitstream.
The cipher will probably be based on the TXOR and the same quad-block idea that is being used at the mmmv_crypt_t1, except that may be in stead of 4 blocks there will be a variable number of blocks and in stead of the 3 choices that the mmmv_crypt_t1 uses, the choices are:
- The next block is a choice description block.
- The next block is noise and the block after the next block is data.
- The next block is noise and the block after the next block is a choice description block.
To limit the maximum ciphertext size per unit of cleartext data volume, the maximum number of non-data blocks between data blocks must be limited. The limit is an encryption algorithm parameter. To hide the location of the data blocks the transmission must hide the ciphertext creation rates. That is to say, it is essential that the ciphertext is transmitted in a constant rate, through a FIFO.
Probably one needs to write that from scratch, because 8bit MCUs are usually not used for executing cryptographically strong hash functions. The MurMurHash is not designed to be cryptographically strong, but it might give some ideas. The number of collisions must be maximized. The way to do it is to require a minimum of N bytes as an input and use some constants, when the input data is smaller. The constants can be pre-processed with input data before using them as inputs for the hash function. Different Hash function implementations can be evaluated by counting the number of collisions that literally every 4B number has. The 4B can address 4GiB, so results must be stored sparsely, may be by using a histogram. Given that it's a fast C program that fits wholly to CPU-cache, the calculation of the 4*2^9 values should take less than a minute on a desktop computer.
There must be some way to test, whether a particular MCU treats integer overflows the same way as the desktop computer does. Otherwise the MCU calculated hash might differ from the desktop computer calculated hash.