December 2003 - cypherpunks-legacy

Re: 56 kbps modems
by craigw＠dg.ce.com.au 17 Dec '03

17 Dec '03

That I realize that baud and bit/sec are not the same, but I feel you would have a hard time getting a 56k modem to work on a line that does not support 28.8k fully, let alone 33.6k. A leased line (copper pair) from telstra only supports 9.6k and costs close to ISDN. When the telco reinstalls the literal tons of copper cable that we have lying underground for at least 20 years in some instances that connects the exchanges, and replaces this with optic fibre preferably, or at least higher bandwidth co-ax, we will not have 28k even. In the states you have better lines and ISDN is far less expensive. For two B channels perminantly connected I have to pay about $2500/month in this country. Not many home users can pay this, thus they have to still use modems. With the lack of bandwidth to and from the exchanges, there is not a chance in hell a 56k modem will work in this country for many years. (Australia - the lucky country...not in regards to bandwidth) > As I am sure has been discussed at length before, baud does not equal > bps. AFAIK, V32bis is only 2400baud. ,'~``. \|/ ,'``~. (-o=o-) (@ @) ,(-o=o-), +--.oooO--(_)--Ooo-----oOO-(_)-OOo-------oooO--(_)--Oooo.------+ | | | Soon, we may all be staring at our computers, wondering | | whether they're staring back. | | | | [Network Admin For WPA Business Products. aka doshai >;-) ] | | .oooO http://pip.com.au/~doshai/ Oooo. | | ( ) Oooo. .oooO ( ) | +-----\ (----( )-------oooO-Oooo--------( )--- ) /---------+ \_) ) / \ ( (_/ (_/ \_) Key fingerprint = 2D F4 54 BB B4 EA F1 E7 B6 DE 48 92 FC 8D FF 49 Send a message with the subject "send pgp-key" for a copy of my key. (if I want to give it to you)

2 1

Re: The Living and the Dead
by jya＠pipeline.com 17 Dec '03

17 Dec '03

On Sep 16, 1996 01:54:40, 'jya(a)pipeline.com (John Young)' wrote: >18 Nam photos on our Web page for a glimpse back to the >future of power-mad policy begetting slaughter. Corrected URL's: http://pwp.usa.pipeline.com/~jya/yp01.jpg through http://pwp.usa.pipeline.com/~jya/yp18.jpg

1 0

Re: Kiddie porn on the Internet
by James A. Donald 17 Dec '03

17 Dec '03

[Allegations that "save the children" is a political organization providing cover for an effort to ban cryptography] At 01:54 PM 9/9/96 -0400, Hallam-Baker wrote: > Their main mission is sending food to Ethiopia and other famine > areas, development work etc. It is ultra-worthy stuff. Not everyone who sends food to the starving children is ultra respectable. Problem is that the usual cause of starving children is tyranny. In order to get close enough to the starving children to take those cute fund raising photographs you have to pay off and get cosy with tyrants. This creates a moral hazard, in that it is hard to tell the difference between normal bribery needed to do anything in a tyrannical state, and bribery to bribe tyrants to create starving children for photo ops. It is very common for international charities to develop excessively friendly relationships with murderous tyrannies, Monsters do not generally sport horns and a tail. More commonly they walk around on two legs with large neon halos prominently displayed. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

ComLaw> Down South
by jim bell 17 Dec '03

17 Dec '03

Cross-post from commonlaw(a)teleport.com At 09:11 PM 9/15/96 -0400, James M. Cobb wrote: > 09 14 96 Associated Press distributes a newsstory headed: > > MEXICAN REBELS WARN OF MORE 'SELF-DEFENSE' ATTACKS > AGAINST GOVERNMENT > Points from the newsstory: > Leaders of a violent new rebel group are vowing to > press their war on Mexico's military and police.... > > [Last month's] raids were the most widespread guerril- > la attacks in Mexico in decades. > > ...during the news conference, the rebel leaders... > said that...bomb threats issued since last month's at- > tacks were part of an outside campaign to discredit the > group. > > They said their targets will continue to be government, > not civilian, sites. > Please note that word: OUTSIDE. > > Imported from Atlanta. > "Overnight" via NAFTA Express: > [The rebel group's statement] cited "the TERROR and > desperation caused by unemployment, the drastic reduc- > tion of the buying power of salaries, the lack of at- > tention to health, education and housing." > Cordially, > Jim > NOTE. The AP newsstory's www.nando.net online filename: > > world2_15734.html > I capitalized the Clinton-word in the last quota- > tion. > This critical essay was composed 09 15 96. >From what has appeared in the American media about this new Mexican rebel group, I'm particularly pleased with them. This is exactly the kind of alternative that we need to the stereotypical, "kill lotsa innocent citizens" attacks which are often associated with the term terrorism. They make it clear that they specifically target soldiers, police, and other government employees. After reading a couple of articles, it is obvious what they need: A method to prevent spoofing of their communiques, a function that PGP could do quite easily. Jim Bell jimbell(a)pacifier.com

