December 2003 - cypherpunks-legacy

RE: Workers Paradise. /Political rant.
by jim bell 17 Dec '03

17 Dec '03

At 02:00 AM 9/16/96 -0700, Timothy C. May wrote: >As to the "social safety net," things are far, far beyond a simple safety >net. When 14-year-old pregnant inner city girls are given money to set up >their own households (cf. Charles Murray's "Losing Ground"), this is not a >"safety net," this is subsidized breeding. A friend of mine (who can be just as coarse as I) calls them "Welfare-powered bastard factories." Jim Bell jimbell(a)pacifier.com

1 0

Edited Edupage, 15 Sept 1996
by E. Allen Smith 17 Dec '03

17 Dec '03

From: IN%"educom(a)educom.unc.edu" 16-SEP-1996 10:15:59.50 >To: IN%"edupage(a)elanor.oit.unc.edu" "EDUCOM Edupage Mailing List" >************************************************************ >Edupage, 15 September 1996. Edupage, a summary of news about information >technology, is provided three times a week as a service by Educom, >a Washington, D.C.-based consortium of leading colleges and universities >seeking to transform education through the use of information technology. >************************************************************ >SATELLITE BROADCASTERS MUST PROVIDE EDUCATION, TOO >A federal appeals court in Washington has ruled that any company providing >direct broadcast satellite (DBS) services must "reserve a portion of its >channel capacity, equal to not less than 4 percent nor more than 7 percent, >exclusively for noncommercial programming of an educational or information >nature," in compliance with regulations drafted by the FCC to enforce laws >enacted in 1984 and 1992. The unanimous decision rejected arguments by Time >Warner and other broadcasters that the law interfered with their First >Amendment rights. "It is the right of the viewers and listeners, not the >right of the broadcasters, which is paramount," said the court, quoting a >1969 Supreme Court ruling. (Chronicle of Higher Education 13 Sep 96 A29) Bloody socialist Supreme Court... sell the _full_ rights, then use the money to reduce taxes. >SYSTEM CRACKER GOT RECIPE FROM HACKER MAGAZINE >The person who disabled New York's Panix Internet service probably followed >the line-by-line instructions for doing so that appeared in the latest issue >of 2600 magazine, the Hacker's Quarterly. "We need to educate the community >that it's very, very simple to cause massive mayhem," says 2600's editor, >who defended his editorial judgment. "A lot of companies subscribe to us so >they can learn before they're victimized." Panix's co-owner says he >supports 2600's right to publish such information: "As a matter of >principle I don't think they should have been stopped," but adds that unlike >most other recipes for breaching security published in the magazine, this >one has no known technical defense. (Wall Street Journal 13 Sep 96 B5) Helpful to quote Panix on it. >Edupage is written by John Gehl <gehl(a)educom.edu> & Suzanne Douglas ><douglas(a)educom.edu>. Voice: 404-371-1853, Fax: 404-371-8057. >Technical support is provided by Information Technology Services at the >University of North Carolina at Chapel Hill. >*********************************************************** >Edupage ... is what you've just finished reading. To subscribe to Edupage: >send mail to: listproc(a)educom.unc.edu with the message: subscribe edupage >Henry R. Luce (if your name is Henry R. Luce; otherwise, substitute your >own name). ... To cancel, send a message to: listproc(a)educom.unc.edu with >the message: unsubscribe edupage. (If you have subscription problems, send >mail to manager(a)educom.unc.edu.)

1 0

Re: Snake Oil FAQ 0.4 [comments appreciated]
by Deranged Mutant 17 Dec '03

17 Dec '03

For those not-yet-in-the-know: I no longer have the time to manage it and asked for somebody (and Matt agreed to) to take the Snake Oil FAQ's care and feeding. Note that this is not cc'd to coderpunks. I don't think it's appropriate for coderpunks. On 16 Sep 96 at 9:56, C Matthew Curtin wrote: [..] > --------------------------- snake-oil-faq ---------------------------- > > Snake-Oil Warning Signs > Encryption Software to Avoid [..] > The Snake Oil FAQ is (to be) posted monthly to cypherpunks, sci.crypt, > alt.security, comp.security, and comp.infosystems. We're targeting those who Does it need to be posted monthly? Better to post pointers to it most of the time, possibly to other places as well (alt.2600 comes to mind...). Perhaps when the first 'non-beta' of this document is released a History could be added. [..] > Different products will serve different needs, and it's rare that a product > will serve every need. (Sometimes a product won't be needed: it may be Nitpick: Hm. Change that to "no product will serve every need". > better to use a utility to encrypt files, transmit them over a network using > standard file transfer tools, and decrypt them at the other end than to use > a separate encrypted utility in some cases.) Or more clearly: is encryption THE feature of the utility, or is it an added feature? It's better to use separate utilities made for that purpose rather than one that tries to do everything. [..] > Key Sizes > > Some ciphers, while currently secure against most attacks, are not > considered viable in the next few years because of relatively small keysizes > and increasing processor speeds (making a brute-force attacks feasible). The Change to "making brute force attacks--that is, trying every possible key--feasible". [..] > Symmetric and Public-Key Lengths With > Similar Resistance to Brute-Force Attacks > > Symmetric Key Length Public-key Key Length > 56 bits 384 bits > 64 bits 512 bits > 80 bits 768 bits > 112 bits 1792 bits > 128 bits 2304 bits That's a controversial comparison. I've read references (from a couple of years ago) saying that a 3k-bit RSA key is as strong as a 128-bit IDEA key. Trying to compare the two (symmetric and assymetric) is like running through a tar pit. > Some Common Snake-Oil Warning Signs > > The following are some of the "red flags" one should watch for when > examining an encryption product > > * Technobabble [..] > A sign of technobabble is a descrption which drops a lot of technical > terms for how the system works without actually explaining how it > works. Often specifically coined terms are used to describe the scheme > which are not found in the literature. Of course, how is an amateur supposed to know if these terms are found in the literature? That was a recurring comment that people sent me when I first posted the FAQ. [..] > Just because software uses to different method of computation Typo! "uses to different method..."? [..] > grounded in mathematical theory. The security is based on problems that > are believed, if not known to be hard to solve. Hm. How about "that are widely believed"? [..] > A OTP system is not an algorithm. It works by having a "pad" of > random bits in the possession of both the sender and recipient. [..] > never again be used. The bits in the pad must be truly random, > generated using a real random source, such as specialized > hardware, radioactive decay timings, etc., and not from an > algorithm or cipher. Anything else is not a one-time-pad. Although it is(?) mentioned below, I'd emphasize here in some way that the users of the OTP generate the key. Somebody else sending you a supposed OTP that he generated is not secure. > The vendor may confuse random session keys or initialization vectors > with OTPs. Explain random session keys and initialization vectors. A glossary at the end of the document would be a good thing. > Sometimes attacks are theoretical or impractical (requiring special > circumstances or massive computing power running for many years), and > it's easy to confuse a layman by mentioning these. Oh yeah. These need to be explained. What I had in mind was timing attacks against RSA or IDEA, or factoring of public keys. > * Keys and Passwords > > The "key" and the "password" are often not the same thing. The "key" "often" not?!? (oops...was that my wording?) They aren't the same, though often they are confused in snake oil. [..] > If there's a third-party utility that can crack the software, > avoid it. > > If the vendor claims it can recover lost passwords (without using a > key-backup or escrow feature), avoid it. > > If there is a key-backup or escrow feature, are you in control > of the backup, or does the vendor or someone else hold a copy > of the key? That is, if you lose the key, you don't want a third party to have as much a chance to recover it as you do. [..] > > If the vendor is unaware of export restrictions, avoid the software: > the vendor is not familiar with the state of the art. Also... if the vendor does not understand export restrictions, avoid the software. I'm thinking of a certain snoil-vendor who said 128-bit IDEA keys were'nt secure since they could be exported. > Because of export restrictions, some legitimate (not-Snake Oil) > products may have a freely exportable version for outside of the USA, > which is different from a separate US/Canada-only distribution. Also Such exportable versions are not as secure, of course. [..] > Other Considerations > > Interface isn't everything: user-friendliness is an important factor, but if > the product isn't secure then you're better off with something that is > secure (if not as easy to use). > > No product is secure if it's not used properly. You can be the weakest link > in the chain if you use a product carelessly. Do not trust any product to be > foolproof, and be wary any product that claims it is. I wanted to add some sort of 'non-guru hacks' to test a product. One example might be to actually examine 'encrypted' files to see if they are really encrypted. (I'm thinking of the AMG archiver, which only encrypted the CRC; CODEC archiver also only encrypted the CRC is a file is not compressed.) Thanks again for taking over the FAQ. A good job! Rob --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) Send a message with the subject "send pgp-key" for a copy of my key.

