December 2003 - cypherpunks-legacy

dos app STACKER, passwd?
by steve willey 17 Dec '03

17 Dec '03

does anyone know how password protection for the dos compression utility stacker works? and more importantly how it can be cracked. i will pay 5 Ghost Marks for USEFUL info. thanks, steve

1 0

PGP 2.6 announcement
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

Does anyone have a copy of the announcement stating the PGP 2.6 would not accept message from previous versions of PGP after September 1, 1994? If so please send it to me. Thanks, Reuben Halper

1 0

Re: Caller ID info...
by fnerd＠smds.com 17 Dec '03

17 Dec '03

In this report... > Report and Order And Notice of Proposed Rulemaking of > March 29th, 1994 (CC Docket No. 91-281) ...FCC apparently decides that per-line blocking should be prohibited since people might forget to unblock it when calling 911. John Levine says, > 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 [too] dumb to block calls when they want to block them. To me the question is, why can't the phone company provide options for blocking-on-all-but-911-calls, and unlisted-except-for-911? More precisely, why can't the FCC allow for this simple possibility? The reasoning seems to be, "since we can't understand why people want this, we must prohibit its even being an option:" > > ...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 find" it "is not the best... thus, carriers may not offer" it. What about what the customers and consumer groups have found and fought for? What is wrong with letting this be decided on a regional, if not provider, if not local, if not personal level? Why must FCC impose least- common-denominator reduction of services? > > ...with comments due by May 18th. That's today. I'm faxing this ill-prepared complaint to 202-632-6975. > > Comments must reference the docket number (CC Docket No. 91-281). > > Send ten copies (yes, 10) to: > > > > Office of the Secretary > > Federal Communications Commission > > Washington DC 20554 -fnerd quote me - - - - - - - - - - - - - - - and i dreamed i was flying high up above my eyes could clearly see the statue of liberty sailing away to sea --Paul Simon -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

2 1

Re: Caller ID info...
by peb＠netcom.com 17 Dec '03

17 Dec '03

Strange reasoning. Why not use the "*70" style code that turns it off for one call, just as *70 disables call waiting for modem use? Paul E. Baclace peb(a)netcom.com

1 0

RESEND: PGP 2.5 mini-review
by schirado＠lab.cc.wmich.edu 17 Dec '03

17 Dec '03

[I sent this out before I learned of the Great List Crash, so I'm resending it now.] Having not seen any activity on the list for the last week or so (I hope everyone's busy writing code!), I figured I'd simultaneously check to see if the list still existed, and share some interesting excerpts from NEWFOR25.DOC, from the PGP 2.5 MIT-legit package. PGP 2.5 is apparently still written by Phil Zimmermann - at least, it purports to be - which in itself is a considerable relief to those of us who had no idea who was responsible. The source code is also available, as before, and I'm sure programmers the world over are even now poring through it in minute detail, looking for backdoors and such. I also expect we'll be hearing from them relatively soon, to tell us of the presence or absence of any suspicious code. Not being a programmer myself, I can only comment on a few aspects. First, there is this: [...] >[An] RSAREF limitation is that it cannot cope with keys longer than >1024 bits. PGP now prints a reasonably polite error message in such a >case. I recall someone mentioning at one point that increasing the size of a key beyond 1024 bits did not justify the increased computing time, but I do not recall the reason why. I believe the reasoning was not that it offered no additional security, but rather, that it was already difficult enough to crack 1K keys, and if you're really that worried about security, you should be tightening up in other areas, such as deciding who to trust and who not to, deciding what information to enter into the computer and what to keep in your head, or maybe making a homemade TEMPEST shield. :) I'd still like to see the math explained a little better, though. Also, has anyone found those references to elliptic-curve crypto? The original article is _An Implementation of Elliptic Curve Cryptosystems Over F-2-155_ , IEEE Journal on Selected Areas in Communications, Vol. 11, #5, June 1993 (page 804). (Schneier mentions that Next Computer's Fast Elliptic Encryption, FEE, uses elliptic curves, and is patented by R E Crandell, USP# 5,159,632,27 October 1992.) Also, look for works by Neal Koblitz. >Printed keyIDs have been incresed to 32 bits, as there were enough keys >out there that 24-bit keyIDs were no longer sufficiently unique. The >previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID. >For example, what was printed as A966DD now appears as C7A966DD. So even though the keyservers only have 5,000 or so registered users, there are enough people out there using PGP and NOT registering their keys with the servers that this extra bit of coding was necessary? Hmm. 24 bits gives us 16,777,216 unique ID's. 32 bits gives us 4,294,967,296. Are there really over 17 million PGP'ers out there, or is my math-impaired brain missing something painfully obvious? >PGP now enables clearsig by default. If you sign and ascii-armor a >text file, and do not encrypt it, it is clearsigned unless you ask >for this not to be done. Which would seem to indicate that PGP is mainly being used for e-mail! Goody! >[...] > >PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random >data in an attempt to force disk compressors to overwrite as much data as >possible. > >[...] > >The normal help files (pgp -h) are pgp.hlp or <language>.hlp, such as >fr.hlp. Now, there is a separate help file for pgp -k, called pgpkey.hlp, >or <language>key.hlp. No file is provided by default; PGP will use >its one-page internal help by default, but you can create such a file >at your site. > >PGP used to get confused if you had a keyring containing signatures from >you, but not your public key. (PGP can't use the signatures in this case. >Only signatures from keys in the keyring are counted.) PGP still can't use >the signatures, but prints better warning messages. Also, adding a key on >your secret key ring to your public keyring now asks if the key should be >considered ultimately-trusted. Prviously, you had to run pgp -ke to force >this check, which was non-obvious. > >[...] > >On Unix, PGP now figures out the resolution of the system clock at run >time for the purpose of computing the amount of entropy in keystroke >timings. This means that on many Unix machines, less typing should be >required to generate keys. (SunOS and Linux especially.) > >The small prime table used in generating keys has been enlarged, which >should speed up key generation somewhat. > >There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!) >when generating primes 2 bits over a multiple of the unit size (16 bits >on PC's, 32 bits on most larger computers), if the processor doesn't deal >with expressions like "1<<32" by producing a result of 1. In practice, >that corresponds to a key size of 64*x+4 bits. > >Code changes: > >At the request of Windows programmers, the PSTR() macro used to translate >string has been renamed to LANG(). > >The random-number code has been *thoroughly* cleaned up. So has the >IDEA code and the MD5 code. The MD5 code was developed from scratch and >is available for public use. So, all in all, PGP 2.5 would seem to be more than just a possible conspiracy by MIT/RSA/et. al., and more than just minor bug fixes that most people wouldn't care about. With the possible exceptions of the size limitations on keys, and whatever arcane pieces have been hacked out of the RSA code to comply with whatever demands they may have made, PGP 2.5 appears to be a legitimate upgrade, with more than a few bugfixes, both major and minor, as well as the all-important improved security (as far as can be seen). Comments? ** schirado(a)lab.cc.wmich.edu [O|o]bjectivist, Evil Capitalist(tm;-), s..O).... You hit the smurf! --More-- male, lesbian, polyamorous, @.../.".. You destroy the smurf! --More-- reader, atheist, Discordian, $$*...].. You feel cynical! free and natural sovereign individual the Frog Farm: e-mail frog-farm-request(a)blizzard.lcs.mit.edu (PGP available)

