June 1993 - cypherpunks-legacy

Re: PKP sellout?
by smb＠research.att.com 13 Jun '93

13 Jun '93

It's worth remembering that for the most part, corporations don't have ethics, they have bottom lines. Most of PKP's objections to the DSA were not really solid; rather, they were in defense of RSA as a profit center. There only two really big ones -- that DSA as originally proposed had too small a key size, and that it doesn't provide secrecy, only authentication. The former has been fixed by NIST, and the latter was a design goal. In this case, NIST really had no choice but to deal with PKP. Apart from the question of the Diffie-Hellman patent -- and in my opinion, DSA definitely did infringe on it -- the proposed algorithm was very close to Schnorr's algorithm, which was patented, and to which PKP had purchased the rights. If NIST had gone ahead without making a deal with PKP, the standard would have been tied up in lawsuits for years, with the outcome quite uncertain. And while that may or may not have suited this community, it would not meet NIST's objectives. I don't see the hand of conspiracy here; rather, I see an encouraging trend, that the private sector is able to compete in cryptographic competence with NSA. I am encouraged by the pledges to allow non-commercial use -- note the lack of any RSAREF-like interface -- and to engage in non-discriminatory licensing. --Steve Bellovin

2 1

Re: PKP sellout?
by Fred Heutte 13 Jun '93

13 Jun '93

This PKP announcement is the last straw. This is clearly a case of the federal policy/procurement bureaucracy going completely out of control. The way things ran under Bush, except if they tried to pull this blatant a deal their bluff would have been called immediately. I think it's time to demand the White House put a total moratorium on all policies related to digital and telecommunications data and privacy until they can extract themselves from this quicksand. And if they won't do that, it's time to kick some *serious* political butt. Don't you let that deal go down! Fred Heutte Sunlight Data Systems "Why make it simple and easy when you can make it complex and wonderful!"

1 0

8088/PGP failures.
by William H. Oldacre 13 Jun '93

13 Jun '93

>I don't know where you've been, but version 2.2 has a notorious bug >that locks up the box under numerous situations. In my experience, >version 2.2 locks up 8088-based computers. Version 2.1 does not. >I was not aware that people still used that version of a computer. >An 8088???? >Don't be so arrogant. >Additionally, when one is running PGP under Windows the "virtual DOS >machine" on which it is running *is* an 8088 (of sorts) and PGP 2.2 will >lock it up 2/3 of the time. >PGP 2.2 runs without a hitch on at least one 10 MHz+ XT box in which >the 8088 was replaced with an NEC V-20 and an 8087 co-processor added >when new... about six years ago. >I don't doubt it for a second, but I know it definitely will lock up a >real 8088. Also there is a problem with DesqView in some cases. I live in Central Florida which experiences more lightning discharges than almost anywhere else in the country (excepting certain mountain tops). We are now entering our most violent season. Yesterday, a semi-trailer was struck on I-75 at a Gainesville exit and had both front tires blown out and his front window shattered. In Florida, you are roughly thirteen times more likely to be killed by lightning than win any single entry in the Florida lottery (lottery odds: 13.9 million to one). My home has been directly struck by lightning and suffered heavy damage. This may help to explain to those who authored the sentences above why I still employ an 8 MHz, 8088 based, Sanyo MBC-775 computer as my primary communications computer (no hard drive). Not counting the disfunctional Honeywell mainframe in the garage, I have over a dozen computers. Why risk a more expensive (and failure prone) system when it's sophistication is not necessary? PGP 2.2 works perfectly on my unit. I suggest that the lockup problem may be more related to the many different approaches to writing an IBM compatible ROM BIOS, rather than to the processor used.

1 0

evil government and corporate plot
by jet＠nas.nasa.gov 12 Jun '93

12 Jun '93

It appears that both NASA and Thinking Machines are involved in a plot to keep me from attending today's meeting. Said plot involves agents of both parties deliberately crashing the CM-5 and requiring me to fix it before I'm allowed to do anything else. [sigh] -eric

1 0

MAIL: logging that happens on soda
by Kelly Goen 12 Jun '93

12 Jun '93

Hi Eric, I as well as many others on this list have either worked as security administrators/ and/or designers in the aspect of systems that you have brought up here. Are you aware of the firewalls mailing list, it could be a HUGE resource in terms of these questions. As to the Logs... well the logfile name could be linked to /dev/null :) that would eliminate the logging problem... Another annoying tracking log is the syslog daemon. Mail connects are logged in their syslog using Sun sendmail and the standard syslog.conf. syslog.conf changes are needed to eliminate this misfeature... cheers kelly p.s. ignore that rather uninformed person who complained you were making yourself look illiterate... most of the folks on this list unless they actually do it for a living(such as moi) ARE quite illiterate about matters such as DNS/Mail logging and TCP/UDP/ICMP/IP logging and/or trusted systems etc. Thats part of what this forum is about for each of us to educate the rest of the list so that privacy issues get FULL spectrum coverage. Please do keep bringing these issues to the forefront... some of do appreciate it. I and others will be happy to discuss the technical details of various tracking and auditing. In-Reply-To: Peter Shipley's message of Fri, 11 Jun 1993 09:51:13 -0700 <9306111651.AA14556(a)edev0.TFS> Subject: MAIL: logging that happens on soda Re: sendmail logs >Eric, most of us know this stuff you are making yourself look very >unix illiterate. I have opened my mouth and removed all doubt. I _am_ mostly illiterate in the details of Unix; this is one system administration detail I did not know. I have known for a long time that these logs were in principle easy for administration to keep, but I did not know that they were an entirely standard feature. I raise this because it affects perceived remailer security and I have not once heard these specific logs brought up, on the list or in person. Eric

