I like that. And I think Sec Consid. is the perfect place to put it. Thanks for putting those words together. I appreciate the effort.
Deb On Mon, Oct 13, 2025 at 6:01 AM Alan DeKok <[email protected]> wrote: > 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. > >
