1995-10-13 - Re: responce to graphic encryption replies

Header Data

From: futplex@pseudonym.com (Futplex)
To: privsoft@ix.netcom.com (Steve Orrin)
Message Hash: 07d0d0c3e744894227513d2f4db12e40b340de4a1258bf1aa041dc1bb2b72731
Message ID: <199510130432.AAA14986@thor.cs.umass.edu>
Reply To: <199510121733.KAA18977@ix7.ix.netcom.com>
UTC Datetime: 1995-10-13 04:33:02 UTC
Raw Date: Thu, 12 Oct 95 21:33:02 PDT

Raw message

From: futplex@pseudonym.com (Futplex)
Date: Thu, 12 Oct 95 21:33:02 PDT
To: privsoft@ix.netcom.com (Steve Orrin)
Subject: Re: responce to graphic encryption replies
In-Reply-To: <199510121733.KAA18977@ix7.ix.netcom.com>
Message-ID: <199510130432.AAA14986@thor.cs.umass.edu>
MIME-Version: 1.0
Content-Type: text/plain


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>




Thread