5 5

No Subject
by morpheus＠entropy.linet.org 12 Jun '93

12 Jun '93

From: morpheus(a)entropy.linet.org (morpheus) Subject: Re: Encrypting the list References: <9306091955.AA09779(a)boxer.nas.nasa.gov> Organization: Ranch Apocalypse Date: Fri, 11 Jun 1993 22:31:42 GMT Message-ID: <1993Jun11.223142.28987(a)entropy.linet.org> In article <9306091955.AA09779(a)boxer.nas.nasa.gov> src4src!imageek!nas.nasa.gov!jet (J. Eric Townsend) writes: >FutureNerd Steve Witham writes: > > We're all prime suspects for being spies. > >'specially those of us with both .gov and .com email addresses, right? And worry all the more about ORGanized spies.. Worrying about spies is pointless. Publicity is good. There isn't any point in cutting people "out of the loop" in effort to stop "spies", what is being discussed needs to be known to as many people as possible. We're talking cryptography, not revolution. -- morpheus(a)entropy.linet.org Vote anarchist. Support your local police, for a more efficient police state.

1 0

REMAILER UPDATE
by Rain.Face＠f418.n161.z1.FIDONET.ORG 12 Jun '93

12 Jun '93

In that I have been off this list for a while, I was wondering if someone could give me a quick update on which anon remailers are still in service and what the current syntax is. Thanks. --------------------------------------------------------------- |<rain.face(a)f418.n161.z1.fidonet.org>|"No apologies, no excuses,| |PGP Key ID # EFAA97 via all servers | no jive and no regrets." | --------------------------------------------------------------- --- Blue Wave/TG v2.12 [NR] * Origin: realitycheckBBS (510)527-1662 (1:161/418.0) -- Rain Face - via FidoNet node 1:125/1 UUCP: ...!uunet!kumr!shelter!161!418!Rain.Face INTERNET: Rain.Face(a)f418.n161.z1.FIDONET.ORG

1 0

MAIL: logging that happens on soda
by Eric Hughes 12 Jun '93

12 Jun '93

I was rooting around soda for some other reason and stumbled upon the mail logs (!) for soda. I just sent myself some mail to generate a sample entry. It's got complete traffic analysis data, complete with to/from pairs, time of day, and message size. Jun 11 08:13:35 soda sendmail[11298]: AA11298: message-id=<9306111513.AA11298(a)soda.berkeley.edu> Jun 11 08:13:35 soda sendmail[11298]: AA11298: from=hughes, size=66, class=0, received from local Jun 11 08:13:36 soda sendmail[11300]: AA11298: to=hughes, delay=00:00:01, stat=Sent I would recommend that all remailer operators find out what kind of mail logging, if any, takes place on their machines. If you need a place to start looking, the mail log on soda was in the same directory as the syslog messages. I would also recommend that this information on mail logging by the system be put in Karl's remailer list. Eric

3 3

Pgp v 2.2/8088/V-20
by XXCLARK＠indst.indstate.edu 12 Jun '93

12 Jun '93

ms>I don't doubt it for a second, but I know it definitely will ms>lock up a real 8088. Grew so accustomed to the NEC V-series I suspect I'd come to think of them as the *real* 8088... and 8080. Uu> Key generation on the XT is as exciting... and as fast... Uu> as a baseball game... ms> Well, more like _cricket_, actually. 8-) There is *nothing* like cricket. Uu> Encryption speed is more than adequate. ms> Considering the math involved, yes. Still even a 20MHz 286 ms> fairly flies doing PGP tasks in comparison, though. Agreed. Just didn't want the potential PGP user with an XT to feel he'd have to settle for a Clipper chip... and had my button pushed by the naif overly impressed with the originovelnew. One wonders what reaction one would elicit were he confronted with an Altair kit and its quarter mile of white wire or MS Basic on paper tape or cassette. --------------------------------------------------------------------- internet : xxclark(a)indst.indstate.edu RelayNet (488) Vanilla BITNET: XXCLARK@INDST FidoNet (1:2230/114) Phone: 911 TechNet 11:800/0 One need not be a weatherman to know which way the wind is blowing. ---------------------------------------------------------------------

1 0

Re: CryptoStacker
by bbyer＠BIX.com 12 Jun '93

12 Jun '93

If the project is called CryptoStacker, why not use Stacker? Have the program go beneath Stacker (or another disk doubling system) and encrypt/decrypt the actual stacker file as Stacker reads it? It would be a much simpler solution once you found out how te interface with Stacker. Ben Byer <bbyer(a)bix.com>

2 1