- cypherpunks-legacy - lists.cpunks.org

PKP
by Doug Porter 13 Jun '93

13 Jun '93

Ok, PKP now effectively has a monopoly. Is an antitrust action appropriate? The timing of this announcement, just after Clipper got set back hard, may be significant. It would have raised far fewer suspicions to put the license out to bid and then make sure PKP got it. My partner, who rejects conspiracy theories out of hand, described the action as "stupid". The folks at Meade may be running scared. The announcement is viewed by some as unnecessarily verifying PKP as a previously hidden asset. If someone is overreacting, perhaps those fighting for freedom are getting to them. Doug

2 1

Re: Mail logging
by Mark 13 Jun '93

13 Jun '93

>The single most basic problem with mail development that we have is >that we don't have enough mail volume through the remailers we have in >order to be able to experiment with better systems. In particular, we >need to examine other reordering algorithms for the case where volume >is low and delivery latencies would be too high with the simple >gather-and-permute algorithm. Well, I hate to point out the obvious but can we organise with the list maintainer to have our mail routed through random machines until it gets to us? I'd only recommend this for the more email aware members as it might prove confusing. Also, to save my own sanity and others certain header munglings might be desirable to ensure that the mail is still filterable. I'd suggest either an addition to the remailer scripts to allow a predefined header line through, or the Subject: line of each message is prefixed with CRYPTO: so the end users can still filter the messages as they now do. Currently I use 'procmail' to filter out various things and it works on the contents of the mail header as so: --------.procmailrc-------------------------- IFS="" PATH=/home/coombs/mark/bin:/usr/local/bin:/usr/bin:/bin MAILDIR=$HOME/mail DEFAULT=/usr/mail/$USER # Filtering for cypherpunks :2 # Two 'if' clauses (^To:.*cypherpunks@toad.com.*|^Cc: .*cypherpunks(a)toad.com.*) (^Subject: .*(UNSUBSCRIBE|nsubscribe).*) /dev/null # If a match send mail here. --------.procmailrc-------------------------- If we were to route all the mail through remailers I would lose the functionality of filtering as I wouldnt know where the email was coming from, nor would I be able to know it was cypherpunks mail until I read the message body. thats why a Subject: line change or a modification to the remailer scripts (if needed) should be made. Assuming the above was made, all the maintainer would have to do is change my mark(a)coombs.anu.edu.au line in the alias file to a: |/bin/random-remail -dest mark(a)coombs.anu.edu.au or |/bin/random-pgp-remail -dest mark(a)coombs.anu.edu.au -key mark(a)coombs.anu.edu.au where 'random-remail' is a short program that scans a list of remailers and randomly selects some, puts the addresses and remail triggers into a file, appends the message and changes the "Subject: blah" line to "Subject: CRYPTO: blah". 'random-pgp-remail' does the same and encrypts the whole message before sending, possibly encrypting again a few times with remailer keys. This approach would (dramatically :) increase the remailer traffic to levels where mail re-ordering is possible. Padding would be the next step, add the lines on the end to bring the message to 512 bytes, 1024 bytes, 2048 bytes or greater. Maybe pad all messages to the nearest 1024 bytes? (see below for a method :) The only problem I can see after the programs are debugged etc is the extra overhead on toad.com, wther it's a non encrypted mail out or not. But if that is acceptable to the maintainer in the intrests of giving remailer operators some fodder then we can implement it I dont see any of the random-[pgp-]remailer programs being longer than 30 or 40 (perl script) lines. I'd write them myself if I could get some mail aliases installed on this host. Admittedly they aren't essential but I'd like them for testing purposes. Mark mark(a)coombs.anu.edu.au PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PA <---- end of padding to make this 2048 bytes long

2 1

what happens when you reply to nobody@cicada.berkeley.edu ?
by nobody＠cicada.berkeley.edu 13 Jun '93

13 Jun '93

Ya, I wanted to know what happens when you responded to mail from nobody(a)cicada.berkeley.edu ? Thanks

2 1

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

13 Jun '93

Let me remind everyone that Capstone has a yet-unspecified exchange protocol. Denning suggested on RISKS that Diffie-Hellman (covered by PKP patents) `could be used'. There is some serious evasion going on here. If Capstone is already built, with a public-key algorithm installed, it suggests that PKP has been cooperating on the Clipper/Capstone proposals all along. It will be most interesting to hear announcements on Capstone that announce its key exchange mechanism. I'm not sure what your point is here. It requires no conspiracy to opt for Diffie-Hellman as a key exchange mechanism; it's simply the obvious way to do things. (I'm speaking professionally here; cryptographic protocols are one of my research areas.) The STU-III's already use Diffie-Hellman; it's possible that the government's license for that patent grants it broad rights for such things. (The government does have free use of RSA; is there any such clause with respect to Diffie- Hellman?) PKP `had' the ability to murder Clipper/Capstone in its crib if it so desired, more so than any other single nexus, by denying the right to use public key algorithms (on which it now has a strangling, monopolistic lock). Gad, I can't believe it didn't occur to me to lobby them to do so. In retrospect, it wouldn't have done anything more than heighten the inevitable betrayal. No, PKP had no such ability. Clipper was always a potential source of profit to them, precisely because either RSA or Diffie-Hellman was needed for it. Given that they were going to make money from Clipper, the only question was how much. As Deep Throat said ~20 years ago, ``Follow the money''. (Those a bit older still should recall Dow Chemical's position on co-operating with the government.) ``Betrayal'' is a moral term. As I said before, corporations don't care about such things, only about bottom lines. That some settlement about DSA would be reached was inevitable. NIST needed PKP's assent to go ahead with DSA. PKP wanted to make money from the DSA, because it extends their profitable lifetime -- the RSA patent expires in 2001, whereas the Schnorr patent doesn't expire till 2008. PKP only opposed DSA while they didn't own the Schnorr patent; their other handle on DSA, the Diffie-Hellman patent, expires even earlier (1997). The interesting thing is the incentive to use Clipper. That's not something PKP cares about one way or another, compared with any sort of widespread use of cryptography (though perhaps RSADSI does; if private cryptography is restricted, RC2 and RC4 have much less of a market). Obviously, NIST wanted some clause like that. In exchange, they had to give PKP something more. My guess is that the hook was to grant them exclusive world-wide licensing rights to DSA, rather than simply a cut of the royalties. Maybe Mr. Bellovin can clarify how this agreement represents an `encouraging trend in the private sector to compete with the NSA' -- Good lord man, not unless you think that PKP represents the entire private sector in cryptographic applications. Uh, touche' -- you do and it does. I was unclear; I wasn't referring to the agreement at all. Rather, I meant that Schnorr had invented the algorithm that NIST had to have -- a signature scheme that is very efficient for smart cards, but could not be used for secrecy. NSA apparently didn't have anything better; I can't believe they and NIST were unaware of Schnorr's work (though perhaps they were unaware of the patent). (I suppose, of course, that NSA might have had something totally different, which they couldn't discuss because it would open up new areas for civilian research...) P.S. doubt P.R.Z. will be in a docile mood after hearing this one... Especially given the part about reserving the right not to license to infringers....

1 0

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