Good effort, will work in many cases.
it misses a entropy generator so the seeding is still deterministic, two arduino's (even with different sketches) will get the same random() sequence and in case of the same sketch they will behave identical I think - unless eeprom is initially different, which normally isn't ...
Good point. Some solutions... Initialize the EEPROM to a value from random.org. Use a different odd prime number for different sketches.
Just putting 1,2,3,4,5, etc as next seed is equally deterministic; only less obfuscated and easier to program no need for happyPrime...
Ah, but I like using a Happy Prime.
it should contain a test that the value written to EEPROM is not the same as the one read from it at the start to prevent "seed-lock "
I don't understand.
the algorithm uses EEPROM to store the seedGenerator over restarts. This is a good idea, however, it uses the first 4 bytes which are the first to use if someone uses EEPROM in their sketch, might be better to use the last 4 bytes of the EEPROM, these are less likely to be used by a sketch.
- readout (part of) the flashmemory (progmem ?) and do a CRC-16 or so => to be used as part of the seed. Then at least two different sketches will get a different seed.
I like the idea but it may add too much start-up delay. I'll investigate when I have more time.
- Every EEPROM might have slightly different timing (I'm thinking about the delay one needs after writing has a reason). Can it be used as source of entropy?
While the physical EEPROM may have slightly different timings, I don't think the CPU has a way to measure it. The datasheet hints that EEPROM reads and writes are driven solely by the processor clock. I vaguely recall considering EEPROM timing instead of watchdog jitter as an entropy source and rejecting the idea because of datasheet hints.