1 0

Diffie Hellman - logs in Galois fields
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

Hi all, A question for the matematicians out there: I am looking at the Diffie Hellman public key exchange protocol and am trying to find out why it is computationally hard to take logs in a finite (Galois) field. My maths tutor has told me a bit about the construction of Galois fields (If I`m correct the construction is Z mod N, N some integer, then a transformation F(x) on the residue classes already in the field) I know also the definition is that there are P**k elements, p a prime. My questions are as follows: 1. How can a field be finite, as by definition it has to be closed under addition, subtraction, multiplication and division???? (sorry if this one is a bit of a no brainer, maybe the definition is different but I can`t seem to see how) 2. Why is taking logs in a finite field computationally hard? - Me and Alec (My maths tutor at college) guessed that it is because exponentiation and logs are each others inverse functions, and somehow this becomes a one way function in a finite field. 3. Are the Galois fields used in Diffie Hellman specially constructed in any way or are they just normal GF???? Thanks for any help anyone can give me.... Datacomms Technologies web authoring and data security Paul Bradley, Paul(a)fatmans.demon.co.uk Http://www.fatmans.demon.co.uk/crypt/ "Don`t forget to mount a scratch monkey" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAjH9j+cAAAEEAMBvREiQR0ot9dFCO0TiSCSunAYLv2g1Bc6I3bz8FzKXNH53 6mieJf/W4rD+CxJpT0q9RQaaoRtkHJLwbjfK2il3D7mEahMAyqvF/xRJNqkXfhM3 sRJM0Jh43l+W0M5vwokbEbk25/bxWWGspTsLD3YHbzKnG6pOcL5OPIRbv66xAAUR tCdQYXVsIEJyYWRsZXkgPHBhdWxAZmF0bWFucy5kZW1vbi5jby51az6JAJUDBRAy NwfvNkCBjDT0xHEBATQPA/9TORmN/UjNecj03q4anpvdyCLiez5sKuNbnYK50RiP Jj4QpWWvST3smyQ0A86DrZY/re056MXwQmARESx0rFZxdnD0oORICl5r8dJLIy3b j8rbA5olXwZwKz73/X5s13v/pvHYX4cIsbVK8NHXqh5llSKt6TBAuGgkIGF29z5k C4kAlQMFEDI3B9mdtf/umVkv7QEBcRYD/1FBteLqsUmr81euxqqnnrpLlyHb58B/ 9sdATuua4uSjX46hXDZ264YozspNrzSB4NEdrmXOWVX3fiE0ga6XkSSkIeF23V90 En37Z0BdbFzgF00FRYTFyTq8eezQrdg/+rBPUsZUmG5wpq3e12FKHQsX01i+1mB2 YmqqwCV5e95eiQCVAgUQMh8uSb5OPIRbv66xAQEqJwP/fxQyiCasjFcbDpsFfsYp put5cCC/9pOx6X3DlbKShPMpUOS+A9HsTEmJQN8Iawv1nSwPdtc2cR/GhW6ilVjW LSloGdMVLabm9pGpZZMkRaZlXFUkOv7VhfgsUiL+vIDryBCAwUZCzQiWycjt/cPi mUqFH41Z7NkyO8ZFdi5GGX0= =CMZA -----END PGP PUBLIC KEY BLOCK-----

