# Key scheduling for ISAAC

Does ISAAC use key scheduling? I do not know programming.

Is it safe if ISAAC derives subkeys using ISAAC itself?

• ISAAC just isn't an algorithm that anyone qualified to work on cryptography would call "safe". Though I'm not aware of published attacks, we have higher standards. We want supporting evidence that an algorithm is safe, not an absence of evidence that it's unsafe. There is no reason to use it, anyway, because serious modern algorithms are more efficient and safer compared to ISAAC. Commented Feb 29, 2020 at 3:07
• Ok can i edit my question further and generalize it for key scheduling. Commented Apr 29, 2020 at 18:09

The author of ISAAC notes:

I provided no official seeding routine because I didn't feel competent to give one. Seeding a random number generator is essentially the same problem as encrypting the seed with a block cipher. ISAAC should be initialized with the encryption of the seed by some secure cipher. I've provided a seeding routine in my implementations, which nobody has broken so far, but I have less faith in that initialization routine than I have in ISAAC.

No official seeding algorithm means no official keystream or key scheduling.

The first sentence of that quote is a red flag for security. If someone knows the algorithm well enough to provide an initialization algorithm then it should be him.

But I suppose he thought that his algorithm would run fine if random values were assigned to each of the 259 32-bit words required to store the state of the RNG. (There is insufficient evidence for that.)

I think that despite it being unconventional, it would be fine for an algorithm designer to say "these values all must be filled with numbers from a HWRNG or key-derivation function," but instead he talks about block ciphers and encryption. (Those next two sentences aren't absolutely technically correct, but perhaps, since it was invented in 1993, the language didn't exist at the time.)

The unofficial initialization algorithm has no key schedule. It does not use subkeys. Instead it alternates between adding one of eight 32-bit seed words to eight words of the RNG state and slightly mixing up those 256 bits in a loop. (Note that just because the seed is 256 bits doesn't mean this algorithm has 256-bit security.)

His implementation actually loops too many times, writing to memory that doesn't belong to the 256 word array he's using. That's called a buffer overflow and it has the potential to be really dangerous. (Which can be as bad as allowing attackers to run arbitrary code on your computer remotely.)

That's another huge red flag. Something you may forgive from a pure mathematician who had to learn programming just to create reference code. But definitely not something you expect from a professional programmer.

... But even if we knew none of that,

# Don't use ISAAC‍!!!

Why?

• There is insufficient evidence to believe that the algorithm is cryptographically secure.
• It's much slower than modern encryption algorithms.
• There is insufficient evidence to believe that the algorithm is cryptographically secure.
• The amount of memory it uses is relatively large.
• There is insufficient evidence to believe that the algorithm is cryptographically secure.
• The author didn't provide evidence for why we thought has algorithm was secure. Merely that he didn't find any biases using empirical data.
• There is insufficient evidence to believe that the algorithm is cryptographically secure.