December 2003 - cypherpunks-legacy

RE: "Cypherpunk" vs. "Cryptorebel"
by Claborne, Chris at SanDiegoCA 17 Dec '03

17 Dec '03

On Wed, 6 Jul 1994, Lefty wrote: > >I like the label "cryptorebel" better than "cypherpunk". The word > >"punk" just does not seem right, while "rebel" does. I do have a > >certain attachment to "cypherpunk". Comments? > > If it weren't for nitpickers, we'd all be knee-deep in nits. There is too much "name recognition" in "cypherpunk" for it to be dropped now...IMHO. ... __o .. -\<, chris.claborne(a)sandiegoca.ncr.com ...(*)/(*). CI$: 76340.2422 PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

1 0

Misattribution
by Jeff Gostin 17 Dec '03

17 Dec '03

"Claborne, Chris at SanDiegoCA" <claborne(a)microcosm.sandiegoca.NCR.COM> writes: > From: Jeff Gostin<jgostin(a)eternal.pha.pa.us> >> can't be broken in a reasonable amount of time. I'm interested in what >> most of the people on this list would consider a reasonable amount of >> time though. This isn't from me... *sigh* Misattributed twice in one week. What's this world coming to? :-) Folks, please watch your attributions. I'd like to be quoted for what I do say, and to see that other people get credit for what they say too... Please?? --Jeff

1 0

FW: Physical storage of key is the weakest link
by Claborne, Chris at SanDiegoCA 17 Dec '03

17 Dec '03

<< some suggestion to keep keys secure on floppy>> <<Lance Cottrel writes: If your passphrase is good (128+ bits of entropy), then your private key is as secure as the messages that you send. Although it need be broken only once, I see no real danger of IDEA being compromised in the near future. Given a good passphrase, I would suggest that you want multiple copies of your key to prevent loss or accidental destruction. My passphrase is > 30 characters. Fortunately Mac PGP remembers the key during any given session so typing is kept down a bit. >> If you are really paranoid, keeping your private keys super secure is a good idea. If a bad guy were come and steal them all she needs to do find out your passphrase (using all kinds of attacks.... camera over your desk....) and bingo, they can read all past and future message traffic to you... ... __o .. -\<, chris.claborne(a)sandiegoca.ncr.com ...(*)/(*). CI$: 76340.2422 PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

1 0

FW: Kevin Mitnik
by Claborne, Chris at SanDiegoCA 17 Dec '03

17 Dec '03

<< >From Edupage: ******************* FBI HUNT FOR HACKER Kevin Mitnick is wanted by the FBI for suspicion of software and data theft from leading telecom manufacturers and service providers. Among his victims have been MCI and Digital Equipment. An ex-convict, Mitnick was described by one judge as having an "addiction problem" with computers, similar to a drug or gambling addiction. During a six-month treatment program he was prohibited from touching a computer or a modem, but the treatment seems to have failed, and one detective says: "I've always considered him dangerous. I had to go underground. If he targets you, he can make your life miserable." (New York Times 7/4/94 A1) ************************** >> I also read an article in the Pheonix paper saying that he did a wire tap on the FBI guys that were trying to find him... among other things. QUESTION: How do they know it was him? I get tired of the News dudes printing stuff as if it were fact. ... __o .. -\<, chris.claborne(a)sandiegoca.ncr.com ...(*)/(*). CI$: 76340.2422 PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

1 0

Bit counting
by Ian Farquhar 17 Dec '03

17 Dec '03

>Why bother when you can simply do an eight line function? >int bitcount(char b) >{ >register int retval=0; > if (a & 1) retval++; > if (a & 2) retval++; > if (a & 4) retval++; > if (a & 8) retval++; > if (a & 16) retval++; > if (a & 32) retval++; > if (a & 64) retval++; > if (a & 128) retval++; >return retval; >} [...] Because on a lot of architectures this implementation may be hideously inefficient. All the world is not an Intel chip, thank god. Ian.

3 2

More Mitnik
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

