December 2003 - cypherpunks-legacy

No Subject
by Anonymous Remailing Service 17 Dec '03

17 Dec '03

E. Brian sed: >Unbelievable!!! To add to this distressing truth, I have learned that >the White House also subscribes to a number of newspapers and periodicals >which are reviewed for things of interest to the Administration and to >the President. I I I I I I ammmmmmmmmm shocked! mebbe tha Slickster just wants to know who orlin's "Deep Throat" is... Keep checkin' them fingerprints, Willie! >Ooops. Dog bites man. >And do you really think the White House couldn't hire a couple of net >gurus to sniff packets if they wanted to hide their "monitoring"(=reading). who sez they dont post, too? heh

2 1

Re: GAK/weak crypto rationale?
by Andrew.Spring＠ping.be 17 Dec '03

17 Dec '03

>intercepts requested and authorized in the past year. As I recall, the >number was quite small - around 12K [?]. Someone had found this out >through an FOIA request, perhaps, (my recollection of it is poor). It was I think it's about 1200. >not a large number, anyway. I must conclude that the actual number of >intercepts is much, much larger than they are saying, and that they must >be getting what they perceive to be good intel from all this snooping. > A more cautious conclusion would be would be that the importance (to the LEA's) of the busts made with crypto is much larger than the numbers suggest. You could interpret that a lot of ways: I suspect that high-profile career-enhancing cases are highly dependent on wiretaps.

4 4

Re: GAK
by Duncan Frissell 17 Dec '03

17 Dec '03

At 09:25 PM 9/3/95 -0400, Brian Davis wrote: >I, of course, know of the "dislike" of GAK here. I am curious to know, >however, if the "dislike" is because government would have access under >any circumstances or if the primary worry is that government will cheat >and get access when most would agree that they shouldn't (either by the >judge "cheating" or a TLA stealing it). Individuals will have their individual objections. My objections are that I don't like governments spending tax money that they don't absolutely have to. Their own survival is *not* a necessity. I think controlling people's speech is a waste of money. Very few Common Law crimes (ie real crimes) are dependent on wiretap evidence for solution. Only phoney bureaucratic crimes (the retail pharmaceutical trade, insider trading, gambling, conspiring to overthrow the government, etc) need wiretaps. My second objection is the control of people's speech. If I communicate with someone, I want to communicate with *them*. I don't want to communicate with the Feds. The Supremes have held that the right to speak includes the right not to be forced to speak. By implication, I would argue that I have the right to choose my own channels of communication including my intended audience (and this has been upheld by the Supremes in other contexts). If the Feds want to know what I've written or said (non-publicly) let them subpoena me and I will be happy to tell them to go to hell. If we can deploy technologies to protect our freedom to communicate the way *we* choose to, then we have the right to do so. Beyond rights, we have the power to do so --- which is worth even more. >In other words ... if it took agreement by a review board composed of >non-LEA members of this list, would the escrow be acceptable?? I don't think many of us would feel better if a private party had to approve the invasion of our privacy. DCF "You can ignore all of the rest of bullshit. All that you need to know about an enemy is how many guns and men does he have and can they stand fire."

3 2

Re: GAK/weak crypto rationale?
by John Young 17 Dec '03

17 Dec '03

