OP25 DES-OFB decryption support

[MTL_Emergencies]

DES-OFB traffic decryption (known key) is now supported on boatbod's fork.

How to get it working?
- Define key variables (16 hex chars) in the key file (such as example_keys.json). Make sure to specify 0x81 as algid.
- Authorize encrypted traffic sync by specifying crypt_behavior as 0 or -1.

New crypt_behavior implemented: -1
When users specify -1 as crypt_behavior, all non-encrypted transmissions will be muted and voice will only be produced on encrypted conversations.
Why? Because often times HDUs are missed and transmission start will produce undesired "encrypted sounds". This behavior (-1) will automatically mute superframes missing encryption info to prevent the generation of undesired "encrypted sounds".

Seeking testers for DES-OFB on TDMA.

 

[ki4hyf]

New crypt_behavior implemented: -1

Will/could this be implemented for RC4?

 

[MTL_Emergencies]

This feature works regardless of the encryption type.

 

[ki4hyf]

Interesting. It segfaults with me when I try to use it with RC4.

 

[ki4hyf]

Update: I was anticipating log requests so I enabled logging (-v11) and it works fine, even with dumping to /dev/null. When I remove -v11 it segfaults on first transmission. Makes me think it's definitely something on my end.

Nice feature, it fixed the split-second garble at the beginning of an encrypted transmission.

 

[ki4hyf]

Update 2: I did a fresh install, but reused my config files. I had a chance to test some, and it will segfault on -v levels less than 9. For me, 9 is the magic number.

 

[MTL_Emergencies]

I do recall messing with a level of verbosity = 9 somewhere in the mute conditions.
Does the bug happen on FDMA or TDMA conversations?

 

[ki4hyf]

I was testing with p25 FDMA. I haven't tried Phase 2.

 

[MTL_Emergencies]

Thanks, I was able to reproduce the bug on my end and corrected it. I opened a PR on github to correct the error on boatbod's repo.