Darren J Moffat wrote: > Do we know that a FIPS 186-2 implementation is going to be slower than > the existing SHA1 based implementation ? > > I think this is the only reason to keep the existing SHA1 based swrand. > If is slower how much slower ? >
I don't have the data yet. > There seems to be conflicting information in the design [last > paragaraph] as to wither there is one "swrand" binary or an "swrand" as > it is just now and a separate fips186-2. > I meant two separate swrand modules -- A new separate swrand for FIPS mode that implements FIPS 186-2 and the existing swrand that we have now. > I strongly favour having two separate binaries: > 1) allows easy testing of the perf differences I thought so too. > 2) policy is easy to see using cryptoadm as it is today Agreed. > no new ioctl's are needed to enable fips mode Please see my response below. > 3) allows further different implementations later Agreed. > > Specific issue: > > "This global variable will be checked by rnd_generate_pseudo_bytes()" > > That will cause a performance problem on multi cpu machines based on > experience I had with the sha1 module checking if VIS was available. > > This is an issue that wouldn't come up with separate modules. > When /dev/urandom is used, the random bytes are generated by rnd_generate_pseudo_bytes() in the KCF module instead of in the provider module. In order for rnd_generate_pseudo_bytes() to apply the FIPS algorithm, it needs to check the FIPS mode flag to see if in FIPS mode. That's why a new ioctl is needed to enable the flag. For performance reason, we can add the FIPS mode flag to rndmag_t (per CPU struct), instead of defining a global variable. For kcf, I think we probably don't want to have 2 separate kcf modules. > I don't mind if doing separate modules means you need to refactor > swrand.c or copy code from it. > > I don't understand the comment about separate kcf.conf files, there is > and should be only one /etc/crypto/kcf.conf. > Because of two separate swrand modules, I thought to have a separate kcf.conf for FIPS mode modules for clean separation. However, we can keep the existing (non-FIPS) modules and new FIPS modules in one kcf.conf file. Thanks, Hai-May
