<div dir="ltr">Hello,<div><br></div><div>Jeremy I think has answered the broadcast issue, so I will focus more on the entropy issue.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 24, 2013 at 3:48 PM, Miles <span dir="ltr"><<a href="mailto:myles@tenhand.com" target="_blank">myles@tenhand.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br>On Wednesday, October 23, 2013 9:18:36 PM UTC-7, Paul Gardner-Stephen wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Howdy,<div class="im"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div><br></div></div></div></blockquote>
<div>I think it is better that we harvest a nice lump of entropy from the radios rather than install random data (that might give naughty people help reproducing your private keys). We could read RSSI levels from the UHF radio, hash it a couple of times, and feed some bits into the entropy pool. This would just require talking to the radio a bit, which isn't too hard.</div>
</div></div></div></div></blockquote><div>Using the radio as a HWRNG is interesting. Wouldn't RSSI be easily predictable (and influenceable) by any observer with an SDR radio? At the very least you'd need to tune the radio to an unknown channel, bandwidth & hopping code first. Or use the difference between the two radios in a clever way. User space clock solutions like havaged or DakaRand seem easier. </div>
</div></blockquote><div><br></div><div>I think clocks are good to use, also. For the radio RSSI, we could easily make an entropy gathering mode where the radio hops over quite a wide band, perhaps from about 870MHz ~ 1000MHz in a random pattern sampling ambient energy levels, i.e. without talking to a remote radio, just listening. Combine that with some clock input, and feeding the RSSI results into the forward channel selection to help further randomise the hopping sequence while sampling for RSSI, and we should be able to make a fairly robust entropy source. Thoughts?</div>
<div><br></div><div>Paul.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><blockquote type="cite"><div dir="ltr">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div></div></blockquote><div>I am not sure how easy it would be to detect the address conflicts when they occur (regardless of address range and size). It would probably require some careful thought and work to implement it</div>
</div></div></blockquote></div>
</div></blockquote><div><br></div></div><div class="im"><div>I agree that it is ugly in many ways, short of getting a doctoral student to work on the problem for a few years. Even then, we still need a solution until then. Let's keep thinking about it for a few days and see if either of us can come up with a good solution.</div>
</div></div></div></div></blockquote><div>IP collisions could be an unintended accident or a deliberate DOS. In the case of DOS, doing nothing seems better than amplifying/feeding the energy monster. </div><div><br></div>
<div>Using the Mac -> IP conversion, we know that any accidental collision will share our last 3 MAC bytes. But the odds are very good they won't share bytes 2-3. </div><div>RARP/ARP/RARP would be awesome if it didn't fail for hidden/distant/lossy nodes. </div>
<div><br></div><div>Nodes with IP address conflicts can still send and receive broadcast traffic. What is serval already broadcasting that we could use to look for trouble unicasting? </div><div>Broadcast to nearest node's (serval?) echo service, unicast to them, if the response doesn't come back, re-Ip? </div>
<div><br></div></div><div class="HOEnZb"><div class="h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:serval-project-developers%2Bunsubscribe@googlegroups.com" target="_blank">serval-project-developers+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a href="mailto:serval-project-developers@googlegroups.com" target="_blank">serval-project-developers@googlegroups.com</a>.<br>
Visit this group at <a href="http://groups.google.com/group/serval-project-developers" target="_blank">http://groups.google.com/group/serval-project-developers</a>.<br>
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank">https://groups.google.com/groups/opt_out</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubscribe@googlegroups.com.<br />
To post to this group, send email to serval-project-developers@googlegroups.com.<br />
Visit this group at <a href="http://groups.google.com/group/serval-project-developers">http://groups.google.com/group/serval-project-developers</a>.<br />
For more options, visit <a href="https://groups.google.com/groups/opt_out">https://groups.google.com/groups/opt_out</a>.<br />