3 2

Re: The Living and the Dead
by jim bell 17 Dec '03

17 Dec '03

At 12:40 PM 9/16/96 -0400, Brian Davis wrote: >On Sun, 15 Sep 1996, jim bell wrote: > >> .... >> How would an AP-type system treat Robert McNamara? He'd be dead in a >> second. To those who say, "What good would this do?" I respond: Anyone in > ^^^^^^ >Kind of kills the betting pool, doesn't it? > >EBD Okay, it was just an expression... It would probably take a couple weeks. Jim Bell jimbell(a)pacifier.com

1 0

RE: Workers Paradise. /Political rant.
by jim bell 17 Dec '03

17 Dec '03

At 11:24 AM 9/16/96 EDT, Dr.Dimitri Vulis KOTM wrote: >jbugden(a)smtplink.alis.ca writes: >> dlv(a)bwalk.dm.com (Dr.Dimitri Vulis KOTM) wrote: >> >Starting with the lying old fart himself. >> >> You shouldn't be so hard on Tim. I tried giving up farting years ago but I = >> found >> I gained a lot of weight. It's also become more socially acceptable as evid= > >I wonder why containing one's fart would cause one to gain weight. Volume maybe, >but I'd think that gas weight about as much as the air it displaces. Actually, less: It's mostly hydrogen. Jim Bell jimbell(a)pacifier.com