1 0

Cryptography of a sort - redux
by Dale Thorn 17 Dec '03

17 Dec '03

If anyone remembers my original postings from a couple weeks ago (my first-ever on The Net), I described a method to "shuffle" bits in a text-stream, using simple random-number generators, to insure that the text cannot be descrambled by brute-force methods. It has occurred to me only after this time that there was significant misinterpretation of what I proposed. I do not change any bits of text, I merely reposition them, therefore there is no applicability of standard analysis techniques (XOR masking, whatever) to the decoding process. The result file contains the same number of zero and one bits as it started with, through any number of encryption layers. The only way to recover the original text is to reposition the shuffled bits correctly, which requires brute-force guessing of the pseudo-random-number output. This guess is very simple for the first encoding layer, but compounds exponentially in subsequent encodings, so that after half a dozen or a dozen passes, where the executable program(s) is called from scratch for each pass, the shuffling rapidly approaches true randomness, and cannot be decrypted in practice except through the exact mirror-image reversal of the encryption passes. An example: How long would it take for you to guess the number (between 0 and 32000) I'm thinking of, if you could guess 16 billion numbers per second? Would it be .000001 second, on average? If you had to guess the ten different numbers I'm thinking of, and get all ten correct sequentially, it should take an essentially infinite amount of time, yes? And remember, since computer bits have such low differentiation (ones and zeros), looking for "patterns" and so forth just doesn't apply in this type of encryption. As to the Public Key part of the argument, once there is general understanding on the above points at large, it might then be worthwhile to discuss the advantages and disadvantages of how to make/distribute Private keys, etc. One gentleman on this forum made an argument recently, something to the effect that it wouldn't be worthwhile for Hacker X to try to break into datastream Y, assuming datastream Y is encoded with such-and-such a key, that datastream Y is sufficiently unimportant, and motive for such a breakin would not be great enough to justify the expected effort. To such arguments, all I can say is, this is the computer age, and enough mundane transactions can add up to something significant, or, one could lower the expected-effort ratio, you get the picture.

2 1

IBM_gak
by jya＠pipeline.com 17 Dec '03

17 Dec '03

9-15-96. PcWe: "IBM Boosts Encryption Initiative " IBM security initiatives next month will include a new way to build encryption into software and technology that could enable U.S. companies to export products with strong encryption algorithms. IBM also will introduce several "key-recovery" technologies that could enable businesses to satisfy the requirement imposed by the U.S. government that it be able to access encrypted data on demand. IBM is attempting to garner industry support for the new key-recovery technology and is expected to license the technology to Netscape and Sun. 9-13-96. BuWi: "Revolutionary Intranet security product to be demonstrated at Interop DotCom " DSN's NetFortress fully automates hardware-based authentication, encryption and key exchange into a plug and play solution. It completely eliminates the possibility of IP spoofing, eavesdropping and break-ins. "After installing it, I couldn't even tell which service a given packet was from - everything but the packet header itself was rendered undecipherable as it traversed the Internet." DSN Technology was founded by Dr. Aharon Friedman and Andy Savas. ----- http://jya.com/ibmgak.txt (6 kb for 2) IBM_gak

5 4

Re: Email Robot draws fire from CypherPunkz
by peter＠baileynm.com 17 Dec '03

17 Dec '03

Sneck. The points I get out of this: 1. Cypherpunks lives up to its name. Mainly, the second part. 2. Whether an email spam is business related or not, it's neither desirable or interesting. Two years ago having a robot like that might have been amusing. Now it's just another spam. 3. Y'all really oughta read Stand on Zanzibar again. I think you're missing the point.

1 0

New Remailers?
by an401dws＠gold.ac.uk 17 Dec '03

17 Dec '03

OK dont shoot me, im new to this list so please Bear with me: I recently secured an account with anon.penet and then a few days later got a post informing me that the servive was now terminated. Anybody out there know of any remailers where you dont have to have a Phd in computer science and a thorough working knowledge of PGP in order to operate? Also, are there any remailers which will accept binary attachments? doug

1 0

Re: 56 kbps modems
by craigw＠dg.ce.com.au 17 Dec '03

17 Dec '03

well here in Australia Telstra our national carrier only "garantees" 2400 baud to work. I live within 2km of the exchange and the best I have ever achieved was 22k/sec over the lines (usually about 18k). This is not what the modem tells you it is doing....but what you get as a result of testing the ACTUAL modem speed using a line analizer program. What a modem manufacturer says you get and what the line gives you are Totaly separate. > People who seemed to know used to say that 'the Shannon limit' >set an absolute upper limit around 40 kbps. Has Shannon been >proven wrong, or what? ,'~``. \|/ ,'``~. (-o=o-) (@ @) ,(-o=o-), +--.oooO--(_)--Ooo-----oOO-(_)-OOo-------oooO--(_)--Oooo.------+ | | | Soon, we may all be staring at our computers, wondering | | whether they're staring back. | | | | [Network Admin For WPA Business Products. aka doshai >;-) ] | | .oooO http://pip.com.au/~doshai/ Oooo. | | ( ) Oooo. .oooO ( ) | +-----\ (----( )-------oooO-Oooo--------( )--- ) /---------+ \_) ) / \ ( (_/ (_/ \_) Key fingerprint = 2D F4 54 BB B4 EA F1 E7 B6 DE 48 92 FC 8D FF 49 Send a message with the subject "send pgp-key" for a copy of my key. (if I want to give it to you)

