Artifact Content
Not logged in

Artifact bf41f717cec8a28c3fe3cca24dbb941abeec8d4a:

Wiki page [Experiment: mmmv_microbot_crypto_t1: Implementation Ideas] by martin_vahi on 2016-12-29 23:19:49.
D 2016-12-29T23:19:49.570
L Experiment:\smmmv_microbot_crypto_t1:\sImplementation\sIdeas
P b1eacc143aa1fde248c8768aa5e68981cd84b86c
U martin_vahi
W 3130
<p><a href="./wiki?name=Experiment:+mmmv_microbot_crypto_t1">mmmv_microbot_crypto_t1</a></p>

<h1>Random Number Generation&nbsp;</h1>

<p>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 <i>(even
regular electrical noise, like the 50Hz or some engine noise)</i> for an input
to some fast cryptographically relatively strong hash function <i>(not
unrollable, has collisions)</i>. The hash function output would be the random



<p>The cipher will probably be based on the
<a href="">TXOR</a> and the same
quad-block idea that is being used at the
<a href="">mmmv_crypt_t1</a>,
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

<li>The next block is a choice description block.</li>
<li>The next block is noise and the block after the next block is data.</li>
<li>The next block is noise and the block after the next block is a choice
description block.</li>

<p>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.</p>


<h1>Hash Function</h1>

<p>Probably one needs to write that from scratch, because 8bit MCUs are usually
not used for executing cryptographically strong hash functions. The
<a href="">MurMurHash</a> 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

<p>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.</p>



Z c40a64d32671c29ea5e0ae292634bdc0