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
participants (3)
-
futplex＠pseudonym.com -
privsoft＠ix.netcom.com -
Ron McCoy