AES/Scrambler Values seem to flip flop in the PDF

[lwvmobile]

Also, need clarification as to which value is the correct value, and also, if possible, can you advise on the key len for AES-CTR (M17-tools seems to use 128/192/256, while M17_implementations uses a hardset AES256 that isn't variable.

[sp5wwp]

I think Table 2.8 has AES and Scrambler swapped.

[sp5wwp]

The only implementation in M17_Implementations doesn't support any encryption.

[lwvmobile]

The only implementation in M17_Implementations doesn't support any encryption.

I misspoke on that, I meant to say OpenHT-fw-test which also uses the value of 1 for AES, and 2 for Scrambler.

[kc1awv]

Resolved with #126

[sp5wwp]

1. M17_spec enumeration issue fixed and made consistent with m17-tools.
2. cps.h was taken from OpenRTX and will be used until we move to using a submodule.

[lwvmobile]

I don't mean to be 'that guy', but that's currently the opposite of M17-tools does. They also use the value of 1 for AES.

[sp5wwp]

I hope all is settled now.

[lwvmobile]

You're going to want to make the same change to m17-rtx-gui as well

https://github.com/M17-Project/m17-tools/blob/51d2cb4cc2a57d94899e79617379ab81e775fe1b/apps/m17-rtx-gui.cpp#L1036

And who knows where else those values are enumerated incorrectly at. I would assume since it was reversed in the mod tools, its probably also reversed on the demod tools.

https://github.com/M17-Project/m17-tools/blob/51d2cb4cc2a57d94899e79617379ab81e775fe1b/include/m17cxx/LinkSetupFrame.h#L26

Not sure if there are any other places or not, those are just the ones I could find with a quick search.

[sp5wwp]

Fixed both.