3

I was looking for a good pseudorandom stream generator to supplement or replace RC4-drop-lots, in a noncrypto application. Since I'm mixing it with output from /dev/random, I decided not to use ChaCha for my purposes - /dev/random might already use it and I didn't want accidental correlation.

I decided something cryptographically capable would give me some guarantees against unpredictability, and I stumbled into ISAAC.

Wherever I see it mentioned, I see it referred to as strong enough for crypto work. But I haven't seen who decided that, and looking at the implementation in C, it looks for all the world like someone picked arbitrary constants for shift operations and fiddled with add operations until they got something that had good statistical properties. (I realize they often look like that, but this code seems especially arbitrary).

The one paper I found that does any analysis promptly diagnoses a bunch of weak keys and proposes ISAAC+ - which no one seems to have discussed at all. A website for ISAAC says it's never been cracked, but given the lack of online discussion about it, maybe only two persons ever tried.

Are there valid reasons for the warm fuzzy descriptions of ISAAC? If it's great and unbroken after all this time, why isn't it a mainstay?

  • From crypto – kelalaka Oct 23 '18 at 17:05
  • Rotation constants often look quite arbitrary and sometimes they are. It's not uncommon to test a variety of constants and see which ones provide the best diffusion. Given that it hasn't seen as much cryptanalysis as AES (or ChaCha) and the fact that it's really not that fast, it's not surprising that it isn't more mainstream. – forest Feb 26 at 3:15
2

I decided not to use ChaCha for my purposes - /dev/random might already use it and I didn't want accidental correlation.

You might want to rethink that. Firstly, /dev/random is not the one using ChaCha20, /dev/urandom is. Secondly, there is no "accidental correlation" to worry about. You can safely use ChaCha20 multiple times and it will remain secure as long as the key:nonce tuples are all unique.

Wherever I see it mentioned, I see it referred to as strong enough for crypto work. But I haven't seen who decided that, and looking at the implementation in C, it looks for all the world like someone picked arbitrary constants for shift operations and fiddled with add operations until they got something that had good statistical properties

ISAAC is considered secure simply because no one has broken it yet, and because analysis appears to indicate a solid and secure design. As for the rotation constants seeming arbitrary, you're right, they often are! That is often how people choose such constants. They try different values and see which ones have ideal diffusion characteristics. I'm not aware of any heuristics for choosing specific rotation constants for an arbitrary cipher. Even ChaCha20 and Salsa20 use constants that were chosen (in part) this way.

The one paper I found that does any analysis promptly diagnoses a bunch of weak keys and proposes ISAAC+ - which no one seems to have discussed at all. A website for ISAAC says it's never been cracked, but given the lack of online discussion about it, maybe only two persons ever tried.

It's not weak keys that were found, but weak states, which are far more hypothetical and harder to generate. ISAAC+ is likely less researched because it is not an entirely new design, but a small tweak on the original design. Such tweaks do not always warrant a significant amount of new analysis.

If it's great and unbroken after all this time, why isn't it a mainstay?

Simple: There are better, faster alternatives like ChaCha20. While it is true that there are no known practical attacks against ISAAC, it's really not that brilliant a design to warrant significant attention. It got some rudimentary cryptanalysis and cryptographers in general feel it is secure, but there is no compelling reason for it to be used, resulting in less attention from the cryptographic community.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.