December 2003 - cypherpunks-legacy

Re: FORGED CANCELS of posts on n.a.n-a.m
by Bill Stewart 17 Dec '03

17 Dec '03

At 06:11 PM 10/5/95 +1000, you wrote: >One thing that occurs to me: suppose I go to control, collect cancel messages, >and build myself a collection of M1's that will work with a given M2? MD5 produces a very random 128-bit output; you're not going to collect any appreciable fraction of the 2**128 possible M2s. As long as M1 is even as simple as MD5(messageid,passphrase), it's pretty open territory. Targeted attacks, however, are still possible, as long as M1 retains the form MD5(known-stuff, passphrase) - assuming the user uses one of the few hundred million wimpiest passphrases, you can search that moderately fast; if you're willing to burn some resources, you might be able to take out most of alt.religion.spam, at least until people use better passphrases. The amount of work depends somewhat on whether you use MD5(known-stuff, passphrase) or MD5(passphrase,known-stuff). For the first case, the cracker would calculate the MD5 context after doing known-stuff (once) and then grind away on passphrases. For the second, the cracker could pre-compute a table of MD5 context for the wimpy password list, and then add known-stuff to each. Since known-stuff is probably longer than passphrases here, the latter is probably more secure for this application. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Announcement: keys.pgp.net
by Paul Leyland 17 Dec '03

17 Dec '03

First the summary for those people who don't like reading more than one paragraph. The address pgp-public-keys(a)keys.pgp.net reaches one of several email keyservers. pgp-public-keys@keys.<country>.pgp.net goes only to key servers for <country>. A start has been made on other services such as ftp.pgp.net. In particular, see http://www.pgp.net/pgp for more information. The domain "pgp.net" was registered last year in preparation for providing a simple and unified name space for PGP infrastructure such as key servers, software distribution sites and so on. The first steps to populate the pgp.net domain have now been taken. They are small steps, but we believe, important ones. Many more will be taken over the next few months. The first additions are for the email public key server network. The key servers are presently known by a number of different names, none of which are particularly obvious to the uninitiated. Worse, many of them are run by students or employees without the official backing of their host organizations. It's not surprising that some are unreliable and/or short-lived. A recent development, however, is that more and more servers are being run by CERT teams. Examples include those run by DFN-CERT (Germany), CERT-NL (Netherlands) and OxCERT (Oxford University). It is in the best interests of the teams that the keyservers be reliable and available. The validity of the keys themselves, of course, must be checked by their users with the usual signature checking built into PGP. We have, therefore, set up "keys.pgp.net" as a set of equal-priority MX records in the DNS. What this means, in practice, is that email sent to pgp-public-keys(a)keys.pgp.net will be sent to a randomly chosen keyserver. It probably doesn't matter which one, as the servers are synchronized. If the first server your mail system tries is not available, it should automatically try the other servers until one works. This should give a rather more rapid and sucessful response than the current mechanism. It is also rather easier for documentation writers, FAQ maintainers and such like to give advice which has a long shelf-life. We recognize that, for efficiency reasons, users of key servers might want to be able to specify a local machine rather than be handed a randomly selected one. The old names will continue to work: the address pgp.ox.ac.uk (for example) will continue to reach the OxCERT keyserver and no others. However, we have also registered sub-domains of pgp.net. In particular, the records for "whatever.uk.pgp.net" will only map to machines for the United Kingdom. At the moment we have the following records in place, with the expectation that more will follow: keys.de.pgp.net Germany DFN-CERT keys.no.pgp.net Norway Univ. of Tromso keys.uk.pgp.net United Kingdom OxCERT, Oxford keys.us.pgp.net United States MIT Large regions, such as the US, will eventually have several servers, each of which will be the target of equal priority MX records. We expect the Netherlands to join in with keys.nl.pgp.net very shortly. Allocation of key servers to the pgp.net domain is only the first step. Plans are advanced to set up a number of other sub-domains, all with the format <service>[.<region>].pgp.net. This structure allows for local customization and yet preserves the uniformity and simplicity of the naming scheme. For instance, the Web-site www.de.pgp.net would, presumably, have the text of the pages in German and would be the site recommended in German documentation, while ftp.no.pgp.net would be the principal archive of PGP-related material in Norway. So far, only ftp.pgp.net and www.pgp.net have been allocated. The URL http://www.pgp.net/pgp has more information on the pgp.net domain as it currently exists and will be kept up to date as the domain becomes more populated. Expect to see more developments along these lines later this year; all will be reported on http://www.pgp.net/pgp The following folk all had a hand in the initial stages of setting up pgp.net: Piete Brooks University of Cambridge, United Kingdom Borge Brunes University of Tromso, Norway Klaus-Peter Kossakowski DFN-CERT, Germany Brian LaMacchia MIT, United States of America Paul Leyland OxCERT, United Kingdom Teun Nijssen CERT-NL, Netherlands

