<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 8 December 2014 at 00:43, Damon Hart-Davis <span dir="ltr"><<a href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
><br>
> Thought…<br>
><br>
> I imagine that at pairing / key exchange that I could set a largish (eg 64-bit) counter at both ends to the same value (or just 0) and send its value or a hash of it with nonce in each encrypted frame, and the hub with lots of memory could remember all previous values used to reject any replays and/or reject any received counter value less than the starting value and allow only a smallish window for new values to allow some frame loss.  In fact maybe the hub only needs the counter which it advances to the received value when it gets a decent frame.<br>
<br>
</span>I think that I just badly reinvented something like the IPSec sliding window mechanism, which is potentially fine…<br>
<br>
<a href="http://www.ipsec-howto.org/x202.html" target="_blank">http://www.ipsec-howto.org/x202.html</a><br></blockquote><div><br></div><div>Good. That proves that you were thinking along the right lines and the fact that you checked before implementing saved time. Besides, adapting a mechanism that is used by IP will lead to consistency and make it a lot easier for people to accept it. IPSec over RF?<br><br></div><div>Bruno<br><br></div></div></div></div>