Good hash algorithm for Moteino for verifying data payload integrity?

[kobuki]

@kobuki What approach would you take when it comes to garage door commands?

Well, there are several approaches I'd consider. A good hash that fits the Atmel is a good candidate. Repeating messages a few times and comparing the important parts of the payload in subsequent ones is also a possibility. For controlling home or garage doors some added security might be important, like code hopping sequences against message repeating attacks. There is a good thread about it here, look for "jump codes" or "code hopping" or similar, I don't have the topic link handy, sorry. And, of course, using the built-in encryption is probably always a good idea, using a strong random key. For a simple door opener probably all of these can be implemented. Most of these already has proven, free code on the net for these chips, so there's no need to re-invent the wheel in each case.

[WhiteHare]

If using listen-mode, I think it may make sense to keep the initial packet to a listening node short so that, in theory, the time its RFM69x  spends cyclically doing  16ma Rx can be  minimized.  However, follow that short packet by immediately sending to the same node a longer packet that can be 72+ bits long or however long it needs to be to have confidence in the integrity of the packet.  The idea is this: the node decodes the first small packet, sticks it in the FIFO for the ATMEGA328P, and then issues an interrupt to the sleeping ATMEGA328P, which then starts to wake up from deep power down sleep (which I've measured taking about 2.1ms on an 8Mhz Pro Mini, and so I'm assuming it would take the the same amount of time on a Moteino).  Now, while the ATMEGA is waking up, the RFM69 stays in receive mode, burning 16ma regardless, so it's already primed to receive the next, longer packet, which it can then decode and shove into the FIFO also.  Therefore, if by the time the ATMEGA328P wakes up from the first interrupt the ATMEGA finds only the first short packet in the FIFO queue for it to read and not also a longer, properly hashed packet behind it, then it may quickly conclude that the first packet was corrupt and it may command itself (the ATMEGA) and the RFM69x to go immediately back to sleep, forgetting all about the entire episode.

Make sense?  I haven't yet tested that, but that's my current mental model of how it could work and still be energy frugal.

You could if you wished send the longer packet as the first packet, and the energy penalty would be meaningful but not knock-dead terrible, simply because the RFM69x already wastes 16ma for about 1.3ms just waking up on each cycle while in listen-mode, so the percentage difference of energy  wasted by having to listen for longer packets all the time isn't enormous--maybe roughly just a 25% difference or thereabouts, depending on further assumptions.