Brian, Jakub, On 01/15, Gix, Brian wrote: > This is a very dangerous course of action. The suggested patch might > potentially cause a node to re-use a sequence number more than once, > which would cause a "dirty nonce" condition, and allow unauthorized > entities to derive the encrypted data without the keys. Good point. Note that his is also possible in the current implementation: since seq_num is applied to nonce with a 24bit mask, it's going to wrap around. > While this is technically possible, especially with a daemon that > might be looping back messages internally without ever using the OTA > interface, it is not really possible in an actual BT driven real life > system. There is another option to exhaust the 24 bit range: we have the overcommit mechanism in the storage. Let's say the daemon starts, sends a few messages (and overcommits the sequence by a certain value), then either the daemon, or the system crashes. Do that a few times, and you end up with storage containing sequence number exceeding 24 bits. > Beacuse we store sequence numbers internally with a u32 sized data > type, we should *let* the value go over the max legal sequence > nunmbver of 0xFFFFFF (perhaps capping it at 0x01000000 to prevent > "super overflows"). Then we *reject* all send requests with a > sequence number > 0xFFFFFF. Sounds good. -- Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND
