Deb,
> On Sep 29, 2025, at 9:51 AM, Deb Cooley <[email protected]> wrote: > > If ISAAC is indeed quick enough, as it is basically just a different stream > cipher (i.e. RC4) than the one I suggested. It has been asserted to be, > but since there are no implementations, are you sure? [the case you > presented stated that AES256 was too slow, but apparently AES128 is not.] There's reference code that Alan had added to the github repository from the original ISAAC work. It's been enough to run some of our tests and experiments. I've tried to carefully not assert comparisons between speeds of ISAAC vs. anything other than our existing MD5/SHA1. AES was introduced by you and Paul recently in this conversation. It's been a decade since I've worked through openssl code, but I've thrown together a quick test case to help us compare AES vs. ISAAC. Let's see if the other authors agree my quick hack is sufficient for a discussion point. This ate my available time today, so document edits will come tomorrow. > The only other sticking point is reuse of the Secret Key for both ISAAC and > the key hashes. Technically, this makes the keyed hashes less robust. > Extraction of a Secret Key from ISAAC compromises the keyed hash versions. I agree that's a possible concern. However, as I noted in a prior mail in this thread, what this would mean is that it's possible to distill the actual key from either our stronger or our less strong mechanism and not simply a key that causes collisions in either of the two mechanisms. This is on the presumption that a key that collides in one mechanism is highly improbable to also collide in the second one. Insert again my assertion that I'm not a cryptographer, but I suspect I'm stating something reasonable. And similarly, the issue is that adding a second key creates a significant operational consideration. If the key for the less strong mechanism is mis-provisioned, the optimized BFD state machine will partially proceed to the Up state and then the session will fail when it moves to the optimized mode with the less strong mechanism. > If ISAAC is literally the only stream cipher that is quick enough, then I'm > happy to help construct words to dissuade any other use of that algorithm > for other purposes. If we find that another more acceptable method can be used, this would mean: 1. There may be little impact on the optimized authentication draft as long as the properties for that mechanism still appropriately parallel what we've done to integrate with ISAAC. If so, the optimized authentication draft might be able to proceed separably. That's the IESG's call. 2. Much of the iSAAC procedure can be ripped out and the alternate mechanism put in place. The text that isn't ISAAC specific simply needs an indexed stream of predictable numbers. The ISAAC specific procedures for bootstrapping would be replaced by using that mechanism to generate such a stream. -- Jeff