Responding to msg by Andrew.Spring(a)ping.be (Andrew Spring) on Tue, 12 Sep 7:3 PM >A more cautious conclusion would be would be that the >importance (to the LEA's) of the busts made with >crypto is much larger than the numbers suggest. You >could interpret that a lot of ways: I suspect that >high-profile career-enhancing cases are highly >dependent on wiretaps. In response to an audience question about wiretaps and crypto, Mr. Michael Nelson of the White House said at the NIST GAK meeting (paraphrased): We are not concerned with bad people using crypto among themselves, we can handle that. We are more concerned with their using crypto to communicate with regular folks, to make legitimate arrangements -- finance, supplies, travel, and so on -- for their nefarious deeds. It's the intermix of the bad with the good that's the problem. Maybe someone else at the meeting heard this differently and will comment, but this seems to mean that the Feds can track, and maybe crack, the crypto-intercomm of "bad people" so long as it is not buried in a torrent of public crypto use. And not commingled with lawful, ECPA- protected(?), communication. Anybody want to elaborate what Mr. Nelson was implying about wiretaps and crypto?

2 1

Mixmaster posting poll
by loki＠obscura.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I am about to release Mixmaster 2.0.2 This version will not contain the Socket code, but will have a bunch of bug fixes. One of the things I am modifying is the posting to news feature. Mixmaster supports posting through either a local inews program, or through a mail-to-news gateway. There seem to be two flavors of the latter: group.name(a)gateway.com and mail2news(a)gateway.com Newsgroups: group.name I really only want to support one of these standards. Which is more standard? Is there a trend towards one becoming the dominant standard? The next version should be out within 48 hours. -Lance -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMFZ+PvPzr81BVjMVAQEa2Qf/d9a3UTzan5gLB/GN/n+DaMSvDLRVJ96V JpH4F+5SO+UQgdxoSAup9+/l+Q11A4O1ZjxpELVEh6e/7U8HjzrGQHCXGIMfzxkt DufouYDViio8cQ7w1Y4OLqlqaD10OUJ5Chrzm013mc7PzFBgF5eb6rf8S4TdGEYg Ly92xWgYHHk8EwhviYxqdBAGnSSTykEkY9E5WHLca+Lt+5ejox1uMEirq6I4rRVZ UBhfiVQhRsD2eKRUx/a3D3eVnuj0jS8+4i3ibcpUDxm+8WY76zGzmz67y66MzaDo 0E0fFK1VeCwrBoNqFJSLYY5e17c7T6hI3mWJYaZFOLL7H3rGsYUcHw== =BdWR -----END PGP SIGNATURE----- ---------------------------------------------------------- Lance Cottrell loki(a)obscura.com PGP 2.6 key available by finger or server. Mixmaster, the next generation remailer, is now available! http://obscura.com/~loki/Welcome.html or FTP to obscura.com "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ----------------------------------------------------------

1 0

NYT on GAK
by John Young 17 Dec '03

17 Dec '03

The New York Times, September 11, 1995, p. D7. Technology / Peter H. Lewis On The Net. Privacy for computers? Clinton sets the stage for a debate on data encryption. In terms of its ability to raise the nation's blood pressure, the debate over data encryption has not yet reached the same levels as gun control. But last week the Clinton Administration appeared to set the stage for an equally divisive debate over the degree to which businesses and individuals have the right to keep secrets when using telephones, computers and other forms of electronic communications. In two days of public hearings last week in Gaithersburg, Md., home of the National Institute of Standards and Technology, the Administration introduced its long-awaited proposals to relax restrictions on the export of cryptographic software. The Administration drew a line in the virtual sands of cyberspace, signaling that it is willing to permit Americans to put stronger cryptographic locks on their electronic data only if a spare key to those locks is made available on demand to law-enforcement agencies. There looms the conflict. Although the debate is about export controls the "export" issue is irrelevant in today's era of global electronic networks. Placing a common privacy program on an Internet computer in Austin, Tex., is effectively no different from sending a shrink-wrapped copy of the program to Moscow. The real issue is how much privacy the Government is willing to allow its own citizens, and the latest word from the Clinton Administration is that the right to electronic privacy, like the right to bear arms, is not absolute. Cryptography is the science of secret writing. In this digital era, it applies not just to notes, but also to telephone calls, money transfers, bank and credit card records, electronic mail, faxes and other computer files. The Clinton Administration's goal is to allow Americans to use the strongest possible cryptographic technology, while at the same time preserving the ability of law-enforcement agencies to perform court-authorized wiretaps as part of the effort to catch drug dealers, terrorists, child pornographers and other miscreants. In other words, it favors strong cryptography, but not too strong. The strength of cryptographic software is measured by the length of the software key necessary to encode and decode a message. The longer the key, the harder it is for an unauthorized user to decipher the message. In recent years, the Government has generally permitted Americans to export cryptographic software with key lengths up to 40 bits. Experts say that 40-bit keys are secure from casual snooping, but will fall quickly to a determined codebreaker. Last week, after more than a year of intense analysis, the Government introduced what it said was the best possible compromise. Under the new policy, companies can export encryption algorithms using 64-bit keys, which are much more secure, but only if spare keys are given to "escrow agents" who would make them available to lawenforcement agents under standard legal procedures, similar to legal wiretaps authorized by a judge. Otherwise, the 40-bit limit continues to apply. Such a "key escrow" scheme is anathema to many privacy advocates who fear Government abuses. The Government first proposed a key escrow system with its so-called Clipper Chip, a technology that failed to win acceptance even as a voluntary standard. The new scheme is somewhat more palatable than Clipper. Key escrow is still unpopular with American computer and software companies, which say it prevents them from competing against foreign companies that have no similar constraints, and with many multinational corporations, which say it prevents them from working with foreign companies that do not especially care for the idea of Uncle Sam holding the keys to their data banks. "If this was intended to be any sort of compromise, I don't think it achieved its end," said Whitfield Diffie, a Sun Microsystems enginePs who attended the meetings. "I didn't see anybody who was enthusiastic." Raymond G. Kammer, deputy director of N.l.S.T., suggested that the hearings last week were intended to elicit public comment, and that the Administration's final position on cryptographic policy were still under analysis. But the emergence of key escrow issues at the N.l.S.T. proceedings suggests that key escrow is emerging as a nonnegotiable demand by some factions of the Clinton Administration, especially the Justice Department and the Federal Bureau of Investigation, led by Louis Freeh. "If this fails," said a figure familiar with the Administration's thinking on the proposed change in cryptographic policy, "it's going to lead to a very divisive debate. And the irony, for libertarians who oppose key escrow, is that if it fails, I am convinced that Louis Freeh cannot be true to his job without proposing domestic controls on data encryption." "He's not going to give up without a fight, and neither is the Justice Department," said the figure, who spoke on the condition he not be identified. Others say they do not think the Clinton Administration has yet arrived at a concrete position, even after more than a year of study and debate. "I don't think it's a final offer," said John Gilmore, an engineer at Cygnus Support, a computer company in Mountain View, Calif. "It looks to me like a weak strawman, a first offer, a proposal to dance." The question is whether American citizens and businesses have the patience to wait for the music to start. And the issue may be moot, anyway because the Internet is no more controlled by the United States than is the United Nations. "The Internet Architecture Board has specifically decided to ignore export controls in designing the security infrastructure for the next generation of Internet protocols," Mr. Gilmore said. "The Internet of 1998 will provide automatic, secure, and fully private communication, without key escrow, internationally." In other words, the Internet community is already planning to jump over the new line in the sand drawn last week by the Administration. Cryptogrophy that is stronger than the Government's proposed system will be built into the Internet by a dozen countries, and American companies and individuals would be foolish not to use it. At that point, millions of Americans will come into direct conflict with Government policy, and the popular gun-control bumper sticker may be replaced by one that says "If cryptography is outlawed, only outlaws will have cryptography." [End]

3 2

Some informed comments on RSA's S/MIME
by Rich Salz 17 Dec '03

17 Dec '03

Date: Thu, 14 Sep 1995 08:39:49 -0700 (PDT) >From: Ned Freed <NED(a)innosoft.com> Subject: Re: Re[2]: MOSS conformance testing Cc: pem-dev(a)TIS.COM Message-id: <01HV9F2PHBSU8Y4Z8U(a)INNOSOFT.COM> > I just got wind of RSA's draft for Content-Type: application/x-pkcs7-mime. > Has there been any discussion on this - comparison to PEM etc.? If so > where's the list, URLs of archives....? Or did I just go "deaf" for a while > here on thist list? (The last could of months have been caught up in > changing companines...) S/MIME was developed privately by RSA in conjunction with a number of other companies. To the best of my knowledge all discussion has occurred on closed, private lists. As a potential customer of RSA I recently managed to get myself added to one of these lists (it may or may not be the only one where S/MIME is discussed) but I haven't had time to post anything there yet. I plan to post this message there in the next couple of days. I'm not saying this approach to protocol development is a good thing or a bad thing, but I do believe that it has led to the production of a specification that is seriously flawed, and that those flaws would have been detected and probably corrected had the discussion been more public. More on this below. > I browsed through the IETF drafts & personal contributions & search tool... > didn't find anything on RSA's "S/MIME". > I did get the PostScript file from RSA's pages & had a read.... > http://www.rsa.com/pub/S-MIME/ The specification, at least, is public. Given the amount of press surrounding this proposal and the strong liklihood of it being widely used I strongly recommend that everyone who is interested in email security obtain a copy of the specification and read it. However, the proposal is simple enough that it can be summarized in just two paragraphs. S/MIME is based on PKCS #7, which in turn is based on classic PEM. The significant difference between PKCS #7 and PEM is that it uses an ASN.1 encoding for the entire security object rather than the header/text encoding of RFC1421. In fact the specification states that mechanical conversion between RFC1421 formats and PKCS #7 should be possible as long as the proper set of algorithms are used. I think that mechanical conversion into and out of the PEM-derived subset of MOSS is also feasible but I haven't checked up on the specifics of this. S/MIME in turn is a simple encapsulation of PKCS #7 in MIME, consisting of an application subtype label and an encoding of the PKCS #7 object using standard MIME encodings. The inner secured content is then seen as another MIME object. This is almost identical to Jeff Schiller's earlier proposal for embedding PEM in MIME. There is only one significant twist -- in the case of signed but not encrypted data the specification calls for the use of multipart/alternative, with the first part being an unsigned copy of the signed data and the second part being the PKCS #7 object, including the signed data. Two obvious flaws in this approach should be obvious from this description. The first is simply one of excessive overhead -- sending signed material in such a way that it can be read on vanilla email systems as well as with an S/MIME system introduces something on the order of 133% overhead. The second flaw is more serious. The data that a user without S/MIME reads is not signed. This opens the door to attacks where the unsigned version is tampered with but the signed version is left alone. This turns into a really insidious problem when you consider how privacy services are likely to be deployed in some environments. One model I expect to be rather popular is that of having a remote signature verification service within a secure enclave. That is, most of the user agents that people use won't have the ability to validate a signature. Users will, however, have secure access to an agent that will validate the signature on a message for them. (The service may well be a different application on the same machine.) They simply submit the message to this service and it tells them whether or not the signature matches. The problem, of course, is that the material the user of the unextended agent reads isn't what's signed. And in general there is no way to correlate this material with the signed copy -- since it was exposed to the message transport layer without any special tagging to indicate its signed nature the transport may well have changed it so its no longer a byte-for-byte copy of the signed version (which is inherently protected against such munging). Comparing this approach with security multiparts is quite instructive. Security multiparts only introduces the overhead necessary to encode the single copy of the data -- at most 33% in the case of base64 -- plus of course the fixed overhead of the signature information. As such, it is far more efficient than S/MIME when it comes to signed but unencrypted material. Security multiparts can be processed in a single pass as well. I'm not sure this is true of S/MIME -- it depends on the specifics of the ASN.1 structure that's used. But by far the most important difference is that security multiparts do not suffer from this vulnerability when used in an environment with remote security servers. You can of couse avoid this problem by not including the extra copy of the signed material. The problem with this approach is that you won't be able to read such a message on anything short of an agent that knows how to take apart a PKCS #7 structure. I note in passing that there was absolutely no reason why security multiparts could not have been used in S/MIME instead of the chosen encapsulation. PKCS #7 explicitly provides a facility whereby the secured data is stored outside of the ASN.1 object. This then fits seamlessly into the security multiparts methodology. I do not propose to debate the relative merits of PKCS #7 versus MOSS. Modulo the MIME issues this is essentially the same as debating the merits of PEM versus MOSS, and I've had more of that than I care for. Besides, I think folks should use whatever security service they feel like using. I've maintained all along that my interest is primarily that of standardizing on a single embedding methodology for use with MIME. I'm very disappointed that S/MIME has seen fit to use what to my mind is a technically inferior embedding solution when compared to security multiparts, and I'd really like to try to get the S/MIME folks to switch to a security multiparts approach if its not too late for them to do so. I'm very interested in any and all comments on what I've written here. I intend to post them to the S/MIME list I'm now on. Ned

1 0

[revcoal@pcnet.com: Re: The owls are not what they seem]
by David Taffs 17 Dec '03

17 Dec '03

fyi... Date: Fri, 15 Sep 1995 00:02:33 -0400 (EDT) From: "Donna J. Logan" <revcoal(a)pcnet.com> To: Marilyn159(a)aol.com Cc: Search Net <snet-l(a)world.std.com> Subject: Re: The owls are not what they seem In-Reply-To: <950912141715_17265559(a)mail06.mail.aol.com> Mime-Version: 1.0 Sender: snet-l-approval(a)world.std.com Precedence: bulk Reply-To: snet-l(a)world.std.com Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1330 It's your service provider....same thing happened to a whole bunch of us when we used to be on it...and only selective posts to selective lists. Look to the headline's your provider has generated the past few days and you'll get a clue as to what's going on...except the net spread by them and the feds is a lot wider than just kiddie pornographers. BTW, I'm being cagey in actually mentioning your service provider's name/ initials, as we found that was one of the "keywords" in the filter program used by them and a certain national police agency (who's initials also trigger the filter program) to flag posts which they thought may be "interesting", resulting in delays of up to days in posting. Same thing happened in live chat in PRIVATE chat rooms, we were able to bring the system to a complete halt by just typing the initials of Frederico's Bumbling Idiots.... The only solution to Amerigo's Obnoxious Lackeys was to cancel our accounts and switch to CHEAPER local service providers, who also happen to provide BETTER service, with no censorship/surveillance. ;-> On Tue, 12 Sep 1995 Marilyn159(a)aol.com wrote: > This is so weird... > Only pieces of the message I sent are getting through. This is a little bit > more but not the whole thing. > Where is the rest of it? > Is this censorship or computer error? >

2 1

VIO_lat
by John Young 17 Dec '03

17 Dec '03

9-15-95. NYPaper: "Company Says Electronic Mail Was Opened to Find Pornography." America Online gave the FBI access to the mailboxes of its subscribers to identify several thousand users who viewed images of children in sexual poses and to trace messages beyond AOL to many more computer users nationwide. Because electronic mail has a life of days or weeks, can be traced and can be easily copied without alerting the owner, reading the mailboxes was particularly effective. It was unclear how much information about subscribers is routinely kept and how much private information was provided to the FBI. Actions of users can be recorded and can reveal much more personal information than the records a telephone company. "F.B.I. Chemist Says Experts Are Pressured To Skew Tests." Officials at the F.B.I. crime laboratory have been accused by one of its chemists, Frederic Whitehurst, of pressuring forensic experts to commit perjury to help secure criminal convictions. With opinion polls showing public support for the F.B.I. eroding after Congressional hearings into the Branch Davidian siege, the accusations regarding the laboratory are in some ways the worst blow yet. Two: VIO_lat (11 kb)

1 0

Chiffrement en Fr
by anonymous＠freezone.remailer 17 Dec '03

17 Dec '03

A web search for Quisquater led to: URL: http://www.cnam.fr/Network/Crypto/ which offers, among other belle chiffre-escrits: L'UTILISATION DU CHIFFREMENT EN FRANCE Le chiffrement est la technique qui consiste à modifier un fichier de façon à le rendre illisible par les personnes auxquelles il n'est pas destiné. Pendant longtemps l'apanage des militaires, il est maintenant un outil indispensable à l'ère des réseaux pour ceux qui veulent protéger la confidentialité de leurs messages. Son utilisation soulève diverses questions. Si cette page Web est l'une des premières en France, il en existe de nombreuses aux Etats-Unis . Je ne parlerai pas beaucoup de technique sur cette page. Si vous voulez en savoir plus, regardez : * L'excellent serveur du Groupe de Recherche en Complexité et Cryptographie, * Quelques modestes explications. Le chiffrement est pratiquement interdit en France par la loi 90-1170 du 29 décembre 1990 (avec décret d'application en décembre 1992). Une excellente petite brochure (avec un sphinx sur la couverture :-) de la Délégation Interministérielle pour la Sécurité des Systèmes d'Information (DISSI) explique cette loi (mais malheureusement ne détaille pas ses conditions réelles d'application). Elle est envoyée gratuitement sur simple demande : DISSI 3 avenue Octave Gréard 75007 PARIS C'est le Service Central de la Securite des Systemes d'Information (SCSSI) qui doit etre contacté pour plus d'information et dépôt des demandes d'autorisation. Il existe deux cas : 1. Soit vous utilisez le chiffrement à seule fin d'authentification (chiffrement de mots de passe pour qu'ils ne circulent pas en clair sur le réseau, par exemple) : il faut faire une déclaration au SCSSI qui est ensuite vérifiée. 2. Soit vous l'utilisez pour la confidentialité. Il faut alors demander une autorisation au SCSSI. SCSSI 18, rue du Docteur Zamenhof 92131 ISSY-LES-MOULINEAUX Cedex Tél. : (1) 40 95 37 15 Fax. : (1) 40 95 37 01 Dans les deux cas, la demande aura pu être faite par le réalisateur ou le vendeur du logiciel. Plus de détails sont donnés dans la présentation de Bruno Malhey (également en PostScript). J'y ajoute que les critères d'acceptation ou de refus ne sont pas publics. Il semble que l'autorisation ne soit donnée qu'aux institutions "sérieuses" (banques, ...) et à condition de ne pas utiliser de logiciels trop efficaces. En effet, il s'agit de conserver la possibilité pour la police de suivre les échanges. On notera que la plupart des pays comparables à la France autorisent le chiffrement, comme le montre l' excellente enquête de Sylvain André (vous pouvez voir aussi l'étude du gouvernement américain). Le logiciel de chiffrement le plus connu est PGP (Pretty Good Privacy). Gratuit, assez simple à utiliser, très efficace, bien documenté, tournant sur de nombreuses plate-formes (Unix, MS-DOS, Macintosh), c'est un excellent outil pour l'utilisateur. Il semble que son autorisation en France soit hors de question. Notez que, si vous voulez utiliser PGP en France, vous avez deux obstacles successifs : 1. PGP est interdit d'exportation par les Etats-Unis. Il faut donc récupérer une des (nombreuses) versions sur un serveur non-américain. 2. Le chiffrement est soumis à autorisation en France. Voir ci-dessus. Certaines personnes trouvent qu'un autre obstacle à l'utilisation de PGP est la difficulté d'utilisation. Celles-ci peuvent lire le remarquable livre de Garfinkel : Simson Garfinkel PGP ; Pretty Good Privacy O'Reilly & associates ISBN 1-56592-098-8 Et il existe d'autres présentations de PGP comme celle d'Ollivier Robert (fichiers PostScript PGP.*.ps), qui existe aussi sous forme d'un serveur Web. PGP protège des fichiers, soit lors de leur transmission sur le réseau (par courrier électronique ou autre méthode), soit en local. D'autres logiciels protègent, par exemple les connexions à distance ou le système de fenêtrage X ( SSH assure ces deux fonctions). Visitez le service Web "International Cryptography Pages" pour avoir tous les renseignements possibles, notamment sur les logiciels disponibles en dehors des Etats-Unis. Enfin, après ces informations purement factuelles, voilà mon opinion. Voir aussi * L'Electronic Frontier Foundation qui lutte pour les droits du citoyen dans le monde informatisé dispose de nombreuses informations sur le chiffrement. * Computer Professionnals for Social Responsability travaille également sur le respect de la vie privée. * Toujours en français, mais conçernant plus spécifiquement le Québec. Page faite par Stéphane Bortzmeyer sur le serveur du CNAM. Dernière mise à jour le 4 août 1995.

1 0