Re: Reformated: How secure....
(Re Steve O's Privasoft followup) Your reply didn't really answer all the questions that have been raised. You mention a 2 digit key extension, so does that mean the key is 11 digits? If not, how is a key extension different from a key? Given that the program is exportable, why is it any stronger than any other exportable system? Re how you would recognize readable text: if the scramble is good, the output would tend to look like white noise. An invalid decrypt would have the same general look. But a valid one would have the properties of a normal fax, which is long run lengths. So if you do a run length check on the data, you could readily distinguish a valid decrypt from an invalid one. Incidentally, I looked at the sample encrypted document on the web. It has an amazing amount of structure in it, and certainly doesn't look at all like the white noise I expected. That in itself suggests a weakness. (Notice the dashed lines running down the page, 7 of them...) Also, you forgot to address the known plaintext attack. If I have both plaintext and cyphertext, then recognition of the correct decryption is no longer an issue (it's simply a compare). For the system to be valid by modern standards it has to be secure against a known plaintext attack, and preferably against a chosen plaintext attack. (In other words, if I get you to fax an image of my choosing I should still not be able to recover the key.) It doesn't appear that it is secure in that sense. Finally, the property you mention of being able to cope with damaged images doesn't sound at all unique. You would fail to have this property if you use a block cypher with long blocks, a cypher with error propagation (e.g. CBC mode in DES), or any cypher applied to the compressed form of the fax. But any stream cypher or transposition cypher (as I gather you use) applied against the raw bitmap has this property, since any flaws in the encrypted image would simply become noise in the plaintext image. (A black line would become a gray line in a stream cypher; in a transposition cypher it becomes pixel dust on the page.) paul
participants (1)
-
Paul Koning 1695