3 2

(Long) RFC: Public Key Finger: A preliminary proposal for a distributed key publishing system
by Geoff Dale 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The original (html) document may be obtained at: http://www.fqa.com/geoff/pkf.htm - --------------------------------------------------------------------------- Version 0.2, Draft Public Key Finger (aka the People's Key Front) A preliminary proposal for a distributed key publishing system - --------------------------------------------------------------------------- Wouldn't it be nice if distributing your public key(s) was as easy as publishing your e-mail address? As a matter of fact, it would be nice if you didn't even have to do anything more than giving out your e-mail address. Keyfinger is a way to make this possible. Requirements: Simplicity Components must be easy to understand, use, integrate, set-up and maintain. Scalability The system must be designed to be distributed and scale to accommodate large users like Netcom and AOL. To this end keyfinger uses the convention of connecting to keys.host.domain.com, allowing the administrator to use various methods to handle request traffic. Flexibility The system should be designed to allow interim solutions and phased deployment. Because of the fact that this system will not be deployed all at once, interim methods will be designed into the protocol. Security Ideally the fetching of keys should be across secure links, signed by the key-server, to avoid man-in-the-middle attacks. The individual keys should be self-certifying if signed by a known trusted entity (such as the ISP). Protocol: Client opens a socket connection to host (keys.host.domain.com or host.domain.com or domain.com) on designated port (a default port should be determined). Sends and inquiry string (user(a)host.domain.com) then the Host returns the contents of the .keyplan file. If the connection fails, the client may try to connect using http with a URL of form (http://host.domain.com/~user/.keyplan) Other supported methods may be finger and DNS lookup. Components: keyfinger Program for fetching the key. E-mail programs could incorporate this to allow automated key lookups within the mail authoring and authorization process. Various search engines could use this to allow key searches. Usage: keyfinger user[@host][.domain.com][@keyserver.domain.com][:port] ex: keyfinger geoff1(a)home.net Host and domain are resolved in the standard manner, a default port is tbd. The optional usage is to add an actual keyserver which could be used for a more traditional key-server system. keyfingerd Program (daemon) run on isp's key server. Would automatically serve up .keyplan files from user's home directories. Some versions may access a local key database instead. 'Nym servers and e-mail gateways would require this kind of service. The keyfinger server would be responsible for keeping the keyplan entries up to date. keyfinger-proxy Program (daemon) running on firewall to allow keyfinger to run through firewalls. Allows keyfinger-ing of foreign systems from within the firewall, but not the reverse. key-setup Program that provides a gui interface to aid in the account setup. Should be able to work with .keyplan files and key databases. Authentication required to change key info required. .keyplan File in the user's home directory that contains the key information. User's on ISP's that don't provide keyfinger service could publish their .keyplan files in the top level of their web directory (/~/public_html or whatever). The contents would be a multipart mime document containing available keys with key-type (and size) information, perhaps in preference order. Allowable mime parts would also include key-revocation certificates. Note: It is a question as to how strictly these allowable types should be enforced. To allow extension of new key types enforce mime-type: key/... but not subtype (eg - key/pgp ). content-handler Java content-handler for dealing with .keyplan files. Actually a content handler could be written for each key mime-type. The java code could actually use http to do retrieval. protocol-handler Java protocol-handler for dealing with "keyfinger:" URLs. This would essentially be an implementation of the keyfinger component. Usage: keyfinger:user[@host][.domain.com][:port] Action Items In no particular order: * IETF Format Draft * Write reference code * Need port designation * Need mime-types for keys and the .keyplan file. Important Dates * 96-09-07 First Publication to the Coderpunks list. * 96-09-14 Presented to SF Bay Cypherpunks Physical Meeting. - --------------------------------------------------------------------------- Page Maintained by Geoff Dale Last Modified: September 15, 1996 _____________________________________________ Geoff Dale - geoff1(a)home.net Paraphrasing Larry Niven: - -- Just think of it as economics in action -- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMjxVrv1Xc5SjvRJ5AQEUoAQAnU193QKDiV5wW+Iv+ozfZfEH7cyi/cz3 LqduEO3BGkmW4Xfz/bXCwIwwSph1LEcePt6v0Wv+QUGOTXR/CZqjtxTzr3uCTHvP 0Zd76ZlfLD+JI3NSFniXsAXEeGeYLnQJqSHAa9cGUCYPh3/pgwfBuwNC+ZTgYkJo ghLkuxHXrLE= =4icU -----END PGP SIGNATURE-----

2 1