1 0

Rethinking the utility of netnews "cancel" control messages
by Erik E. Fair 17 Dec '03

17 Dec '03

The day of unauthenticated netnews control messages of any kind is basically over. We gotta: 1. turn off all automated system-wide control of netnews, or 2. properly authenticate all such messages (newgroup, rmgroup, cancel, etc.). I think we also ought to think carefully about continuing to have a "cancel" control message (and the Supercedes: header) any more, authenticated or not - as useful as this mechanism occasionally is to remove unsightly spams (and other Officially Troublesome Material), isn't this kind of casual revisionism something that is, historically, to be avoided? If you had a netnews system which simply marked a message as cancelled in some way, would you set your netnews reader to seek out cancelled messages? Or ignore them? If you were a librarian or historian operating The Official USENET Archive of Everything, would you accept and process cancel control messages? "Backbone cabal? What's that?" Erik Fair <fair(a)noc.use.net>

1 0

Re: Rethinking the utility of netnews "cancel" control messages
by Rich Salz 17 Dec '03

17 Dec '03

Cancel/Supercede is a useful model -- architecting them out of Usenet is a very bad idea. Ask Clarinet.

1 0

re. GAK - (was Re: Europe)
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Wed, 04 Oct 1995 12:58:24 +0100 >From: Christian Wettergren <cwe(a)it.kth.se> >| Sweden: The authorities have not yet said anything at all about >| where they stand in the GAK controversy. Probably very few have >| heard about it. [...] >So lets go off and think hard about good (culture-related) arguments >why this is a bad idea. We'll gonna have to look really nice, and >say some sensible things. :-) Crypto is used for making sure that insiders get in while outsiders are kept out of encrypted files/messages. Strong crypto does a better job of keeping outsiders out. Things like TIS CKE are mechanisms for making sure that insiders continue to get in, in spite of mishaps with their keys. Any such system can be evaluated on its technical merits (does it really separate the insiders from the outsiders as well as it claims to?) (does it survive various disasters (because if it doesn't survive, it can't keep insiders in)?) This is a separate topic from GAK -- which boils down to the Government's claim that it should be listed as an insider for everybody. That's what needs to be brought to everyone's attention. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHQP11QXJENzYr45AQGLTwQAnZheg0W7qMbX4SuWExsFuVj9K4bVeBQ0 KV0B+xVY259TMRBU/U6seneQ9hY/xxsqBb+fKLBI99GRcT0+4bun21TprfBiPR2v bsH/ZK6g3v5pexY8NlOv1bl9FIa1EoytMOVAsJhBtW4hddFa+tcsQSRNAWN2yoXk u5cGLzUSIx4= =BY+c -----END PGP SIGNATURE-----

1 0

Re: Restrictions on Munitions _Imports_
by John Gilmore 17 Dec '03

17 Dec '03

