- cypherpunks-legacy - lists.cpunks.org

caller ID outrage from the FCC -- time to act (fwd)
by Stanton McCandlish 17 Dec '03

17 Dec '03

Looks like the 2-pronged assault on privacy from Clipper and Digital Telephony just grew another prong... Forwarded message: Date: Sun, 15 May 1994 21:15:06 -0700 From: Phil Agre <pagre(a)weber.ucsd.edu> To: rre(a)weber.ucsd.edu Subject: caller ID outrage from the FCC -- time to act I've enclosed two messages from the Privacy digest about an outrageous FCC plan to undermine crucial privacy protections on caller-ID systems for telephones. Caller-ID exists so that marketing companies can collect information on unwitting consumers, and those same companies have lobbied long and hard to eliminate simple, ordinary schemes to give people control over whether this information is made available from their telephones. Having lost this battle in many states, they have evidently moved to the federal level. But time remains for your comments to make a difference. Please read the enclosed messages, judge for yourself, and act. Phil Encl: Date: Sun, 15 May 94 13:23 PDT From: privacy(a)vortex.com (PRIVACY Forum) To: PRIVACY-Forum-List(a)vortex.com Subject: PRIVACY Forum Digest V03 #10 PRIVACY Forum Digest Sunday, 15 May 1994 Volume 03 : Issue 10 Moderated by Lauren Weinstein (lauren(a)vortex.com) Vortex Technology, Woodland Hills, CA, U.S.A. ===== PRIVACY FORUM ===== The PRIVACY Forum digest is supported in part by the ACM Committee on Computers and Public Policy. ----------------------------------------------------------------------------- Date: Fri, 6 May 94 12:10:59 PDT From: carl_page(a)rainbow.mentorg.com (Carl Page @ DAD) Subject: FCC attacks Private Unlisted Phone Numbers Banned Nationwide. Law Enforcement Explicitly Compromised. Women's Shelters Security Threatened. Telephone Rules of 30 States Overturned. Direct Marketing Association Anticipates Profit. The FCC released its Report and Order And Notice of Proposed Rulemaking of March 29th, 1994 (CC Docket No. 91-281) With the arrogance that only federal bureaucrats can muster, the Federal Communications Commission has turned the clock back on Calling Number ID and privacy protection rules nationwide. Have you ever had any trouble giving a direct marketer your phone number? You won't any more. Your Per Line Caller ID blocking will be banned, thanks to the FCC Order which preempts the privacy protections provided by 30 states. The order carefully enumerates the concerns of law-enforcement agencies which need per-line blocking to do their jobs. It mentions the need Women's shelters have for per-line blocking. (A matter of life and death on a day-to-day basis) It mentions that the customers who attempt to keep unlisted numbers confidential will be certainly be thwarted. (Can one train all kids and house-guests to dial *67 before every call? Can you remember to do it yourself?) But the Order dismisses all of these problems, and determines that the greatest good for the greater number will be accomplished if RBOC's can profit a bit more by selling our numbers and if the direct marketers have less trouble gathering them. The FCC doesn't seem to trust consumers to be able to decide whether they want per-line blocking. It praises the $40 cost of an automatic *67 dialer as an appropriate disincentive that will benefit the nation by discouraging people's choice of per-line blocking. There was one part of the order I was pretty happy about, until I read it. The FCC has also banned the sale of numbers gathered by 800-900 number subscribers using the ANI system, unless they obtain verbal consent. (Note that no rules prevent sale of numbers from the presumably blockable CNID system.) The problem is that the only enforcement of the rule seems to be that the requirement must be included in the fine print of the ANI sale contract between the common-carrier and the ANI subscriber. So it seems to be up to the common-carrier to enforce a rule which is contrary to their financial interest. How can a person who suffers from publication or sale of their number recover compensation? The FCC is soliciting comments, due May 18th in their Further Notice Of Proposed Rulemaking on two issues: o Whether the Commission should prescribe more precise educational requirements. o Whether and how the policies adopted on caller ID should be extended to other identification services, such as caller party name or CPNI. I can think of some suggestions... ------------------------------ Date: Wed, 11 May 94 02:39:45 EDT From: johnl(a)iecc.com (John R Levine) Subject: FCC order on interstate Caller ID [ From TELECOM Digest V14 #208 -- MODERATOR ] I picked up a copy of the FCC's Caller ID order, which is available by FTP as /pub/Orders/Common_Carrier/orcc4001.txt or orcc4001.wp. (Kudos to the FCC for making this info available so easily and quickly, by the way.) Much of the order is straightforward and not contentious, e.g. delivering CNID between local and long distance carriers is so cheap to implement that neither may charge the other for the data. They also note that per-call blocking is a good idea, and that *67 should be the universal code to block CNID delivery. But the arguments they list against per-line CNID seem, to me, to be astonishingly specious. There are three blocking options 1) per call for anyone, 2) per line for anyone, and 3) per line for special groups. The FCC thinks, not unreasonably, that it's a mare's nest to ask the telco to implement 3, since they have to determine who's in the special groups and who isn't. Then they say: 43. In the NPRM, we tentatively concluded that per line blocking unduly burdens calling party number based services overall by failing to limit its applicability to those calls for which privacy is of concern to the caller. The Commission noted that even in the case of law enforcement personnel, there may be a need to maintain calling number privacy on some calls, but that the same number may be used to telephone other law enforcement personnel, victims of crimes, cooperative witnesses, and family or friends. The Commission asserted that in these types of calls, calling number privacy is not needed and calling number identification can actually be a valuable piece of information for both the caller and called parties. The record reflects the useful nature of CPN based services, and the comments of Rochester illustrate that callers are likely to be interested in blocking only a small percentage of their calls. The comments of USCG illustrate the usefulness of caller ID to emergency services. In contrast, Missouri Counsel's analogy to unlisted numbers is inapposite because caller ID only permits parties called by the calling party to capture the calling party number, and then only if the calling party has not activated a per call blocking mechanism. We find that the availability of per call unblocking does not cure the ill effects of per line blocking. Moreover, in an emergency, a caller is not likely to remember to dial or even to know to dial an unblocking code. For the foregoing reasons, we find that a federal per line blocking requirement for interstate CPN based services, including caller ID, is not the best policy choice of those available to recognize the privacy interests of callers. Thus, carriers may not offer per line blocking as a privacy protection mechanism on interstate calls. We agree that certain uses of captured calling numbers need to be controlled, and address that issue infra. In other words, per-line blocking is a bad idea because subscribers are too dumb to unblock calls when they want to unblock them, although they're not to dumb to block calls when they want to block them. In paragraph 47 they note that where per-line blocking is offered, telcos use *67 as a blocking toggle, so users can't really tell what *67 does, but it doesn't seem to occur to them that the problem is easily solved by requiring a different code for unblock than for block. In paragraph 48 they wave their hands and say that people who care about privacy can just buy a box for "as little as $40.00 per unit" that will stuff *67 in front of each call. Thanks, guys. The docket number is 91-281, with comments due by May 18th. Comments must reference the docket number. Send ten copies (yes, 10) to: Office of the Secretary Federal Communications Commission Washington DC 20554 Before you fire off a comment, please get a copy of the order, since there's a lot of material beyond what I've summarized. For people without FTP access, I've put them on my mail server. Send: send fcc-cnid.txt (for the text version) send fcc-cnid.wp.uu (for uuencoded compressed WP version) to compilers-server(a)iecc.com. Regards, John Levine, johnl(a)iecc.com, jlevine(a)delphi.com, 1037498(a)mcimail.com ------------------------------ End of PRIVACY Forum Digest 03.10 ************************ -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 14 1994

