Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!caip!princeton!allegra!ulysses!mhuxr!mhuxt!houxm!ihnp4!cuae2!ltuxa!ttrdc!levy From: levy@ttrdc.UUCP (Daniel R. Levy) Newsgroups: net.crypt Subject: Re: randomly adding bits/bytes (compressing text before encryption) Message-ID: <1144@ttrdc.UUCP> Date: Tue, 19-Aug-86 13:25:49 EDT Article-I.D.: ttrdc.1144 Posted: Tue Aug 19 13:25:49 1986 Date-Received: Thu, 21-Aug-86 00:52:13 EDT References: <8608042018.AA04376@ucbjade.Berkeley.Edu> <7024@utzoo.UUCP> <806@petsd.UUCP> <553@mecc.UUCP> Organization: AT&T, Computer Systems Division, Skokie, IL Lines: 55 In article <553@mecc.UUCP>, sewilco@mecc.UUCP (Scot E. Wilcoxon) writes: >In article <806@petsd.UUCP> joe@petsd.UUCP (Joseph M. Orost) writes: >>In article <7024@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>>> ... Using compress(1) before using crypt(1) or... >>Compressed data is very good for encryption, because it contains almost no >>redundancy, and no constant data (with the header gone). Unlike Huffman >>coding, there is no compression table in the data at all. > >The compress program's output is more compressed as it goes along, so that >the beginning is in practically plaintext. It IS?? Here is an od -c of the first part of the replied-to article, put through compress: 0000000 037 235 220 F 344 274 i 003 202 \r 235 : x 302 204 030 0000020 S ' L 031 031 ! 322 240 q 003 207 F 210 6 e 306 0000040 214 \t 1 247 314 235 4 l 306 274 001 321 344 215 033 020 0000060 A 352 234 001 021 003 007 \b 030 9 t 304 260 241 c 206 0000100 \f 226 9 p 330 P 245 \f 233 0 y Z X ) # 0000120 g N 032 223 : @ 330 ! j 324 $ \b ! d 270 0000140 210 001 c * \b 033 / d 320 x 201 c 306 016 020 F 0000160 351 224 001 A 207 216 034 2 c \ T 251 2 004 212 002 0000200 ( a 350 240 I Z 366 354 F 203 \b 025 2 t \b Q 0000220 " E 213 030 5 r 364 \b R 244 202 200 003 223 v 374 0000240 030 362 \r 220 300 i 327 266 005 201 b 212 H : 212 0000260 270 \0 q 245 360 033 < & S ( p 342 q 316 031 201 0000300 u 340 314 I 352 246 \f 035 027 c 344 344 201 C G 301 0000320 224 : b 324 d 244 223 264 g R 9 a 334 220 031 310 0000340 & 017 210 0 d 310 244 q 263 R L 032 : s ^ 210 0000360 311 # v 016 e 221 m 340 310 ) 3 307 ( s 262 e 0000400 360 ` 026 S 306 314 233 355 312 270 211 = 233 316 Q 0000420 7 242 233 p 237 023 346 L 231 026 I 210 $ 345 Q 243 0000440 306 214 307 031 E 306 026 024 > ( @ D \ e $ U 0000460 222 033 , 260 204 C 013 ) 235 321 202 N / 305 4 S ... Now if someone can show how this is "plaintext" I'd be mildly interested... > I think this is what an earlier >poster meant when referring to a header weakness, not just the 3-byte header. >(Other compression programs tend to have large headers with compression >tables in them.) >-- >Scot E. Wilcoxon Minn Ed Comp Corp {quest,dicome,meccts}!mecc!sewilco >45 03 N 93 08 W (612)481-3507 {{caip!meccts},ihnp4,philabs}!mecc!sewilco > Laws are society's common sense, recorded for the stupid. > The alert question everything anyway. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy