On Oct 12, 2025, at 8:48 PM, Deb Cooley <[email protected]> wrote: > > Much, much better. I'm deleting the things I think we agree are resolved. > The rest I've prefaced with [DC] > > What is left is: > > key management - generation (statement in Sec Consid) and PRNGs (and how they > are used). See my notes in Jeff's last message. > > I also think we are still missing the statement in Sec Consid. that basically > says, ISAAC is ok for this particular use case, and no other. I'd add that > to the last paragraph of 15.1. I'd like it to be unsubtle and a little in > your face. > > The last thing I said I would help with was a statement about future methods. > Since this is an experiment, is it possible to have a 'future work' section > (I've never seen one). Other options might be the Introduction, or Sec > Considerations (I guess). Something like: More secure methods may be an > option as CPUs get faster and memory more plentiful. Options could be using > AES w/ hardware acceleration in OFB mode (FIPS 197, SP 800-38A, Output > Feedback Mode), CHACHA in S/W (a stream cipher, RFC 7539), or other well > understood techniques.
Perhaps adding the following text near the top of 15.1, after the initial paragraph. I've tried to be clear, while at the same time raising major red flags about the use of this protocol. The security of this proposal depends on the security of the ISAAC algorithm, which has had minimal analysis. While it is believed that the algorithm is secure enough for this use case, no proof is offered. ISAAC was chosen here for the reasons discussed in Section 3.1, as no other option was found to be suitable. The choice of ISAAC was driven in part by the limited functionality of systems which implement this specification. Many of these systems do not have hardware assistance for cryptographic opertations, meaning that any CSPRNG based on a block cipher would be unsuitably slow. Where hardware assistance for block ciphers is available, ISAAC offers no advantanges, and many disadvantages. More secure methods are better choices as CPUs get faster and memory more plentiful. Alternative solutions could be AES with hardware acceleration in OFB mode (FIPS 197, SP 800-38A, Output Feedback Mode), or CHACHA in software (RFC7539 [RFC7539]), or other well understood techniques. For these reasons and many others, the ISAAC CSPRNG is at best tolerable for use in this specification, and is completely unsuitable for use in any other IETF protocol.
