Ah, OK. Wonder if a bitmap strategy would work for that as well.
Does devnonce recording on the end node need to be that complicated? Does the server actually check if your devnonces are sequential? e.g. 0,1,2,3,4 - after all those are valid random numbers as required in 1.0.2 too, albeit unlikely to be sequential. But bear with me.
So if, for example, you have used devnonce=200, all you need to do is not reuse a lower number so you just store the last devnonce and increment it next time. However, simple incrementing is possibly hackable.
A pet Idea I have is using prime numbers if sequential numbers are a no-no. So, starting with DevNonce=0, next time add a prime number like this. (I believe this is like hashing into a ring buffer)
nextDevNonce=(prevDevNonce + PRIME) & 0xFFFF
of course it needs to be stored in the end device but itâs only 16 bits not a 64k list nor 8k bytesâŚ
Then save it for next time. Using a prime number ensures you donât repeat the same number (unless my maths is flawed) whereas it is possible to randomly select the same number (albeit unlikely) in succession. You know youâve gone past 64k when it wraps back to zero.
Just me thinking out loud.
Incrementing numbers is what the newer specification requires, to get the most out of your credentials the increment should be 1. No need for fancy schemes. Because 1.0.4 doesnât allow smaller numbers then ones already seen wrapping is a no no.
1 Like
That makes sense. I havenât read 1.0.4 yet - just 1.0.2 this evening.