Anybody want to give this guy The Business? Earlier attempts didn't seem to sink in. -Paul

Path: HiWAAY.net!imci2!imci3!newsfeed.internetmci.com!news.mathworks.com!nntp.primenet.com!news.primenet.com!btcarey From: btcarey@primenet.com (Brent A. Carey) Newsgroups: comp.sys.mac.programmer.help Subject: Cryptography Revisited Date: 23 Aug 1996 01:15:01 -0700 Organization: Primenet Services for the Internet Lines: 67 Message-ID: <btcarey-2308960115290001@news.primenet.com> X-Posted-By: @198.68.41.180 (btcarey) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit X-Newsreader: Yet Another NewsWatcher 2.2.0

I am posting again to hopefully clear up my last post on this topic. I have received a dozen e-mail replies since I posted less than a day ago. I believe I poorly represented my request earlier.

I am retired professional with several years of training and experience in intelligence analysis and cryptanalysis. The encryption scheme I developed was employed for 3 years for passing sensitive data over unsecure channels. Working for the government, the original program was written for DOS and enjoyed the benefit of physical security. That is to say, access to the encryption program itself was carefully restricted.

Where I feel I was unclear is on the key to the scheme's security. Any encryption scheme can be cracked provided the cryptanalyst has enough of a sample to work with, enough time, and/or enough processing power. My encryption scheme relies on data bursts of time-sensitive packets. Each machine running the program has its own time and packet signature. The unique signatures make it impossible (nothing is impossible) to decrypt a complete file without access to both the sender's and receiver's signatures. Even then it would take an enormous amount of processing power to crack (more than big business can justify, but not much for major governments). The only way to obtain a computer's signature (which is easily changed on a regular basis), is to have physical access to the computer's encryption application and support files.

With the help of a more experienced DOS programmer, an application was built that provided adequate protection that would increase the time required to extract a computer's signature (even if one knew exactly how to do it), that it was impractical to attempt.

I am now porting the application to the Mac with the intent to sell it to a private contractor that is developing RISC-based computers for specialized use in the government. I have been assured that a PPC native application will run on the computers, and was encouraged to develop the application. Mostly what I need to know is how long it would take a super-human cracker to obtain a signature and how she would do it. If I can increase the expected time to 96+ hours, I'm in business (I always assume half of my best guess - 48 hours is the required specification).

I am developing the code with the help of an excellent Mac programmer. The problem is, that neither of us can crack it at all, although we know that is theoretically possible. He lacks sufficient crypto understanding, and I lack sufficient computer knowledge. Working together we make little progress, and truthfully don't have enough time to develop and crack at the same time. I will not be comfortable with the final product until someone cracks it and I have a sound understanding of the weaknesses that I have not considered.

Finally, MacPGP is a GREAT program. I didn't mean to belittle any of the PGP programs. PGP carries much more protection than necessary for it's intended and practical uses. Granted, it could use a new interface, but it is certainly functional and not lacking in features. Initially, I considered releasing a public version of my application in response to the need for a more Mac-like encryption program. There is no reason for the average Mac user to switch from PGP to my program. It lacks (and will always lack) the features of MacPGP, and although it is more secure than PGP the user must accept some increased inconvenience to realize the bulk of the added security. For most users, this is adding overkill to overkill.

I extend my apologies for posting this huge message off topic, but I felt I had grossly misrepresented my request. I feared the influx of e-mail tomorrow morning if I didn't clarify. I appreciate all those that extended advice. I will follow up on much of it, and I thank those who replied.

Brent A. Carey

-- Paul Robichaux LJL Enterprises, Inc. paul@ljl.com Be a cryptography user. Ask me how.