After some component shopping and leaving the current prototype to produce some serious test output, my hardware random number generator project takes several unexpected turns.
Once upon a long ago I thought that the most reasonable approach to test my hardware random number generator was to use tests that other people have written, so I’d avoid testing my own stuff and missing some critical mistake. Well, things didn’t quite turn out as I expected…
With a microcontroller hooked up between a hardware noise generator and a computer, the next step is to write firmware for it. There is a surprisingly wide range of approaches on how to turn analog noise into high quality random data and this video shows how to implement at least the most promising ones.
While there are still ways to optimize the noise generator module, the next step towards a proper hardware random number generator is to process its output in a microcontroller and hook that up to a computer. Here’s the hardware side, including a number of alternatives I’ve taken a look at but decided not to pursue at least for now.
If you rather trust a hardware random number generator you can build and audit yourself, rather than buying some trusted (according to the vendor) platform module, this series may be for you. In this episode I explain how the Zener/avalanche diode based noise generator I use works.
Here are my personal highlights from last week’s RIPE-68 in Warsaw/Poland, and some quick info on a secret little project of mine.
In a reply to the previous episode, Matthias pointed out that while the ramond is a useful tool, it is little if any use against a malicious attacker. Right, but if you let an attacker into a subnet with potential targets, you are in some very serious trouble anyway.
As promised in episode #22, here are some simple but useful things you can do with IPv6 Autoconfiguration but can’t do with DHCP.
In virtually all IPv6 trainings and consulting sessions the question pops up if DHCPv6 or Stateless Address Autoconfiguration (SLAAC) is the way to go. Here’s why you quite likely need both.
If you think that IPv6 is a “network job”, you are in for a nasty surprise: The fun really only starts once the network provides IPv6 and you have to make your applications IPv6-aware. And even that’s not primarily a technical job…