Hi Henning,<div><br></div><div>Thank you for the responses.  I was indeed looking into attaching VPN-capable boxes at wired points on the mesh to create encrypted tunnels where necessary, not only because the firmware stack I'm using (OpenWRT + ath9k) doesn't appear to support encryption in ad-hoc at present, but also because I would expect such encryption to take a heavy toll on the little 400MHz CPUs of the access points.<br>
<br></div><div>Please see my follow-up question below about olsr-secure ...</div><div><br><div class="gmail_quote">On Tue, Mar 1, 2011 at 1:28 AM, Henning Rogge <span dir="ltr"><<a href="mailto:henning.rogge@fkie.fraunhofer.de">henning.rogge@fkie.fraunhofer.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Tue March 1 2011 06:49:13 Ben West wrote:<br>
> First off, a low-level question ...<br>
><br>
> Is any information available about the key (type, content, length) used by<br>
> the olsr-secure plugin?  I see that the module exists in v0.6 of OLSR, but<br>
> I can't find any documentation about how to generate the key file.  Also,<br>
> am I correct in undestanding that his plugin basically works to prevent<br>
> route spoofing by an untrusted node, but not to actually encrypt mesh<br>
> traffic?<br>
</div>The secure plugin does not encrypt the traffic of the mesh at all, its just a<br>
group-key based signature system for the OLSR packets. The key has to be<br>
supplied in a textfile.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Are there requirements on the key in this text file, or is it arbitrary?</div><div><br></div><div>I.e. could it be any sequence of characters, ideally of some non-trivial length and with decent entropy?  E.g. an MD5 hash of the current UNIX time?</div>
<div><br></div></div>-- <br>Ben West<br><a href="mailto:westbywest@gmail.com">westbywest@gmail.com</a><br>
</div>