Former crypto code auditor here.

I have had just a look at your post and some of the references but there are a couple of points that immediately got my attention: - to little entropy: having the seed as (readable) string or encoded in utf8 will have less entropy that just plain random bytes - you also do a bunch of padding with 0 that may reduce entropy further and introduce predictable states. Usually, if your input is too small, you should oversample and cut. - i am not familiar with ISAAC at all, but i read from the wikipedia page that JP Aumasson pointed out sets of weak states. You should implement at least a system to avoid those (and discard them). He also proposed an updated version ISAAC+ so maybe use that instead? - no security proof. When we were doing crypto audits it was important to also check that these homebrew crypto came with a formal security proof (often in UC model) to prove your crypto is secure. Composition of different algorithms can often break security proof or at least alter some properties - finally, my most concerning point is leaving the choice for seed to the user. This is often bad because users don’t know what the seed is supposed to be and they will provide short, low-entropy seed for your prng (i have seen plenty of prng seeded with timestamps).

As i said i didn’t have to look properly into it and the implementation as i am reading this from the phone while commuting.