December 2003 - cypherpunks-legacy

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

New remailer concept.
by Jim Pinson 17 Dec '03

17 Dec '03

It occurs to me that most people have more to fear from their neighbors, than they do from the powerful TLA's. Knowing that you are hunting for a new job is not important to the world at large, but could be embarrassing if your current employer found out. Likewise, the people most interested in knowing about that sex list you subscribe to are your coworkers. The answer of course is encryption, but that is a problem when you are writing to your, well... , "crypto challenged" friends. Also, two way encrypted messages to most discussion lists is not possible (to my knowledge). To address these problems I suggest the creation of "crypto remailers". They would work like this: You subscribe to the remailer by sending a request including the account name you wish. This could be either a real name (jpinson) or a pseudonym (lizard). You would also include in the subscription request a copy of your public key. Assuming there are no name collisions with existing users, you would get back a message of acceptance, and a copy of the remailers public key. To use the remailer, you would create a message containing as the first line a "request remail to: USERNAME" , followed by your message. You then encrypt the message with the remailers public key and send it to the "remail" account at the remailer. The remailer then decodes the message you sent, and sends it to its destination as plain text. It sets the "from" field to your account name on the remailer. The recipient of your message can then reply to your remail account in plain text, with no need for any "remail to " commands or special processing. A .forward pipe on your remailer account would run a Perl script to encode the message to you with your public key, and send it to your real address. (for security it could set the "from" field to something other than your remail account name) The advantage is that you have total protection at your end. All mail to and from the remail account is encrypted. You could now subscribe to lists, and receive mail from lists, without your local administrator knowing anything about them. This last feature could be useful for students at universities that limit access. Is there anything like this out there already? Jim Pinson Charles Darwin Research Station, Galapagos

2 1

re: HTML, OLE
by Dr. Manhattan 17 Dec '03

17 Dec '03

> Has anyone considered OLE compliant PGP encrypter/decrypter objects > that would act on the contents of the document? I've thought about it, and am just starting to climb the OLE learning curve (I am reasonably familiar with Windows programming with MFC). This of course would assume a native windows PGP, a feat that would require substantial rewriting of PGP itself. This is something I will not undertake since PGP itself is apparently going to heavily changed/updated in the future (PEM compliance, dbm files for keyrings, an API, etc.) and I don't want to put effort in an evolutionary dead end. But after that, making PGP an OLE client wouldn't be too much extra work. Then you could link/embed OLE items into a PGP document (such as Word, Excel, Write, Paint, Sound Recorder, any other OLE server items). Actually, embedding would be necessary since a mere link wouldn't survive encryption and decryption on a possibly different machine (i.e. the link would point to meaningless memory). The fancier approach would be to make PGP an OLE server as well, such that you could link/embed a PGP document (encrypted text, signed text, etc.) into other apps. Again, embedding would be necessary. If PGP were an OLE client, you ould embed graphs, pictures, sound, spreadsheets, etc. into a document, and encrypt the document. If PGP were an OLE server, you would embed encrypted pictures, encrypted spreadsheets, encrypted cound, etc. into a document and mail the document. Of course, it would seem easier to just embed OLE items and encrypt the document once. I don't know what the prefered behavior is. I lean towards PGP as an OLE client.

2 1

(Fwd) Re: NSA seems to be lobbying against bank use of triple-DES
by John Young 17 Dec '03

17 Dec '03

Forwarding Cyberia-L mail by: dcain(a)pioneer.uspto.gov (David Cain) on Wed, 23 Nov 7:8 AM ------------------- John Thomas writes: > It's clear that NSA is opposed to triple-DES because it cannot break it. > I'm not supprised the banks are going ahead even if triple-DES cannot be > exported; it will be trivial to develop the hardware overseas, since all > the algorithms are public. Although NSA will neither confirm nor deny <grin> one of the fundamental principles of cryptography is that any encryption system which cannot be broken is also inefficient - like the one-time-pad. NSA may be concerned with allocation of CRAY resources, but I doubt they are concerned about the viability of breaking triple-DES. One of the most important concepts of cryptography is that false security is worse than poor security, for if you are aware of a system's vulnerability, you can guard the weak points. NSA's point that layering encryptions not only doesn't strengthen the security, but may create patterning that is more susceptible to differential analysis than a single DES pass, is an important one. More is frequently less in crypto. Now, I have no more insight into NSA motivations than the next shmoe, but the objections they raise are legitimate from a security standpoint. As for independent creation in Europe, there is a component to "real" hardware DES which is classified. dc Primary Examiner USPTO Cryptography David Cain * Speaking for no one * Escape to find the shining light dcain(a)uspto.gov * Borne within evolving sight dcain(a)osf1.gmu.edu *

2 1

Re: (Fwd) news spoke
by acspring＠knoware.nl 17 Dec '03

17 Dec '03

>Forwarding Design-L mail by: <carr0023(a)GOLD.TC.UMN.EDU> () on (by John Young) >_________________________________________________________________ >___________ UNIX(r) System V Release 4.0 (gold.tc.umn.edu) > >This system is for the use of authorized account holders only. > >Individuals using this computer system without authority, or in >excess of their authority, are subject to having all of their >activities on this system monitored and recorded by system >personnel. > >In the course of monitoring individuals improperly using this >system, or in the course of routine system maintenance, the >activities of authorized account holders may also be >monitored. > >Anyone using this system expressly consents to such monitoring >and is advised that if such monitoring reveals possible >evidence of criminal activity, system personnel may provide >the evidence gathered to law enforcement officials. This text is taken almost verbatim from CERT Advisory CA-92:19. The idea behind it is to protect systems operators from lawsuits if they monitor the keystrokes of a hacker breaking into their system. It's quoted in Cheswick and Bellovin's _Firewalls_and_Internet_Security_ (a totally cool book BTW). They quote from the case _United States_v._Seidlitz_ 589 F.2d 152 (4th Cir. 1978) where the defendant claimed that keystroke monitoring of his attempt to break into OSI's computer constituted an illegal wiretap. The judge blew him off, of course. If you're worried that this boiler plate legalese gives them carte blanche to listen in on your IRC sessions on #bondage, then forget it. It (_probably_) doesn't. -- Man! Woman! Child! All! are up against the WALL of SCIENCE! <acspring(a)knoware.nl> PGP Key print:4C 17 EC 47 A1 6D AF 67 F3 B4 26 24 FE B2 0F 5E

1 0