> We did make some enhancements that serve our needs, but may not be > best for everyone. We actually need entropy in quantity since we could be > doing a lot of crypto operations back to back and it can easily become our > worst bottleneck.
Have you looked at the "Yarrow" algorithm? > To this end, we have an entropy buffer in kernel memory that pulls > large blocks of entropy from the RNG if it's going to read from it at all. > The device puts out several orders of magnitude more entropy than the > original drivers captured, and we needed as much as we could grab. > Ideally we would not mix the entropy into the entropy pool and just use the > high quality entropy from the buffer, but we decided to minimize divergence > from the original sources and not switch to 100% hardware entropy. In CURRENT, I have implemented Yarrow to achieve just this purpose. > The drawback to our approach is that it can spend a lot of time in > the kernel. To tune this behavior we added a few sysctl's. The start/stop > script after the diff's tweaks a few of these settings after boot up. Again, look at current. The RNG is _really_ fast. > I cc'd Kaj Groner, who actually did the work for us. He's not on > this list, so don't drop his address. I was more involved at the higher > levels of what we needed to get done when we rebased our appliance from > OpenBSD to FreeBSD last Summer. :-) You may be pleasantly surprised :-) M (Thanks for the sources!) -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
