Deb,
> On Sep 29, 2025, at 5:30 PM, Jeffrey Haas <[email protected]> wrote: > >> 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. Said coauthors are not being responsive. I've pushed some code doodling to https://github.com/mjethanandani/bfd-secure-sequence-numbers in the jhaas-aes branch which gives some possibly useful anecdata. I'll endeavor to work with the coauthors to clean up that code and more directly incorporate it in the main branch for posterity, but I'm not gating our document work on this. As a rough comparative methodology, since AES-128-OFB is expected to run in constant time, but ISAAC computes entire 256 entry pages in one round under the reference code, I used the openssl library to take a plaintext block of 256*sizeof(uint32_t) with an initialized key and encrypt that plaintext block. The resulting ciphertext I'm feeding into the next round. The intention is to try to make sure that any overheads for the AES code in openssl is reduced for better comparability of the mechanisms. AES doesn't require "pages", however use of other PRNG mechanisms would still require pre-generating some look-ahead and caching of the results to deal with reordered, lost, or attack packets. On my ancient mac (Xeon processor), running the isaac() operation and the test openssl code with no specific optimizations enabled but what my mac will give me, ISAAC and AES-128-OFB run in roughly comparable time. However, Alan had pointed out that even the mac will have some hardware optimizations available. I used two debug flag modes available for openssl to shut off some of the hardware optimizations. In one case, this resulted in 2x slower than the ISAAC code. In the other case, it was 5x slower. I don't intend to draw any deep bit of concrete data from this aside from "other mechanisms might run as fast as ISAAC" and "hardware optimizations are important for some technologies". The overall headache we continue to work from is these things are all situational. If you have the hardware to support fast operations and they don't degrade your performance - use them! If not, having other options might be all we have to encourage better deployment of authentication. See the proposed updates in the optimization draft that hopefully spell that story out better. -- Jeff
