responce to graphic encryption replies

First, I would like to address the issue of David C.'s spam of the 
usenet. Mr. Clavedetcher does not work for nor does he represent us in 
any way. After receiving word from Cypherpunks that he had spamed the 
list I personally contacted him and informed him to cease and desist 
these actions or face legal action. We at PrivaSoft do not conduct nor 
condone such actions on the Net. During my conversation with him I 
discovered he was a zealous individual looking to make good on our 
rebate program, as per our Web page. If you should receive any further 
spams from him or any other over zealous netuser, Please contact me 
immediately. Also if you could inform me of other news groups/ lists he 
spammed so I may contact them as well regarding this. Thanx.

    Second I would like to begin addressing several of the issues 
raised by my inquiry of Graphic Encryption. Firstly Graphic Encryption 
is the scrambling of a graphic image using an encryption algorithm. In 
PrivaSoft's case the Image is that of your document, including all text 
and graphics contained therein. Syntel Sciences, the distributor of 
PrivaSoft, does not wish to publish its algorithm at this time, however 
if there is any question as to the strength of PrivaSoft and its 
Graphic Encryption engine, I would be happy to post a sample document 
for you to try and crack. Also, I have recently put together an info 
sheet on the Security provided by PrivaSoft which I can post if there 
is interest. 

    One of the key strengths, as I see it, of graphic encryption is 
that during decryption via hacking, there is an added time element when 
a human interface is required to verify the product, ( since it is a 
graphic picture being produced, regular checksums for intelligible 
words can't be used sans implementing OCR), even if this is only 10 
milliseconds per try this is increases the time to crack exponentially 
beyond that of a data encrypted document of similar key length and 
algorithm strength. 

    Once again I would like to apologize on behalf of Syntel Sciences - 
PrivaSoft for the nuisance caused by the spam done by David C. and I 
wish to reiterate that such actions are not condoned by us and will not 
be tolerated.

Steve Orrin
Mgr. Tech. Services,  PrivaSoft

*************************************************
PrivaSoft TM                                    *
Distributed by Syntel Sciences, Inc. USA        *
1877 Springfield Ave PO BOX 600                 *
 Maplewood NJ 07040-0600                        *
Tel. 201-378-8865  Fax. 201-762-3742            *
Http://www.privasoft.com/privasoft              *
E-mail: privsoft@ix.netcom.com                  *
*************************************************

Steve Orrin writes:
> Also, I have recently put together an info sheet on the Security provided 
> by PrivaSoft which I can post if there is interest. 

I for one am interested. Perhaps you could put it up on your web pages ?

[...]
>     One of the key strengths, as I see it, of graphic encryption is 
> that during decryption via hacking, there is an added time element when 
> a human interface is required to verify the product, ( since it is a 
> graphic picture being produced, regular checksums for intelligible 
> words can't be used sans implementing OCR), even if this is only 10 
> milliseconds per try this is increases the time to crack 

This is an interesting point I hadn't previously considered. Can anyone
comment on the state of the art in fast approximate character recognition ?
I expect that the people working on recognition of text in TV pictures etc.
would have a good idea. 

My lay computer scientist's guess is that it wouldn't be all that difficult to
pick a small sample window a couple of characters wide, and decide if the
contents were a couple of characters. Then you'd worry about testing for
higher-level linguistic intelligibility as a second cut. But I don't
really know.

A known-plaintext attack on the system would ideally include knowledge of the
typefaces, fonts etc. typically used to print documents at the source.... 

> exponentially 
> beyond that of a data encrypted document of similar key length and 
> algorithm strength. 

ObTheoretician:
Um, exponentially in terms of what ?  It sounds like this multiplies the
expected brute force cracking time by a constant, but doesn't change the
big-O time of the algorithm. I agree, however, that big constants can be
rather significant when it comes to real world applications.

-Futplex <futplex@pseudonym.com>

> 
> Steve Orrin writes:
> [...]
> >     One of the key strengths, as I see it, of graphic encryption is 
> > that during decryption via hacking, there is an added time element when 
> > a human interface is required to verify the product, ( since it is a 
> > graphic picture being produced, regular checksums for intelligible 
> > words can't be used sans implementing OCR), even if this is only 10 
> > milliseconds per try this is increases the time to crack 
> 
> This is an interesting point I hadn't previously considered. Can anyone
> comment on the state of the art in fast approximate character recognition ?
> I expect that the people working on recognition of text in TV pictures etc.
> would have a good idea. 
> 
[....] 
> 
> -Futplex <futplex@pseudonym.com>
> 

I wouldn't think you would have to use OCR to detect a successful 
decryption. The graphic file is going to have a highly correlated 
structure, long runs of white space etc. The statistics for such a file 
would be different than the random distribution you'd get from using the 
wrong key. Even if the graphics format is compressed, leading to a more 
even distribution, there might be known plaintext at the beginning of the 
file, headers, size etc.


Ron McCoy
Rmccoy@mercury.interpath.net