1 0

PGP 2.6 and the future
by Robert A. Hayden 17 Dec '03

17 Dec '03

Seems to me, perhaps, that the introduction of 2.6 might be a precursor to RSA legally cracking down on anyone running pre-2.6 versions (accepting that 2.4, viacrypt, is ok). Scarey if you think about it, especially if the RSA folx are in bed with the fed, which doesn't seem that unrealistic considering the political climate. That, coupled witht he fact that no one has yet verified the seciurity of 2.5/2.6 lead me to seriously question the security of this new version, since we are essentially being forced to use it if RSA starts suing everyone, or gets the fed to crack down because of patent infringement. Sorry, just a rambling... ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> Political Correctness is \/ Finger for PGP 2.3a Public Key <=> P.C. for "Thought Police" -=-=-=-=-=-=-=- (GEEK CODE 1.0.1) GAT d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++ n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)

4 7

How to make fixes stick (Was Re: PGP 2.5 Beta Release Over, PGP 2.6 to be released next week)
by Richard Johnson 17 Dec '03

17 Dec '03

According to Jeffrey I. Schiller, PGP 2.6 will issue broken messages, unreadable by earlier legal versions of PGP (Viacrypt's 2.4 in USA and Canada, and any version outside backward-crypto-land) In summary, how do we make our fixes to this obvious bug stick? (Institutional paranoia on) To me, this change is an obvious step in satisfying the TLA's desire for a segmented crypto market to slow widespread use of strong crypto. On the one side, we have misapplied ITAR regulations preventing export of a worldwide standard. On the other side, we have a wrongly-granted patent preventing use of an imported worldwide standard. PGP is a de-facto worldwide standard, and they're trying to break it. (Institutional paranoia off) From the keyboard of: Adam Shostack <adam(a)bwh.harvard.edu> > And 2.4 is legal, if the 2.6 code doesn't recognize that, > well, then that code is buggy & will need to be fixed. :) Adam has the right idea. The question is, how do we make such a fix stick? In order to beat the "canonical release" advantage of the broken 2.6, we'll need to spread the word widely (at least until a 2.6-compatible PGP is released and ported to the full range of current platforms by our outside compatriots). Some suggestions for after we create such patches: Letters to computer magazines (Infoworld, Wired, PC Week, etc.) Add entry to PGP FAQ about communicating with non-USA/Canada PGP users Add entry to PGP WWW pages in UK Weekly postings of the patches to alt.security.pgp (from outside NA) Monthly postings of the patches to alt.sources.patches (from outside NA) Press releases in other appropriate newsgroups, repeated Come up with others, particularly for the non-net world. :-) Richard

