home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: sci.crypt
- Path: sparky!uunet!wupost!crcnis1.unl.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!agate!dog.ee.lbl.gov!network.ucsd.edu!qualcom.qualcomm.com!servo.qualcomm.com!karn
- From: karn@servo.qualcomm.com (Phil Karn)
- Subject: Re: Another well-intentioned novice's question
- Message-ID: <1993Jan5.184500.29800@qualcomm.com>
- Sender: news@qualcomm.com
- Nntp-Posting-Host: servo.qualcomm.com
- Organization: Qualcomm, Inc
- References: <1993Jan04.051300.26089@rat.csc.calpoly.edu> <cfG9faf0Bwwb4F5T9z@transarc.com> <1993Jan05.160811.29681@rchland.ibm.com>
- Date: Tue, 5 Jan 1993 18:45:00 GMT
- Lines: 11
-
- In article <1993Jan05.160811.29681@rchland.ibm.com> lwloen@rchland.vnet.ibm.com writes:
- >But, an illuminating one, I think. I claim, still, that compression should
- >be done as an economy-of-transmission move and not a security move, per se.
-
- And an economy-of-CPU move too. Most compression algorithms, although
- somewhat CPU-intensive, are still less so than most encryption
- algorithms when implemented in software. So if you compress and then
- encrypt you may actually take many fewer cycles than if you just
- encrypt.
-
- Phil
-