December 2003 - cypherpunks-legacy

Re: Error Condition Re: UNSCRIBING
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Responding to msg by lharrison(a)mhv.net ("Lynne L. Harrison") on Wed, 14 Feb 10:12 AM >>An MIT student, no doubt hoping to enhance the >>reputation of his school, wrote: >> >>>> Who the fuck are you? .......As for your ending remarks I don't give >>>>a fuck what Judge Ito, Tim May or any other person has to say. > > The best thing is to annoy the message. UNSCRIBE >messages hit the c|punks list every so often. Rest >assured that the MIT student knows very well how to >unsubscribe - and how to spell. Yeah, place your bet that Tim writes these trolls and answers them, pumping the conversation, fostering coy controversies. Smart guy, bores easily, likes to lure the rubes, he says. Toy with them, spout outrageous remarks, act indiginant when they are challenged, feign hurt, let suckers defend him. Sometimes mimics Rimm, may impersonate him, too, or coach Marty, who knows? He's got lots of Net personas, seldom non grata. He's a vintage infotainer, California dreaming, an export techno-wine of the region. Avid Rube

1 0

Re: anonymous age credentials, sharing of
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:38 PM 2/14/96, Michael Froomkin wrote: >Suppose Alice is a CA who issues anonymous age credentials. >Bob is 15 >Carol is 25 > >Carol gets a legitimate anonymous age credential from Alice bound to an >anonymous public key generated for this purpose. Carol then gives the >key pair to Bob. Bob uses to do things only adults are legally permitted >to do. (It's not bound to Carol's everday keypair because that's not >anonymous....) > >What can stop Bob and Carol from subverting a scheme that relies on >anonymous age creditials in this manner? Nothing, except biometric methods (fingerprints, retinal scans, electronic signatures (the pen type), DNA, etc.) That is, if the credential is transferrable by transfer (not a syllogism), then it can be transferred. If, however, the credential needs some input from a local biometric input device, then this makes it harder to transfer the credential. Unless the biometric device is bypassed.... (Likewise, Carol could log on to the illegal activity and "let Bob watch." Another form of bypassing viewing credentials.) >If the answer is "nothing" this might mean that purveyors of "adult" >material might have no defense against a law requiring that they collect a >True Name + age creditential.... There are interesting questions here....mostly I think of the "True Name" as only another credential, but this is a complicated argument to make, and I don't have the time right now. (Also, Perry is even now composing a "what does this have to do with cryptography?" perrygram.) --Tim May Boycott espionage-enabled software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

A brief comparison of email encryption protocols
by Raph Levien 17 Dec '03

17 Dec '03

This message briefly reviews and compares the four major email encryption protocols under discussion: MOSS, PGP, PGP/MIME, and S/MIME. Each is capable of adequate security, but also suffers from the lack of good implementation, in the context of transparent email encryption. I will try to address issues of underlying cryptographic soundness, ease of integration with email, implementation issues, support for multimedia and Web datatypes, and backwards compatibility. An additional grave concern is key management. Contrary to some beliefs, key management is not a solved problem. All of the proposals contain some mechanism for key management, but none of them have been demonstrated to be scalable to an Internet-wide email system. My belief is that the problems with key management do not stem from the classic Web of trust/certification hierarchy split, but the nonexistence of a distributed database (with nice interfaces) for holding keys. The encryption protocols also stand in the way of such a database, with key formats that are either overly complex, inadequate, or both. In case it is not clear by now, this review will be quite subjective, in many cases representing my own beliefs rather than objective fact. I'll try to point that out where I can. Also, I do not claim to have a thorough understanding of PEM and PKCS. Much of my knowledge comes from implementing premail, a tool that acts as "glue" between mailers and encryption packages. It supports PGP, MOSS (using the TIS/MOSS 7.1 implementation), and a draft of PGP/MIME, in addition to a wide range of anonymous remailer services. While usable, premail has many limitations, and certainly does not represent the "holy grail" of transparent email/crypto integration. Thus, my participation in the Internet Mail Consortium Secuirty Workshop (http://www.imc.org/security-workshop.html) I apologize for the wide distribution, and ask that followups be trimmed. PGP --- PGP (Pretty Good Privacy) is, of course, the de facto standard for email encryption on the Internet. PGP's underlying cryptography is quite sound - RSA (up to 2048 bits with the most recent implementation), IDEA with a 128 bit key, and MD5. PGP is entirely in accordance with the recent recommendations on minimum keylength (http://www.bsa.org/bsa/cryptologists.html) and in fact does not include a mode of operation in violation of those recommendations. This makes PGP (and, by extension, PGP/MIME) unique among the encryption protocols. PGP is packaged in a single application (i.e. a single binary) which performs encryption, decryption, signing, verification, and key management. It does not depend on the existence of great deal of infrastructure. These factors have, in my opinion, been decisive in PGP's popularity. However, PGP is still not suitable for fully transparent email encryption. The reasons are complex, and I will only touch on them here. The main missing feature is the lack of MIME integration. Thus, PGP is not suitable for multimedia types other than US-ASCII text. PGP does contain some support for 8-bit charsets, but at cross-purposes with MIME. Signature checking of non-US-ASCII data is simply not reliable. To give an idea of this problem, the most recent international version (2.6.3i) tries several different character set conversions when verifying signatures, to see if any of them will work. However, since a large fraction of email _is_ US-ASCII text, this feature alone probably does not explain the lack of deployment. PGP contains a number of implementation flaws (including silly things like not locking files, so that concurrent invocations fail). In addition, key management has some problems. Mostly, key management is hard to learn, time consuming, and requires a great deal of manual intervention. The "Web of trust" is supposed to fix this, by providing transitive trust of key authenticity. However, in practice the Web of trust has not delivered. In my experience (with many dozen correspondents), I have only had one or two keys transitively trusted. A standard PGP-signed message consists of a "-----BEGIN PGP SIGNED MESSAGE-----" line, the signed text (subject to some canonicalization rules), a "----BEGIN PGP SIGNATURE-----" line, a version line, the PGP signature itself, and an "-----END PGP SIGNATURE-----" line. All this is in the message body. The headers indicate that the message is a standard 7-bit, us-ascii, text/plain message. Thus, mailers have to parse the message contents to identify the message as PGP signed, or to extract the signed parts. This is at cross-purposes with MIME. Mailer implementors are reluctant to include such ad-hoc extensions. Existing extensibility mechanisms, based on MIME, cannot be used. PGP encrypted messages are similar - the identification as an encrypted message can only be made by parsing the message body. One technical problem with PGP is its inability to support single-pass processing, because the data format includes a size field. PGP/MIME -------- PGP/MIME is an effort to integrate MIME and PGP. There is a workable draft based on the MIME security multiparts, but the PGP/MIME mailing list is divided. Some particpants are happy with the existing draft, while others feel that other points in the design space (for the most part, labelling existing PGP message formats with appropriate MIME types) would be better. The design space is large and complex, with many constraints on efficiency, simplicity, backwards compatibility, and functionality. It is not clear that a consensus will develop at all. There are two implementations of the PGP/MIME draft: premail, and the PGPMIME reference implementation by Michael Elkins. For more information about the PGP/MIME draft, see http://www.c2.org/~raph/pgpmime.html . PGP 3.0 ------- Many people are hoping that PGP 3.0 will somehow come along and solve all their problems. PGP 3.0 is only an evolutionary improvement over the existing implementations (MIT PGP 2.6.2 and PGP 2.6.3i). For the most part, it will support only the existing message formats. There may be support for decoding draft PGP/MIME signed messages, but this is still being negotiated. The main advance in PGP 3.0 is a cleaned up implemenation. The PGP 2.6.2 code is disgusting, and should not be integrated directly into any mailer application. The 3.0 code will be modular and based on published interfaces. Furthermore, the 3.0 development team plans to release the code as both a stand-alone application and as a library. It is difficult to predict when the public release will happen. Based on what I've seen, fall of 1996 seems the most likely. MOSS ---- MOSS (MIME Object Security Services) is an attempt at an email encryption protocol in accordance with MIME. It is currently an Internet RFC. There is a reference implementation (TIS/MOSS 7.1). MOSS is mostly cryptographically sound. However, the choice of symmetric encryption algorithm (and key size) is left unspecified. Thus, it cannot be said that MOSS is in accordance with the recommendations for minimum keysize. In fact, the only public implementation, TIS/MOSS 7.1, uses 56-bit DES, which is in direct violation of these standards. The TIS/MOSS implementation has a number of other problems. It is big and complex, probably due to its TIS/PEM ancestry. For more information about TIS/MOSS, see http://www.tis.com/docs/Products/tismoss.html . MOSS supports two modes of key management: X.509, and completely manual key management. In this way, it is a dramatic advance over PEM, which only supported X.509, but life for implementors remains hard. One feature which I believe is sorely lacking is a cryptographic hash of the public key as the basic unit of manual key management. Thus, people either have to trust the mechanism by which the key was delivered, or examine the base-64 representation of the entire key. I consider this to be a serious usability problem. For an example of how hashes of keys have been done right, see Netscape 2.0's handling of untrusted certificates. S/MIME ------ S/MIME is an attempt to graft MIME support onto underlying PEM standards. See http://www.rsa.com/rsa/S-MIME/ for more info. I feel compelled to deal harshly with RSA's S/MIME FAQ (http://www.rsa.com/rsa/S-MIME/smimeqa.htm) It suggests that MOSS has interoperability problems because of multiple implementations, while S/MIME presumably doesn't. I take strong exception to this statement. There is no technical basis for it. I consider the possibility of admitting multiple implementations as a _requirement_ for an Internet email standard. However, because S/MIME is documented, it hopefully will be possible to create independent implementations, in spite of what RSA says. The only symmetric encryption algorithm mandated by S/MIME is 40-bit RC2. Thus, S/MIME is in violation of the key size recommendations. Further, RC2 has not been confirmed to be publicly known. If RC2 is not known, then an independent implementation of S/MIME is impossible. Fortunately, source code for an alleged implementation of RC2 has recently been posted to the Internet, resolving this problem, if it is authentic. If not, then my reservations remain. S/MIME also recommends 56-bit DES CBC and (either 112 or 168 bit) DES EDE3-CBC. This is good; any S/MIME implementation in accordance with the recommendations will conform to the keysize recommendations as well. S/MIME remains firmly grounded in the X.509 certification hierarchy, although the FAQ claims that the guidelines for hierarchies are "more flexible" than in PEM. One cryptographic weakness of S/MIME is that eavesdroppers can distinguish between encrypted and signed-and-encrypted messages. This violates the principle of disclosing a minimum amount of information. PGP, PGP/MIME, and MOSS do not have this problem. Probably the most controversial aspect of S/MIME is its signature format. An S/MIME signed message is a MIME multipart in which the first part is the data to be signed, and the second part is a complete PKCS #7 (section 10) signed message. This protects quite well against munging by mail transport, but has two problems. First, the size of the message is doubled. Second, the fact that the two singed messages are identical is not enforced (if it were, mailer munging would cause too many signatures to fail). Thus, Eve can send Alice and Bob a message (M1, (M2, Signature(M2))). Alice, not having an S/MIME implementation, would see only M1. Bob, having an S/MIME implementation, would see only M2, for which the signature would check. Alice, being suspicious, might call Bob up on the telephone and ask whether the signature was really valid. Bob would of course say yes. Unless they compared notes on the contents, they would not notice the discrepancy. To my mind, this counts as protocol failure, and thus it is not possible to claim that S/MIME conforms to best cryptographic practice. I would expect that doubling the message body will create performance problems in a Web environment. For example, if the first message is used for display, then it becomes necessary to compare the two messages. If, instead, the second message is used, then the first message will be responsible for significant added latency. Integration with mailers ------------------------ Integration with mailers is quite difficult. In general, the mailer implementor will need to add specific features to support cryptography. Because of the restrictiveness of ITAR regulations, such an approach may not be practical for US developers, at least while supporting strong cryptography. Perhaps the biggest feature required in the mailer is integration of key management and the "address book". If this feature is not implemented in the mailer, then two address books are required - one to select email addresses, and another to map email addresses to keys. This approach is used by premail, and is the source of many usability problems. It would be nice if a database existed which could map email addresses to public keys without manual intervention, but none of the proposals on the table are capable of it. Such a database would certainly improve usability, as well as making it considerably easier to Another feature that is required for fully transparent integration is caching of decrypted session keys. If not implemented, then the user interface delays in navigating a mail folder become unacceptable. To my knowledge, no implementation supports this feature. One dimension in the design space is whether the cryptographic engine is tightly integrated with the mailer (i.e. shares an address space), or is a separate process that communicates with the mailer. Both approaches have been implemented. Both approaches are subject to numerous pitfalls, which have unfortunately not been entirely avoided. These issues have more to do with implementation than with the encryption protocol, but I thought I'd mention them here, so that they are not actively thwarted. Conclusion ---------- All of the proposals described here can be used for secure email. None of them will be widely deployed in this capacity unless they are implemented well. I have concerns that both MOSS and S/MIME are susceptible to political pressure which will restrict key sizes insecurely in practice. I would like to see consensus develop around one of the proposals, so that energies used for implementation can be more focussed and effective. It is my hope that this conference will move in that direction. Raph Levien

2 1

New discussion group "CDA96-L" = COMMUNICATIONS DECENCY ACT of 1996 (fwd)
by Robert A. Hayden 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Tue, 13 Feb 96 22:49 PST From: Gary Klein (bear-at-heart) <gklein(a)willamette.edu> To: Neil Radford <N.Radford(a)library.usyd.edu.au> Subject: New discussion group "CDA96-L" = COMMUNICATIONS DECENCY ACT of 1996 In light of the recent furor over the airwaves, in the media, and in lawsuits regarding the COMMUNICATIONS DECENCY ACT of 1996 that United States' President Clinton signed into law on February 8, 1996, I have created a forum for people to discuss the concerns raised by this (and similar) pieces of legislation. LISTNAME: CDA96-L FULL TITLE: Communications Decency Act of 1996 Discussion Group FORMAT: Un-moderated, Postings must come from registered subscribers SUBSCRIPTIONS: via LISTPROC software LISTOWNER: Gary M. Klein <gklein(a)willamette.edu> Management & Business Economics Librarian Hatfield Library Willamette University Salem, Oregon 97301 USA DESCRIPTION: CDA96-L is open to the networkng community. Its primary role is to serve as a means of communication among people who are concerned about the implications of the United States of America's COMMUNICATIONS DECENCY ACT of 1996 (signed into law by President William J. Clinton on February 8, 1996). Its secondary role is to serve as a discussion forum for similar legislation or regulation that may be in the formative or final stages in any other country, or at any local jurisdiction that would restrict, limit or inhibit use of Internet resources based on "decency", "morality", "offensiveness", or based on the age of someone using, operating, or accessing an Internet resource. SUBSCRIBING TO THE "CDA96-L" LIST: Anyone may subscribe to the list by sending a <sub cda96-l your name> command to <listproc(a)willamette.edu> For example, if Idi Amin wanted to subscribe, the post would be: mailto: listproc(a)willamette.edu text: sub cda96-l Idi Amin OTHER LISTPROC COMMANDS: Will be supplied to each subscriber as part of the Welcome Message. (please feel free to cross-post this announcement in appropriate places) GARY M. KLEIN "not your average librarian & indecent communicator" Hatfield Library / Willamette University / Salem, Oregon 97301 USA work 503-370-6743 / gklein(a)willamette.edu

1 0

Re: The Internet Party
by Deranged Mutant 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Brian D Williams wrote: [..] > <bright idea!>Looks pretty dim to me. > Say, why not pick our own candidate? > Why not form our own Party? > The Internet party........ > It would be the ultimate write in campaign. > Now all we need is a candidate who stands for free speech, personal > privacy and the right to encrypt.......Just as bad as people who vote for ONE issue like abortion or civil rights or NAFTA/GATT and ignore everything else. These are important issues, but they aren't the only ones. And any support from netters will fall after arguing about everything else. ...and the sad thing is you might well shoot yourself in the foot for voting against somebody over one or two issues. I know people who'd vote for anybody but Clinton. They babble about Clinton being a "socialist" <chuckle> so much that they'd end up voting for a National Socialist <not funny either...!> > "I nominate John Perry Barlow. Who will second the nomination?"I nominate Frank Zappa. The music's better and dead presidents don't cost as much to maintain. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMSKSfyoZzwIn1bdtAQEr7gF/enFcC7CX8islsCHJ9BHdWa3SAvmvxlZh Nd39qds0s0D5gjRcEoKTu9wiHCmIOqaU =aKJh -----END PGP SIGNATURE-----

1 0

Re: Regulation of citizen-alien communications
by tien＠well.sf.ca.us 17 Dec '03

17 Dec '03

Resident aliens, as well as U.S. persons, have First Amendment rights. Second, we have a right to speak to foreign audiences. Independently of the First Amendment, there is an equal protection issue whenever you discriminate against aliens. There's case law on these points which I won't bother to cite. Lee

1 0

Common Carrier Status is Often a Red Herring
by tcmay＠got.net 17 Dec '03

17 Dec '03

[I picked a new thread title. Speaking of which, YACM (Yet Another Cyberspace Magazine) is out: "Herring," or "Red Herring," or "Pickled Herring." I only glanced at it long enough to see that it had the obligatory interview with cyberspace guru Marc Andreesen, the obligatory cover photo of Steve Jobs, and the obligatory other techno-rave articles. Probably several mentions of PGP, but I didn't bother to look for them. Needless to say, I put it back on the shelf before being too heavily contaminated.] At 7:48 PM 2/14/96, Declan B. McCullagh wrote: >Since you don't understand the way Federal criminal charges work, >there's no reason I should take your argument seriously. (Hint: The >*U.S. Attorney*, or an AUSA, files charges, not you, me, or a random >"athiest.") > >As for this mythical Bible being removed, that is irrelevant to this >discussion, which centers around a Bible being *prosecuted*. If I had a >Bible on my web site (perhaps the TCM Vernacular Translation!) I'd >remove it just to make a point. As I suspect the owner of the web pages >did. By the way, this is one reason why the "try to be like a common carrier" arguments are somewhat weak. Let me explain. I hear often on this list and in other places that Web sites and other Net sites should strive to be as much like common carriers as possible, that removing any items or discouraging controversial material (Zundelsites, militia sites, Sarin formulas, antifeminista material, etc.) will weaken their defense in a legal case. Well, I don't buy it. Maybe in the abstract, and in the long run, it has worked out that common carrier status involves non-intervention. However, in the real world it is _real prosecutors_ who decide who to go after. Real prosecutors who are ordered to prosecute a CDA case are not going to go after clean-living ISPs who happened to let one questionable item through, they're going to go after the rough trade, just as Declan suggests. Now, in the real world, does anybody think that "The Christian Fellowship Internet Service Provider," which has taken numerous steps to limit access to indecent material, is *more likely* to be prosecuted by federal prosecutors than "Buck Satan's Anything Goes Web Site"? (Hint: "Common carrier" status is not something that gets handed out to some Internet providers and not others. Second hint: so far as I have heard, there has not yet been any determination as to whether some ISPs are "common carriers" and others are not.) The realpolitik of it is that an ISP which tries to limit access by minors, which discourages Zundelsite material, and which makes soothing comments about Jess Helms and the Christian Right will of course be *far less likely* to be prosecuted under whatever CDA charges come up as some leftist, anarchist, radical ISP which takes a hands-off approach. Sad, but true. This is also known in legal circles as "the chilling effect." [ObPerry: "What does this have to do with the IPv6 domestic distibution?" ObAnswer: "Nothing. Since you're so concerned about people coding, go back to coding."] ---Tim May Boycott espionage-enabled software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

[ASSASSINATION NOISE] Re: V-chips, CC, and Motorcycle Helmets
by Bill Stewart 17 Dec '03

17 Dec '03

At 11:36 AM 2/13/96 -0800, you wrote: >The Rushdie incident is simply so far removed from "Assassination Politics" >that it can't possibly be used to refute it; I still believe it actually >demonstrates how much effort somebody has to go to, to protect a targeted >person. One targeted person is easy to protect. 10,000 would be FAR >harder. And the moment a few of those guys got "whacked," the rest would >want to resign their jobs and hope they would be allowed to retire in peace. Rushdie is just low on your target list. I agree that it's much harder to protect 10,000 people (say the Iranians put out a contract on Baha'is and other heretics, at $X/head...) but it's still abusable. Maybe the Anonymous Captains of Industry put out a contract on strike leaders. >From a cypherpunks perspective, yes you could run an assassination lottery, though it might be hard for the assassin to collect - how do you prove that _you_ were the hit man, and not merely the nearest person to a phone after it happened? How do you prevent an anonymous escrow agency from refusing to deliver the cash? Some of the protocols may be difficult to work out. Meanwhile WANTED, DEAD OR ALIVE JIM BELL REWARD 13 demo-cyberbucks An assassination-sponsoring society is _not_ a polite society. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

Hey Derek: who are you? (toad.com is glitching...)
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

Would the author of this message please reply to me by e-mail? I received it under the name <owner-cypherpunks(a)toad.com>, with no subject whatsoever. The remailer is freakin' out... >The other question I have is: who do you think the "customers" of PGP >are? If you think the majority of PGP's customers are the >crypto-privacy activitst types, you are highly mistaken. PGP has hit >the main stream, and is being used by many non-crypto-aware people. >Probably more of them than there are of us. > >If you want to discuss this more, let's take it to private email, >please. > >-derek > > **** NEW PGP 2.6.2 KEY ********* 2048 bits Key ID:24201BA1 1996/02/13 Jean-Francois Avon <jf_avon(a)citenet.net> Key fingerprint = 23 B6 24 31 86 67 FB 35 C7 A7 AF 12 A1 61 E9 3D **** OLD KEY: DO NOT USE ANYMORE UNLESS FOR VERIFYING SIGNATURES **** 1024 bits Key ID:57214AED 1995/10/04 Jean-Francois Avon <jf_avon(a)citenet.net> Key fingerprint = 84 96 76 AE EB 7C AB 15 88 47 87 B0 18 31 74 9F

1 0

[NOISE] Re: The Internet Party
by Bill Stewart 17 Dec '03

17 Dec '03

At 01:01 PM 2/14/96 -0800, Brian D Williams <talon57(a)well.com> wrote: >If I see one more ad for some dumb ass >politician running for president I'm going to puke. ><bright idea!> >Say, why not pick our own candidate? >Why not form our own Party? >The Internet party........ Because there's way too little for us to agree on outside of Internet issues; it's like forming the Pro- or Anti- Abortion Party, or the Womens' Party or whatever. >It would be the ultimate write in campaign. >Now all we need is a candidate who stands for free speech, personal >privacy and the right to encrypt....... >"I nominate John Perry Barlow. Who will second the nomination?" For a write-in candidate, you don't _need_ a second. Just put it in your .signature file and see what happens. On the other hand, John's a Republican, and they desparately need _somebody_ as a candidate :-) #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281 ! Frank Zappa for President !

1 0