2 1

NES
by SGT=DARREN=S.=HARLOW%ISB%MCTSSA＠nwsfallbrook3.nwac.sea06.navy.mil 17 Dec '03

17 Dec '03

Does anyone have a write-up on NES? I believe that it is based on DES, but I am not sure. It is for a paper that I am writing up. Thanks! Sgt Darren Harlow - Computer Security MCTSSA, Camp Pendleton, USMC Internet: harlowd(a)nwsfallbrook3.nwac.sea06.navy.mil or another less reliable & slower: harlow(a)mqg1.usmc.mil Voice: Comm: (619) 725-2970 DSN (Autovon): 365-2970 Fax: Comm: (619) 725-9512 DSN (Autovon): 365-9512 PGP Public key available upon request "The views expressed are my own, and always will be..."

3 2

Re: PGP outside the US
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

So: US users can legally use PGP 2.5. Foreign users can also use PGP 2.5 until the US decides to kidnap them. As far as I know there are no laws against sending encrypted traffic across the border. Where lies the problem? With people like me who commute from the UK to the US regularly and don't particularly look forward to a strip-search and a flashlight up the butt every visit. (Unless the customs officer is *very* cute...) This is why I specifically don't want a copy of 2.5/2.6... - and I can't see any need for it anyway. G

2 1

PGP 2.6 incompatibilities
by VACCINIA＠UNCVX1.OIT.UNC.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- First I would like to say that Mr. Bailey is being taken (should have recanted while you had a chance), that being said, it is worth it to get someone to examine the code in a thorough manner. I'll ante up $10 to help alleviate the pain of losing this bet, Mr Bailey. Only good things can come of such a bet in my opinion. Perhaps, the above code analysis will present some new insights into patches and maybe even improvements! Someone wrote the list to say that the RSAREF code in 2.5 is not as good as Phil's, MIT seems to agree since it now has implimented new RSA code "while you wait". I'm not using this new code unless the type of patch Adam Shostack has suggested is implemented, that is, it is fully compatible with previous (i.e. 2.3, 2.3a, 2.4) versions. This attempt at divide and conquer cannot be allowed. I would like to use a PGP which does not violate intellectual property rights (no matter the shaky legal patent grounds, at least here in the U.S.), but I'm not willing to use an "us" (americans, canadians) version of PGP leaving "them" (anyone else) totally incompatible. That just incapacitates all of us. Bring on PGP 2.6a. Scott G. Morham !The First, VACCINIA(a)uncvx1.oit.unc.edu! Second PGP Public Keys by Request ! and Third Levels ! of Information Storage and Retrieval !DNA, ! Biological Neural Nets, ! Cyberspace -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdfjrD2paOMjHHAhAQGSmQQA11SRVxevsL3NNvaBRyYc0yzqLjfxJ3dN 7I2leHc73nRwPwhhUJt2xeooHLlAlOHtLa+FBcbz8E03/vd8aBe7G0t7I4h0pSoB ujT5FRrArqV2x7AlVZquhbRECJ2nhwcIxN862GLvOYYQtIbC7NKvOYCFYMVt0p+x N1/28tvfRD4= =EB2O -----END PGP SIGNATURE-----

1 0

Bidzos in the NYT
by Duncan Frissell 17 Dec '03

