|No such thing as a small change|
but password/session key generation can be made reasonably secure even with a nonfunctional RNG
Really? How? That is a pretty big assumption.
How do you protect against predictably generated keys? Say, if the device does not have a hardware clock (and this one doesn't) and the program is started as part of the startup scripts, you end up with a very predictable set of constraints (process id, system time, memory layout, ...).
While it may take a lot of raw processing power to compute the tables, you may only have to do it once. So, access to a bunch of high performance computers with good GPU's and a week or two of waiting may be all that's needed. Say, a few computers optimized for bitcoin mining. Or an attacker could just rent a botnet for a say or two.
Even if it's only "session keys" that expire after a few minutes. The encrypted data can be stored and decrypted later. With any luck, the session contains a few passwords or other sensitive information that are valid much longer.
You see, there is no "reasonable" security. It either works, or it doesn't.
"I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"
In reply to Re^6: Your random numbers are not that random (UtS,L)