1 0

Spam blacklist project
by hallam＠ai.mit.edu 17 Dec '03

17 Dec '03

Hi, The following idea just hit me. How about a server which maintained a list of people who don't want to recive SPAM? The idea being that email recpients who don't want SPAM send their email address to the list. A SPAMer who want to check an email to see if it is on the list could then obtain the SHA-Digested list of addresses and remove them from their internal databases. Of course I don't for a moment imagine that this will be 100% effective. Without government regulation there will always be slimeballs who send mail to people who don't want it. The advantage of this scheme is that it would mean that the spam industry can avoid regulation pressure and they can deflect criticism. Meanwhile recipients of unwanted spam have a legitimate beef. Comments? Phill

6 7

Re: New Remailers?
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

At 10:53 AM 9/16/96 BST, you wrote: >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? Raph Levien's remailer list lives at http://www.cs.berkeley.edu/~raph/remailer-list.html Most of the remailers on it are the one-way variety - you can send mail to someone anonymously, but you don't get an address for people to reply to you. They're easy to use. Some of them also support anonymous reply blocks, which are a somewhat difficult-to-use feature - you basically PGP-encrypt your return address (in the correct syntax), and tell anybody who wants to reply to you to include the block at the beginning of their mail. There have been some pseudonym servers besides anon.penet.fi, which provide higher security, and are easier to use than anonymous reply blocks, once you set them up (which generally involves creating anonymous reply blocks :-) Two of them have been spammed to death, but the cyber remailer at alias(a)alias.cyberpass.net is still up. Send it a request for help to get information. Raph has a new system coming soon; see his remailer list for details. Private Idaho is Joel McNamara's friendly user interface for remailers and PGP. http://www.eskimo.com/~joelm/pi_list.html . Runs on MSWindows. It made it _much_ easier to use the alpha nymserver while that was still alive; don't know if the new version supports cyber yet or not. Remailer security depends on encryption - otherwise wiretappers can watch mail going into the remailer and know where it's going. So you'll need to learn to use PGP, but it's pretty straightforward, and Private Idaho makes it more convenient. The Mixmaster remailers provide higher security remailing, also with no reply capability; you need to get special client software, which I think isn't ported to Windows yet? >Also, are there any remailers which will accept binary attachments? There are three popular ways to do binary attachments - 1) MIME-encoding (uses MIME headers and maybe a 7-bit content transfer encoding.) 2) UUENCODE (simple-minded header and 7-bit ASCII.) 3) Mail-handler-specific headers with binary stuff following Uuencode is a no-brainer - just stick the uuencoded binary after the remailer headers. As far as I know, none of the remailers are particularly MIME-aware, but they do glue headers together. So you could probably start sticking MIME headers after the remailer headers and try a few times to get it to work. Mail-handler-specific behaviour is, of course, mail-handler-specific :-) You can try it and see, and remember that the person at the other end may not have the same kind of mail handler you do, so even if you sent the mail directly instead of through a remailer, it might not work. You may have trouble getting your mail client to do what you want for sending the message (e.g. if you use Cc:Mail or MSMail.) I looked at the code for my remailer, which is a modified Ghio2, though I don't think I modified this part, and it'll trash binaries. The problem is that, after processing headers, it shoves the rest of the input stream into the output file by a loop of fgets() check for cutmarks fprintf() which will trash anything that contains nulls, and may not do the right thing for newlines either, though it won't bother high-bits. I suppose it wouldn't be too hard to write a getchar/putchar loop that checks for cutmarks while transferring data safely (this would be easier if cutmark behaviour includes outputting the cutmark.) However, the remailer uses the native mail program (e.g. sendmail) to forward the mail, so if your sendmail trashes binaries, or does annoying vestigial things like changing "From " to ">From " at the beginnings of lines, it'll still lose. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto

1 0

Re: Kiddie porn on the Internet
by jim bell 17 Dec '03

17 Dec '03

