I've been sniffing messages sent from some Avi-on CSRmesh devices that I have, and csrmesh.crypto.decrypt_packet is giving me garbled data (but a valid hmac) for messages where the 4th byte is non-zero.
I believe this is because the SEQ length in the CSRmesh protocol is 3 bytes not 4 bytes and the 4th and 5th bytes in the packet are the message's source address. This fixes the decryption for me and matches nicely with the 3 byte SEQ followed by a source address used in the Bluetooth mesh profile's network PDU (which looks to be heavily influenced by CSRmesh).
The reason this is breaking decryption is because the IV includes a 1-byte 0 padding between the SEQ and the source address / magic field, which is shifted by one byte if the SEQ is treated as 4 bytes. If the first byte of the source address is zero then this shift doesn't change the message and everything still works. Messages sent from devices not on the network (like a phone app or this library) always come from a source address of [0x00, 0x80], so this is not an issue for make_packet.
I've been sniffing messages sent from some Avi-on CSRmesh devices that I have, and csrmesh.crypto.decrypt_packet is giving me garbled data (but a valid hmac) for messages where the 4th byte is non-zero.
I believe this is because the SEQ length in the CSRmesh protocol is 3 bytes not 4 bytes and the 4th and 5th bytes in the packet are the message's source address. This fixes the decryption for me and matches nicely with the 3 byte SEQ followed by a source address used in the Bluetooth mesh profile's network PDU (which looks to be heavily influenced by CSRmesh).
The reason this is breaking decryption is because the IV includes a 1-byte 0 padding between the SEQ and the source address / magic field, which is shifted by one byte if the SEQ is treated as 4 bytes. If the first byte of the source address is zero then this shift doesn't change the message and everything still works. Messages sent from devices not on the network (like a phone app or this library) always come from a source address of [0x00, 0x80], so this is not an issue for make_packet.
Current IV format used by decrypt_packet
IV format I believe is correct