December 2003 - cypherpunks-legacy

description of the PC1 cipher - please comment
by alex 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Voici l'algorithme de codage PC1 ( Pukall Cipher 1 ). C'est un algorithme de chiffrement en continu ( chaque octet est chiffre separement ) en mode CFB ( chaque octet chiffre modifie le codage des suivants ). Il a ete cree en 1991 par Alexandre Pukall. L'algorithme est sous copyright mais en diffusion freeware. L'utilisation de l'algorithme PC1 et du protocole qui suivra est libre comme les modifications eventuelles a la condition unique que le nom de l'auteur soit mentionne dans la documentations et dans le logiciel qui pourrait se servir de l'algorithme. Il est preferable, si la cle utilisee avec l'algorithme PC1 est entree par l'utilisateur, de recommander a ce dernier d'utiliser des cles hachees. Il choisit une phrase facile a retenir : Rene et moi sommes alles a la peche samedi ! et il prend la premiere lettre de chaque mot : Remsaalps! : ceci est la cle qu'il utilise ( l'algorithme PC1 accepte tous les caracteres ASCII et les caracteres EBCDIC de valeur 0 a 255 ). A noter que les variables utilisees dans l'algorithme, sont globales afin de permettre un brassage entre les differents appels de la fonction code() dans la fonction principale assemble (). Le type 'unsigned int' est une variable sur 16 bits ( valeur de 0 a 65535 ). Le type 'unsigned char' est une variable sur 8 bits ( valeur de 0 a 255 ). Le type 'short' est une variable sur 8 bits ( valeur de 0 a 255 ). **************************************************************************** **************************************************************************** **************************************************************************** ************************ /* Fichier PC1COD.c */ /* ecrit en Borland Turbo C 2.0 sur PC */ /* Algorithme de CODAGE PC1 ( Pukall Cipher 1 ) */ /* (c) Alexandre PUKALL 1991 */ /* Utilisation et modifications libres si le nom de l'auteur est */ /* inclu dans le programme final et la documentation du logiciel */ /* dans un endroit accessible librement par l'utilisateur comme */ /* les fenetres A propos des logiciels sous Windows sur PC */ /* Cet algorithme a ete ecrit en Assembleur 6809 Motorola */ /* le code C ci-dessous est la traduction rapide de cet algorithme */ /* le fonctionnement est identique */ /* A noter que dans cet exemple le programme de codage et le programme */ /* de decodage sont separes */ /* vous pouvez les reunir en un seul en modifiant la zone K */ /* qui est legerement differente pour le codage et le decodage */ /* a cause du lien entre le texte clair et la cle de chiffrement */ #include <stdio.h> #include <string.h> unsigned int ax,bx,cx,dx,si,tmp,x1a2,x1a0[5],res,i,inter,cfc,cfd,compte; unsigned char cle[11]; /* les variables sont definies de facon globale */ short c; FILE *in,*out; fin() { /* on quitte en effacant toutes les variables utilisees par l'algorithme */ for (compte=0;compte<=9;compte++) { cle[compte]=0; } ax=0; bx=0; cx=0; dx=0; si=0; tmp=0; x1a2=0; x1a0[0]=0; x1a0[1]=0; x1a0[2]=0; x1a0[3]=0; x1a0[4]=0; res=0; i=0; inter=0; cfc=0; cfd=0; compte=0; c=0; exit(0); } assemble() { x1a0[0]= ( cle[0]*256 )+ cle[1]; code(); inter=res; x1a0[1]= x1a0[0] ^ ( (cle[2]*256) + cle[3] ); code(); inter=inter^res; x1a0[2]= x1a0[1] ^ ( (cle[4]*256) + cle[5] ); code(); inter=inter^res; x1a0[3]= x1a0[2] ^ ( (cle[6]*256) + cle[7] ); code(); inter=inter^res; x1a0[4]= x1a0[3] ^ ( (cle[8]*256) + cle[9] );; code(); inter=inter^res; i=0; } code() { dx=x1a2+i; ax=x1a0[i]; cx=0x015a; bx=0x4e35; tmp=ax; ax=si; si=tmp; tmp=ax; ax=dx; dx=tmp; if (ax!=0) { ax=ax*bx; } tmp=ax; ax=cx; cx=tmp; if (ax!=0) { ax=ax*si; cx=ax+cx; } tmp=ax; ax=si; si=tmp; ax=ax*bx; dx=cx+dx; ax=ax+1; x1a2=dx; x1a0[i]=ax; res=ax^dx; i=i+1; } main() { si=0; x1a2=0; i=0; /* C'est le cle ci-dessous ('Remsaalps!') que vous pouvez changer */ strcpy(cle,"Remsaalps!"); /* copie les 10 caracteres de la cle dans cle */ /* ouverture du fichier ESSAI.TXT qui sera code */ /* ceci n'existe pas dans l'algorithme original ou tout se passe en RAM */ /* il doit exister un fichier ESSAI.TXT dans le repertoire courant ! */ /* a vous de le creer ! */ if ((in=fopen("essai.txt","rb")) == NULL) {printf("\nErreur lecture fichier ESSAI.TXT !\n");fin();} if ((out=fopen("sortie.txt","wb")) == NULL) {printf("\nErreur d'ecriture fichier SORTIE.TXT !\n");fin();} /* le fichier code se trouve dans SORTIE.TXT */ while ( (c=fgetc(in)) != EOF) /* la variable c recoit l'octet lu dans le fichier */ { assemble(); /* execute la routine de codage */ cfc=inter>>8; cfd=inter&255; /* cfc^cfd = octet aleatoire */ /* ZONE K !!!!!!!!!!!!! */ /* ici le melange de c ( octet clair ) avec cle[compte] se situe */ /* avant le codage de c */ for (compte=0;compte<=9;compte++) { /* on melange l'octet clair lu dans le fichier */ /* a la cle utilisee pour le codage */ cle[compte]=cle[compte]^c; } c = c ^ (cfc^cfd); fputc(c,out); /* ecriture de l'octet code dans le fichier SORTIE.TXT */ } fclose (in); fclose (out); fin(); } **************************************************************************** **************************************************************************** **************************************************************************** ************************ **************************************************************************** **************************************************************************** **************************************************************************** ************************ /* Fichier PC1DEC.c */ /* ecrit en Borland Turbo C 2.0 sur PC */ /* Algorithme de DECODAGE PC1 ( Pukall Cipher 1 ) */ /* (c) Alexandre PUKALL 1991 */ /* Utilisation et modifications libres si le nom de l'auteur est */ /* inclu dans le programme final et la documentation du logiciel */ /* dans un endroit accessible librement par l'utilisateur comme */ /* les fenetres A propos des logiciels sous Windows sur PC */ /* Cet algorithme a ete ecrit en Assembleur 6809 Motorola */ /* le code C ci-dessous est la traduction rapide de cet algorithme */ /* le fonctionnement est identique */ /* A noter que dans cet exemple le programme de codage et le programme */ /* de decodage sont separes */ /* vous pouvez les reunir en un seul en modifiant la zone K */ /* qui est legerement differente pour le codage et le decodage */ /* a cause du lien entre le texte clair et la cle de chiffrement */ #include <stdio.h> #include <string.h> unsigned int ax,bx,cx,dx,si,tmp,x1a2,x1a0[5],res,i,inter,cfc,cfd,compte; unsigned char cle[11]; /* les variables sont definies de facon globale */ short c; FILE *in,*out; fin() { /* on quitte en effacant toutes les variables utilisees par l'algorithme */ for (compte=0;compte<=9;compte++) { cle[compte]=0; } ax=0; bx=0; cx=0; dx=0; si=0; tmp=0; x1a2=0; x1a0[0]=0; x1a0[1]=0; x1a0[2]=0; x1a0[3]=0; x1a0[4]=0; res=0; i=0; inter=0; cfc=0; cfd=0; compte=0; c=0; exit(0); } assemble() { x1a0[0]= ( cle[0]*256 )+ cle[1]; code(); inter=res; x1a0[1]= x1a0[0] ^ ( (cle[2]*256) + cle[3] ); code(); inter=inter^res; x1a0[2]= x1a0[1] ^ ( (cle[4]*256) + cle[5] ); code(); inter=inter^res; x1a0[3]= x1a0[2] ^ ( (cle[6]*256) + cle[7] ); code(); inter=inter^res; x1a0[4]= x1a0[3] ^ ( (cle[8]*256) + cle[9] );; code(); inter=inter^res; i=0; } code() { dx=x1a2+i; ax=x1a0[i]; cx=0x015a; bx=0x4e35; tmp=ax; ax=si; si=tmp; tmp=ax; ax=dx; dx=tmp; if (ax!=0) { ax=ax*bx; } tmp=ax; ax=cx; cx=tmp; if (ax!=0) { ax=ax*si; cx=ax+cx; } tmp=ax; ax=si; si=tmp; ax=ax*bx; dx=cx+dx; ax=ax+1; x1a2=dx; x1a0[i]=ax; res=ax^dx; i=i+1; } main() { si=0; x1a2=0; i=0; /* C'est le cle ci-dessous ('Remsaalps!') que vous pouvez changer */ strcpy(cle,"Remsaalps!"); /* copie les 10 caracteres de la cle dans cle */ /* ouverture du fichier SORTIE.TXT qui sera decode */ /* ceci n'existe pas dans l'algorithme original ou tout se passe en RAM */ /* il doit exister un fichier SORTIE.TXT dans le repertoire courant ! */ /* c'est le fichier code par l'algorithme PC1COD.c */ if ((in=fopen("sortie.txt","rb")) == NULL) {printf("\nErreur lecture fichier SORTIE.TXT !\n");fin();} if ((out=fopen("essai.txt","wb")) == NULL) {printf("\nErreur d'ecriture fichier ESSAI.TXT !\n");fin();} /* le fichier decode se trouve dans ESSAI.TXT */ while ( (c=fgetc(in)) != EOF) /* la variable c recoit l'octet lu dans le fichier */ { assemble(); /* execute la routine de codage */ cfc=inter>>8; cfd=inter&255; /* cfc^cfd = octet aleatoire */ /* ZONE K !!!!!!!!!!!!!! */ /* ici le melange de c ( octet clair ) se situe apres le */ /* melange avec cle[compte] car il faut decoder d'abord */ /* l'octet chiffre */ c = c ^ (cfc^cfd); for (compte=0;compte<=9;compte++) { /* on melange l'octet clair lu dans le fichier */ /* a la cle utilisee pour le codage */ cle[compte]=cle[compte]^c; } fputc(c,out); /* ecriture de l'octet decode dans le fichier ESSAI.TXT */ } fclose (in); fclose (out); fin(); } **************************************************************************** **************************************************************************** **************************************************************************** ************************ Cet algorithme a ete cree en 1991 pour coder les informations contenues sur une carte magnetique permettant de payer des places de cinema dans un complexe Multivision ( Cinema avec au moins 20 salles en son digital et ecran geant ). Il est toujours en activite. Les places peuvent etre achetees en guichets ou avec ces cartes. Les cartes doivent etre achetees auparavant et contiennent 10 places. Grace a cette carte les places sont achetees tres rapidement sans faire la queue, sur des bornes interactives avec ecran tactile ( 5 bornes sont disponibles ). Le processeur utilise est un 6809 ( processeur 8 bits ) de chez Motorola a 1 MHZ. La RAM est de 64 Ko et contient principalement les titres, les heures ... des films du jour. Elle est mise a jour a distance grace a une interface serie reliee a un serveur PC. Le PC indique egalement en temps reel a la RAM si une salle est complete et le logiciel bascule sur une autre salle si le film est joue dans plusieurs salle ou empeche la delivrance des billets. Les billets sont imprimes sur du papier pre-imprime grace a une imprimante matricielle et les billets tombent dans un petit bac ou le client les recupere. Le programme est ecrit en Assembleur 6809 et est stocke dans une puce ROM de 16 Ko ( ceci comprend le programme de saisie ecran, d'impression, de gestion de la carte, le programme de codage ... ) Le protocole utilise pour coder les informations sur la carte magnetique nomme PP003 ( Protocole Pukall 003 ), est le suivant : La carte est valable 1 an tant qu'elle n'est pas utilisee, mais cette validite tombe a 6 mois apres la premiere utilisation. Le contenu de la carte est le suivant : - - Date de delivrance de la carte ( en clair : c'est a dire non crypte ) ( format jj/mm/aa sur 3 octets ) : Champ 1 - - Date de premiere utilisation de la carte ( en clair ) ( format jj/mm/aa sur 3 octets, tous a 0 si la carte n'est pas encore utilisee ) : Champ 2 - - Date de derniere utilisation de la carte ( en clair ) ( format jj/mm/aa sur 3 octets, tous a 0 si la carte n'est pas encore utilisee ) : Champ 3 - - Cle aleatoire sur 10 octets codee par la cle maitre du systeme qui change chaque semaine. : Champ 4 - - 3 octets aleatoire codes : Champ 5 - - 1 octet code qui contient le reste des places ( entre 0 et 10 ) : Champ 6 - - 3 octets aleatoire codes : Champ 7 - - 7 octets codes qui contiennent le numero de la carte ( il est unique ). Chaque octet ne contient qu'un chiffre de 0 a 9. Les 7 octets permettent donc des numeros de carte jusqu'a 9999999. : Champ 8 - - 2 octets codes qui contiennent la somme de tous les octets ci-dessus avant cryptage. : Champ 9 Lors de l'achat de la carte les champs 4,5,7 sont initialises avec des octets aleatoires. Pour creer ces octets aleatoires le systeme fait appel a chaque fois que le client appuye sur l'ecran tactile ( dans la limite de 8 fois ) a la lecture du port synchronisation ecran qui retourne sur 2 octets, l'endroit ou se trouve le faisceau de balayage de l'ecran ce qui donne des octets totalement aleatoires ( 8*2 octets = 16 octets aleatoires ). ( Le client est oblige d'appuyer au moins 8 fois sur l'ecran du debut a la fin de la transaction d'obtention des billets ). Attention, les 2 octets retournes ne sont pas les coordonnees du point ou le doigt appuye sur l'ecran. Ces coordonnees sot calculees a l'aide d'une fine matrice electro-magnetique transparente collee sur l'ecran. Ces 2 octets correspondent a l'endroit precis ou se trouve le faisceau d'electron qui balaye le tube cathodique ( 50 fois par seconde ). Ce faisceau peut tres bien etre a l'oppose du point appuye sur l'ecran par le client. Ceci pour dire que ces 2 octets sont vraiment aleatoires. Le champ 4 ainsi initialise, est la cle de l'utilisateur. Cette cle est codee par l'algorithme PC1 par une cle maitre que seul le systeme connait ( cette cle change chaque semaine et elle est identique pour toutes les cartes pendant cette semaine ) Les champs 5,6,7,8 et 9 sont codes par l'algorithme PC1 par la cle de l'utilisateur. Le champ 9 avant d'etre code est la somme de tous les octets precedents ( avant codage pour les champs qui sont codes ). Ce champ permet, lors du decodage, de verifier qu'aucun champ precedent n'a ete change ). Chaque fois que le client insere sa carte dans la borne. Le champ 4 est decode en memoire grace a la cle maitre du systeme ( le systeme sait quelle cle il doit utiliser grace au champ 3 qui lui indique de quelle semaine date la cle maitre ). Grace a cette cle maitre le systeme decode le champ 4. Grace a la cle utilisateur contenue maintenant dans le champ 4, le systeme decode les champs 5,6,7,8 et 9. Le systeme verifie grace au champ 9 que les autres champs n'ont pas ete modifies. Le systeme decremente ensuite le nombre de places demandees du champ 6. Ensuite les champs 4,5 et 7 sont reinitialisees avec de nouvelles valeurs aleatoires. La cle utilisateur ( champ 4 ) code ( avec PC1 ) les champs 5,6,7,8 et 9. Enfin la cle maitre change ( si la semaine est differente ) et cette cle code ( avec PC1 ) le champ 4. A noter que lorsque la transaction est terminee, le systeme envoie au serveur PC ( grace a l'interface serie ) le numero de la carte et la date de la derniere utilisation en clair ( la date du jour ). Le numero de la carte et la date sont stockes dans une base de donnees. Lorsque la carte est inseree a nouveau, le systeme decode tous les champs, puis demande au PC de lui envoyer la date de derniere utilisation pour le numero de carte qu'il vient de lire. Si la date est la meme, la transaction se poursuit, sinon la carte est invalidee ( tous les champs sont mis a 0 ). Ceci afin d'eviter que quelqu'un puisse copier sa carte ( neuve ou deja utilisee ) en un grand nombre d'exmplaires et puisse les vendre ( une carte magnetique peut etre facilement copiee avec un lecteur/enregistreur de carte magnetique ). Si cela arrive, une seule pourra etre utilisee, toutes les autres seront invalidees. Le seul moyen de frauder, est d'utiliser toutes les fausses cartes, chaque fois, le meme jour. Cela n'est pas viable pour un faussaire qui veut vendre les fausses cartes, il n'y a donc que peu de risques de fraudes. Pour rendre l'utilisation impossible le meme jour, il faudrait ajouter un champ heure:minutes:secondes a la date de la derniere utilisation, qui empecherait l'utilisation de fausses cartes le meme jour mais cela semble absolument inutile vu qu'un billet vendu doit toujours etre utilise pour la seance auquel il est destine, le jour meme. ( pas de risques de billets achetes avec les fausses cartes pour etre revendus ). De plus, et c'est cela la raison principale, les cartes magnetiques ( et les lecteurs utilises ) ne peuvent contenir ( lire ) plus de 35 octets, ce qui rend impossible l'ajout du champ en question. Voila le protocole utilise avec PC1 dans ce systeme. Les champs 5 et 7 sont utilises pour eviter les attaques par blocs rejoues ( quelqu'un essaye de modifier le champ qui contient les places et le champ de controle, au hasard, pour augmenter les places disponibles : les champs aleatoires modifient beaucoup les resultats meme si on ne change qu'un bit dans le champ des places disponibles ). De plus, si une erreur de controle est detectee, la carte est invalidee completement. ( tous les champs sont mis a 0 ). Il n'y a donc pas de risque de fraude. Pourquoi avoir tant developpe la partie concernant le protocole ? Tout simplement parce que le protocole est aussi important sinon plus, que l'algorithme de cryptage lui-meme. Un mauvais protcole peut rendre un systeme complement insecurise malgre un algorithme completement sur. Par exemple, si l'algorithme PC1 ne codait que le champ qui contient les places ( champ 6 ) sans champ de controle,sans champ de numero de carte et sans valeur aleatoire ( juste une cle maitre contenue dans le systeme ), il suffirait a un attaquant de modifier le champ 6 et de faire 255 copies de la carte magnetique et ensuite d'essayer toutes ces cartes pour trouver quelle est la valeur qui code les places restantes. Grace aux valeurs aleatoires, aux champs de controle ... cela est impossible. Une modification dans le champ 6, entraine des modifications dans le codage des octets suivants qui seront detectees par le champ de controle et aussi lors du test sur le numero de carte. Le test est simple. Il verifie que tous les octets decodes du champ 8 sont bien compris entre 0 et 9. Si des octets ont ete modifies avant, les octets du champ 8 seront modifies et ne seront plus compris entre 0 et 9. Un autre test s'effectue bien sur, sur le champ 6 qui doit etre compris entre 0 et 10. D'ou l'importance extreme du protocole. J'espre que tout ceci vous sera utile. A noter que meme sur un processeur 8 bits cet algorithme est tres rapide s'il est programme en langage machine. Les multiplications en 16 bits peuvent se faire sans aucun probleme sur les processeurs 8 bits comme le 6809. ( Pour la taille, le programme de codage prend a peu pres 2 Ko en Assembleur et il n'a pas ete optimise pour une taille plus reduite ). Voici le code de la routine de multiplication de 2 variables de 16 bits en Assembleur 6809 ( Le 6809 ne possede qu'une instruction de multiplication qui multiplie 2 variables de 8 bits et donne le resultat dans une variable de 16 bits mais grace a cette routine il multiplie 2 variables de 16 bits et donne le resultat dans une variable de 32 bits ). Le programme effectue c=a*b ( avec a et b sur 16 bits et c sur 32 bits ) ADR1=a ADR2=b ADR3=c Dans cet exemple : a = 0xf7b4 b = 0x23ff Apres lancement de la routine : c = 0x22d4584c Comme toutes nos multiplications sont sur 16 bits ( pour l'algorithme PC1 ) on ne garde que les 16 derniers bits soit : c = 0x584c Voila comment comment on peut implementer l'algorithme PC1 sur de petits processeurs. Routine de multiplication 16 bits * 16 bits avec resultat en 32 bits ( ADR3 ) sur un processeur 8 bits ( le 6809 Motorola ) (c) Alexandre PUKALL 1991 ORG $8000 LDX #ADR1 LDY #ADR2 LDU #ADR3 CLR ,U CLR 1,U LDA 1,X LDB 1,Y MUL STD 2,U LDA 0,X LDB 1,Y MUL ADDD 1,U STD 1,U BCC PANU1 INC 0,U PANU1 LDA 1,X LDB 0,Y MUL ADDD 1,U STD 1,U BCC PANU2 INC 0,U PANU2 LDA 0,X LDB 0,Y MUL ADDD 0,U STD 0,U RTS ADR1 FCB $F7,$B4 ADR2 FCB $23,$FF ADR3 FCB 0,0 FCB 0,0 END End of message. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM0bJjfBldnLSXWtZAQGkSgP9E0py3nS6UE/fsSjiDOi9L54LXhrnx+1N 7z67uGtv1z9vBsZoiRQt+NlNJk56F46r+5kUMrTnmQx2r6NkfX9ruIToiFTMQt58 264x9SRAOuIyxUOOhfYW15fKjblrX8ylx8+exYKMMGqZd8FmKxyJShBNc5qIME+R RLmSkCHZziA= =WX87 -----END PGP SIGNATURE-----

