This blog series by user  discusses some security aspects of HardenedBSD, along with an Entropy Assessment of FreeBSD. The author runs various tests using DTrace and documents his findings across 2 different blogs, and more to come in the future. Check out the blog links for the full and detailed report.


The True Value of Randomness: Initial Results in Hardened/FreeBSD Entropy Assessment (Part 1 of Series)

First, touching back on some background: Currently, I am employed by Acumen Security, LLC as a Lead Security Engineer where I work on Common Criteria and FIPS consulting and evaluation testing.  Most of this (especially the FIPS 140 stuff) is basically being the crypto police — verifying the correct implementation and operation of cryptographic algorithms and modules, correct implementation of encrypted communications channels, etc.

In order for a product to be accepted into evaluation these days, the product vendor and lab must first submit an Entropy Assessment Report.  Essentially, this is proving that there is enough raw randomness being fed into the crypto system from the start, because if you have week or predictable initial entropy, the strength of the entire rest of the crypto system is compromised

Original article:

Deeper Exploration in (Free|Hardened)BSD Entropy (Part 2 of series)

So, the other day I posted some background and initial findings from a side project in attempting to measure entropy in FreeBSD and HardenedBSD systems.  Rather than instrumenting the kernel with printf(9) or log(9) calls, I decided that I wanted to take the opportunity to start digging with with DTrace.

The first blog post attracted a little bit of attention, and I got into a fairly long conversation on Twitter with John-Mark Gurney that let me know that I was on the right track, but needed to get a little bit further in to really, effectively count what was being fed in.

Original article: