Artifact Content
Not logged in

Artifact 760dd35ab3ecc2832268db9cdc0dfe705f4306b4:

Wiki page [Experiment: mmmv_microbot_crypto_t1: Implementation Ideas] by martin_vahi on 2016-12-29 22:57:07.
D 2016-12-29T22:57:07.552
L Experiment:\smmmv_microbot_crypto_t1:\sImplementation\sIdeas
P c985c97b01e95ab4d7a18b636785033ed8a50fc9
U martin_vahi
W 1675
<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


<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



Z 8105b905960a57ca82a2acc50c08603b