Peter D. Junger--Case Western Reserve University Law School--said: > There is a United States Munitions List for imports that is > administered by the Treasury Department, but cryptographic devices and > software are not included on that list. I agree with Peter. I looked this up at one point. The government has considered trying to impose import controls on crypto, like they've considered every other option they could think of. The question is what it would buy them except more trouble from the public. NSA can't sustain a claim that it would help them, since they aren't supposed to be spying on Americans anyway. But in Clipper-II, NSA risks effective export controls to advance FBI wiretapping interests. Now that NSA is in fully naked in bed with the FBI, they could jointly claim some governmental interest in killing off domestic privacy. But that's what would land them in trouble with the public. I really think they would have done better to have just shut up about crypto and not pushed the issue. The more they tighten the screws, the more agitated and educated the public gets. For every Clipper chip that has sold to a non-governmental party, ten Cypherpunks or 'punk sympathyzers have risen up and started writing code, investigating, talking to their friends, publishing articles in the press, and filing lawsuits. Ten years ago it was pretty lonely to be a cryptographer. Most of us wouldn't be on this mailing list -- the list itself would probably not exist -- if the government had just quietly let the export criteria advance, year after year, and had let the quaint academics play with their toys. But they tried alternating between stonewalling us and forcing crap down our throats. The result has been that the public now *cares* about crypto policy. And the public will get what it wants, in the long run, no matter what the impact on the privileges of the current crop of bureaucrats. John

1 0

Comments on STT Spec Implementation Details
by Rick Johnson 17 Dec '03

17 Dec '03

Hi All - Last week our team published jointly with Visa the STT specification. Since then, we've received some comments that the wire formats and protocols section for STT have not been complete enough for developers to implement. We're very interested in feedback and specifics on this. We worked to keep _only_ the detail we felt required to implement STT -- the language is intentionally terse. However, it is in everyone's best interest that the STT spec is completely understood and implementable. We want your participation in this. We've set up an alias direct to our team to respond to your comments: stt(a)microsoft.com Non-technical flames direct to: Rick - aka - Rick Johnson rickj(a)microsoft.com

2 1

Re: Rethinking the utility of netnews "cancel" control messages
by Erik E. Fair 17 Dec '03

17 Dec '03

At 10:34 10/5/95, Rich Salz wrote: >I would like to put my corporate legal infrastructe on an internal secure >conferencing system. News (with crypto-signed articles) is ideal. >Without a "destroy all copies" concept I cannot do this. > /r$ This, presumably, is a lawyer, discovery, lawsuit thing, right? Erik

1 0

Re: Certificates, Attributes, Web of Trust
by tcmay＠got.net 17 Dec '03

17 Dec '03

I have often said "You are your key." That is, keys have priority over names, even True Names. The biometric True Name identity of a person holding a key is only _another attribute_ of the key. Maybe important, maybe not. It depends on the nature of the transaction. But I go further: a huge number of interesting applications of strong crypto have no connections at all with physical persons, let alone with True Names. Agents in computer transactions, applets fired across networks, agoric entities in computational ecologies, BlackNet sorts of markets, and on and on. The notion that a cryptographic key needs to be tied to a physical person is deeply flawed. The talk of certification authorities is OK, so long as the practice is _completely_ and "strongly" voluntary (*). (* I think maybe we need a term like "strongly voluntary," to parallel "strong crypto." A key escrow system which can have arbitrary escrow holders--company lawyers, grandmothers, computers in other buildings, etc.--is "strongly voluntary." A government-sanctioned program which authorizes, approves, regulates, and controls escrow holders is *not*. GAK is not strongly voluntary, even though it will be sold as a "voluntary" system.) --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

subjective names and MITM
by Wei Dai 17 Dec '03

17 Dec '03

Neither certification hiearchies nor the PGP web-of-trust are very useful because they try to bind True Names to keys and True Names have many problems. People can have duplicate names and can change their names (what happens if I legally change my name to Bill Clinton and try to get Verisign to certify my key under that name?), and often we don't care about someone's True Name. Perhaps it is better to think of names as subjective identifiers, and public keys as global ids. That is, a person who has a collection of public keys gives each of them a name, but different people can name their keys differently. Of course the holder of the corresponding private key can help in the naming process (e.g., "Please call me Wei"). If two people need to talk about a third party, they can refer to him by an arbitrary name after establishing a common binding between his key and that name. In this scheme, the man-in-the-middle problem goes away because you are no longer trying to communicate with a True Name, whose binding with a key can be spoofed, but rather with the key itself. If the holder of that key chooses to act as a middle-man by relaying messages around, that is his business, and there is really nothing you can do about it. Wei Dai

7 12