Page 1 of 2 12 LastLast
Results 1 to 25 of 48

Thread: TRBO - Clear audio vs. Enhanced Privacy audio

  1. #1
    Join Date
    Dec 21, 2011
    Posts
    4,892
    Thanks
    4,950
    Thanked 8,389 Times in 2,315 Posts
    Country: Canada

    Default TRBO - Clear audio vs. Enhanced Privacy audio

    Attached is a brief audio test I made of TRBO audio: Clear vs. Enhanced (40-bit encryption). TRBO uses the AMBE+2 codec.

    Moto themselves admits there's a loss of audio quality in Enhanced mode:

    Quote Originally Posted by Motorola
    Enhanced Privacy uses multiple keys and a random number to ensure that the encryption data is different for each data message and each superframe of a voice message. This requires transporting crypto parameters (e.g. key Identifier, Initialization Vector) with the voice or data payload. A voice message, in the case of Enhanced Privacy, requires an additional header and replaces some of the least important bits of the voice payload with the Initialization Vector. The additional header increases the System Access Time except when Talk Permit Tone is enabled (in repeater mode) where the additional header replaces one of the normal voice headers. The replacement of payload bits reduces the voice quality. Note that the reduction in voice quality is barely noticeable.
    I can detect a slight difference. It's much more noticeable after an extended conversation, when we switch to clear mode.

    Basic Privacy is not affected by this.

    Test radio is a XPR7550 with R02.06.04 firmware. AGC enabled. Audio taken directly from master site with TRBOWatch.

    Anyone else have comments on this?
    Attached Files Attached Files


  2. The Following User Says Thank You to Mars For This Useful Post:

    blcomm (Nov 24, 2016)

  3. #2
    Join Date
    Jan 19, 2013
    Location
    In Your Network
    Posts
    2,728
    Thanks
    3,060
    Thanked 1,965 Times in 992 Posts
    Country: Holy See

    Default

    I can't tell much difference. I wish we could tweak the audio like we can with the Astro25 platform though.

  4. #3
    Join Date
    Feb 04, 2012
    Posts
    2,036
    Thanks
    249
    Thanked 912 Times in 401 Posts

    Default

    The basic encryption uses a slightly different key structure than the advanced thats why they need the extra packet. Both use stream encryption so any loss in audio quality must be based on a different sample size or rate in the AMBE encoder.

    I could really use some info on the structure of AMBE+2 codec. this will tell us if the codec is capable of different levels of "digitisation" etc. or if the changes are in the PI header.

  5. #4
    Join Date
    May 15, 2012
    Posts
    364
    Thanks
    92
    Thanked 285 Times in 125 Posts
    Country: Canada

    Default

    Advanced encryption also looses the benefit of error correction on the part of the repeater (assuming you're using one). This is also why using encryption slightly decreases your usable range as well. Basic encryption doesn't work like "encryption" per say, so it isn't affected the same.

  6. #5
    Alpha's Avatar
    Alpha is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Feb 12, 2012
    Location
    Directly above the center of the earth.
    Posts
    2,780
    Thanks
    1,235
    Thanked 1,530 Times in 738 Posts
    Country: Christmas Island

    Default

    Shades of DES-XL all over again. They robbed bits from the audio for sync to make it more robust than regular DES and give it "increased range" (which is mostly market-speak horse puckey) but it sounded noticeably worse.

    With the newer digital vocoders, this is surprising unless they are changing the symbol rates. I can understand them losing the forward error correction or making it less effective, but you'd think that wouldn't affect the audio unless you are in a fringe situation with very high BER where the FEC was doing a lot of correction.

  7. #6
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    968
    Thanks
    391
    Thanked 719 Times in 340 Posts
    Country: Great Britain

    Default

    Oh dear, was it too good to be true? A future AES secured digital tier 2 LMR system that was as good as today's tier 1 P25 <sigh>
    It is a fine thing to be honest, but it is also very important to be right

  8. #7
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    944
    Thanks
    297
    Thanked 694 Times in 258 Posts
    Country: Australia

    Default

    Good call - Yes encryption was an afterthought on DMR, which is why there are silly kludges like replacing the least significant voice bits with the IV. ...

  9. #8
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    944
    Thanks
    297
    Thanked 694 Times in 258 Posts
    Country: Australia

    Default

    Nah, its purely because some bits that are used for voice information are replaced with encryption information. The rate and sample size is the same, however there is, put simply, missing information.

    P25 has no error correction on the least significant voice bits - which results in the voice becoming ever so slightly robotic as the BER starts to increase. TRBO Advanced Privacy simply does away with them altogether.

    Quote Originally Posted by Notarola View Post
    so any loss in audio quality must be based on a different sample size or rate in the AMBE encoder.

  10. The Following User Says Thank You to MattSR For This Useful Post:

    blcomm (Nov 24, 2016)

  11. #9
    Join Date
    Feb 04, 2012
    Posts
    2,036
    Thanks
    249
    Thanked 912 Times in 401 Posts

    Default

    Thanks Matt

  12. #10
    Alpha's Avatar
    Alpha is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Feb 12, 2012
    Location
    Directly above the center of the earth.
    Posts
    2,780
    Thanks
    1,235
    Thanked 1,530 Times in 738 Posts
    Country: Christmas Island

    Default

    Something doesn't sound right. LPC vocoders like IMBE and AMBE don't have "significant bits" like straight D/A conversion. They work by modeling the human vocal tract, which produces 3 types of sounds - voiced, unvoiced and noise. Every bit of speech the vocal tract can make are combinations of these sounds, they compose the "phonemes" that comprise the gamut of human speech.

    Voiced sounds have a pitch, amplitude and duration. These sounds are the "err" and "mm" noises we make with our vocal cords.

    Unvoiced sounds have an amplitude and a duration. These are the clicks and pops we make with our upper palette, teeth and tounge, like "t" and "k" sounds.

    Noise is bits of white noise with an amplitude and a duration. These are the hisses we make with our tongues and teeth, like "s" sounds.

    So, the way the vocoders work is they have a table of all the possible bits of speech the vocal tract can make (about 64 phonemes), and they match the incoming sounds to one of these bits of speech to select the one(s) that match most closely to what the DSP thinks it is hearing. From that it constructs a symbol which is essentially what bit of speech it thought it heard, how loud and what pitch (if voiced).

    Hence, there are no "significant" or "insignificant" bits. Every frame is as important as the next, and when it gets them wrong we hear random wrong phonemes (gollywoggles, or digital crap) or if the frame is lost it tries to use the previous frame over again. In a fringe situation there are enough lost frames every now and then to make the audio noticeably robotic sounding. When the errors get bad enough it goes off the wall and sounds like encryption with the wrong key.

    I can understand how using the error correction data for encryption instead will make the stream less robust but again I maintain that should only be an issue in fringe areas or if the BER is already high for some reason.

  13. #11
    syntrx No Longer Registered

    Default

    Quote Originally Posted by MattSR View Post
    Good call - Yes encryption was an afterthought on DMR, which is why there are silly kludges like replacing the least significant voice bits with the IV. ...
    The only provision for crypto in the standard is a single bit privacy indicator, which you set to 1 if crypto is in use. The rest is left for the vendors to decide themselves, and Motorola just happened to take an unnecessarily kludgy approach.

  14. #12
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    944
    Thanks
    297
    Thanked 694 Times in 258 Posts
    Country: Australia

    Default

    Quote Originally Posted by Alpha View Post
    Hence, there are no "significant" or "insignificant" bits.
    Sure there is. Take P25 for example - 88 bits per voice frame. Those 88 bits are sliced up into 8 different chunks that have either maximum, medium or no error correction, depending on their significance. The most signifcant bits get the most error protection, and the least significant bits get none.

    There are types of bit significance other than the traditional bit ordering that you're referring to above...

    For example, the voiced pitch and intensity information is more important (significant) than the background comfort noise. The people at DVSI made the more important information fit into the more significant bits, and the lesser important information went into the least significant bits (this is not by chance). The error protection then gets applied accordingly:-

    Quote Originally Posted by Daniels P25 Guide, Page 48
    The voice frame bits are rated according to their effect on audio quality and are then protected usingGolay and Hamming codes. The 48 most important bits (u_0 through u_3) are error protected with four (23,12,7) Golay code words. The next 33 most significant bits (u_4 through u_6) are error protected with three (15,11,3) Hamming code words. The last 7 least significant bits (u_7) are not error protected. Construction of the IMBE™digital bit stream into voice code words is given in Figure 4-5.
    Last edited by MattSR; Feb 24, 2013 at 10:52 PM. Reason: formatting

  15. #13
    Join Date
    Dec 21, 2011
    Posts
    4,892
    Thanks
    4,950
    Thanked 8,389 Times in 2,315 Posts
    Country: Canada

    Default

    I'm in favor of Motorola making a "proprietary change" to the standard, in order to support better encryption and audio quality. But they should make it obvious in their CPS that enabling such a feature, breaks the standard/compatibility with other vendors' radios.

    The difference in quality is noticeable after an extended conversation. And let's face it: 40-bit is junk. Hopefully AES-128 will come out (like we've all heard) soon. But I wonder: Since AES-128 is a longer key length (32-bit I believe, as 256 is 64-bit key) will it require the use of more "insignificant" bits? i.e. worse audio quality? This is where the "proprietary" part may come into play.

  16. #14
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    944
    Thanks
    297
    Thanked 694 Times in 258 Posts
    Country: Australia

    Default

    Quote Originally Posted by Mars View Post
    But I wonder: Since AES-128 is a longer key length (32-bit I believe, as 256 is 64-bit key) will it require the use of more "insignificant" bits? i.e. worse audio quality?
    Hi Mars,

    The "insignificant" bits are used for the initialization vector, which artificially increases the key size. By using a larger key (by going to AES128 from say 40 bit RC4) you can get away with a smaller IV, so theres no reason they would need to 'steal' more of the voice bits to make the IV larger.

    e.g. RC4 40 bit key + 72 bit IV gives a key size of 112 bits. AES128 + 72 IV key gives 200 bit key size - the difference between a 40 bit and 112 bit key is significant, since 40 bit keys can relatively easily be recovered. The extra strength in going from a 128 bit key to a 200 bit key is totally academic, neither can be brute forced using commonly available gear.


    Cheers,
    Matt

  17. #15
    Join Date
    Dec 21, 2011
    Posts
    4,892
    Thanks
    4,950
    Thanked 8,389 Times in 2,315 Posts
    Country: Canada

    Default

    Matt: Thanks for the AWESOME explanation. Having you on board is an asset to the forum. Excellent info.

    Is it at all possible Moto could still "break the standard" by giving more data-space back to the voice codec, and maintain 128-bit AES keys? Not that I have a problem with breaking the standard so long as the user knows it's non-compliant. Just curious. (If what I've said is confusing, all I want is secure voice quality, which is same-as-clear.)

    Thanks again!

  18. #16
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    944
    Thanks
    297
    Thanked 694 Times in 258 Posts
    Country: Australia

    Default

    Quote Originally Posted by Mars View Post
    Is it at all possible Moto could still "break the standard" by giving more data-space back to the voice codec, and maintain 128-bit AES keys? Not that I have a problem with breaking the standard so long as the user knows it's non-compliant. Just curious. (If what I've said is confusing, all I want is secure voice quality, which is same-as-clear.)
    No problem!

    I think its likely they won't reduce the voice quality any further. It will probably stay the same as Advanced Privacy. My guess is that they will stay with the same same IV size, and simply move to AES128.

    Cheers,
    Matt
    Last edited by MattSR; Feb 25, 2013 at 04:16 AM.

  19. #17
    Alpha's Avatar
    Alpha is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Feb 12, 2012
    Location
    Directly above the center of the earth.
    Posts
    2,780
    Thanks
    1,235
    Thanked 1,530 Times in 738 Posts
    Country: Christmas Island

    Default

    Quote Originally Posted by MattSR View Post
    Sure there is. Take P25 for example - 88 bits per voice frame. Those 88 bits are sliced up into 8 different chunks that have either maximum, medium or no error correction, depending on their significance. The most signifcant bits get the most error protection, and the least significant bits get none.

    There are types of bit significance other than the traditional bit ordering that you're referring to above...

    For example, the voiced pitch and intensity information is more important (significant) than the background comfort noise. The people at DVSI made the more important information fit into the more significant bits, and the lesser important information went into the least significant bits (this is not by chance). The error protection then gets applied accordingly:-

    Thank you for that explanation and reference. My age is showing, I am most familar with the older LPC type vocoders which gave rise to the MBE types later on, and the weighting of significance is a "new thing" since the old days. The other big difference is the older systems had variable duration phonemes, but the newer MBE systems use fixed-size sample windows, but otherwise they are very similar in function.

    I learned from the guy who invented one of the first original LPC vocoders - an IC for Texas Instruments that was used in the Speak-And-Spell toy (and a payphone I designed later on).

  20. #18
    sanjurjo No Longer Registered

    Default

    DMRDecode can be used to analize mototrbo (show PI header, dump voice frames to a tcp port, etc) , maybe someone with access to a know basic privacy and a know enhaced privacy systems can report what differences they have.

  21. #19
    Join Date
    Feb 04, 2012
    Posts
    2,036
    Thanks
    249
    Thanked 912 Times in 401 Posts

    Default

    There are a ton of differences. The PI is just the tip of the iceburg.

  22. #20
    sanjurjo No Longer Registered

    Default

    Quote Originally Posted by Notarola View Post
    There are a ton of differences. The PI is just the tip of the iceburg.
    Can you provide details of what these differences are.?

    Having DMRDecode to identify basic/enhaced/AES privacy in use on unkown systems will be a nice feature.

  23. #21
    Join Date
    Feb 04, 2012
    Posts
    2,036
    Thanks
    249
    Thanked 912 Times in 401 Posts

    Default

    DMR will tell you its encrypted if you look at the LC voice header. You will see that the FID is set to 10 and the privacy bit is enabled. For enhanced the PI field is also populated.

  24. #22
    syntrx No Longer Registered

    Default

    Motorola describes in this patent how Enhanced Privacy works:

    http://www.google.com/patents/EP2347540B1

    For that matter, most if not all of TRBO's proprietary functionality is described in patents. European Patents contain much less fluff and bull**** than U.S. Patents, and are a lot more useful as reference material, so if you Google for patents to learn about TRBO's inner workings, these are the best candidates.

  25. #23
    standardmissile No Longer Registered

    Default

    As long as Motorola doesn't pull some BS similar to the Skipjack/Clipper Chip fiasco of the 1990s, a move to something better than RC4 should be an improvement. However I think for TRBO a software based DES or 2 key 3DES standard could be a suitable solution for most corporate setups due to the longer key length. 40 bit COMSEC is pretty puny, and anything would probably be better, including some of the rolling voice inversion scramblers on the market.

  26. #24
    syntrx No Longer Registered

    Default

    DES would be a poor choice, and 2/3DES even more so. That algorithm is very slow when implemented in software (which it wasn't designed to be); much slower than AES.

  27. #25
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    944
    Thanks
    297
    Thanked 694 Times in 258 Posts
    Country: Australia

    Default

    Yep, AES-128 makes a lot more sense in this day and age...