[serval-project-dev] More on mesh addressing.

[Paul Gardner-Stephen]

Hello,

Jeremy I think has answered the broadcast issue, so I will focus more on
the entropy issue.


On Thu, Oct 24, 2013 at 3:48 PM, Miles <myles@tenhand.com> wrote:

>
>
> On Wednesday, October 23, 2013 9:18:36 PM UTC-7, Paul Gardner-Stephen
> wrote:
>>
>> Howdy,
>>
>>>
>>> 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.
>>
> 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.
>

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?

Paul.


>
>
>>
>>>
>>>> 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
>>>
>>>
>> 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.
>>
> 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.
>
> 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.
> RARP/ARP/RARP would be awesome if it didn't  fail for hidden/distant/lossy
> nodes.
>
> 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?
> Broadcast to nearest node's (serval?) echo service, unicast to them, if
> the response doesn't come back, re-Ip?
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to serval-project-developers+unsubscribe@googlegroups.com.
> To post to this group, send email to
> serval-project-developers@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/serval-project-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubscribe@googlegroups.com.
To post to this group, send email to serval-project-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/serval-project-developers.
For more options, visit https://groups.google.com/groups/opt_out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cpunks.org/pipermail/cypherpunks/attachments/20131025/0dc6497f/attachment.html>