Re: PKZIP - Encryption
"L. DEkel" writes:
PKZIP Encryption:
PKZIP encryption is often said to be: Weak, "a joke" ,"a deception" etc. Maybe it's time to put things in the right perspective.
One must realize (yet again) the difference between: Theoretical Cryptography - and - Practical Cryptography:
"Perry E. Metzger" writes:
I could see why one would want to use a weak encryption system if it bought you something. However, good encryption systems are as cheap to use as bad ones. Therefore, why ever use a bad one? If the top of the line lock costs the same amount as a toy lock, why buy a toy?
Your remark is basically correct, here are few clarifications: I didn't recommended PKZIP for encryption, I said it's an Archiver that has an option to encrypt it's files, and that Practically this encryption is not so bad as people think. About costs: a complete system, including hardware, to support "full armor" for a computer, is far more expensive than using PKZIP, so the question is again of money, but that depends of what you're trying to encrypt. If you are a bank for example, it would make sense to spend several thousands on such a system, if you just send your friend a letter once in a while, containing a movies lists, than PKZIP is enough, you don't have do use say PGP. An good opposite example is PGP: you could define it as an Encrypter which has an archiving option (Of course it archives for the purpose of encryption), so why not use PGP as an archiver instead of PKZIP ? Because: There is the question of convenience (security=1/convenience - postulate), people don't like to pass their plaintext through several utils, where one compresses it, the other encrypts etc., they want a convenient util to use. But: Who says this old postulate (security=1/convenience) is correct today ? you can write a program/script/batch to do all sorts of dirty jobs, why not write a multi-purpose: compression/encryption/mailing/etc. system ? or just use a simple script/batch util to "glue" the different utils together ? Of course it has been done: (here are some examples) compression/encryption system - with HPACK archiver which uses PGP, the UC2 (PRO) archiver which uses 3DES. encryption/mailing(sometimes with compression) system - PEM, RIPEM etc. More problems there: These utils are not "standard" as yet, many people say they want a popular archiver where they know "everybody" use, and PKZIP is among the popular and multi-featured among the archivers, so why,they say, would they bother to adopt an esoteric encrypter or archiver ? The main problem: people are not "privacy protecting" oriented, they don't care too much about the subject. ("who will bother to crack this system just to read my mail ?") What do we do ? Educate them of course. That is why the spread of knowledge in the subject is so important. (Knowledge, not unsubstantiated rumors). All in all, there is no reason not to use a crypto system, if you think your privacy/safety are in danger. I claim that in this world of compromises, choosing PKZIP is not as bad as presented, knowledge should be passed to all user about the risks involving the use of one system or the other, but there is too much rumors that obscure the subject and can misguide a user, not versed in the field of cryptography. And if you "must", choose PKZIP (it is better encrypting then none, and better than some, like ARJ, but certainly not among the best). ,,,,,,,,,,,,, DEkel (noXys) '''''''''''''
L. DEkel writes:
"Perry E. Metzger" writes:
I could see why one would want to use a weak encryption system if it bought you something. However, good encryption systems are as cheap to use as bad ones. Therefore, why ever use a bad one? If the top of the line lock costs the same amount as a toy lock, why buy a toy?
There is the question of convenience (security=1/convenience - postulate), people don't like to pass their plaintext through several utils, where one compresses it, the other encrypts etc., they want a convenient util to use.
I think the point is that the postulate is true only because the people who write "convenient" software usually either don't have a proper clue about security or are afraid of crossing ITAR. Secure encryption algorithms are intrinsically no less convenient than insecure ones. Quite the opposite, from what I've seen: secure algorithms tend toward simplicity, because it's easier to prove theorems with a simple algorithm than with a convoluted one. RC4 is a fine example of this, astonishingly uncomplicated. It's as easy to drop IDEA into a compression/archiving utility as it is to put in the dreaded "proprietary" algorithm. Easier. And if you don't want to pay the licensing fees, use Blowfish or 3-DES. Why these companies don't is a anybody's guess. Take the example of StuffIt on the Mac, which started out with DES and moved to some internally produced algorithm for reasons no one at Aladdin has been willing to explain to me, even when I asked with relative bluntness. Evidently, it was worth some trouble to them to _reduce_ their security, of all things. That is a sad, sad situation. (No particular flame on Aladdin, other than the obvious technical one. They're a fine bunch of folks, from my experience.) -- Will
participants (2)
-
L. DEkel -
W. Kinney