UPDATE (9/16/2014): I encourage people to read Bruce Schneier’s post regarding surreptitious tampering of computer chips, which includes hardware random number generators. It’s nearly impossible to know that a hardware RNG hasn’t been tampered with at the time of manufacture to facilitate a backdoor. Therefore, it might be worth sticking with a software RNG, as is the default behavior in Raspbian.
The Broadcom System on a Chip (SoC) in the Raspberry Pi features a hardware random number generator that can be used as a high-quality source of random numbers. This might be worth enabling if you’re using OLSRD in a secure mode. The secure mode causes the node to exchange cryptographic messages with other nodes in the mesh network. Strong cryptography benefits greatly from the use of a high quality random number generator. Also, the system load should decrease since the task of producing random numbers is offloaded to a dedicated hardware device.
Here’s a link to a quick how-to with the steps for enabling the hardware random number generator on the Raspberry Pi:
HSMM-Pi Blog 
I wonder how OLSDR secure mode would be construed under Part 97.113 (messages encoded for the purpose of obscuring their meaning). I suppose for part 15 devices it’s of no concern, but things might get interesting for nodes running 1 or 2W…
Cryptography and amateur radio has been a pretty hot issue lately.
73
Mike K2MTS
Heh, OLSRD, clearly I have SDR on the brain lately…
OLSRD uses encryption to prevent unauthorized access to the network. I think it’s comparable to keeping a repeater’s control codes secret. All other OLSRD communications are sent in the clear; only the identity challenges and responses are encrypted to prove that a mesh node is authorized. Here’s a link to an interesting article that makes this argument:
Click to access Data%20Encryption%20is%20Legal.pdf
Similarly, if using SSH to connect to mesh nodes then you should not encrypt the communications once authenticated, but it makes sense for the authentication step to be conducted securely. I’m not aware of any legal cases around this issue, but it seems to reason that encryption for the purpose of limiting access should be allowed.
Hi Scott,
A couple more comments!
Is it possible that you can create a feature request page on the blog?
I have a couple that I have been thinking about the last few days! I will first give a little explanation! I think that the Pi (or Beaglebone) would probably be most useful as an end node at this point. It is extremely powerful for what we are asking it to do, and more expensive than a WRT54G to get up and running. Where we would probably use them is in the shack, or someplace where we want to offer services. So, that said, features that make it more powerful in that application are the most interesting to me.
We are in a pretty tough area for Mesh, and it is going to take a lot of ‘hops’ to get us all connected here in the mountains, so an option that would be useful in the short term would be a simple way to create something like a vpn to link remote mesh nodes. I know it is not what we want the end state to be, but like I said in the short term it would bring other nodes up that could be cut off for some time. (That might build a node and then forget about the idea because they are currently unable to participate)
The other thing that I am interested in is the ability to add a second antenna to the node. The linksys hardware allows me two antenna ports. We need the ability to add another interface I think to make it most useful. I am not sure the easiest way to do this.
I bought a couple more adapters this last week, and have had one up on my pi for several days now and it seems to be stable. I did have to remove the hotplug line from the interfaces file as was previously suggested. They cost 10.38 ea and have the RT3070 chipset.
http://www.ebay.com/itm/130681769345?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649
Drew
Drew,
I saw some mention of ‘private tunneling’ on the hsmm-mesh.org website, but no real documentation or Howtos. So it would seem it can be done, but documentation seems to be on the thin side.
73
Mike K2MTS
I did find some instructions somewhere, but they were extremely complicated, and it seems like there might be a better way to do that in the background, rather than expect the average joe to figure it out for himself. It ought to be a configuration option that can be turned on or off.
Totally agree, I’ll let it soak for a while on my Pi before automating it.
Reblogged this on Assaf Shomer .
First off, typo from the future: “UPDATE (9/16/2014)”.
Second, I don’t blame Bruce Schneier, and those who follow his blog (including myself), being cautious of using hardware RNG chips. After the revelations of Edward Snowden about the NSA, everything is certainly suspect. However, you don’t have to rely solely on hardware RNG tools to feed your entropy pool, but I would not recommend ignoring them either.
There are many ways to feed your entropy pool, with both software, and hardware. There are the “Entropy Keys” from Simtec (which is currently out of stock) which will deliver about 4 Kpbs of true random data to the pool per key. You can install haveged on your Raspberry Pi, which in turn will feed your entropy pool with about 1 Mpbs true random data. You can also add external sources, such as sound cards or atmospheric noise from radios. All in conjunction with your Broadcom hardware RNG. The more you’re mixing the pool, the better you are.
Lastly, I call into question whether or not an attack on a tampered hardware RNG is practical. There are too many variables that must be known on the internal state of the system before the encrypted data can be practically broken. Again, I agree with caution, but I’m also practical. Suppose you generate a long-term PGP key for use with Top Secret documents, using the Intel DRNG, which is supposedly tampered with by the NSA. Can the NSA break my encrypted private key? If so, how? Because from where I’m sitting, they need to know my passphrase encrypting the key, when I generated it, where I generated it, and the state of the system during generation.
We have statistical analysis tools to verify the quality of randomness, such as the Diehard and NIST tests. If you let the tests run long enough, patterns will begin to emerge on tampered RNGs, and it should be noticeable that they are not trustworthy. I’ve run these tests on my Raspberry Pi for days on end, and while errors emerge, and that’s expect (no errors would certainly be suspect), I haven’t found anything that would lead me to believe that I cannot trust the Broadcom HRNG on the Rpi.