chris.claborne(a)sandiegoca.ncr.com wrote: > I also read an article in the Pheonix paper saying that he did a wire tap >on the FBI guys that were trying to find him... among other things. YES, whether it is true or not that is exactly the sort of stuff we need to get Joe Lunchbox saying "YES!"--and getting Joe Lunchbox on our side* is more important that you know. (Who do you think held down the tax on the beer I am drinking right now? That's right, it was Joe, and I admire that.) We need to watch our image, and Mitnik (if he is smart) is a great way to distact from the pedophile scare. How can people get indignant when they are too busy laughing? The idea of one social misfit wire tapping the FBI (and they want to put wiretaps in the *design*?) is so entertaining--and understandable by Joe Lunchbox--that I can't stand it. -kb * Our side: strong crypto without backdoors for either Mitnik or Freeh is good. Agree? -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

1 0

Tim May and Security for The Millions
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

Tim (yes, it was me--Kent Borg--you quoted the most recent time you said--roughly--that other people's security is no very important to you), there is a very good reason why you want *everyone* to have good security. The fact that "everyone" will use up the snooping resources of the TLAs, leaving less for them to throw at you, is not the main point, for the TLAs might come up with clever secret approaches which allow their resources do amazingly efficient things. What you really want to know is what the state of the art is inside the NSA, what efficient things they can do. (You want to know the *whole* story behind the S-boxes, what Skipjack is, etc.) The best way to do this is to badly, I mean *BADLY*, tempt them to tip their hand. If pedophiles (the canonical/mythical threat) are the threat they see then put the best security we (on the outside) have in the hands of the world's pedophiles and watch the prosecutions. Either the TLAs tip their hands by cracking the 1998 version of PGP 5.0.2 with IDEA^3 or they don't. If they do, you know they cracked it. If they don't you know one of two things: 1) They didn't crack it. 2) They did crack it *but* are too afraid to say they cracked it--which is nearly equal to not having cracked it. (Preventing them from acting on information is close to denying them the same information--the Coventry Legend and all.) A wonderful way for us to drive cryptological research out into the light is to *temp* them into showing their hands, and giving good security to *everybody* is the best way to do that. Following this argument, preventing trivial "quick brown fox"-attacks is part of the job of giving good security to everyone, make them work at the interesting problems. Conclusion: my recent "passwords are hard" tirade is not completely off-subject. More general conclusion: user interface issues ("My Mom" et al) are very important. Certainly, working on the gaping hole of Tempest attacts is very important (any ideas?), but don't forget that RF-snooping of moving notebooks requires risky ~field work~ and bad take-out food, something properly high-tech TLAs hate. Tempest attacks are only worthwhile against juicy targets, while some other attacks are useful in bulk. (For examples of how poor passwords are useful in bulk, read RISKS, use your imagination, and extrapolate to large populations.) Tim, the best way for you to have good security is to put good security in the hands of the millions. -kb, the Kent who can sometimes get personal and use first names -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

1 0

Schneier Claims on Multiple Encryption
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

In Applied Cryptography (at 8.2.5) Bruce Schneier says: "What about encrypting a block once with algorithm A and key K-a, and then again with algorythm B and key K-b? Aside from being susceptable to ... meet-in-the-middle attacks, there is no guarantee that the two algorythms will work together to increase security. There may be subtle interactions between the two algorithms which actually *decrease* security." Wait. If applying a different algorithm with an unrelated key might decrease security, then the TLAs could themselves apply another algorithm with their own unrelated key as an analysis technique, no? Kent's Hypothosis: Superencrypting different algorithms with unrelated keys can never weaken non-trivial algorithms. Stacking DES on top of IDEA on top of Ceasar can be no worse than the strongest of the the set--assuming the keys are unrelated and the attempted security is not through obscurity and the algorithms are not so confused as to be each other's analysis. -kb -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

2 1

RE: Kevin Mitnik
by Random H0Z3R 17 Dec '03

17 Dec '03

Kent Borg wrote: > I am under the impression that I would not like Mitnik personally, but I > have never personaly met him... > Would I turn him in? Well, put it this way: I would not harbor him but > neither would I work very hard to figure out where he is or whether a > particular "nobody" on this list be him. Somehow, I get the idea that the "nobody" you're referring to is yours truly. Well, I'm not him, but your suspicion does bring up a valuable point, though: if you're suspicious that a certain "chained remailer user" is the infamous Mr. Mitnik, then certain TLAs might also share that suspicion. Therefore, anyone using such "underground" services as anonymous remailers should use exceeding care. If they start to use traffic analysis, or any of the other "sigint" techniques discussed here, even though you aren't Mr. Mitnik, you may well get "caught" in their "dragnet".

1 0

Re: Counting bits
by Ian Farquhar 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Just for entertainment value, I clipped your function and compiled it >with Turbo C++ 1.01 in default (ANSI C) mode. Here's the .asm code >produced (comments and setup code edited for brevity) Both Sun C and GCC on a Sun SPARC system running 4.1.3 produced this code for each bit-count line (-O4 optimization used): L77042: andcc %o0,2,%g0 ; AND the bit bne,a L77044 ; branch/anull if zero inc %o5 ; increment bitcount L77044: This, I believe, is as optimized as it is possible to get on a uniprocessor machine. On both compilers, the routine size was 28 instructions total, and that would also be the maximum path length for the execution of this routine when passed an ASCII 255 value. A MIPS-based DECserver running Ultrix 7.1 produced this (again, -O4): $34: lb $11, 0($sp) ; Load the byte off the stack and $12, $11, 16 ; AND the bit beq $12, 0, $35 ; branch/anull if zero addu $3, $3, 1 ; increment bitcount $35: Total instruction count was 28. This is non-optimal, as there is no need to reload off the top of the stack on every line, and if so modified it would be equivalently efficient to the SPARC implementation. On a Cray Y-MP/EL running UNICOS 7.0.6 (-O3, which is equivalent to - -hinline3,scalar3,task3,vector3): L5 = P.* S7 2 ; Move 2 into S7 S0 S2&S7 ; S0 = S2 AND S7 JSZ L6 ; Jump to L6 if the bit was zero S7 1 ; Move 1 into S7 S1 S1+S7 ; Up the bitcount in S1 L6 = P.* ; 9 Note that the Cray C compiler (or indeed any C compiler I know of) is not yet capable of recognising the option of using the population count instruction here, because it is nearly impossible to determine what this particular routine is doing. Even so, the total instruction count is 80, which is somewhat excessive. The "Move 1 into S7" could probably be eliminated by using another scalar register, and I suspect (but don't have the manual here so I cannot confirm) that they'd be better not to reload the mask every line, but instead to load it once and shift. Additionally, you could probably vectorise this, but I doubt it would buy you much. Anyway, that's an analysis of three high end architectures on this code fragment. Personally I feel that a lookup table would be a MUCH more efficient implementation for most systems which lack population count, even for words up to 20 bits or so in size (depending on your storage requirements and latency at accessing main memory, of course). Enjoy. One of these days I will get back to my project of implementing crypto primatives in CAL, but I do not have the time right now. BTW, folks, playing around with this is fun. I still believe that either the SKIPJACK interim reports Cray-implementation timing figures were wrong, or the conditions under which the program was compiled was incorrect (most likely), or that SKIPJACK contains no s-boxes. Take your pick. Ian. -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLhukvdCZASdT8NoBAQHe/wQAzW/zmoiiAz9vswLO5kQcs6TSoAhIK7SM 1hTrvbXTbNwrnK2FyhC4nZaUPIjnZufOeCoQPs1DJNsCZ1q6Gx1nlVj/hTyBUxYr THQ9ZLOUFruSDa18enx4J1iSrliBeoGcV0CuGRxClNoFrDkYedzRS0nN+m/rq35W Vcsk0HFxq0g= =Wpri -----END PGP SIGNATURE-----

2 1