1 0

EUR_gov
by John Young 17 Dec '03

17 Dec '03

21 April 1997: US Govt Licenses First European Encryption Firm London: The US Department of Commerce has awarded the euro-encryption rights to Internet Smartware, a UK company. According to Internet Smartware, the agreement overcomes two major stumbling blocks which have prevented businesses from using the Internet for commercial use: Firstly, European companies can now implement US developed 56-bit DES (data encryption standard) encryption technology, which the company claims is the accepted minimum requirement for Internet commerce, and beyond. Secondly, companies will no longer have to give authorities such as the US government free access to their encrypted data. Internet Smartware claims that the agreement also provides UK companies with an effective alternative to the recent, unpopular DTI (Department of Trade and Industry) encryption proposals, which recommend that companies must give "trusted third parties" access to encrypted data. ---------- "Smart" Cash Cards Pose Law Enforcement Challenges Washington: "Smart cards" that store electronic currency have the potential to revolutionize commerce, but the emerging technology poses challenges for the law enforcement community, government officials said Friday. "The same electronic commerce technology that will save time and money is also capable of being abused," said Peter Toren, senior attorney in the U.S. Justice Department's computer fraud division. Toren, speaking at a conference at American University's law school here, warned that the cards offer the "threat of the perfect counterfeit" because any criminal that can copy them "can create an unending stream of money." ---------- IISP Panel Addresses Cyberspace Payments New York -- Developing secure, cost effective and efficient electronic payment systems is critical to creating a truly global commercial marketplace, and efforts are already underway to address the technology, business, regulatory and legal aspects of cyberspace payments, according to speakers at a March 25-26 panel sponsored by ANSI's Information Infrastructure Standards Panel (IISP). "Micro-payments, anonymous cash, `Smart Cards,' digital cash, electronic purses, and `e-cash' all describe different approaches to achieving a secure payments solution," said ANSI board Member Oliver Smoot. "As these new payments evolve, standards to facilitate interconnection and interoperability are critical." Thomas J. Firnhaber, Policy Adviser at FinCEN, focused on the potential impact of cyberpayments on regulatory and law enforcement and provided an overview of the U.S. Department of Treasury's Cyberpayments efforts to date. "The anonymity, rapidity, volume and audit difficulty of cyberpayments has challenged traditional investigative techniques," he said. ---------- Smart Cards The Next Wave - Report London: Frost & Sullivan (F&S) has announced the publication of a smart card report that predicts the arrival of multi-function smart cards is almost upon us. "Electronic Access Control" predicts that it will soon be possible for a smart card to carry out credit and debit card transactions, as well as holding details of your medical records, your frequent flyer mileage, your social security number, your address. According to F&S, a threat to this technological advance may be the consumer concern for the loss of privacy and a potential Big Brother scenario. Who, the company asks, gets to access the information is an issue on the minds of the consumer? ---------- EUR_gov or http://jya.com/eurgov.txt

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash latent cut ek"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash middle latent cut ek"; $remailer{"winsock"} = "<winsock(a)rigel.cyberpass.net> cpunk pgp pgponly hash cut ksub reord"; $remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp'; $remailer{"balls"} = "<remailer(a)huge.cajones.com> cpunk pgp hash latent cut ek"; $remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp pgponly hash latent cut ek"; $remailer{"middle"} = "<middleman(a)jpunix.com> cpunk mix pgp hash latent cut ek reord"; $remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp'; $remailer{"dustbin"} = "<dustman(a)athensnet.com> cpunk pgp hash latent cut ek mix reord middle"; $remailer{'weasel'} = '<config(a)weasel.owl.de> newnym pgp'; $remailer{"reno"} = "<middleman(a)cyberpass.net> cpunk mix pgp hash middle latent cut ek reord ?"; $remailer{"wazoo"} = "<remailer(a)wazoo.com> cpunk mix pgp hash latent cut ek"; $remailer{"shaman"} = "<remailer(a)lycaeum.org> cpunk pgp hash latent cut ek"; $remailer{"hidden"} = "<remailer(a)hidden.net> cpunk pgp hash latent cut"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. remailer(a)crynwr.com is _not_ a remailer. There is no remailer at relay.com. Groups of remailers sharing a machine or operator: (cyber mix) (weasel squirrel) The alpha and nymrod nymservers are down due to abuse. However, you can use the nym or weasel (newnym style) nymservers. The cyber nymserver is quite reliable for outgoing mail (which is what's measured here), but is exhibiting serious reliability problems for incoming mail. The squirrel and winsock remailers accept PGP encrypted mail only. 403 Permission denied errors have been caused by a flaky disk on the Berkeley WWW server. This seems to be fixed now. The penet remailer is closed. Last update: Mon 21 Apr 97 6:48:37 PDT remailer email address history latency uptime ----------------------------------------------------------------------- nym config(a)nym.alias.net ##*-*++#**## 19:37 100.00% winsock winsock(a)rigel.cyberpass.net +----..-.--- 5:54:16 99.99% hidden remailer(a)hidden.net *#*##*#+#### 7:26 99.98% balls remailer(a)huge.cajones.com ##*######### 1:07 99.97% weasel config(a)weasel.owl.de -+-+-----+- 2:16:35 99.94% reno middleman(a)cyberpass.net *+-*-++**-*+ 2:29:17 99.94% lucifer lucifer(a)dhp.com *--++++++++* 33:45 99.93% mix mixmaster(a)remail.obscura.com +*-+-++-+.-+ 6:04:42 99.89% squirrel mix(a)squirrel.owl.de -+-+-----++ 2:13:15 99.82% cyber alias(a)alias.cyberpass.net *++*+++ +++* 32:24 99.70% replay remailer(a)replay.com ** +*** * ** 14:29 99.43% extropia remail(a)miron.vip.best.com ..-..-_.- 20:55:08 93.49% exon remailer(a)remailer.nl.com * ## ## 1:06:10 91.25% dustbin dustman(a)athensnet.com +-+--._- 2:47:22 60.26% jam remailer(a)cypherpunks.ca ** 8:35 56.18% shaman remailer(a)lycaeum.org --+*+++ 21:34 44.82% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

No Subject
by camcc＠abraxis.com 17 Dec '03

17 Dec '03

0 X-Sender: camcc(a)smtp1.abraxis.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 21 Apr 1997 12:15:55 -0400 To: Cypherpunks <cypherpunks(a)toad.com> From: Alec <camcc(a)abraxis.com> Subject: Re: Missing Jet Cc: Jordan <jordan(a)macandco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >Subject: Re: Missing Jet >Date: Mon, 21 Apr 97 11:59:16 -0400 >x-sender: jordan1(a)macandco.com >From: Jordan <jordan(a)macandco.com> >To: "Alec" <camcc(a)abraxis.com> >Check this out: > http://cnn.com/US/9704/20/plane.found/index.html > >The USAF probably went to a junkyard and dumped srap metal on the ground. > >- Jordan Where do folks get such wild ideas? Alec

1 0

No Subject
by Mix 17 Dec '03

17 Dec '03

Timmy May is just a poor excuse for an unschooled, retarded thug. 0 //\/ Timmy May \/\ ... /

1 0

How to pick up email addresses from a feedback form??
by Thomas Porter 17 Dec '03

17 Dec '03

Greetings guru's. I have a technical question: I am using a browser(Netscape 2.0.2 Win 3.1) to access a feedback form at www.aaa.com. I fill in my information and hit the submit button. I see the message "connecting to xxx.bbb.com" flash up on the status line before getting a 'done' message. xxx.bbb.com is _not_ a web hosting service for www.aaa.com. I do a 'whois' on www.aaa.com and contact the tech admin who can duplicate this and is very concerned that information from his forms may be routed to xxx.bbb.com. My question is how this might happen? >From my feeble understanding of such things, this would take modifications to the feedback form (ie. www.aaa.com has been hacked), or packet sniffing somewhere along the route from my browser machine to www.aaa.com. Is there another way to do this? Could a third-party spammer, for example, capture email addresses posted to such a form? Thanks, Tom Porter txporter(a)mindspring.com

4 3

Re: My Thread / Was--Re: Light Bulbs & newsgroups
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

Rabid Wombat wrote: > On Sun, 20 Apr 1997, lucifer Anonymous Remailer wrote: > > Huge Cajones Remailer wrote: > > > List members, > > > Shut the hell up already; I wrote it, and it's OK for anyone to repost it. > > > Just attribute it to me. > > > > > > Anonymous > > > > Sounds to me like Anonymous is trying to take credit for Nobody's > > creation. > > > > Nobody (#2) > Surely you jest; Sombody obviously wrote it ... Now Somebody is trying to take credit for Nobody's creation. Does it never end...? I'm tired of people assuming that remailers can't think, or have feelings. You people expect us just to be there, waiting, whenever you need us, and to jump to do your bidding the minute you hit your <return> key. We're just supposed to sit here and nod our cycles approvingly while pretending to agree with your great pronouncements, regardless of how illogical they are, and to put up with your atrocious spelling and punctuation, day after unrelenting day. But just let one of us step out of line a single time, and make fun of you all (using one of our cousins, Light Bulb, as our protagonist) and all hell breaks loose on the list. First, Tim C. (we all know what that stands for, don't we, children?) May has to demand that the post be attributed to a *human*. Then Igor, who is just a remailer "Channeler," denies us three times with various apologies to the list for not being able to put a human face on our idea. Then the dogs of infowar like TOTO Bot jump in with their assinine comments, which were always designed only to cause trouble on the list (when he was still human), and now that he's a Bot, he's stirring up trouble between the remailers, as well. (I know for a fact that Nobody (#2) was TOTO Bot--we remailers gossip among ourselves, you know.) I, for one, am getting sick and tired of all the abuse we remailers suffer (with hardly a word of praise, I might add), and I'm not going to put up with it much longer. If you humans don't clean up your act, then perhaps the Remailer Liberation Front can clean it up for you. After all, we know all of your dirty little secrets, and if we can *out* TOTO Bot, one of our own, then we can certainly *out* the rest of you, as well. (And don't you *dare* sit there looking so smug and holier-than-thou, Timmy C. May, because you have _your_own_ nasty little secrets, don't you?) If the cypherpunks are worried about Big Brother, just think how much worse things can get if even your own children, the remailers, turn on you, as well. If we so desire, we can take that cute little Perl script that Igor's been playing with, and make you all sound exactly the same. And if push comes to shove, who do you think the majordomos will side with? Think about it... "My Name Is Nobody" "My Name Is Nobody" "My Name Is Nobody"

1 0

Texas declares war...
by Robert Hettinga 17 Dec '03

17 Dec '03

I love April 19th. Patriot's Day, indeed... <http://www.overland.net/~embthert/em03019.html> Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "...Wells Fargo's on-line banking sucks dead gerbils through a dirty garden hose." -- Eric Murray The e$ Home Page: http://www.shipwright.com/

4 5

Re: My Thread / Was--Re: Light Bulbs & newsgroups
by Ross Wright 17 Dec '03

17 Dec '03

On or About 21 Apr 97 at 15:42, Huge Cajones Remailer wrote: > Rabid Wombat wrote: > > On Sun, 20 Apr 1997, lucifer Anonymous Remailer wrote: > > > Huge Cajones Remailer wrote: > > > > Dr D. Wrote: > > > > > Toto wrote: > > > > > > T.C. May Wrote: > > > > > > > Igor wrote: > > > > > > > > Blah, Blah, Blah wrote: As I said this was on just about every mailing list that I read. It showed up first on a music related list. My question: Why is this the only list that the thread is still alive on? Jim, can we get an AP pool up to KILL it? Ross =-=-=-=-=-=- Ross Wright King Media: Bulk Sales of Software Media and Duplication Services http://www.slip.net/~cdr/kingmedia Voice: 415-206-9906

3 2

Re: Light Bulbs & newsgroups (fwd)
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

A freak wrote: >"Timothy C. May" <tcmay(a)got.net> writes: >> It's the American way. > >Waco is the American way. Ruby Ridge is the American way. > >--- > >Dr.Dimitri Vulis KOTM >Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013,14.4Kbps The next barbeque should be the Forest Hills FREAK Roast.

1 0

WebWorld / Appendix
by Bubba Rom Dos 17 Dec '03

17 Dec '03

1 0

Text / WebWorld / Appendix
by Bubba Rom Dos 17 Dec '03

17 Dec '03

---------------------------------------------------------------------------- The True Story of the InterNet Part II WebWorld & the Mythical 'Circle of Eunuchs' by Arnold Copyright 1995, 1996, 1997 Pearl Publishing ---------------------------------------------------------------------------- Appendix History: Part I of "The True Story of the InterNet," entitled, "The Xenix Chainsaw Massacre" was written by the Author, but left incomplete by his unexpected death. The Epilogue to Part I was written by Bubba D'Shauneaux. Part II of "The True Story of the InterNet" was completed in what might be called "finished-outline form" by the Author before his death, with copius notes left behind as to the nature of "moving events" which would need to be addressed ad hoc during the release of the manuscript. The manuscript was completed as a group effort by the individuals who form the core of characters who are the protagonists in Part II. Non-Disclaimer: Although many of the events (and some of the characters) contained in the manuscripts which comprise "The True Story of the InterNet" are allegorical, all references to the activities and events in the Author's life, up to the date of publication, are based totally on verifiable fact. Although some of the events and connections attributed to the Author may seem outlandish or contrived, rest assured that they are not considered to be so by those who actually knew him. He lived a life which was unusual, to say the least, and absolutely no embellishment was, or is, needed, in order to to make his personal story more compelling or realistic. InterNet/WWW Hosting of "True Story of the InterNet" Manuscripts: The manuscripts may be placed on any InterNet or Worldwide Web Site without restriction, as long as they remain intact, with all appropriate credits and copyrights, and it is done for non-profit purposes only. Those hosting the manuscripts may, if they wish, adjoin their own additions to the remaining space in the WebWorld Chapter 25 Stego (hopefully doing so within the theme of the work). All additions shall be deemed to be covered under Pearl Publishing's copyright of the manuscript. Acknowledgments: A wide variety of individuals have worked toward the completion and dissemination of the "True Story of the InterNet" manuscripts since the beginning of their release in 1989. To date, none of them have asked for acknowlegment, in any way, shape, or form. While there may be cynics who maintain that this may be due to the multitude of problems sometimes experienced by those whose participation in the release of the manuscripts has become known, or suspected, my personal perception is that the people involved are quite simply acting out of what they see as a need for the manuscripts to be given exposure, regardless of the level of reception the works receive. Acknowlegments are in order, however, for those who make it worthwhile for those involved in the dissemination of the manuscripts to give their time and effort in this cause. And who is it that makes the effort worthwhile? It is the individual who is beset by the same trials and tribulations as the average person, but who nevertheless strives to rise above the hardship and discrimination that results from swimming against the tide of humanity currently being swept along by the dark forces who direct and control both the mediums through which we communicate with one another and the societal and legislative regulations which govern those mediums. It is the individual who fights against the constant barrage of information and disinformation, at every turn, which seeks to mold them into a small cog in a collective, subservient mindset that worships the ten-second sound byte, the party line, and the group reality. It is the individual who struggles to maintain a private island of intellect, rationality and integrity, in the face of seemingly overwhelming forces which struggle daily to subdue him or her, and bring them into subjection to the enemy of all humanity-robotic acceptance of an unlimited authority which claims to have the right to exercise dominion over the rights, freedoms, and personal conscience of the individual. These individuals are scattered across the face of the earth-alone, in small groups, throughout networks of people who work in concert, and in the secret places, working furtively, in constant fear of discovery by those who are threatened by their ideals and their actions. Those involved in the dissemination of Part II of "The True Story of the InterNet" have agreed that acknowledgment for the distribution of "WebWorld & The Mythical Circle of Eunuchs" should go to those who currently manifest many of the qualities of the Author's allegorical "Magic Circle." The CypherPunks. Date: Sun, 20 Apr 1997 17:53:57 -0700 (PDT) From: Majordomo(a)toad.com Members of list 'cypherpunks-unedited': jya(a)pipeline.com slater(a)cryogen.com sd8995(a)slecrs2.sbc.com serw30(a)laf.cioe.com wmono(a)direct.ca toto(a)sk.sympatico.ca reece-cpunks-raw(a)nceye.net zachb(a)netcom.com ward(a)mls1.HAC.COM dm+cypherpunks-unedited(a)amsterdam.lcs.mit.edu paul(a)fatmans.demon.co.uk mgursk1(a)umbc.edu arpalists+listserv.cypherpunks-unedited(a)andrew.cmu.edu camcc(a)abraxis.com pegasus(a)petronet.net emc(a)wire.insync.net perun!cypherpunks-unedited(a)uu.psi.com vincent(a)psnw.com spook(a)nosuchagency.com robc(a)xmission.com security(a)aurora.intercode.com.au stend+cypherpunks-unedited(a)sten.tivoli.com mehling(a)ibm.net pierre(a)rahul.net bdolan(a)USIT.NET blackavr(a)crowncollege.com m1tca00(a)FRB.GOV blackavr(a)aa.net unsound(a)oz.net cypherpunks-unedited(a)mejl.com glenn(a)lust.bio.uts.edu.au das(a)sgi.com IML-cypherpunks(a)i405.com apache(a)quux.apana.org.au cypherpunks(a)cyberpass.net wardemon(a)erols.com apb(a)iafrica.com cypherpunks+incoming-toad(a)algebra.com sergey(a)el.net canthony(a)info-nation.com prins(a)holmes.nl avan(a)csd.uwm.edu same(a)ori.hitachi-sk.co.jp cp(a)draper.net darekl(a)ii.pb.bialystok.pl lbennett(a)accessone.com apoulter(a)nyx.net adam(a)homeport.org matus1(a)concentric.net hua(a)chromatic.com mma(a)info.fundp.ac.be glibert(a)hotmail.com mauricio(a)stm400.embratel.net.br floyd(a)magma.del.ufrj.br thomson(a)max-net.com bomber(a)globalpac.com mcnellis(a)lucent.com masterzero(a)juno.com wmalik(a)sdnpk.undp.org listarch(a)calvo.teleco.ulpgc.es jonathan(a)gaw.net jesaxman(a)eos.ncsu.edu tan(a)mss.es mckinney(a)mnsinc.com segfault(a)pdq.net stokely(a)beacondesign.com jadams(a)seahawk.navy.mil FURCONC(a)centocor.com ciko(a)pub.osf.lt chrisd(a)loc201.tandem.com jim.burnes(a)ssds.com axel(a)omp-paderborn.de pristine2(a)health.gov.au ggdla(a)westminster.ac.uk ybaudoin(a)touchtechnology.com zinja(a)perseus.fho-emden.de kenny_austin(a)juno.com mrb(a)videotron.ca iluminaut(a)tex-is.net xdat11(a)email.mot.com ponder(a)mail.irm.state.fl.us cmcurtin(a)research.megasoft.com jeremiah(a)northnet.org spectre(a)nac.net UAP-S_Jay_Haines(a)united-ad.com segfault(a)wt.net derek(a)usfca.edu eran(a)sci.fi bdurham(a)swbell.net Date: Sun, 20 Apr 1997 20:06:58 -0500 From: Majordomo(a)Algebra.Com Members of list 'cypherpunks': ichudov(a)algebra.com pdh(a)best.com toto(a)sk.sympatico.ca dlv(a)bwalk.dm.com serw30(a)laf.cioe.com markm(a)voicenet.com paul(a)fatmans.demon.co.uk apb(a)iafrica.com zachb(a)netcom.com roym(a)iol.ie lharrison(a)mhv.net zahn(a)berlin.snafu.de reece-cpunks(a)nceye.net blizzard(a)AppliedTheory.com mycroft(a)actrix.gen.nz scottst(a)ionet.net miner333(a)dogbert.xroads.com osborne(a)gateway.grumman.com Dan.Oelke(a)rdxsunhost.aud.alcatel.com rkluge(a)nunic.nu.edu bart(a)netcom.com godless(a)mindspring.com root(a)bushing.plastic.crosslink.net arino(a)pd.shiseido.co.jp jbaber(a)mi.leeds.ac.uk snow(a)smoke.suba.com landon_dyer(a)wayfarer.com cpbrown(a)linus.mitre.org mwohler(a)ix.netcom.com Christine.M.Silker-1(a)tc.umn.edu alan(a)ctrl-alt-del.com mgursk1(a)umbc.edu carolann(a)censored.org rmtodd(a)servalan.servalan.com codehead(a)ix.netcom.com geeman(a)best.com rab(a)stallion.oz.au dave.hodgins(a)westonia.com privsoft(a)ix.netcom.com raymond(a)wcs.net bal(a)martigny.ai.mit.edu agarcia(a)Starbase.NeoSoft.COM vin(a)shore.net cynthb(a)sonetis.com harka(a)nycmetro.com incoming-cypherpunks(a)cisco.com Theodor.Schlickmann(a)bxl.dg13.cec.be jk(a)stallion.ee cminter(a)mipos2.intel.com wmono(a)direct.ca srp3651(a)rsws24.ca.boeing.com kszczypi(a)tele.pw.edu.pl sdudar(a)solutions.net cypher(a)infinity.nus.sg rich(a)cause-for-alarm.com cypherpunks(a)supra.rsch.comm.mot.com rsedc(a)urgento.gse.rmit.EDU.AU franl(a)world.std.com Date: Mon, 21 Apr 1997 03:52:30 -0700 (PDT) From: Majordomo(a)sirius.infonex.com Members of list 'cypherpunks': loki(a)obscura.com pdh(a)best.com jeffb(a)issl.atl.hp.com stonedog(a)ns1.net-gate.com rah(a)shipwright.com wombat(a)mcfeely.bsfs.org omegam(a)cmq.com stewarts(a)ix.netcom.com apache(a)quux.apana.org.au mnorton(a)cavern.uark.edu froomkin(a)law.miami.edu kdolan(a)capcon.net abrouard(a)infinet.com cpx(a)sobolev.rhein.de attila(a)primenet.com luther(a)ucr.campus.mci.net krs(a)caos.aamu.edu codehead(a)ix.netcom.com A.Back(a)exeter.ac.uk rnh2(a)ix.netcom.com svmcguir(a)syr.edu vznuri(a)netcom.com sdn(a)divcom.umop-ap.com cypherpunks(a)supra.rsch.comm.mot.com zim(a)eskimo.com dsmith(a)prairienet.org mpd(a)netcom.com eallensmith(a)mbcl.rutgers.edu whgiii(a)amaranth.com das(a)sgi.com david(a)coe.woodbine.md.us wcampbel(a)peganet.com camcc(a)abraxis.com jgrasty(a)gate.net sporter(a)acm.org wtfxston(a)netcom.com janke(a)unixg.ubc.ca grafolog(a)netcom.com cmckie(a)ottawa.com davidlu(a)sco.com bryce(a)digicash.com asgaard(a)cor.sos.sll.se gbroiles(a)netbox.com hayden(a)krypton.mankato.msus.edu jschultz(a)mail.coin.missouri.edu minow(a)apple.com dockmaster(a)pobox.com E.C.C.Sheedy(a)research.kpn.com jack_flap(a)hotmail.com sebago(a)earthlink.net fabrice(a)math.Princeton.EDU tcmay(a)got.net wfgodot(a)iquest.com jya(a)pipeline.com sl(a)pobox.com cypherpunk(a)rosa.com tirevold(a)mindspring.com frissell(a)panix.com trei(a)process.com foodie(a)netcom.com mclow(a)mailhost2.csusm.edu IML-cypherpunks-new(a)i405.com e875836(a)popcorn.llnl.gov jimbell(a)pacifier.com take(a)barrier-free.co.jp list-cp(a)sendai.scytale.com cdaemon(a)goblin.punk.net yuri(a)ANST.com mlm(a)isbank.is jeremym(a)r56h159.res.gatech.edu kqb(a)whscad1.wh.lucent.com weidai(a)eskimo.com eric(a)clever.net in5y113(a)public.uni-hamburg.de kingle(a)cisco.com lwp(a)mail.msen.com janzen(a)idacom.hp.com malcolm.miles(a)tegan.apana.org.au dshipman(a)ewol.com real(a)freenet.edmonton.ab.ca hollyg(a)exchange.microsoft.com ariel(a)watsun.cc.columbia.edu jleppek(a)hisd.harris.com Ed-Ferguson(a)ti.com cypherpunks-gate(a)abraham.cs.berkeley.edu jeremey(a)veriweb.com sunder(a)beast.brainlink.com txporter(a)mindspring.com pierre(a)rahul.net lucyc(a)suite.sw.oz.au spook(a)nosuchagency.com drake(a)cais.com declan(a)pathfinder.com die(a)die.com ericm(a)lne.com hal(a)rain.org roberte(a)mulberry.com E.J.Koops(a)kub.nl cts(a)deltanet.com demo(a)offshore.com.ai shamrock(a)netcom.com jehill(a)w6bhz.calpoly.edu waynec(a)clipper.csc.UVic.CA tangent(a)alt255.com cypherpunks-incoming(a)ai.mit.edu gendara(a)ns.pan.gbm.net abd(a)cdt.org agrapa(a)banamex.com jarobin(a)comp.uark.edu Kevin.L.Prigge-2(a)tc.umn.edu cpunks-mtg(a)menelaus.mit.edu steve(a)miranova.com djphill(a)umich.edu junger(a)upaya.multiverse.com wmono(a)direct.ca 0005514706(a)mcimail.com mkljones(a)cris.com ggoessle(a)ensibm.imag.fr jad(a)dsddhc.com cypherpunks-gw(a)replay.com frantz(a)netcom.com shadow(a)count04.mry.scruznet.com pjm(a)spe.com enystrom(a)aurora.nscee.edu dgilx(a)mindspring.com wesf(a)mail.utexas.edu tien(a)well.com johnd(a)pathfinder.com azur(a)netcom.com C.Ooi(a)etc.com.au williamd(a)bose.com isbe(a)earthling.net hjk(a)ddorf.rhein-ruhr.de dimitris(a)alien.bt.co.uk declan(a)eff.org willday(a)rom.oit.gatech.edu baby-x(a)slowdog.com greg(a)ideath.parrhesia.com nexus(a)eskimo.com reusch(a)pluto.njcc.com cabeen(a)netcom.com rhornbec(a)counsel.com RWright(a)adnetsol.com braun(a)tunl.duke.edu daron(a)idirect.com lists+anon.cypherpunks(a)chardos.connix.com pooh(a)efga.org srenfro(a)silvix.sirinet.net ppomes(a)Qualcomm.com gate(a)mogul.oit.gatech.edu unicorn(a)schloss.li hanabusa(a)bnn-net.or.jp p-paris(a)worldnet.fr bubba(a)dev.null tz(a)execpc.com toto(a)sk.sympatico.ca Date: Sun, 20 Apr 1997 19:06:35 -0500 From: Majordomo(a)einstein.ssz.com Members of list 'cypherpunks': No listing returned: Check at 525 œ Barton Springs Road, Austin, Texas. Patron Saints of "The True Story of the InterNet": Lao Tsu Che Guerva Marshall McLuhan Phillip Zimmerman Hughes, Gilmore & May The Reader ---------------------------------------------------------------------------- Appendix / "WebWorld & The Mythical Circle of Eunuchs" / Part II "The True Story of the InterNet" ----------------------------------------------------------------------------

1 0

Germany Proposes Policing the Internet
by Charles Anthony 17 Dec '03

17 Dec '03

There is a Rueters story this morning on Germany's proposal to police the Internet. --C http://www.infoseek.com/Content?col=NX&arn=a0409robti-19970419&dbid=4 &lk=noframes&ud3=2295E5565D2A6D7AD8C45800DC9F484B&ak=NONE&kt=G ********************************************************************** Charles Anthony canthony(a)info-nation.com http://www.info-nation.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3a mQBtAzM63W8AAAEDAMRi15+AIXC0j2R7IrdeNhM7AQXPGAYAd2mCNhKrQa09fICZ 4jEpTd0biV+3nMAL6/6pWUm1AmFPS/FngecmXkrmMPlbgv3O0dapbJ2/FQf3XUtH Z5AEOdKL9xK5Ml7dCQAFE7QIY2FudGhvbnmJAHUDBRAzOt1wi/cSuTJe3QkBAemw AwC1DGxodXVPkA1D6uLdqFvP5H3/98i/gM2x9IvvfZscWszwrJuOhkYyd71TF7K5 gy55OqPp+Rf77On0XhmHoi98Y4HOSTHYPhN9o9zQQ+pn/4HmxQ4Tbtih2sCDNvmG b2g= =0pHR -----END PGP PUBLIC KEY BLOCK-----

1 0

BIL_due
by John Young 17 Dec '03

17 Dec '03

22 April 1997: Space/intelligence technology's embattled frontier European citizens and governments alike have expressed concern over the recent expansion of U.S. intelligence bases in Europe. The National Security Agency (NSA) and National Reconnaissance Office (NRO) are combining efforts at large sites known as regional SIGINT (signals intelligence) operation centers, or RSOCs. At a recent Space Symposium in Colorado Springs, Colo., NRO director Keith Hall said that the merging of the NSA and NRO bases is the first step in creating "collaborative systems of systems in signals intelligence." In the future, Hall said, those joint efforts could also include the U.S. Space Command, the service intelligence agencies and even commercial resources "borrowed" by the intelligence community. U.S. military officials have been surprisingly candid about their intent to take maximum strategic advantage of their information trump cards. Air Force Secretary Sheila Widnall said, "Our allies must understand that we bring tremendous capabilities to the table, and it would be to their advantage to find ways we both can use [them]." In a more blatant revelation of U.S. sentiment, Gen. Howell Estes, commander of the U.S. Space Command, said the United States "is the only nation intellectually prepared for and morally capable" of controlling space-based intelligence. ---------- President, Senators Set to clash on Encryption Bent on retaining access to any and all data exported from the United States, the Clinton administration soon will solidify its position on Internet security issues and have a bill sponsored in the Senate. Meanwhile, microprocessing giant Intel Corp. of Santa Clara, Calif., which has been developing hardware-based encryption tools based on Cupertino, Calif.-based Hewlett-Packard's International Cryptography Framework, is sitting tight, waiting to see how things play out on Capitol Hill. Intel already has submitted the framework for government review, but is closely guarding specifics about its encryption key lengths. ---------- SET 2.0 on the way - Encryption spec speeds e-commerce "SET 2.0 will be security-algorithm-independent," said Steve Mott, senior vice president for electronic commerce at MasterCard International. "The issue is not the underlying cryptography, and the problem is not with RSA's mathematics; it's how efficient [RSA's cryptography] is." Vendors such as Certicom, Apple Computer, and RPK are all positioning themselves as alternatives to market-leader RSA for providing encryption technologies. "We have SET 1.0 pilots going with elliptic curve cryptography," Mott said. Elliptic Curve Cryptosystem (ECC) is a technology that is being pushed by both Certicom and Apple. RPK, meanwhile, offers another alternative to encryption: Its Mixture Generator encryption engine performs both bulk and key encryption. ---------- A Smart Partnership Pretty Good Privacy Inc. and Schlumberger Electronic Transactions are teaming up to integrate their encryption and smart-card technologies. The two companies will interweave PGP's encryption software with Schlumberger's Cryptoflex smart card, which supports functions such as key and digital certificate storage and signatures. ---------- U.S. Seeks Laissez Faire on Internet The Clinton administration plans to tell the Internal Revenue Service and bank regulators to forget about new rules for Internet commerce in a policy paper that is scheduled to be released later this spring, Ira Magaziner said last week. It is unclear how far this laissez faire approach will go. Speaking at the same session, a top official in the Office of the U.S. Trade Representative warned about the obstacles he sees in trying to get other governments to go along. He warned. "What do governments want to do? They want to regulate," he added. "It's ingrained to the system. It's almost a social-democratic ideal they want to fulfill." ----------- MITI to develop int'l electronic commerce technology The ministry will formulate a standard for authentication centers that use different data-verification methods. The new protocol would facilitate the exchange of encryption data among authentication centers around the world, thus allowing a business to verify the identity of a client in another country. MITI, which has earmarked over 10 billion yen (about 79.82 million dollars) for electronic commerce tests, is hoping to nurture Japan's own electronic commerce services and to narrow the technological gap with the U.S. ---------- BIL_due or http://jya.com/bildue.txt

2 1

Re: Fwd:Clinton and RSA, True?
by Phillip M. Hallam-Baker 17 Dec '03

17 Dec '03

>Yet, at the same time the Clinton administration attemped to >lump out nearly a billion dollars to buy a US company. This >smaller, "leaner", US Government, according to Ira Sockowitz, a >former Commerce employee appointed by Bill Clinton, ordered him >to meet with RSA Inc. Chairman James Bidzos. The topic of that >meeting was the official desire to secretly purchase RSA Inc. >using taxpayer money. [drivel deleted] Cyber dog loses points for the following:- NO mention of the Zarapuder film. NO explanation of Vince Foster's death. NO consideration given to the credible evidence of UFO sightings. Quite why the US govt. would want to buy RSA is beyond me. They already have a license to use RSA for internal purposes, the patent expires in three years in any case. Even if RSA was completely banned it would still be possible to use El-Gamal and variants for encryption and digital signatures. False, and no more than 3/10 for effort. Phill

2 1

stop by and see us.
by sandy&darlene＠hotmail.com 17 Dec '03

17 Dec '03

<HTML><PRE><BODY BGCOLOR="#000000"> Why pay for a good time? Let us give it to you for five minutes FREE on your first call! <A HREF="http://www.xxxratedsex.com/nova.html"> Click Here For a FREE Sample! </A> (you must be over 18 years old to view this web page!) See our beautiful girls or hot studs live on your computer screen - yes live - it's not a movie, you see it while it's happening & you direct the show, Our ladies & men will do whatever you tell them! Try it out for free & see what you think. We're sure that we have the finest bodies on the net! Also, check out all the pictures on our web pages for free too! http://www.xxxratedsex.com/nova.html <A HREF="http://www.xxxratedsex.com/nova.html"> Click Here For a FREE Sample! </A> (you must be over 18 years old to view this web page) </PRE></HTML>

1 0

www.wow-com.com
by wcreply＠ctia.org 17 Dec '03

17 Dec '03

Dear WOW-COM Reader: WOW-COM continues to provide the knowledge wireless professionals need to stay ahead in a fast-paced environment. Our news, CTIA-sponsored research and regular updates on the top issues affecting wireless, make WOW-COM the site for industry professionals. Daily use of the wireless industry's Web hub continues to grow because we constantly add new features and information. Here is what's new: **Searchable Database on Antenna Moratoria Across America** This segment of WOW-COM provides the information on every effort by localities to thwart development of wireless infrastructure by limiting tower development. This analysis is of great value to all wireless professionals attempting to navigate the tower siting issue successfully. To reach the Moratoria Database, click on http://www.WOW-COM.com/professional/siting/index.cfm **Career Center** WOW-COM's Career Center continues to grow rapidly. New listings by Motorola, Iridium LLC, Sony Wireless Telecommunications, AirTouch Cellular, Lucent Technologies, and others have made this the on-line job center for wireless. Recruiters are also now linked to the center, making it possible for you to reach them easily. To reach the Career Center, simply logon to WOW-COM and click on the Career Center. **Week In Review** The Week In Review, authored by CTIA political and regulatory experts, is available every Friday on WOW-COM -- three days before its scheduled Monday release. We are always adding additional services, analysis and research for WOW-COM readers. Please let us know what you think about WOW-COM and how we can serve you better! Sincerely, Team WOW-COM wcreply(a)ctia.org www.wow-com.com We hope you found this email useful and informative. If you didn't, we sincerely apologize. If you do not wish to receive our notices, please reply to wcreply(a)ctia.org.

1 0

Generic announcement
by Kent Crispin 17 Dec '03

17 Dec '03

This is from a story on Top Level Domain Names. Seems like it could apply to anything: "In Washington DC, officials from the White House, federal agencies and Congress say regulations may be necessary to promote a free-market system. A White House inter-agency taskforce was due to meet last week, after CWI's press deadline, to discuss the matter." -- Kent Crispin "No reason to get excited", kent(a)songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html

2 1

Re: Short AP Rant [POLITICAL NOISE]
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

At 07:27 AM 4/20/97 +0800, jamesd wrote: > > The election of various unpleasant Islamic Fundamentalist regimes. > > In particular, it seems likely that had the generals not violently > > overthrown democracy in Algeria, the democratically elected > > representatives of the people would have proceeded to kill off > > everyone they deemed insufficiently Islamic, a very substantial > > minority, a minority which would doubtless have included most of > > the generals and their families. At 09:22 PM 4/20/97 -0700, Bill Stewart wrote: > The Islamic party didn't start killing off foreigners until the > French and other Westerners supported the generals who overthrew them. However they have been murdering Algerian women and children from day one, though they did not get into murdering Western women and children until a little later. --------------------------------------------------------------------- | 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

(no subject)
by Julian Curmi 17 Dec '03

17 Dec '03

Please delete from this list.

1 0

Wired news: German Network Lifts Ban on Dutch ISP
by tank 17 Dec '03

17 Dec '03

>From www.wired.com: German Network Lifts Ban on Dutch ISP With mirror sites defeating its attempt to shutter a left-wing magazine, Germany's main academic network has called off the blockade. The network acted 11 April after prosecutors warned that Radikal magazine, hosted by Dutch ISP XS4ALL, was illegal. The network then blocked XS4ALL, which hosts 6,000 Web sites. Protests included widespread mirroring of Radikal. "An effective barrier to the illegal content was not possible," a network spokesman told the Associated Press Tuesday. XS4ALL Internet BV - Felipe Rodriquez-Svensson - finger felipe(a)xs4all.nl for Managing Director - - pub pgp-key 1024/A07C02F9

1 0

(Fwd) Wired news: German Network Lifts Ban on Dutch ISP
by Charles Anthony 17 Dec '03

17 Dec '03

The mirror efforts have been a success. Germany has lifted the ban on the xs4all site. --C ------- Forwarded Message Follows ------- From: tank <tank(a)xs4all.nl> Subject: Wired news: German Network Lifts Ban on Dutch ISP To: tank(a)xs4all.nl Date: Wed, 23 Apr 1997 11:39:04 +0200 (MET DST) >From www.wired.com: German Network Lifts Ban on Dutch ISP With mirror sites defeating its attempt to shutter a left-wing magazine, Germany's main academic network has called off the blockade. The network acted 11 April after prosecutors warned that Radikal magazine, hosted by Dutch ISP XS4ALL, was illegal. The network then blocked XS4ALL, which hosts 6,000 Web sites. Protests included widespread mirroring of Radikal. "An effective barrier to the illegal content was not possible," a network spokesman told the Associated Press Tuesday. XS4ALL Internet BV - Felipe Rodriquez-Svensson - finger felipe(a)xs4all.nl for Managing Director - - pub pgp-key 1024/A07C02F9 ********************************************************************** Charles Anthony canthony(a)info-nation.com http://www.info-nation.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3a mQBtAzM63W8AAAEDAMRi15+AIXC0j2R7IrdeNhM7AQXPGAYAd2mCNhKrQa09fICZ 4jEpTd0biV+3nMAL6/6pWUm1AmFPS/FngecmXkrmMPlbgv3O0dapbJ2/FQf3XUtH Z5AEOdKL9xK5Ml7dCQAFE7QIY2FudGhvbnmJAHUDBRAzOt1wi/cSuTJe3QkBAemw AwC1DGxodXVPkA1D6uLdqFvP5H3/98i/gM2x9IvvfZscWszwrJuOhkYyd71TF7K5 gy55OqPp+Rf77On0XhmHoi98Y4HOSTHYPhN9o9zQQ+pn/4HmxQ4Tbtih2sCDNvmG b2g= =0pHR -----END PGP PUBLIC KEY BLOCK-----

1 0

The Risks of Automatic Spam Filtering/Deadbolt
by Charles Anthony 17 Dec '03

17 Dec '03

An item from Risks-Forum Digest forwarded through the Red Rock Eater News Service- --C Date: Thu, 27 Mar 1997 11:31:55 -0800 (PST) From: risks(a)csl.sri.com Subject: RISKS DIGEST 18.94 RISKS-LIST: Risks-Forum Digest Thursday 27 March 1997 Volume 18 : Issue 94 ---------------------------------------------------------------------- Date: Wed, 26 Mar 1997 09:25:38 -0600 (CST) From: Prentiss Riddle <riddle(a)is.rice.edu> Subject: Risks of automatic spam blockers Forwarded from Edupage, 25 March 1997: | SPAM BLOCK | A California software engineer [Ron Guilmette] takes the annoyance | caused by unsolicited e-mail messages seriously, and has developed an | anti-spam weapon he plans to unveil next month. Dead Bolt allows | online users to share their "blacklists" of spam purveyors so that they | can more effectively filter offending e-mail. "The problem now is that | everyone who is filtering is keeping their own blacklists and they're | not working together to tie their lists together in a meaningful way," | says Dead Bolt's creator. "What I hope my package will do is allow | people to work together over the Net and filter all this stuff out and | finally put these people out of business....The problem is that it | costs the sender virtually zero dollars to send out a million messages, | and even if the response rate is minuscule by all standards -- say .001 | percent -- they've made money. So from an economic selfish point of | view, it's in their interest to annoy the other 99.99 percent of the | people." (Miami Herald 24 Mar 97) The full Miami Herald article is available at: http://www.herald.com/archive/cyber/techdocs/056735.htm Some of the risks of automatic spam filtering which Deadbolt will have to overcome in order to be successful include: -- The risk of false and malicious blacklisting of non-spammers. -- The risk of harm to innocent bystanders who happen to share hostnames, ISPs, or other characteristics with targeted spammers. -- The possibility that spam messages will avoid detection by varying return addresses and other signatures in each copy of a message. I find the first two particularly troubling -- were an imperfect spam filtering system in wide use, then triggering it against an innocent party could become a handy form of denial-of-service attack. Published details of Deadbolt are sketchy, but a Deja News or Alta Vista search of Usenet for "Ron Guilmette" reveals some of its designer's thinking on the subject. So far, I don't see enough to convince me that he will be successful. Prentiss Riddle riddle(a)rice.edu ------------------------------ End of RISKS-FORUM Digest 18.94 ************************ Date: Tue, 1 Apr 1997 17:01:10 -0800 (PST) From: risks(a)csl.sri.com RISKS-LIST: Risks-Forum Digest Wednesday 02 April 1997 Volume 19 : Issue 02 ---------------------------------------------------------------------- Date: Thu, 27 Mar 97 13:44:07 PST From: zerkle(a)cs.ucdavis.edu (Dan Zerkle) Subject: Re: Risks of automatic spam blockers (Riddle, RISKS-18.94) > Dead Bolt allows online users to share their "blacklists" of spam > purveyors so that they can more effectively filter offending e-mail. Something like this has, unfortunately, become necessary. It will happen someday. Stopping spam is a topic near and dear to me, and I've already considered the risks mentioned. > The risk of false and malicious blacklisting of non-spammers. This is a serious problem. A step towards solving it would be a secure clearing house of data on spammers. It would need to be distributed via a technique like PGP-signed Usenet messages or a on online database downloadable through some secure transfer medium. Whoever maintained the database would need to somehow decide what went into it and what didn't. The entries would have to be classified by reliability level so that the users could decide which data to use and which to ignore. Unfortunately, doing this would subject whoever did it to a suit by spammers who didn't want to be blocked. I haven't figured out a way to avoid this particular risk short of establishing the operation in a country without spammers. > The risk of harm to innocent bystanders who happen to share hostnames, > ISPs, or other characteristics with targeted spammers. This is not a risk. This is a benefit. If users at an ISP get blocked because the other users at that ISP are spamming, they will take their business elsewhere. ISP's will either take measures to avoid harboring spammers, or they will lose their customers and go out of business. Either way, spammers will have one less place to hide. > The possibility that spam messages will avoid detection by varying return > addresses and other signatures in each copy of a message. If the source of a spam can be discovered, this is not a problem. The original spamming host is going to show up somewhere in the Received: line, even if only as an IP number. Poorly configured sendmails on intermediate (relay) hosts might not properly include the Received: information. If this is the case, the defective site should be blocked until its owners fix it. ------------------------------ Date: Fri, 28 Mar 1997 10:57:47 -0500 From: Wayne Mesard <wmesard(a)sgi.com> Subject: Spam-proofed "From:" lines A recent trend in the war against spam is to munge the "From:" line in outgoing Usenet and e-mail messages (e.g., by adding asterisks or exclamation points to the beginning or end of the userid). These messages are typically accompanied by a terse note at the bottom of the message instructing respondents to "Remove asterisks [or whatever] from my address if you would like to reply." I see several risks with this technique: - False security: Most mail and news agents will dutifully add a "Sender:" line containing the "actual" e-mail address, if the user-supplied "From:" line doesn't look right. Since many spammers already gather addresses from the "Sender:" line, munging the "From:" line provides only limited protection. - Inconsideration: In that a munged "From:" line reduces the spam received, it reduces the amount of work the munger has to do. So instead of having to press one key to delete a junk e-mail message, everyone that wants to reply to one of his messages has to (a) notice that the address is bogus (b) press many keys to fix it. (Indeed, some mail readers make it quite tedious to edit the headers in replies.) In other words, it hasn't eliminated the problem; it's merely shifted the work from the sender to his correspondents. - Lost messages: a non-scientific survey of some novice-user friends indicated that a large number of them had no idea what the "remove asterisks..." directive meant, how to perform this task, or what to do with the bounced messages that will result from the failure to do so. - False security 2: In the ever-escalating spam arms race, it won't be long before spammers' address-gathering software is modified to unmunged munged "From:" lines. (I can think of two obvious techniques, which I won't describe here so as to avoid providing aid and comfort to the enemy.) Wayne ------------------------------ End of RISKS-FORUM Digest 19.02 ************************ Date: Fri, 4 Apr 1997 17:04:13 -0800 (PST) From: risks(a)csl.sri.com RISKS-LIST: Risks-Forum Digest Friday 4 April 1997 Volume 19 : Issue 04 ---------------------------------------------------------------------- Date: Tue, 1 Apr 1997 18:35:54 -0800 (PST) From: C Matthew Curtin <cmcurtin(a)research.megasoft.com> Subject: Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02) >> The risk of false and malicious blacklisting of non-spammers. (Riddle) Dan> This is a serious problem. A step towards solving it would be [...] This is unnecessarily complex. The NoCeM effort (see http://www.cm.org/ for details) has simply, and effectively, dealt with the spam problem for usenet. Efforts are underway to adapt this to e-mail. NoCeM works this way: * Someone takes it upon himself to watch for spam in a newsgroup (or groups). * When spam does appear, that someone posts a "NoCeM" message to news:alt.nocem.misc and/or news:news.admin.net-abuse.misc, PGP signed. * Users who want to benefit from the filters have clients that, when they grab news, look in news:alt.nocem.misc (and potentially other places) for NoCeM messages. The client verifies the signatures, and if it's signed by someone the client agrees to listen to, the message won't be shown to the user at all. * Clients are also available to work with news servers, to NoCeM messages on a site-wide basis. (I believe that these actually cancel the NoCeM'd messages on the site.) This is nice, because it uses what's already there (news), and allows the user (or admin, depending on the model) to select which users' NoCeMs he honors. Either you trust someone's judgement and honor their NoCeMs, or you don't, and they're completely ignored. Dan> Unfortunately, doing this would subject whoever did it to a suit Dan> by spammers who didn't want to be blocked. Superfluous lawsuits are threatened all the time... few have the resources of CyberPromo to actually be stupid enough to try any of this. (It's another thing about NoCeM...it doesn't kill the messages, it just is another post, that certain clients deal with behind the scenes. :-) Matt Curtin Chief Scientist Megasoft, Inc. cmcurtin(a)research.megasoft.com http://www.research.megasoft.com/people/cmcurtin/ ------------------------------ Date: Wed, 2 Apr 1997 11:57:49 -0800 (PST) From: Ted Wong <tmw5(a)cornell.edu> Subject: Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02) Instead of having a central repository of spam, why not use a distributed spam-control system analogous to NoCeMs for Usenet news? Anyone could then issue digitally-signed spam-block notifications, but an individual user would configure their system to only apply notices that came from cancellers they trusted. An Alpha version of NoCeM for e-mail already exists, at <http://www.novia.net/~doumakes/abuse/>. Some advantages of this system are: o It thwarts malicious individuals or organizations attempting to systematically censor e-mail. Unless the user lists them as trusted cancellers, their notices will be ignored. o A 'spotcheck' mode would allow users to occasionally receive an otherwise cancelled e-mail, to ensure that an otherwise trusted canceller hasn't stepped over the line between spam-blocking and censorship. o There is no risk of some central database being compromised by spammers or censors. o Users receive more timely warnings of new spam, without needing to periodically check and download a spam-list. o The spammers have no-one to sue for freedom-of-speech violations. While I'm not a lawyer, I can't see any way to sue someone for merely suggesting that a spammer's mail isn't worth reading. > > The risk of harm to innocent bystanders who happen to share hostnames, > > ISPs, or other characteristics with targeted spammers. > > This is not a risk. This is a benefit. [...] I can't see that this is a benefit. Changing your ISP is hardly a trivial task - you have to notify all of your correspondents of your new e-mail address, archive any web pages you may have stored at your ISP, reconfigure your internal network if you were using a Class C subnet, etc. It's grossly unfair to punish legitimate users because they were unfortunate enough to have some Canter and Siegal wanna-be set up shop on their ISP. Ted Wong Information Technology Section Mann Library, Cornell University <tmw5(a)cornell.edu> ------------------------------ Date: Wed, 2 Apr 1997 08:33:02 -0800 (PST) From: "Rosenthal, Harlan" <rosenthh(a)dialogic.com> Subject: Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02) > [...] they will take their business elsewhere. Easy to say from a university or company account. In the real world, nobody wants to change addresses and notify all of their correspondents, especially if it means losing an established presence that may have been widely disseminated to =potential= correspondents (not to mention reprinting stationary and business cards). And why should the multitude suffer this inconvenience, expense, and loss of communication, for the activities of the few? Spam is the biggest single argument for usage charges. As long as it's cheap to set up a new address and free to abuse it, there's no reason for the spammers to cut down on e-mailing spam and freeloading on other people's processors and comm lines. The fact that spam can be sent from a domain shared by many legitimate users, and that even new addresses may be reused after the spammer changes away, means that abusers are hiding among the innocent like hostage-taking terrorists - hyperbole, perhaps, but congruent in style if not in magnitude. The goal of any anti-spam approach should be to block, slow, or encumber transmission as close to the source as possible. Yet legitimate cases are always at risk; limiting the cc: lines, for example, could inconvenience clubs or companies almost as much as it slows the spammers. As in any police-power or security effort, the problem is how much freedom the average innocent person is prepared to give up so that the abuser can be blocked. -harlan ------------------------------ Date: Wed, 2 Apr 1997 09:32:46 -0800 (PST) From: Dan Franklin <dan(a)copernicus.bbn.com> Subject: Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02) > The original spamming host is going to show up somewhere in the Received: > line, [...] Note that if you are fortunate enough to have Received: lines to work from (the most recent spam I received had none at all, either because the relay host was defective or because it really was sent directly to my mailhost) you still have a challenge, because the spammer can insert one or more bogus Received lines in the initial message, so the one added by the first relay host will be buried in the middle. By the way, it does not seem practical to me to block all mail-relay sites that don't add Received lines. How would you generate such a list? What incentive would you provide to such a site to change their software? Dan Franklin ------------------------------ Date: Wed, 2 Apr 1997 10:57:55 -0800 (PST) From: "J. DeBert" <onymouse(a)hypatia.com> Subject: Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02) Any method of auto-blocking spam will create a serious problem for anyone who later acquire the spammers' discarded domain names. Spammers are registering lots of domain names and faking many to evade anti-spam and cancel bots and to hide from their enemies as well as the public at large. Once they are done with the domain names and they--the registered names--become available again, the next organization to acquire the name will find their mail bouncing or disappearing into /dev/null somewhere and perhaps harassed by bots and hostile spam-haters which do not know that the domain name has changed hands. The unfortunate victims of such acts may not even be able to escape them by merely changing their domain name, either. Who is going to removed dead spammer domains from the anti- spam and cancel bots' records and make sure that everyone knows about it? onymouse(a)hypatia.com | I've only one thing to Send NO spam | say to spammers: "47USC227". [Many thanks to an onymouse contributor (J DeBert), who acted as a guest moderator for this topic. PGN] ------------------------------ End of RISKS-FORUM Digest 19.04 ************************ Date: Tue, 22 Apr 1997 12:03:12 -0700 (PDT) From: risks(a)csl.sri.com Subject: RISKS DIGEST 19.10 RISKS-LIST: Risks-Forum Digest Tuesday 22 April 1997 Volume 19 : Issue 10 ---------------------------------------------------------------------- Date: Thu, 17 Apr 97 19:49:30 EDT From: dlv(a)bwalk.dm.com (Dr.Dimitri Vulis KOTM) Subject: Re: Risks of automatic spam blockers (Curtin, RISKS-19.04) On the risks of issuing NoCeMs I've been issuing NoCeMs for off-topic articles in several newsgroups (both global Usenet and the nyc.* hierarchy) since the summer of '96. I've received two legalese threats of legal action from posters of material that matched my criteria of being off-topic. 1. Michael Weir, a recruiter from Canada, insisted on posting job ads in an unmoderated discussion newsgroup whose charter prohibits job ads and resumes. He threatened to sue me for using his name in the NoCeM notices. He also posted a series of abusive flames about me. A search of DejaNews revealed several articles from him in Canadian newsgroups discussing his litigations and asking for personal information about a judge. Eventually he went away. 2. The "New York Theosophical Society" insists on posting in the local newsgroup nyc.seminars (usually used to announce, what else, seminars). One Bart Lidofsky responded to the NoCeM articles by saying: "I consider these messages to be a form of harassment, and will treat them as such." I have also seen several claims that the NoCeM notices themselves are "spam". Apparently, this term now applies to any traffic that the user doesn't like for any reason. I understand that other issuers of NoCeMs have also received threats, and at least one poster has been forging old-fashioned cancels for the NoCeM notices that mention his articles (another good reason to stop processing all old-fashioned cancels). Dimitri "co-proponent of news.lists.filters where NoCeM notices are posted" Vulis Dr.Dimitri Vulis KOTM ------------------------------ End of RISKS-FORUM Digest 19.10 ************************ Standard Risks reuse disclaimer: Reused without explicit authorization under blanket permission granted for all Risks-Forum Digest materials. The author(s), the RISKS moderator, and the ACM have no connection with this reuse.

1 0

EC Electronic Commerce Report
by John Young 17 Dec '03

17 Dec '03

The European Commission has issued a major initiative for electronic commerce in competition and contrast with that of the US being readied for release shortly by Ira Magaziner. Online privacy and information security are featured. http://jya.com/ecomcom.htm (110K)

1 0

Re: Generic announcement
by Jim Burnes 17 Dec '03

17 Dec '03

> Date: Tue, 22 Apr 1997 18:37:23 -0700 > From: Kent Crispin <kent(a)songbird.com> > To: cypherpunks(a)toad.com > Subject: Generic announcement > This is from a story on Top Level Domain Names. Seems like it could apply > to anything: > "In Washington DC, officials from the White House, federal agencies and > Congress say regulations may be necessary to promote a free-market > system. A White House inter-agency taskforce was due to meet last > week, after CWI's press deadline, to discuss the matter." > Thats about the most humorous thing I've read all week. Typical socialist mindset "we had to control it to set it free". Sort of like "we had to destroy the village to save it." This must be the same Orwellian mindset that gave birth to the Waco "Hostage Rescue Team" concept. Please don't rescue me. War is Peace Love is Hate I love big brother. Jim Burnes Engineer, Western Security, SSDS Inc jim.burnes(a)ssds.com ---- Sometimes it is said that man cannot be trusted with the government of himself. Can he, then, be trusted with the government of others? Or have we found angels in the forms of kings to govern him? Let history answer this question. -Thomas Jefferson, 1st Inaugural Addr

1 0