1 0

RE: Cryptosystems Journal
by Pat Farrell 17 Dec '03

17 Dec '03

> Does anyone know where one can read back issues > of CryptoSystems Journal? I was looking for > Volume 2 Number 2. I tried at several Univeristies > but they said only the Library of congress had it. Tony Patti is the publisher of Cryptosystems Journal. He is _not_ on the net, his old portal account has been closed. He is working hard on Volume 3. You can reach Tony via snail mail to: Tony Patti Editor, Cryptosystems Journal PO BOX 188 Newtown PA 18940-0188 USA Tony has been publishing the Journal for a while, complete with floppies. I know he has non-US subscribers. I wonder how he exports it. I have a copy of Volume 2 Number 1, and Volume 2 Number 2. But you'd have to be in the DC area to see it. If we get a DC-area meeting working in May, I can bring it for folks to look at. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0

MotherJones MJ94: Pretty good hellraisin' (fwd)
by truher＠mojones.com 17 Dec '03

17 Dec '03

MotherJones MJ94: Pretty good hellraisin' -- by Ariel Sabar Philip Zimmermann, our February 1994 Hellraiser, is rushing to finish what he tentatively calls Voice PGP, named after his uncrackable computer encryption program, Pretty Good Privacy. His new creation turns a personal computer into a secure telephone--much to the consternation of the feds. Voice PGP uses a computer and high-speed modem to compress and encrypt the caller's voice before transmitting it onto ordinary phone lines. Only the called party can decode what the user is saying, in real time. Why Zimmermann's hurry? "We have a window of opportunity to fill this technology niche before the government acts," he says. Otherwise, once U.S. intelligence gets its hands on telephone surveillance technology, "it will be like putting a sticker on every phone that says, 'J. Edgar Hoover inside.'" Zimmermann and other cypherpunks are already disturbed by the government's decision to install the Clipper chip (an encryption device whose passwords are known to both the user and the feds) in computer communications software. His aim is to get Voice PGP out there (for free, like PGP) and widely in use by the end of the year. All rights reserved. Redistribution permitted with this notice attached. Redistribution for profit prohibited.

1 0

Anonymity is rude...
by Eric Johnson 17 Dec '03

17 Dec '03

According to Intel (via their acceptable use policy) anonymity is "bad form" which is monitored: Do not post any messages anonymously. This is viewed as bad form by the Usenet community and system managers are asked to track down offenders. This wastes Intel's time and resources. http://nearnet.gnn.com/gnn/news/feature/intel_guidelines.html Ahem, --Eric

1 0

PGP for voice... it's here :)
by lile＠netcom.com 17 Dec '03

17 Dec '03

almost... -lile

1 0

Re: FW: James Fallows on Clipper
by peb＠netcom.com 17 Dec '03

17 Dec '03

Re: The Atlantic, June 1994. The article is another "Nothing to Worry About". The article unfortunately occurs in the same issue that has a feature article about the possibility of Russian gangs obtaining nuclear weapons which also details how the coup attempt was observed by the NSA and Bush decided to let the good guys know so that the attempt could be thwarted. The NSA opposed letting them know since it would reveal their abilities, but Bush took the chance that this was not as bad as having a bunch of hardliners controllng the big bombs. This feature article will certainly give people the impression that crypto must be controlled or is at least a very important millitary matter. Now the NSA can't listen in, the article reported, but who knows what they've done since then. I hope to write a letter responding to Fallows' article, but right off I noticed some errors: he states that the millitary and intelligence services will use Clipper themselves when in fact, it would not be approved for secret information. (Recently someone noted that this is probably due to the key handling methods, but it could certainly be due to escrow itself as being risky.) Additionally, he brushes aside the accepted cryptographic methods (open inspection and testing) as being frivolous. (This seems to be a result of the NSA envy and pride runs through the article.) Paul E. Baclace peb(a)netcom.com

1 0