[OpenTRV-dev] Thinking aloud: preventing replay attacks

[Damon Hart-Davis]

Well,, except that the sizes of all the parts used in the IPSec (numbers of bits in hashes) are potentionally too large for our 64-byte frames if we’re to actuslly get any data in there, but that’s another matter!

Rgds

Damon

> On 8 Dec 2014, at 21:09, Bruno Girin <EMAIL ADDRESS HIDDEN> wrote:
> 
> 
> 
> On 8 December 2014 at 00:43, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> >
> >
> > Thought…
> >
> > 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.
> 
> I think that I just badly reinvented something like the IPSec sliding window mechanism, which is potentially fine…
> 
> http://www.ipsec-howto.org/x202.html
> 
> 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?
> 
> Bruno
>