December 2003 - cypherpunks-legacy

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

Need help in Russia...............
by Robert M. Humphrey 17 Dec '03

17 Dec '03

This is the first time I've been in this system, so I guess I just jump in. I am an American Communications Engineer doing business in Russia. You think you have problems with privacy! Anyhow, after having to eat the contents of a few of my messages as served by the local Russian Administration (who aren't on my mailing list!), I decided to try for a little privacy. No joy in Mudville!! A friend in the US suggested that I try PGP. Then I find out that I can't have someone send me a copy. Then I find out that I can download something from CompuServe. Right! Have you ever tried data on a Russian Telephone line? I was abl to get about 20KB before Ma BellSkov decided to cut me off. Lots of times. I have access to InterNet e-mail through some system in Moscow (about 5000 miles from here) and I do have access to UUENCODE and DECODE plus the usual PkWare stuff. Anyone with any ideas how I can get going on PGP or something else under the circumstances would be more than welcome. By the way, a simple system probably won't do much good. When the climate changed in Russia, a lot of very capable KGB people ended up with no jobs. Since they had the skills needed, they either entered the Russian Mafia, went into Industrial Espionage or (just to show how desparate they were and how little self respect that had left) became lawyers! It's the second group that I have to deal with. If it's not well encrypted, you can buy any information that exists over here. If anyone has any ideas on how I can get going in this direction, let me know at: Robert(a)rmh.khabarovsk.su BTW...Khabarovsk is a city of about 700,000 located 20km from the Manchurian border with china in Far Far Eastern Russia (less than 500 miles from the Pacific coast. I do mostly Satellite communications and many types of radio communications. Thanks Bob

1 0

Re: (fwd) Cryptologist needed
by bart＠netcom.com 17 Dec '03

17 Dec '03

I guess when I first forwarded this to the list, the header was not included. What follows is the entire posting from the ba.jobs.contract Usenet group which includes the name of the person who posted it. dberg(a)netcom.com is the person to answer all questions about the job.

1 0

Re: Detwiler's Crypto Mailing List
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: From: Peterwheat(a)aol.com : I found this by doing a keyword search (cryptography) in America Online's : database of mailing lists. I thought it might be of interest to the : cypherpunks mailing list: Oh God :-( Either Detweiler has got himself an AOL account or all AOL people are as clueless as they're reputed to be... He follows it with this... > From: Anonymous <remailer-admin(a)chaos.bsu.edu> > Can anyone tell me if one can use PGP 2.6 with an online service [America > Online]. From what the FAQ says, I need an actual UNIX account rather than > just an E-Mail Gateway. Is this true? > If not, then how do I encrypt without attaching the pgp file [which goes only > to other AOL users] or without using BinHex and inserting THAT into my > message body? Not all of my peers use AOl or possess BinHex. Hmmm... I think theory #1 is the more likely one. Is it time to shout 'He's baaaaack!' yet? - I'll know soon enough if I log on to cypherpunks and find 50 articles all following up posts from AOL... G

1 0