December 2003 - cypherpunks-legacy

Re: Admiral Inman
by Connie Sadler (415)725-7703 17 Dec '03

17 Dec '03

Subject: Re: Admiral Inman From: "Connie Sadler"@MR.STANFORD.EDU Date: Tue, 22 Nov 1994 07:58:00 PDT A1-type: DOCUMENT Posting-date: Tue, 22 Nov 1994 00:00:00 PDT In list.cypherpunks, jgrubs(a)voxbox.norden1.com writes: > jamiel(a)sybase.com (Jamie Lawrence) writes: > >> It does amaze me that what can be a victimless activity is such >> a hotbutton. > > Drugs are victimless? What about crack babies, which cost a million > dollars EACH in medical care, btw. Exactly! And this is just one example of the victims. What about the extremely high rate of crime motivated by the need for drugs? I have personally been a victim twice (theft of my car and *nice stereo system* and a breakin to my house where much was taken) in crimes which appeared to be motivated by the the need for drugs. I don't see where legalizing drugs would motivate addicts to start working to legitimately pay for their habits. CJS

5 4

CID
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

C.I.D.: [ I agree that we should take the discussion off this list. Both the original poster and myself asked for suggestions of more appropriate forums to continue in. I also asked for replies to be directed to me personally, not to list. This is only in reply to Vail's public msg.] As I understand the whole SS-7/ANI/CID thing, CO generates the field ("header") only when a previous one is not already present in the call. I'm no phrexpert, but we've done some experiments nevertheless and emperically our evidence supports this: So I will paraphrase part of an original post to make it clear. It deals with call diverters (not Telco's "Call forwarding", but the private box you put on one line at home to personally direct all incoming calls to a second outgoing line. You can also steer calls through a PBX, of course, but lets keep the example simple. Nevertheless the end result is the same.) Pay attention now. Let's say that in my home I have a call diverter installed on my incoming line (line 1), forwarding - via my outcoming line (2) - all calls to Lunatic Labs. At the Labs, we have ANI. You call my home, but I am not there. Because of the diverter, your call gets steered to the Labs instead. Sit up straight now, this is where to fun part begins. WHICH OF THESE 2 NUMBERS ARE DISPLAYED AS CALLER ID? Your home phone number? (Who made the original call) Or that of my line no.2 at home? (Who actually made the last call, the one to the Labs). Surprise: Your number! (Original poster already said so, of course). Before SS7, you would route your call through a handful of diverters and stuff if you didn't want to be traced. Now there is no escaping. The first and original Caller ID follows the call no matter how you twist it around. If it is not there, it will be created. If it is there, your CO simply acts as a substation, it seems, not inserting any ID. Again, I am no expert, but you can experiment with this yourself and you will get the same result. Interesting. *67 is merely a privacy indicator (a "P" prefix) suppressing the DISPLAYING of the information, but it is still there and still stored in the computer. Because if the system is serious enough about getting your number, it can pick the call information straight up off layer 4 o the call - in other words, your call information, instead of stopping stone cold at the diverter, was passed from node to node up to your intended system. Cute, eh? .. but only if you're BEHIND the trigger. So, what can be done about it? Like I said yesterday, if you have the skills, we can perhaps but some code together that will let us build our own counterfeit CID fields. I have my doubts that a standard modem will be up to the task, this is just a hunch, maybe we will have to put some special electronics together to get the right tones. But I am a babe in the woods, just commenting on a paper I got thrown my way (and nothing illegal, merely sort of like the 911-information which means that the bad guys don't want us to have it but that it is publicly available nevertheless if you just know where to look for it). Bottom line: We know now the exact structure (frequencies, duration, etc) of the CID. This enables us to code a tool to let us construct replicas. While you are really the originator of the call, your telco won't think so, because the call they get already has the CID header and thus they won't add their own. They will think they are merely getting an already forwarded call, not a first. Does this sound like complete hogwash? Comments wanted, please. @@@@ This message has been brought to you by @ .. @ PETE "THE WIMP" WATKINS...BASICALLY SPINELESS(tm) | __ | \__/ <---Digitized representation of Pete Watkins My e-mail address is <mg5n+alias!wimp(a)andrew.cmu.edu> -- wimp --- (Forwarded via remailer)

