FW: Cryptography Revisited

[Paul Robichaux <paul@fairgate.com>]

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.