ADP vs/ DES-OFB

[ASTROMODAT]

Can someone knowledgable with both ADP versus DES-OFB be so kind as to try to provide an edge-of-the-cuff, overall rough assessment, and break it down inot one of the following four categories:

1) ADP is roughly 50% "as good/powerful,etc." as DES-OFB

2) 90+% as good as DES-OFB

3) Only 5% as good as DES-OFB

4) Not even 5% as good as DES-OFB

Trying to get a rough feel for the difference in protection quality/difficulty to break, etc.

[mrtor]

Can someone knowledgable with both ADP versus DES-OFB be so kind as to try to provide an edge-of-the-cuff, overall rough assessment, and break it down inot one of the following four categories:

1) ADP is roughly 50% "as good/powerful,etc." as DES-OFB

2) 90+% as good as DES-OFB

3) Only 5% as good as DES-OFB

4) Not even 5% as good as DES-OFB

Trying to get a rough feel for the difference in protection quality/difficulty to break, etc.

And I would like to tack on another question for an ADP guru, I asked this a long time ago and never got an answer.

With ADP is it a Static Key that is programmed into every radio and that then is the Key until all radios are re-programmed with the CPS or is it able to be remotely changed via OTAR or similar.

Curious..

Thanks
Mike

[mr.syntrx]

RC4-40 (aka ADP) is a joke. 40-bits is ridiculously short - it's 1/65536 the size of the 56-bit single DES keyspace. Even DES is secure in comparison.

A 40-bit RC4 keyspace can be searched in a few hours with a bunch of $20 Xilinx Spartan-II FPGAs. University students have searched the whole keyspace in a day or two with spare, reasonably modern PCs lying about the campus, at no cost to themselves or their institution. The 34800 year figure to search the entire keyspace touted by our friends in Schaumburg is nonsense - it implies a search rate of just over 1 key per second. A 25 year old pdp11 can do better than that.

A more determined attacker with $10,000 to spend could build a machine to find a key in an average of about 12 minutes. $300,000 would probably get you a key in around 30 seconds, and $10,000,000 would likely get you a key in just under a second.

[ASTROMODAT]

"The 34800 year figure to search the entire keyspace touted by our friends in Schaumburg...”

Where did you get this information about ADP from Motorola, in terms of an article, or one of their publications, marketing literature, etc.? I'd really like to get a copy of any such article, if at all possible, or perhaps a link to somewhere that has this Motorola position documented on ADP (e.g., 34,800 years needed to crack it).

I have not been able to find any Motorola info whatsoever about ADP, so whatever written literature you have is infinitely better than what I have (which is zippo). I'd like to read Motorola's entire spiel, and then decide for myself as to its validity, etc.

BTW, if it takes a couple of classrooms full of EE students a week or so to crack just one single key, or $300,000 computers multiple days, etc. to crack just one single key, that would be way MORE than adequate for what we need for a particular application I have. Now, if it was VPA, or some such rolling code inversion garbage, I'd agree that's a waste of time for anything short of a 9 year old cub scout with a Tandy scanner. The app I have does not require the industrial strength of DES, and ADP may be more than adequate. This way, we could make use the ultra el cheapo XTL-1500 for this particular project.

Keep in mind, too, that if it takes days or weeks (realistically) to crack just one single key, the firmware uplift package on the XTL-1500 that supports ADP also provides Multi Key. This way, we could dump 16 keys into each radio and change the key in use every day, still giving us over 2 weeks before we'd need a key reload. The amount of radios in this application is small, so reloading a fresh set of 16 keys every few weeks in each radio is a no brainer issue.

Thanks, in advance, Mr. Syntrx for any help on this.

[mr.syntrx]

The 34800 year figure was allegedly stated in a paper by /\/\ some time ago. I haven't seen this document first hand, so YMMV.

http://batboard.batlabs.com/viewtopic.p ... ht=adp+rc4

For commercial purposes the security RC4 offers is fine, certainly well ahead of voice inversion junk, but I wouldn't want cops, feds etc using it for drug busts. The cartels and the mafia could easily spare a few grand to pay an EE graduate to build them a machine that would allow them to have The Man's keys before he even got to the door.

The problem with rotating keys in a multikey radio is that which one of those keys you're using on a day to day basis can be determined through statistical analysis of the encrypted data (particularly the first couple of bytes), as RC4 is slightly biased in its output. Cryptographers reccomend that RC4 keys never be reused.

[MattSR]

/revives dead thread

Well, Check this out - straight from the horses mouth it would seem... ADP is RC4 based. The bloke that coded ADP for Motorola has put it on his resume on the web for all to see.

http://members.tripod.com/~rbaz/resumes/projects.doc

[escomm]

but I wouldn't want cops, feds etc using it for drug busts.

Apparently neither does Motorola

Code: Select all

This feature is designed for customers who do not have the money to buy the encrypted modules for Astro Radios but still want privacy from Scanners. 

[alex]

Here's the whole quote from that page...

(ADP) RC4 Encryption:

The ADP (Advanced Digital Privacy) software project is a privacy feature used within the Astro Radios to encrypt audio data and send it to other radios with the same encryption algorithm. This feature is designed for customers who do not have the money to buy the encrypted modules for Astro Radios but still want privacy from Scanners.

I was responsible for finding an encryption algorithm and implementing it in C language which would them be ported into the DSP and Encryption modules for usage. I picked out RC4 because we wanted an algorithm which was private but not so secure that it would take our encryption module customers. RC4 was a private algorithm making is secure but it can be broken by individuals with the money and technology to break it. But for the average listener on scanners, it is secure enough so scanners cannot listen on private conversations.

I also coded the RC4 algorithm and tested it for completeness. I also did performance testing on RC4 in the DSP and checked for loading issues for RC4. Loading issues for the DSP represents the percentage of processor power the DSP would have in encrypting/decrypting encrypted data. It is made by a formula of (RC4 Encryption cycles / Superframe) / (Superframe cycles / Superframe). The percentage is done in percents. I also documented my findings; and also documented the RC4 architecture for the ADP project.

I worked with other engineers to put the code into an assembly format. I worked with others to make sure that the code worked effectively.

[bellersley]

Exactly. People aren't using ADP if they require security like they would with DES-OFB. Heck, 2 bit encryption would be enough to keep the scanners off.

[batdude]

2 bit encryption would be enough

that would be enuf for about 50% of the "snoops" out there...


make it 32 bit and i'll raise that to 99.9 %




d

[mancow]

ASTROMODAT,


Why is rolling code a joke?

Please elaborate just how you would break it.

It sounds like for your application (not highly sensitive) it would be fine.

[motorola_otaku]

ASTROMODAT,


Why is rolling code a joke?

Please elaborate just how you would break it.

It sounds like for your application (not highly sensitive) it would be fine.

Don't bank on getting a reply. He put an egg in his shoe and beat it, as they say.

[tvsjr]

ASTROMODAT,


Why is rolling code a joke?

Please elaborate just how you would break it.

It sounds like for your application (not highly sensitive) it would be fine.

Don't bank on getting a reply. He put an egg in his shoe and beat it, as they say.

And please, please, don't tempt that troll to come back. I wish him and Cowthief all the best, but I'm quite glad to not have to put up with his :o any more.