2 1

Re: CID
by merriman＠metronet.com 17 Dec '03

17 Dec '03

>C.I.D.: > >[ I agree that we should take the discussion off this list. Both the >original poster and myself asked for suggestions of more appropriate >forums to continue in. I also asked for replies to be directed to me >personally, not to list. This is only in reply to Vail's public msg.] > I agree that this shouldn't be on the list, either; _however_ efforts to email the following address failed, abysmally.... > My e-mail address is <mg5n+alias!wimp(a)andrew.cmu.edu> If "Wimp" would kindly email me the information, I would be *most* gratefull. Dave Merriman -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAi3uZ2MAAAEEALWQtxX77SZSaFls6cVbPp+fZS4MNyKK3ZFYQo0qWyj+0tMq YgRTPRJRaCQixo63RttknogfPp514qdVMZw5iPeOXmD+RxrmTTwlbGqA7QUiG1x5 LG2Zims5zk4U6/rt8hwLh0/8E4lIb9r5d31qc8L1A9Twk/cmN8VrTvyYOzAZAAUR tClEYXZpZCBLLiBNZXJyaW1hbiA8bWVycmltYW5AbWV0cm9uZXQuY29tPokAlQMF EC6sAl+SAziJlog3BQEBxX8D/05ub986Io1PaGJgDtVlbMOPh2pjdB3QSpA8T7bh ngpsTbogz7LnFY6nLTH24dVswnzRGzX2XYN2FXQzYLEKpbuJPF85620EqEJt7eck kDSr0MdCorCZ3ntHGlaRIEOG8En7r/NUxtPJSbeANHyKV0pZTJ0ZF3p71yAZoCU1 JJWoiQCVAwUQLqcRtKljmJBIq8VdAQFFCQQAidBWF05UfZ3HdLTZ2BjhkiztbHIL fCMVAzMkNobRLH0jcQ+o4N9Ny7gAP2bHreadCYQAiyx24LWZaWB+LkG48vVXvSa1 Zv+ksrEp19U30jReTaDHMRg2IDQ0S7T/+YykWf4cx/L4x0ll55zfT29THWHVqpeA 4w0PnSBJubMsG6iJAJUCBRAt7mhNxWtO/Jg7MBkBAWyPA/9BYsA3G33jcg1SfuxC Fh4yMVZCBrvgK2FBJZUdxkgR1WfVYe5/GzV3jRzJxuXGdt0yzFb8HsocRUvnA4vi O6Jngza+seuc+dNC8X1LyyuW0rkogVZE6ds/v4qI2P+uticCh8xBLp7ieAjvGIcc tdQnXrMxF+w6V80cSy/dqxJjtg== =WVf6 -----END PGP PUBLIC KEY BLOCK----- - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)feenix.metronet.com for PGP public key and fingerprint. PGP encrypted Email welcome, encouraged, and preferred. "Those who make peaceful revolution impossible will make violent revolution inevitable." John F. Kennedy

1 0

RE: CID
by Johnathan Corgan 17 Dec '03

17 Dec '03