17 Dec '03

Markoff has a profile of Jim Bidzos on the front page of today's NYT business section. "Profit and Ego in Data Security." No death threats mentioned other than: "The government would like him not to exist," said Jeffrey I. Schiller, a computer manager at the Massachusetts Institute of Technology, who has negotiated a licensing deal with Mr. Bidzos. DCF --- WinQwk 2.0b#1165

1 0

Ripem Mac, MacPGP and NEON
by GERSTEIN＠SCSUD.CTSTATEU.EDU 17 Dec '03

17 Dec '03

Hey guys- Can anyone tell me what the latest version of Ripem for the Mac is, as well as where I can find it. Also, does anyone know when MacPGP 2.5 or 2.6 will be available? Reply to either question via private mail as I am no longer on the list :( Neon- Mail me if you did/did not get my post to you. Adam Gerstein GERSTEIN(a)SCSU.CTSTATEU.EDU

1 0

Re: PGP 2.5 Beta Release Over, PGP 2.6 to be released next week
by Ezekial Palmer 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Date: Mon, 16 May 1994 14:56:06 -0400 From: "Perry E. Metzger" <perry(a)imsi.com> Besides, since 2.5 is legal, and doesn't have this "feature", and can be fixed by people at will, I suspect that no one will see any reason to use 2.6... I still haven't seen a good reason to stop using 2.3a . . . . Zeke -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdgC/hVg/9j67wWxAQE4gQQAgS7erpez7HooIXwHQri0pK3iNPYjAH5d ostRb9+NA9usyJrQ8kC+mQbV67R9dcnqZqivHEx63OXN+Wbo1zy3sZb8W5hs+S8r /cM1FcWJOb9gKVksIFi2DJHP3RljoLHeZQbYJutcTgFhWxokyjOo+rig4gzacfp5 jMlcA3BzXGM= =RyRf -----END PGP SIGNATURE-----

1 0

(fwd) Re: Real random numbers
by Jim choate 17 Dec '03

17 Dec '03

Path: bga.com!news.sprintlink.net!hookup!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gumby!wupost!spool.mu.edu!torn!nott!cunews!freenet.carleton.ca!freenet3.scri.fsu.edu!mailer.acns.fsu.edu!not-for-mail From: jac(a)ds8.scri.fsu.edu (Jim Carr) Newsgroups: sci.physics Subject: Re: Real random numbers Date: 24 Jun 1994 15:56:03 -0400 Organization: Supercomputer Computations Research Institute Lines: 39 Message-ID: <2ufdoj$h69(a)ds8.scri.fsu.edu> References: <2u69cp$46q(a)asterix.uni-muenster.de> NNTP-Posting-Host: ds8.scri.fsu.edu Keywords: real random numbers , Monte Carlo simulation In article <2u69cp$46q(a)asterix.uni-muenster.de> hoppep(a)asterix.uni-muenster.de (Peter Hoppe) writes: > >4-bit random numbers (0,1,...,15) have been produced from >thermal noise by a complicated method. >Since the production is not due to a determining algorithm >(of a pseudo random generator) these numbers are 'real random numbers'. >So a priori there could not be any periodicity in the number series. >The equipartition has been checked by the "chi-square-test" and the >correlations by the "serial-test" [1]. Both equipartition and >correlations fulfill the theoretical expectations very good. >[1] D. Knuth, The Art of Computer Programming, Vol. II, > Addison-Wesley, 1969 There are much tougher tests for random numbers than these, particularly if they are to be used for Monte Carlo where the numbers are used as m-tuples. The tests you really need to make are the ones George Marsaglia calls the 'monkey test' and the 'birthday test', as well as the m-tuples test. The first two are generalizations of the well known statistics problem of the monkey typing Shakespeare and of coincident birthdays in a group of people. They are tough to pass. The problem as I see it is that 4-bit numbers do not generate much variability, so you will really need m-tuples of 4-tuples of these. This increases the chance that long range correlations will catch up to you when you least want them. I am sure George would be interested in this, however, since they have been looking at ways to incorporate physical noise that is truly random into the very sophisticated generators like the combination of lagged fibonacci with congruential. The problem is that noise is seldom random enough, according to talks he has given. -- James A. Carr <jac(a)scri.fsu.edu> | "It's never confusing though, http://www.scri.fsu.edu | because ultimately it all fits Supercomputer Computations Res. Inst. | -- it's just cockeyed and fits Florida State, Tallahassee FL 32306 | and is fire." - Norman Maclean

1 0