Save your money instead? That’s a dull conclusion. Why not do both, i.e. buy a random bitser and expect things to break; after all, we all know that the code is the weakest link by definition.
However… -you felt it coming, didn’t you?- some USB randombitser does not stand in the way at all, either. They’re not worthless. The obvious example is with virtualization, and specifically the notion that layers of kernels on one host all ASLR the heck out of everything. In this situation depleted entropy pools can stall processes by a little or by a lot.
At least, *strokes his beard*, I think this was how it used to be: not long ago I noticed that kernel.randomize_va_space=0 offered a speed increase on VMs, which then lead me to discover virtio-rng, that could be loaded on the guest and enabling it on the host instead, yielding similar speed gains. But I’m not sure if entropy depletion is still a potential blocker with ASLR nowadays.
Still. Knowing that code can snafu something so easily on one hand, doesn’t mean that something something etc.
I disagree. Most RNG’s people use rely on cryptography whose claims have been unreliable as it’s a newish field. The TRNG’s like BitBabbler (an example not endorsement) rely on noise in specific, analog circuits. This is backed by physics that’s essentially the same this year as it was decades ago. Billions of implementations of analog circuits further confirmed those principles instead of case with software crypto where theorists and implementers screw it up a lot. It’s also simple to build and test. So, a highly-proven, simple method in analog vs less-proven, complex one in software leads me to think former is empirically the best option. Only reason these are a USB devices is because all CPU’s don’t come with such things. Some already do. Good idea to push for more.
So, best tools for job across the board. Best algorithm, constructed/used in a way consistent with mathematical analysis, implemented with safe language (eg SPARK analysis), fail-safe error handling, using truly random numbers, and with EMSEC protection. That’s basically NSA’s Type 1 process from what I reverse engineered of various writings. Also how they do high-assurance crypto (EAL7-ish) in general. Here’s two of those I’ve dug up, one old and one new, showing the level of rigor that goes into such projects vs what’s in typical commercial or FOSS.
Note: DTIC is one of least-known, best groups that U.S. government funds. They’re a little, gold mine of useful papers coming out of defense-related research. No curated list for them that I’m aware of but I stumble on them here and there. Citeseerx largely replaced them for me but some stuff is only in DTIC.
Note 2: Galois Inc open-sourced one of their works NSA funded for Type 1 development at Cryptol.net. Lets you specify & prove crypto algorithms then auto-generate a software or hardware implementation. Badass. Galois has a Github page where they release a lot of other stuff. Easy route for FOSS high-assurance of crypto libraries is probably a combo of TLA specs, HAMMER for parsers, SPARK + Rust + MISRA-C for protocols, and CRYPTOL for algorithms.
Save your money instead? That’s a dull conclusion. Why not do both, i.e. buy a random bitser and expect things to break; after all, we all know that the code is the weakest link by definition.
However… -you felt it coming, didn’t you?- some USB randombitser does not stand in the way at all, either. They’re not worthless. The obvious example is with virtualization, and specifically the notion that layers of kernels on one host all ASLR the heck out of everything. In this situation depleted entropy pools can stall processes by a little or by a lot.
At least,
*strokes his beard*, I think this was how it used to be: not long ago I noticed thatkernel.randomize_va_space=0offered a speed increase on VMs, which then lead me to discovervirtio-rng, that could be loaded on the guest and enabling it on the host instead, yielding similar speed gains. But I’m not sure if entropy depletion is still a potential blocker with ASLR nowadays.Still. Knowing that code can snafu something so easily on one hand, doesn’t mean that something something etc.
I disagree. Most RNG’s people use rely on cryptography whose claims have been unreliable as it’s a newish field. The TRNG’s like BitBabbler (an example not endorsement) rely on noise in specific, analog circuits. This is backed by physics that’s essentially the same this year as it was decades ago. Billions of implementations of analog circuits further confirmed those principles instead of case with software crypto where theorists and implementers screw it up a lot. It’s also simple to build and test. So, a highly-proven, simple method in analog vs less-proven, complex one in software leads me to think former is empirically the best option. Only reason these are a USB devices is because all CPU’s don’t come with such things. Some already do. Good idea to push for more.
So, best tools for job across the board. Best algorithm, constructed/used in a way consistent with mathematical analysis, implemented with safe language (eg SPARK analysis), fail-safe error handling, using truly random numbers, and with EMSEC protection. That’s basically NSA’s Type 1 process from what I reverse engineered of various writings. Also how they do high-assurance crypto (EAL7-ish) in general. Here’s two of those I’ve dug up, one old and one new, showing the level of rigor that goes into such projects vs what’s in typical commercial or FOSS.
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA298090
https://www.umsec.umn.edu/sites/www.umsec.umn.edu/files/hardin-icfem09-proof.pdf
Note: DTIC is one of least-known, best groups that U.S. government funds. They’re a little, gold mine of useful papers coming out of defense-related research. No curated list for them that I’m aware of but I stumble on them here and there. Citeseerx largely replaced them for me but some stuff is only in DTIC.
Note 2: Galois Inc open-sourced one of their works NSA funded for Type 1 development at Cryptol.net. Lets you specify & prove crypto algorithms then auto-generate a software or hardware implementation. Badass. Galois has a Github page where they release a lot of other stuff. Easy route for FOSS high-assurance of crypto libraries is probably a combo of TLA specs, HAMMER for parsers, SPARK + Rust + MISRA-C for protocols, and CRYPTOL for algorithms.