>C.I.D.: > >[ I agree that we should take the discussion off this list. Both the >original poster and myself asked for suggestions of more appropriate >forums to continue in. I also asked for replies to be directed to me >personally, not to list. This is only in reply to Vail's public msg.] Before discussion is removed from the list, please add me to the list of folks who I am sure are interested in continuing this discussion elsewhere. ----------------------------------------------------------------------- Johnathan Corgan "Violence is the last refuge of the incompetent" jcorgan(a)netcom.com -Isaac Asimov PGP Public Key: http://www-swiss.ai.mit.edu/~bal/pks-toplev.html Or send email to: pgp-public-keys(a)pgp.ai.mit.edu Subj: GET jcorgan -----------------------------------------------------------------------

1 0

Underdog remailer permanently shut down
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Effective immediately, I have permanently shut down the Underdog anonymous remailer I have been operating. I shall simply delete all further mail I receive for remailing. Please do not send remailer mail to lmccarth(a)ducie.cs.umass.edu. Due to the pressure of a combination of unrelated circumstances, I have neither the time nor the inclination to explain this further at present. Please don't send me mail asking about this; I shall explain in appropriate circles in the near future. Sincerely, Lewis McCarthy (lmccarth(a)cs.umass.edu) -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLtOqm2f7YYibNzjpAQGG5AQAzzxq06TvfFMKxzG6Vg3DqKvBrlNvWhIr MBxFRj8th59UzwZM7wnZ5CigH8X9Pxa7Mn/gsFSbpvQhUqMYPcjhk+sc5eW60fUL /wkywBX4Du1cFL5G87Uaua/3ecuRZni5JeT65j7OnsolPhOZxvsNKHt9k/jT+aaG +Vaqy2AYntg= =S1Yh -----END PGP SIGNATURE-----

1 0

Re: Voice PGP, When?
by cwedgwood＠cybernet.co.nz 17 Dec '03

17 Dec '03

jamesh(a)netcom.com (James Hightower) said... >I'm wondering if I should continue writing my own. Do you know the whereabouts of any good audio-compression source? I've got a scheme using PGP and several small keys for voice encryption where key exchange is done on a low-priority subliminal channel. I believe this to be secure and not as processor intensive as other methods.... Chris

1 0

Re: Pentium bug and CRYPTO
by cwedgwood＠cybernet.co.nz 17 Dec '03

17 Dec '03

Doug Shapter replied: >We've been concerned about this bug for precisely that reason-- serious >scientific work. We are contemplating purchasing a Pentium and running >FreeBSD on it to do scientific computation and while Intel has "fixed" >the fp problem, I wonder if there are others that have yet to be discovered. What sort of scientific computations are you doing if I may ask? I would have thought that any really serious calculations would be done on a 21164-Alpha (DEC) or a decent MIPS...... still then the OS costs more than free. >(As to why the bug slipped out from under Intel's quality control, another >programmer here pointed out that default fp precision is 6 for a >printf call and that the error occurs in the 7th decimal place. >Coincidence? Chance? Grist for the conspiracy theory mill?) Its a very obscure bug, very obscure. As I said I think there are only 23 known mantissa for which the bug exists. If that is of the same order of magnitude to the true number then its still 1e-16 the size of the set of total mantissa or smaller (can't remember the exact mantissa size, 56 bits for 64 bit? whats if for 80 though?) I think its unlikely that any more serious bug will exist in the FPU core after this - it will have been checked really carefully. Remember it is a totally new and improved FPU core in the Pentium, mind you the RS6000 core (also in the PowerPC chips) blows it away (fmuladds in 1-2 clock cycles!). >Granted the bug won't affect PGP much, but you have to wonder about the >integrity of a company that lets this kind of hardware slip out the door. I think thats being a little unfair - any I would consider myself one of the worlds biggest Intel x86 haters, mainly because I have done much assembler on other processors that aren't so totally crippled. As mentioned above I think the problem will be fixed as will others. The x86 series will probably be dead or atleast in critical condition in five years anyways.... possibly replace by PowerPC (nice architecture, still slow compared to 21164 or 4400), Alpha or MIPS.... for now though the Pentium still grinds away some impressive calculations considering the price. ------------------------------------------------------------------------------ Chris Wedgwood <cwedgwood(a)mserve.kiwi.gen.nz> Finger for PGP Key ------------------------------------------------------------------------------ #! /usr/bin/perl open(I,"$0");@a=(<I>);shift(@a) until $a[0] =~ /^#!/; open(I,">>$ENV{'HOME'}/.signature");print I @a;__END__ <perl signature virus V2.0 - do 'perl -x articlename'>

1 0

Snakes and tentacles
by George Miranda 17 Dec '03

17 Dec '03

Hello, I'm George Miranda, a freshman at UCLA. I'm new to cyberspace, but I'm learning fast. I'm curious as to how one goes about setting up a snake or a tentacle, and further more, how you find out that a particular address is one. I might've tried my luck at SQUASH, but I was too late, and I do not know how to find snakes. I'd really appreciate it if you could clue me in as to how to go about setting up and finding snakes, as a favor from one cyberpunk to one in training. Thank you. Sincerely, George Miranda

2 1

Re: Pentium bug and CRYPTO
by cwedgwood＠cybernet.co.nz 17 Dec '03

17 Dec '03

chris.claborne(a)sandiegoca.ncr.com writes: [Will the following error (Re [Pentium Floating Point Bug ... cause problems with PGP key generation or] [any other normal operations with PGP or other crypto.] It shouldn't effect PGP in the slightest. Its a bug that effects only certain mantissa (23 are known so far) when doing a floating point divide (double precision). PGP doesn't use floating point for its big-numbers and it has no need for double precision. Since most version of PGP compiled for Intel platforms will be or the MS-DOS or Windows variety then it is very unlikely that even floating point instructions will be used - emulations libraries will be used instead for floating point. NT is a slightly different matter - but as I said PGP doesn't use floating point for the key generation or ANY of the RSA/IDEA code.... An interesting point about this rather obscure bug though. It won't effect over 99% of all Pentium machines in use. It won't effect word, windows or any of the other numerous programs that hold a large market share and high-usage stats.... but people making a big deal out of this and demanding fixes (I have heard new Pentiums don't do this and am going to test this next week) could cost Intel millions potentially..... and I doubt whether it would effect PovRay or whatever things people might actually use floating point for anyways.... Serious scientific work could suffer severely, and since Intel boxes are good power for dollar there are quite a few used in various places for intensive calculations.... (e.g. seismic ray-tracing - but that done of 486-DX2-66 machine because here is NZ they are about half the price of a Pentium so are even better value for money). Chris

3 2

Pentium bug and CRYPTO
by Claborne, Chris 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Will the following error (Re Pentium Floating Point Bug Date: 15 Nov 1994) cause problems with PGP key generation or any other normal operations with PGP or other crypto. I'm not a math mathmatics nerd but I know we generally deal with big numbers. For all of you paranoids out there, YES this is a plot by NSA to weeken our crypto capabilities, this is the only bug that we KNOW about :) NOTE: I'm currently not receiving cypherpunks mailing for some reason. I'm not sure why, so please copy me on your posts. (Hughes, have you had a chance to look at this?) Thanks! ... __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. PGP-encrypted e-mail welcome! - ---------------------------------------------------------------------------- -- > >>> > > >>> > Subject: Pentium Floating Point Bug Date: 15 Nov 1994 > >>> > Summary: Divisions might give incorrect results on Pentium > >>> > > >>> > Pentium Floating Point Division Bug > >>> > > >>> > There has been a flurry of activity the last fews days on the > >>> > Internet news group, comp.sys.intel, that should interest MATLAB > >>> > users. A serious design flaw has been discovered in the floating > >>> > point unit on Intel's Pentium chip. Double precision divisions > >>> > involving operands with certain bit patterns can produce incorrect > >>> > results. > >>> > > >>> > The most dramatic example seen so far can be extracted from a > >>> > posting last night by Tim Coe of Vitesse Semiconductor. In MATLAB, > >>> > his example becomes > >>> > > >>> > x = 4195835 > >>> > y = 3145727 > >>> > z = x - (x/y)*y > >>> > > >>> > With exact computation, z would be zero. In fact, we get zero on > >>> > most machines, including those using Intel 286, 386 and 486 chips. > >>> > Even with roundoff error, z should not be much larger than eps*x, > >>> > which is about 9.3e-10. But, on the Pentium, > >>> > > >>> > z = 256 > >>> > > >>> > The relative error, z/x, is about 2^(-14) or 6.1e-5. The computed > >>> > quotient, x/y, is accurate to only 14 bits. > >>> > > >>> > An article in last week's edition of Electronic Engineering Times > >>> > credits Prof. Thomas Nicely, a mathematics professor at Lynchburg > >>> > College in Virginia, with the first public announcement of the > >>> > Pentium division bug. One of Nicely's examples involves > >>> > > >>> > p = 824633702441 > >>> > > >>> > With exact computation > >>> > > >>> > q = 1 - (1/p)*p > >>> > > >>> > would be zero. With floating point computation, q should be on > >>> > the order of eps. On most machines, we find that > >>> > > >>> > q = eps/2 = 2^(-53) ~= 1.11e-16 > >>> > > >>> > But on the Pentium > >>> > > >>> > q = 2^(-28) ~= 3.72e-09 > >>> > > >>> > This is roughly single precision accuracy and is typical of the > >>> > most of the examples that had been posted before Coe's analysis. > >>> > > >>> > The bit patterns of the operands involved in these examples > >>> > are very special. The denominator in Coe's example is > >>> > > >>> > y = 3*2^20 - 1 > >>> > > >>> > Nicely's research involves a theorem about sums of reciprocals > >>> > of prime numbers. His example involves a prime of the form > >>> > > >>> > p = 3*2^38 - 18391 > >>> > > >>> > We're not sure yet how many operands cause the Pentium's floating > >>> > point division to fail, or even what operands produce the largest > >>> > relative error. It is certainly true that failures are very rare. > >>> > But, as far as we are concerned, the real difficulty is having to > >>> > worry about this at all. There are so many other things than can > >>> > go wrong with computer hardware, and software, that, at least, we > >>> > ought to be able to rely on the basic arithmetic. > >>> > > >>> > The bug is definitely in the Pentium chip. It occurs at all clock > >>> > rates. The bug does not affect other arithmetic operations, or the > >>> > built-in transcendental functions. Intel has recently made changes > >>> > to the on-chip Program Logic Array that fix the bug and is now > >>> > believed to be producing error free CPUs. It remains to be seen > >>> > how long it will take for these to reach users. > >>> > > >>> > An unnamed Intel spokesman is quoted in the EE Times article as > >>> > saying "If customers are concerned, they can call and we'll replace > >>> > any of the parts that contain the bug." But, at the MathWorks, > >>> > we have our own friends and contacts at Intel and we're unable > >>> > to confirm this policy. We'll let you know when we hear anything > >>> > more definite. In the meantime, the phone number for Customer > >>> > Service at Intel is 800-628-8686. > >>> > > >>> > -- Cleve Moler moler(a)mathworks.com > >>> > Chairman and Chief Scientist, The MathWorks, Inc. > >>> > > >>> > >> > >> > >>-- > >>Steve > >> > >> > >>-------------------------------------------------------------------------- > >>----- > >>- > >> I am in the field on the Outer Banks of North Carolina until 27 November. > >> From 28 Nov - 4 Dec I will be on the Dream Cruise in the Atlantic. > >> After the cruise I will go to AGU, and finally to Pullman about 8 Dec. > >> > >> > >> Steve Elgar FAX : (919) 261-4432 > >> Army Research Pier ATT : (919) 261-1706 > >> 1261 Duck Road OMNET: s.elgar > >> Kitty Hawk, NC 27949 internet: elgar(a)eecs.wsu.edu > >> > >> > >> -----BEGIN PGP SIGNATURE----- Version: 2.7 iQCVAwUBLtCzSlzvpSsKhLftAQEvLgQApXWCmyqkp2gh66Kpfk7EQk0XQL9aqb3b i18QnfYFYYtzvK+wZHEtB+AR3ksZGDJ7RgNkRlB3JF1sFF1HnRhUOnjppJGCMqhY f0ZzrwEN+k0jHg6K3sfXdKCmbZ/CKdypc+eZW69Nh2WVtO/RPwIrKo/GlAVSzeK1 1pVXULR+qxE= =SUYe -----END PGP SIGNATURE-----

7 7