At 08:51 AM 9/15/96 -0700, James A. Donald wrote: >[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, Yet another obligatory AP (Assassination Politics) reference: If a person is really interested in helping out "starving children" he may be able to do far more good by purchasing the death of the local tyrant(s), rather than (just) buying more food. After all, if the donor really believes that this starvation isn't endemic to the country, he has to conclude that it's a condition which is forced on the victims. In addition, you almost always find that these starving countries have well-supplied militaries, defending the local warlords against each other as in Somalia. Indeed, in Somalia the incoming food was actually used to buoy up one group against another, because access to it is controlled directly or indirectly by the factions. Some might argue that the death of a single leader doesn't normally fix the problem. While that's often true, it's normally because there isn't an automatic guarantee that the next 20+ leaders will ALSO be killed if they display the same problems as the first. Provide that guarantee, and (somewhat paradoxically) not only do you not need to kill the 20+, you probably won't have to kill the first one! (wondering when the world will see the light...) Jim Bell jimbell(a)pacifier.com

2 1

Redundancy in XOR encryption
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have a question I hope someone here might be able to answer: As the method of cryptanalysis of XOR (Ie. index of coincidence) relies on redundancy in the plaintext, would the following be strong: Compress P to get perfect compression (ie. 0 redundancy) Encrypt F (the compressed text) using a repeated key XOR of course this is all rather theoretical as there is no such thing as perfect compression, but I just thought it might be interesting to see if this is indeed strong, superficially it appears so to me... -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: cp850 iQCVAwUBMj2TvL5OPIRbv66xAQGRpgP+LU0Y8sxzO6rObCYAQdrD8/R/iDJN3m0Z 4ZetS7jcbz7wT6bj2l7Usb0F4h/YMhxtl0y9EQ91ozg35jfRKdy2IwUoMDvqsVSZ wKmaM/DpEt2LDyRQnzIvlNYQp6/eXQoBUb7r9SH/dZbjM7culpjzJLhd07Nx5okE jUmPNBLm9m0= =RHie -----END PGP SIGNATURE----- Datacomms Technologies web authoring and data security Paul Bradley, Paul(a)fatmans.demon.co.uk Http://www.fatmans.demon.co.uk/crypt/ "Don`t forget to mount a scratch monkey" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAjH9j+cAAAEEAMBvREiQR0ot9dFCO0TiSCSunAYLv2g1Bc6I3bz8FzKXNH53 6mieJf/W4rD+CxJpT0q9RQaaoRtkHJLwbjfK2il3D7mEahMAyqvF/xRJNqkXfhM3 sRJM0Jh43l+W0M5vwokbEbk25/bxWWGspTsLD3YHbzKnG6pOcL5OPIRbv66xAAUR tCdQYXVsIEJyYWRsZXkgPHBhdWxAZmF0bWFucy5kZW1vbi5jby51az6JAJUDBRAy NwfvNkCBjDT0xHEBATQPA/9TORmN/UjNecj03q4anpvdyCLiez5sKuNbnYK50RiP Jj4QpWWvST3smyQ0A86DrZY/re056MXwQmARESx0rFZxdnD0oORICl5r8dJLIy3b j8rbA5olXwZwKz73/X5s13v/pvHYX4cIsbVK8NHXqh5llSKt6TBAuGgkIGF29z5k C4kAlQMFEDI3B9mdtf/umVkv7QEBcRYD/1FBteLqsUmr81euxqqnnrpLlyHb58B/ 9sdATuua4uSjX46hXDZ264YozspNrzSB4NEdrmXOWVX3fiE0ga6XkSSkIeF23V90 En37Z0BdbFzgF00FRYTFyTq8eezQrdg/+rBPUsZUmG5wpq3e12FKHQsX01i+1mB2 YmqqwCV5e95eiQCVAgUQMh8uSb5OPIRbv66xAQEqJwP/fxQyiCasjFcbDpsFfsYp put5cCC/9pOx6X3DlbKShPMpUOS+A9HsTEmJQN8Iawv1nSwPdtc2cR/GhW6ilVjW LSloGdMVLabm9pGpZZMkRaZlXFUkOv7VhfgsUiL+vIDryBCAwUZCzQiWycjt/cPi mUqFH41Z7NkyO8ZFdi5GGX0= =CMZA -----END PGP PUBLIC KEY BLOCK-----

2 1