Suggestions, Maybe Questions
Closed this issue · 4 comments
Had a few suggestions, take it for what it is, just a couple things I've thought to myself while writing both an M17 decoder, and more recently, an encoder as well. Not sure if any of these would potentially be detrimental to actual hardware radio performance or cause any strange side effects with decoding otherwise.
- Use the reserved bits in the LICH chunk to signal CAN and Stream Data Type. For example, while not spec, I wrote my encoder to insert the CAN value into bits 43,44,45 and the data type value into bits 46,47 into the reserved bit field of each Link Information Channel. I figured this may be beneficial if signal is marginal/bad, or late entry, and it at least allows radio users to receive some voice, without having to wait on a completed and correct LSF to be assembled.
-
Send Multiple LSF frames prior to transmission of stream or packet data. Just in case of signal issue or similar, might be beneficial to send multiple LSF frames prior to voice or data.
-
Use the Encryption Subtype field during AES encryption to explicitly set the length of the AES key. 01 = 128; 10 = 192; 11 = 256;
I haven't seen a definitive answer as to the actual length of AES-CTR key expected, but I've seen the m17-tools seemingly support a variable len key based on a semi-forced user input len, but it seems to be stuck at 128-bit only with the nb and nk values hard defined. Using the subtype field alleviates the need to have an encoder/decoder guess the key len value based on the supplied len of the key. If a user supplies a key value of a random short value, like 69, should that be treated as a 128-bit key, 192-bit key, or 256-bit key? That value, while not secure, having a ton of leading zeroes is still just as valid as '1234567890ABCDEF 6969696969696969 7777777777777777 1234567890ABCDEF', and using the subtype field will force the encoder and decoder to a fixed len. Either that, or just always force 256 on that enc type?
I also realize most ham users aren't particularly interested in using encryption by any means, so I can understand that that is pretty low priority or no priority, and maybe just leave it up to individuals to implement in their own desired methods that aren't entirely in spec.
Anyways, those are just some random suggestions I had.
Thanks for your recent updates on dsd-fme!
- If you can not retrieve the whole link setup data from LICH chunks - the stream is not for you (too low signal). Receiving garbled speech is nothing good.
- If, with all the FEC, you would need to receive multiple LSF in a row to be able to decode it - see above.
- Again - if the user doesn't know the key's length in advance - it means the transmission is not for them.
m17-toolsis lacking, so don't treat is as a reference. Especially when it comes to encryption.
Is Extended Callsign Data found in the Meta field encoded as UTF-8, or Base 40? Manual doesn't specify, and also, Meta has more bytes to work with, so didn't know which.
Okay, I found it on page 40, I guess it helps to actually read from time to time.