December 2003 - cypherpunks-legacy

Announcing SecureDrive 1.3A
by edgar＠spectrx.saigon.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is to announce the availability of Version 1.3A of SecureDrive. This is a maintenance release of SecureDrive 1.3. It mainly fixes reported problems and has minimal new function. See file BUGS13.DOC. The only visible functional change from 1.3 is the appearance of msg Check bytes in Disk x: Boot Sector need updating from 1.3 to 1.1/1.3A. Proceed? which will be issued by both LOGIN and CRYPTDSK when they attempt to verify a passphrase on a hard disk or diskette encrypted by version 1.3 CRYPTDSK operating in version 1.1 compatability mode. This corrects the error in computing the check bytes used to verify the passphrase and updates the check bytes to the correct 1.1 value and WRITES back the boot sector. Note that once this update has taken place, this disk cannot be decrypted by release 1.3 anymore. Releases 1.3 and 1.3A of Secure Drive are based on releases 1.0 and 1.1, mostly written by Mike Ingle <mikeingle(a)delphi.com> and version 1.2, with significant new code by myself. The code which we wrote is not copyrighted, but the program contains GNU Copylefted code, and therefore may be freely distributed under the terms of the GNU General Public Licence. See file COPYING for legalese. Version 1.2 and 1.3 add significant new function. As of Version 1.2, you may use an operand /PGP with LOGIN, either by itself, or with other operands. By itself, LOGIN /PGP will prompt for a passphrase and set the PGPPASS environment variable with whatever is entered. If PGPPASS is already set then LOGIN D: /PGP or LOGIN /F /PGP will use whatever PGPPASS is set to as the passphrase. For the hard disk partition, LOGIN will test the PGPPASS passphrase. If it is incorrect, then it will prompt you for another passphrase. If PGPPASS is NOT set when these forms of LOGIN are used, than a passphrase is prompted for AND PGPPASS is set to this passphrase. This is more secure than using the SET command since LOGIN only echoes "*"'s when entering the passphrase. As of Version 1.2, typing LOGIN /C /PGP will clear the SecureDrive crypto keys from memory AND clear the PGPPASS environment variable. This is done in a manner less likely to leave your passphrase in memory than just using the DOS SET command. In addition, Version 1.2 clears all the free memory it can find, which is likely to include some plaintext. However, if you want to be absolutely sure all traces of sensitive data are erased from memory then turning off the computer is still recommended. As of version 1.2, if PGPPASS is set before you run CRYPTDSK, CRYPTDSK will ask to use the value of PGPPASS for the passphrase before prompting you (for encryption), or try PGPPASS (for decryption). Obviously, if you encrypt or decrypt a lot of diskettes at once, this feature can save you a lot of typing. The purpose of these changes is to allow you to enter a single passphrase only once per boot IF you choose to use the same passphrase for your PGP secret key, your SecureDrive encrypted hard disk partition, and SecureDrive encrypted floppies. Version 1.3 supports up to four hard drive partitions in "safe" mode, only one of which may be active at any given time. One purpose of having multiple encrypted hard disk partitions is so that up to four users (perhaps members of a family) can each have their own encrypted partition with its own unique passphrase. This allows up to four users to have privacy from each other, even if they all use the same PC and physical hard disk(s). Version 1.3 gives you a choice of whether to use the version 1.1 passphrase digest or to use the (faster but perhaps slightly less secure) 1.0 version. If you select 1.0 compatiblity, it's unnecessary to decrypt and re-encrypt your 1.0-encrypted hard disk partition(s) and floppies. If you decide to switch to 1.1 passphrases, Version 1.3 CRYPTDSK will allow you to convert in one pass with no plaintext stored on disk. Version 1.3 includes the 1.2 changes for using PGPPASS. There are additional ehhancements to allow you to use the hard disk passphrase for the floppy disks without typing it in, even if PGPPASS is not set or is something different. Version 1.3 CRYPTDSK will operate on hard drives with SECTSR loaded. It uses SECTSR to protect the disk during conversion and will leave an encrypted disk partition in protected mode. Mike Ingle and I have different opinions on the distribution of SecureDrive. Under the GNU General License (copyleft) I do not need Mike's permission to distribute version 1.3 and I have not asked for same. My policy on distribution is in the version 1.3 doc: Exporting this program. Cryptography is export controlled, and sending this program outside the country may be illegal. Don't do it. The "author" of versions 1.2 and 1.3, Edgar Swank, says that the export ban should not prevent you from placing this program on public BBS's and anonymous FTP sites in the US and Canada. If individuals outside the US/Canada use the internet or international long distance to obtain copies of the program, THEY may be breaking US law. Any such foreign individuals should be aware that US law enforcement may legally (under US law) apprehend individuals who break US laws even if such individuals are not on or even have never been on US soil. Such apprehension may remove such individuals directly to US jurisdiction without benefit of extradition proceedings in such individuals' home country(ies). This has actually happened in at least two cases, Mexico -- suspect in murder of US drug agent, Panama -- Noriega -- indicted in absencia for drug smuggling. As is well known, after a small war with Panama, Noriega was brought to the USA, tried and convicted. He is now a guest of the US Government in a Florida prison. SecureDrive Version 1.3A is already available for download on the following public BBS's as SECDR13A.ZIP: Eagle's Nest (408)223-9821 Flying Dutchman (408)294-3065 Also I have a report (unverified so far) that Version 1.3 may now be obtained from a mailserver. Send mail to Server(a)Star.Hou.TX.US with body text that looks like this get /files/public/secdr13a.zip quit Please attempt to use the mailserver or the two BBS's above before requesting a copy directly from me. I will send a FEW more copies via E-mail to persons with a US/Canada net address who request a copy AND promise to upload it to a USA/Canada e-mail fileserver or anonymous FTP site. (I don't have access to FTP from my account here). I will announce here as I learn of Version 1.3A availability via additional automated e-mail or FTP sites. Here is the contents of SECDR13A.ZIP: Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- -------- ---- ---- 18321 DeflatX 6914 63% 06-14-93 22:27 0767480b --w- COPYING 1332 DeflatX 518 62% 01-30-94 09:30 bbb5655c --w- MAKEFILE 1632 DeflatX 1260 23% 12-04-93 00:43 980125ec --w- KEY.ASC 19664 DeflatX 4183 79% 11-19-93 21:42 22c2502c --w- CRYPT2.ASM 1355 DeflatX 629 54% 01-21-94 08:44 db63ade4 --w- RLDBIOS.ASM 24652 DeflatX 7740 69% 01-29-94 14:51 d0f5feaf --w- SECTSR.ASM 7507 DeflatX 2581 66% 12-29-93 21:15 ceda9b20 --w- SETENV.ASM 33 Stored 33 0% 07-16-93 06:09 aa6151a5 --w- M.BAT 16175 DeflatX 3949 76% 01-29-94 17:57 88215957 --w- CRYPTDSK.C 12260 DeflatX 3167 75% 01-29-94 18:27 7b10d96f --w- LOGIN.C 11557 DeflatX 3277 72% 05-09-93 19:38 e71f3eea --w- MD5.C 10860 DeflatX 2878 74% 01-29-94 18:07 3a9154c0 --w- SDCOMMON.C 1778 DeflatX 1160 35% 01-30-94 09:31 48688ff7 --w- SECTSR.COM 1152 DeflatX 586 50% 01-30-94 10:15 e44c593f --w- BUGS13.DOC 31425 DeflatX 10610 67% 01-30-94 09:59 235f457a --w- SECDRV.DOC 35024 DeflatX 16598 53% 01-30-94 09:31 99417b77 --w- CRYPTDSK.EXE 34072 DeflatX 16021 53% 01-30-94 09:31 26a2fb82 --w- LOGIN.EXE 3407 DeflatX 1097 68% 05-11-93 12:49 f1f58517 --w- MD5.H 3020 DeflatX 909 70% 01-24-94 03:32 8ee1c1f6 --w- SECDRV.H 1254 DeflatX 541 57% 05-09-93 19:39 182978aa --w- USUALS.H 152 Stored 152 0% 01-30-94 10:03 68a2560c --w- SECTSR.SIG 152 Stored 152 0% 01-30-94 10:04 a1d33655 --w- LOGIN.SIG 152 Stored 152 0% 01-30-94 10:04 845de45f --w- CRYPTDSK.SIG ------ ------ --- ------- 236936 85107 65% 23 Also note that the ZIP file contains PGP detached signatures (*.SIG) for the executable files. Finally here is my public key, also available on many public keyservers; note who has signed it. Type bits/keyID Date User ID pub 1024/87C0C7 1992/10/17 Edgar W. Swank <edgar(a)spectrx.saigon.com> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIF ECwAALo04ip/MkW/XQEBmNQD/0jUVqT0LMoVvw7Zz2FXyWrdBn6bRlyGxeqQWhig DXRipZ824/fHbA2vkbAczEayw8ZpwRVmhWNsxxWhjYFIi92KYJbAP/XIbr+rEuTI hPKKKKhuuGLUWhfXhCFluHjs3CA6ZQwnT4jnu1NlCkcnWLbL4ktqub2zLwrHCPUe 31L1iQCUAgUQK9Y50xgzoWUItwfFAQHPrAPzBbf6lQyzwbUwdxayzLDoh3Hygnun Looi+yzziEVQchOgSt3sLe2I108DLxTgp+26lJYTAZB+Gg8HGyB+Nz6263D0XlVU XQi9/7CSRyd8bhYFeuFPwFzHPWZlyLDAIsuaEfBsmp2DBLgffvhUCqiiWYmP9oa+ rOA+5IHS+xN8tIkAVQIFECu5dYOzvL/Jh3qmYQEBYDICAI5KdaTiPr2Y1OtRCTi6 xMG6hnRNalvK9C5d/bxrKnUYqsfSpKayX+Ts9psmq6a6doOrX3AAtgcZuTCYUfQk d22JAJUCBRArlzITocE4X0qvAOUBAahdA/4rRoSVp3G+Ki0wvkcAvpnwt7vSEYpH XSkyoC8LdAqs9bft5NDTOykgw5H1qFG1Doqk6oR0yxY0k91eVoBVclLWDb94sNO3 JjHJKO/QdODik5DpmXEnQhBfLlujuYkCtJjoBv1+QdImnnv9aNidGuLAneNvZ+UN NqfE3IRShzNw3IkAlQIFECtj5iw2VpfGMt2Y2QEBDEYD/2iMMml65eFaNWrNP7ab Yh8QW3+Mnjyl5CNpAjGkxejmIm4nZKqUHN5DuGzpJDnstRwbz6daXK15XcoM1m8g uhu6UzIwHs9+hbKE6inTCz4C0mE55PSmvF/ejjexnGzsiFpuFnjN/sRrSHc57flO IUWBCZD8Hizz3aYBxmvwJ863iQCVAgUQKxEXHOJ13g7/Z/cLAQGyYgP/apcv9V2M bHFgU0hl0D4MLqGjBReUfDroxQCsgsTb/0nr1W9yltBMqYPgD7ThLAf2rxIPNbGy D7VUA27LTwQTS6n2mbtkHOvGQVw7J2GwTA6319Gf0Qne0M1h7VJWjFX0Vzjuh/nk 6btxM2uTLSF2nUsDXe5/9N5XeesFhrbXNrM= =4fGE - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVFwE94nNf3ah8DHAQEkVQP/QzHZ0oqDW3XYrpYANTfeA7hIMgweKz8N 7/UpkV5XHhePwEfJA3fFn2Gs/BwF6Oy0xsJOk16AIE5JtAWqp5x3jzQ6BuJhkhhk RcVrmtqqBfj8PMnpm3rdQRUMC9CftxA/m06y3Cw5FHgxvrOXcZfyrsBIR26UejsI 4fOY+JjlglQ= =sBOp -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0

STEG: a real-life use for steganography
by hughes＠ah.com 17 Dec '03

17 Dec '03

I had an extremely interesting conversation with a fellow last night, say, X. A mutual friend of ours had steered him towards me. X has contacts in a country C which will remain nameless. The government of C is extremely repressive and has a large internal police force. The situation, evidently, is one similar to the old USSR, where masks behind masks were used in daily life, little is exactly as it appears, and the default discourse is sideways speaking. The scenario is almost worst-case. There is a need for steganography, since the use of cryptography is grounds for suppression; likewise there is a need for covert channels. There is a need for double-blinding of identities, since one's friends may be difficult to detect. And so on. The aspect that _is_ good is that C is not the whole world, and there are plenty of us not in C. The first most useful facility to set up, X thinks, is simply news from outside of C as a bypass of the media in C--wire service articles about C, for example, as well as a feed of the newsgroup "soc.culture.<C>". Here's the technique we came up with last night. C has an indigenous music M which is periodically performed in the United States. We were thinking about pressing short-run CD's of these live performances. We all know where the news feeds go. The CD's would be distributed via standard music channels and would be surprisingly brisk sellers. The costs of the project can evidently be footed by willing members of the M industry in C. Now let me address the standard comment "Oh, steganography completely solves that problem." Please. That's like saying, "Oh, just use an internal combustion engine to solve your long distance transport problems." Such statements are a failure of imagination and seriousness. A practical system to carry this project out is quite large. I see at least the following pieces needed: -- A facility to gather the data being put on the disks. This by itself is no trivial task, since it involves the collection of many disparate sources. -- An authoring system to arrange the data, once collected, into a usable structure. -- An encryption system for the arranged data. Such a system can't treat the data as one long stream, because of the segmented nature of the data. The ability to mount the CD as a file system would be good leverage for other programmers. -- A mastering system to combine a music master CD (done separately) and a data master (in some format) into a new music master CD. This will, at the least require a machine with a CD reader and writer. Blank media, FYI, for a CD writer are about $20/disk. The CD writer is about $5K. These numbers are approximate and falling rapidly. -- A CD pressing facility. These are commercially available at quite reasonable cost in quantities in the 100's. -- A CD distribution system. This will likely be the M industry, and thankfully the details of international shipping and customs will be taken care of, as well as retail distribution. -- A decryption system to get the data off the CD. -- Client software to make use of the information. It need not all be in text format. -- A key distribution system. A secret key per CD and word of mouth may be sufficient. A system to make rememberable sentences out of an arbitrary 128 bits (and the inverse) would be useful to facilitate word of mouth. This is no small task. Those interested in participating may start working on any of the above. The tasks are fairly separable. Here are some that I can identify as critical. -- A standard for encoding data into the low bits of an audio CD. This will likely require a lot of specific knowledge of the low level encoding and error correction systems used in CD's. I do know that they are not simple, being much more than bit-correcting linear codes. -- A standard for the encoding of file system data onto these low bits. This should be a separate document, even though the design of this will be influenced by the bit encoding standard. Some adaptation of existing file system standards may be appropriate. -- A standard for the encryption format for the file system. It may be that Matt Blaze's CFS cryptograpy can be lifted wholesale. -- Multiplatform software support for all of the above. I am pleased to have a real example to work on, rather than a lot of wixering about hypotheticals. I welcome discussion of this topic. Eric

5 4

Re: San Jose BBS subject to M
by freeman＠MasPar.COM 17 Dec '03

17 Dec '03

> Hmm... wish I had the exact original handy to mis-quote ... Is this the one you mean? First they came for the Communists, and I didn't speak up, because I wasn't a Communist. Then they came for the Jews, and I didn't speak up, because I wasn't a Jew. Then they came for the Catholics, and I didn't speak up, because I was a Protestant. Then they came for me, and by that time there was no one left to speak up for me. by Rev. Martin Niemoller, 1945.

1 0

UNSUB
by MCALVINK＠ccmail.sunysb.edu 17 Dec '03

17 Dec '03

UNSUBSCRIBE m calvinkoons

2 1

REMAILERS: Netcoms Policy and hazards to remailers
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

An issue arose today with Netcoms DASD migration... My Account was moved from /ux/accountname to /uxx/accountname, which caused my .forward file to begin bouncing mail. Netcoms sysadms promptly moved my .forward to .forard.bak to eliminate the bounces and notified me via the now working mail. During my conversation with the admin I asked specifically what Netcoms policy vis-a-vis ECPA, search warrants, and warrantless requests from Law enforcement of any kind for both e-mail in transit and stored files.. The answer was as it should be. A "proper" search arrant would be required prior to cooperation with LE. Netcom as a policy ill NOT provide ANY materials other than account name without a search warrant, unless an account on netcom is used to crack another site and netcom is liable( in which case they will file a complaint and give cooperation to investigating officers.) a warrant is required for release. The subject of remailer and crypto out of a netcom account didnt elicit any comment from the sysadmin...) Tomorrow I will call and ask specifically on that area... anon

1 0

Remailer Delays
by Brian Beker 17 Dec '03

17 Dec '03

The last two messages I've sent through remailers have taken upwards of two days to arrive at their destinations. Parallel messages sent directly arrived immediately. The two remailers are Hal's and rebma. What is making this happen? Is it related to all the recent PGP FAQ traffic? Which remailers if any are not suffering from these lags? THX, B

1 0

Followup: Notes on key escrow meeting with NSA
by Matt Blaze 17 Dec '03

17 Dec '03

Newsgroups: sci.crypt,talk.politics.crypto,comp.org.eff.talk,alt.privacy.clipper Subject: Re: Notes on key escrow meeting with NSA In a recent article, I wrote: >A group from NSA and FBI met the other day with a group of us at Bell >Labs to discuss the key escrow proposal. They were surprisingly >forthcoming and open to discussion and debate, and were willing to at >least listen to hard questions. They didn't object when asked if we >could summarize what we learned to the net. Incidentally, the people >at the meeting seemed to base a large part of their understanding of >public opinion on Usenet postings. Postings to sci.crypt and >talk.politics.crypto seem to actually have an influence on our >government. > >A number of things came out at the meeting that we didn't previously >know or that clarified previously released information. What follows >is a rough summary; needless to say, nothing here should be taken as >gospel, or representing the official positions of anybody. Also, >nothing here should be taken as an endorsement of key escrow, clipper, >or anything else by the authors; we're just reporting. These notes >are based on the collective memory of Steve Bellovin, Matt Blaze, Jack >Lacy, and Mike Reiter; there may be errors or misunderstandings. >Please forgive the rough style. Note also the use of "~ ~" for >'approximate quotes' (a marvelous Whit Diffie-ism). A couple of clarifications and new recollections. Same disclaimers as above. The NSA people were asked whether they would consider evaluating ciphers submitted by the private sector as opposed to simply proposing a new cipher as a "black box" as they did with Skipjack. They said they can't do this because, among other things, of the extraordinary effort required to properly test a new cipher. They said that it often takes from 8-12 years to design, evaluate and certify a new algorithm, and that Skipjack began development "~about 10 years ago.~" I asked if we should infer anything from that about the value of the (limited time and resource) civilian Skipjack review. They took that with good humor, but they did say that the civilian review was at least presented with and able to evaluate some of the results of NSA's previous internal reviews. Regarding the scale of the escrow exploitation system, they said that they did not yet have a final operational specification for the escrow protocols, but did say that the escrow agencies would be expected to deliver keys "~within about 2 hours~" and are aiming for "~close to real time.~" Initially, the FBI would have the decoder box, but eventually, depending on costs and demand, any law enforcement agency authorized to conduct wiretaps would be able to buy one. The two escrow agencies will be responsible for verifying the certification from and securely delivering the key halves to any such police department. As an aside, we've since been informed by a member of the civilian Skipjack review committee that the rationale for not having the escrow agency see the actual wiretap order is so that they do not have access to the mapping between key serial numbers and people/telephones. Also, on second reading, I wasn't at all clear about the reverse engineering resistance of the chips. I wrote: >...they are designed to resist reverse engineering the data in the >chip without destroying the chip. It is not clear (from the >information presented at the meeting) whether the chips are equally >resistant to destructive reverse-engineering to learn the skipjack >algorithm.... That is, the chips are designed to resist non-destructive reverse engineering to obtain the unit keys. They do not believe that it is possible to obtain the unit key of a particular chip without destroying the chip. They did not present any assertions about resistance to destructive reverse engineering, such that several chips can be taken apart and destroyed in the process, to learn the Skipjack algorithm. Finally, I should have made clear that "Clipper" is more properly called the "MYK-78T". -matt

1 0

Magic Money Digicash System
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Magic Money Digital Cash System Brought To You By Pr0duct Cypher Based on PGP Tools - The Crypto Construction Set Send to csn.org, should appear under /mpj somewhere Magic Money is a digital cash system designed for use over electronic mail. The system is online and untraceable. Online means that each transaction involves an exchange with a server, to prevent double-spending. Untraceable means that it is impossible for anyone to trace transactions, or to match a withdrawal with a deposit, or to match two coins in any way. The system consists of two modules, the server and the client. Magic Money uses the PGP ascii-armored message format for all communication between the server and client. All traffic is encrypted, and messages from the server to the client are signed. Untraceability is provided by a Chaum-style blind signature. Note that the blind signature is patented, as is RSA. Using it for experimental purposes only shouldn't get you in trouble. Digicash is represented by discrete coins, the denominations of which are chosen by the server operator. Coins are RSA-signed, with a different e/d pair for each denomination. The server does not store any money. All coins are stored by the client module. The server accepts old coins and blind- signs new coins, and checks off the old ones on a spent list. Suppose Alice wants to pay Bob some Magic Money. Alice uses her client module to extract some coins from her account (file). She then mails those coins to Bob, using a secure channel such as a PGP message. Bob runs his client module on the coins. The client module checks the signatures, and totals up the value of the coins. It then prompts Bob to choose the values of new coins which total the same value as the old ones. For example, Alice sends Bob a 64-unit coin. Bob chooses a 32-unit and two 16-unit coins. The client module then generates proto-coins, which are blinded but unsigned. It produces an output file containing Alice's coins, and the new proto-coins. Bob mails this to the server. The server counts up Alice's coins, checks their signatures, and checks for double-spending. It puts the coins on the cancelled list, signs the proto-coins, and mails them back to Bob. Bob runs his client module on the reply message. It unblinds the signed coins and adds them to his coin file. This completes the transfer. The Magic Money server is a filter, accepting input from stdin and sending output to stdout. To set up a server, you first compile the server program and install it in its own directory. Dump some random junk in a file called rand.dat. This and the system clock is hashed to generate random numbers. Then execute "s i" to initialize the server. It will prompt you for some information. For the denominations, I would use powers of 2 (1, 2, 4, 8, 16, 32, 64, 128...) because they minimize the number of coins needed to transfer any amount. The server will create a key and an e/d list. An ascii-armored copy of the server's public key is written to bank.asc. Users must have this key to use the server, so however you publicize your server, include the key. Set up the system so that, when a message comes in, the server is executed and the message (which need not be cleaned up first) is piped into stdin. The output from the server should be mailed back to the user. The server can be run through a remailer, if you don't want to reveal your location. This would be easiest through a penet-style remailer. Operating through a cypherpunks-style remailer would require an external mechanism to handle reply headers. However you do it, just see to it that messages go into the server and the output goes back to the right user. If you just want to experiment on one machine, put the server and client in different directories, to prevent their files from interfering with each other. Set up a shell script/batch file to feed the client's output into the server and return the server's reply. The server has the ability to include a message to the client. If the file msg.txt exists in the server's directory, it will be included in the server's replies, and the clients will display it. The client will wait for a keypress after displaying the message, so the last line should be "press any key to continue" or something similar. The message should not be longer than one screen, because there is no "more" in the client. The main use for the message is to warn users of expirations (see below), but you can send anything you want. To set up a client, compile the client module (unless the server operator was nice enough to provide a binary [hint]) and put it in its own directory. Put some random junk (for random numbers) into rand.dat, and put the server's ascii-armored key in bank.asc. Now execute "c -i" to initialize your client. It will create a key and generate "output.asc" which should be mailed to the server. When the reply comes back, save it in a file and run "c <file>". This will initialize your e-list and coin name files. If the server has a msg.txt, you will see it. Now get another user to send you some coins. Coins are binary, not ascii- armored, because we assume you will use a PGP message or other "envelope" to transport them. Execute "c <file>" to process your coins. The client will show the denominations as the signatures are checked. It will show the total, and allow you to choose denominations for the new coins you want to generate. Then it will generate a file "output.asc" which should be mailed to the server. Take the server's reply and run "c <file>" on it. It will extract and unblind the coins, displaying them as it does so. When it is done, you will have some coins to spend. To pay someone some coins, execute "c -p". The client will show a list of coins you have, and allow you to choose values to extract. These will be copied into "coins.dat", which you then mail to the person you want to pay. He does as above to deposit them. Do not lose "coins.dat" because the coins are removed from your file as they are extracted. Server maintenance and expirations: the server must keep track of all the coins which have ever been spent, at 16 bytes each. While the server uses an efficient hash file to maintain speed, the file will eventually grow to consume the entire filesystem of the host machine. There must be a way to clear it out eventually. The server operator executes "s n" to generate a new e/d list. The old list will be renamed. Old coins are still valid at this point. The server operator should put up a message warning users to exchange their old coins. The next time a user interacts with the server, his elist will be updated automatically, and the old one renamed. The user can (and should be warned to) execute "c -x" to automatically exchange all his old coins for new ones. After a reasonable time, and plenty of warning (!) the server operator executes "s d" to delete the old spent list, efile, and dfile. Old coins are now worthless. The next time a user interacts with the server, his old elist will be deleted automatically by his client. Old coins will now show up as having zero value, and a "c -x" will discard them as "expired coins". If the user was dumb enough not to exchange his coins, too bad. The server will only sign as much value as it receives, so the amount of money in circulation remains constant. We have a chicken-and-egg problem: how is value created? The server operator has the magical ability to create new coins from thin air. He executes "s m <x> <x> <x>" where x is the denomination of the coins he wants. The result is a coins.dat file, which can be mailed to a user and processed by his client module. The server just signs the coins directly, without any blinding. Coins are represented by RSA integers in the normal PGP-signature format. The coin is 16 bytes, padded in the same way that PGP 2.3a pads a signature. The coin is stored signed, that is, raised to the d power. There is no hashing involved; RSA is used directly. To blind a coin, the client generates a blinding factor, a large random number. The random number is raised to the appropriate e power, modulo the server's n. It is then multiplied with the unsigned coin, generating a blinded "proto-coin", which is sent to the server. The server signs the blinded coin by raising to the power d. This "decrypts" the blinding factor at the same time as it signs the coin, because RSA is multiplicative. Then the client divides out the blinding factor, leaving the signed coin. How big should the blinding factor be? I am not sure. Right now, it is set to the modulus minus one byte. This is certainly secure, but it takes a long time to unblind because mp_inv is a slow operation. If you know how long it needs to be, feel free to change it. Now, if you're still awake, comes the fun part: how do you introduce real value into your digicash system? How, for that matter, do you even get people to play with it? What makes gold valuable? It has some useful properties: it is a good conductor, is resistant to corrosion and chemicals, etc. But those have only recently become important. Why has gold been valuable for thousands of years? It's pretty, it's shiny, and most importantly, it is scarce. Digicash is pretty and shiny. People have been talking about it for years, but few have actually used it. You can make your cash more interesting by giving your server a provocative name. Running it through a remailer could give it an 'underground' feel, which would attract people. Your digicash should be scarce. Don't give it away in large quantities. Get some people to play with your server, passing coins back and forth. Have a contest - the first person who (breaks this code, answers this question, etc.) wins some digital money. Once people start getting interested, your digital money will be in demand. Make sure demand always exceeds supply. If some people get servers up and running, and if there is any interest, I can write an automatic client which will accept and pay out Magic Money without human intervention. Please let me know if you have an application for this, or any other ideas for the system. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVChQcGoFIWXVYodAQFDhAQAlOdUdnZZxarfxIbACZlHv+Hza+lLkaQl 2eMBro4Bu/QV6wjnTPfw4AND8HbsgdCYjsh7B6XBkpLqVqSk0/fBkwrb4jmvG/bD sU2ccYm2Da9qShHaYWSqApugVA+0bPc9LSHxpbbrAfXIkMQvYqKQMjde6VW4zecZ fZAtf6J/7TY= =N7Kb -----END PGP SIGNATURE-----

1 0

Re: remailer delays
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Brian Beker asked, "The last two messages I've sent through remailers have taken upwards of two days to arrive at their destinations. Parallel messages sent directly arrived immediately. The two remailers are Hal's and rebma. What is making this happen? Is it related to all the recent PGP FAQ traffic? Which remailers if any are not suffering from these lags?" I am not using remba at all, not even pinging it. The last three days have seen the "Bomb me!" request dwindle to about 5-6 a day. Hal's ("shell") is working without a glitch. That leaves remba. If I can get my list of remailer details completed, people like you with specific needs (today you want speed) will be happier. The fast remailers that I am using and have had NO problem with are: @remailers = ( "catalyst(a)netcom.com", "remailer(a)dis.org", "ebrandt(a)jarthur.claremont.edu", "remailer(a)merde.dis.org", "elee7h5(a)rosebud.ee.uh.edu", "hfinney(a)shell.portal.com", "hh(a)soda.berkeley.edu", "qwerty(a)netcom.com" ); These are not necessarily the most secure ones, but they are all pingable with variable 5 minute to 1 hour delays for the pings to come back. If speed is of concern, these are your remailers. cicada and pmantis are also quite fast but are not meant for what I need them for. I am very sensitive to kicking mailers off my list if I cause a problem, even once. The merde and dis.org remailers often add an hour delay, seeming to batch things out. jarthur is often ~10 minutes, but just as often an hour. - From my incomplete List: Remailer Fast? OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB -------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ---------- bsu-cs + ? ?/? + ? ? ? ? ? 23a ? catalyst + N? SM/MQ - - ? - PA M 23a - choas + ? ?/? + ? ? ? ? ? - - cicada ++ ? ?/? - - - - ? ? - - dis.org -/-- ? ?/? - ? ? ? ? ? 23a ? extropia +/? ? ?/? + ? ? ? Pr? ? 23a ? jarthur +/-- St SM/MQ? - ? ? ? Un ? 23a - menudo -- ? ?/? - t1 ? ? ? ? - ? merde -/-- ? ?/? - ? ? ? ? ? - ? penet.fi -- St ?/? - t? 24 + Pr H - - pmantis ++ ? ?/? - ? - - ? ? - - qwerty + C SM/MQ - - - - PA M 23a + rosebud ++/- ? ?/? - - - ? ? ? 23a ? remba ? ? ?/? ? ? ? ? ? ? 23a ? shell ++/+/- St ?/? - ? ? ? ? ? 23a - soda ++/- St+? ?/? - ? ? ? ? ? - Subj: Strips Subject header? NL: Non-linear remailing? 123->231. RD: Random delay added (max, in hours)? Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages. CPU: Pr = private. PA = account on public access machine. Un = university. Phys: Physical security of the CPU, especially at night. H/M/L. BitB: BitBucket feature? Fast?: ++ <5 min + 5-10 min. - ~10-30 min delay -- pinging isn't practical due to long delays +/- sometimes +, sometimes - Normal internet mail delays are common, and are not equivalent in the two directions between any two remailers. Mail still gets through. OpLog: F: full copies of all mail is archived. My large volume mailing should help put a stop to this. St: Stats logs of when mail was remailed. St+: Stats logs of when and where mail was remailed. St-: simple counter. N: operator keeps no logs. SysLog: SM: sendmail logs of when and where mail was exchanged. Root access. MQ: mailqueue accessible by anyone on the site. Could make logs. -Nik (Xenon) -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVJ3RwSzG6zrQn1RAQEfFQP/Rkt6bVBWCetn4YH/dm7LJ+EhAia+NXDy EutlgmKJKXPc2eh3pypVb0cxdlMr/dOidXrTY3LzCF4iHOc7/l1FNegkbrJltf9R +rOHyh23FDnQZE8NIxq9KLr++iUxMFsq8UfmNy+Z5ojMh2Nc+54CBSHoAMMEryPG oEOu5i3jK08= =nfRB -----END PGP SIGNATURE-----

2 1

Re: Magic Money Digicash System
by Hal 17 Dec '03

17 Dec '03

Wow! Hot stuff! I looked at csn.org, but I didn't find magic money. The pgp_tools has been there for a while, of course. Somebody post when they find it. Hats off to Pr0duct Cypher! Hal

1 0

Re: Prodigy snooping
by Mike Ingle 17 Dec '03

17 Dec '03

>I heard from a friend that Prodigy was scanning user's hard drives. >Basically, when you logged on Prodigy made a complete directory of your >hard drive and uploaded it. Prodigy was using this to find out what >applications you used so they could direct the appropriate advertising >towards you. Apparently, they're suffering several lawsuits now because >of it. This tale has been around for a while. Prodigy makes a huge file, over 1 MB, on your hard drive and stores information there to speed up the data transfer. People started finding bits of their files in there. They claimed that Prodigy was snooping into their systems. Prodigy denied it and claimed that their software just didn't bother to clear the disk space when it allocated it, so whatever was there, stayed there until the space was used. They distributed a utility which would zero out that information. Whether they were really snooping or not, who knows? If they were, they were pretty stupid to leave clear text in the file. >My friend heard this on the trailing end of a radio talk show. If it was >really happening, it sounds horrible. Could Secure Drive be set up to >stop this kind of attack? Secure Drive would stop it if you weren't logged into the encrypted drive when you ran Prodigy. Of course, if you were logged in and they knew about Secure Drive, they could get your encryption key as well as your data... --- Mike

1 0

request for information
by dave_taffs＠rainbow.mentorg.com 17 Dec '03

17 Dec '03

I saw the following on imp-interest, and thought somebody here might be interested in responding (perhaps?)... PS: She has David Chaum's internet address by now, I'm certain... to: imp-interest(a)thumper.bellcore.com from: owner-imp-interest(a)thumper.bellcore.com date: Fri, 4 Feb 1994 10:29:56 -0500 (EST) subj: Digicash story/Internet Letter sender: jayne levin <helen(a)access.digex.net> sent: 02/04/1994 8:33 am (PDT) --------- **| I would like to explore the issue of digital cash in my next issue of The Internet Letter. I am trying to contact David Chaum but don't have his e-mail address, so I'd appreciate any help in making contact with him. I'd also like to get a grip on some of the issues involved in developing digital cash as well as the status of work in this area. Who else should I talk to? Jayne Jayne Levin Net Week Inc. Editor 220 National Press Building The Internet Letter Washington, D.C. 20045 USA +1 202 638 6020 Fax: +1 202 638 6019

1 0

interagency_workgroup.notice (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Re: Running regularly
by mbriceno＠netcom.com 17 Dec '03

17 Dec '03

Xenon askend: >> Before I start throwing out ideas that I'm sure aren't new to readers here, >> I have a simple question that perhaps I should post to comp.unix.questions >> or comp.lang.perl, but.... Can I, and how would I, get a perl script to >> kick in and send out mail every few minutes when I am NOT logged in. Is this >> possible on Netcom? Hal answered: >Most public Unix systems will not let you do this, in my experience. >The two Unix commands which usually give you the ability to run programs >at regular intervals are "at" and "crontab". You can read the man pages >and try running these to see if they are enabled for you. Netcom has a "policy against detached processes because of the load they put on the system and therfore 'crontab' and 'at' disabled for all users.(Netcom support)" To make your life even harder they kill all your processes upon hangup. Here is (half) the workaround: They forgot to disable "sleep" and they also didn't disable "nohup." You can simply write a script that sleeps for 30 min, executes your program and goes back to sleep. Call it with "nohup script &" and you're in business. The next problem that must be addressed is the auto-logout upon >14min of inactivity on the modem level that Netcom imposes on you. There is a simple 2 line command that you can add to your .login file to disable the auto-logout. I saw it once posted in one of the Netcom newsgroups, but I lost it. Perhaps you might post the question there. I would not advise to ask Netcom support for it... Some of the messages responding to the above post talked about "supending the account for intentionally disabling, blah, blah" 8-) Good luck, -- Marc Briceno <mbriceno(a)netcom.com> PGP public key by finger

1 0

reno_key_escrow.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

gore_crypto.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

harris.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

clipper_q-and-a.txt (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

wh_press_secy.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

doj_escrow_intercept.procedures (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

4 4

Re: STEG: a real-life use for steganography
by fnerd＠smds.com 17 Dec '03

17 Dec '03

Eric talks about a hypothetical system S which he discussed with real acquaintance X of country C (with repressive government G), for stegging information I in through exogenously-produced CDs of indigenous music M. One problem is that S is proposed for use by lots of people in C. That means the whole system won't be a secret for long. Soon G will know not only which records and which equipment to ban, but also the passphrases for the records--so why encrypt or even camoflage it? Maybe making copies of existing popular records would help. Classics that lots of people already have. Are there already records produced for C but manufactured outside of C? Do they import music popular outside C? > -- A facility to gather the data being put on the disks. This by > itself is no trivial task, since it involves the collection of many > disparate sources. Maybe the newsgroup you mention is just the thing for the second-to- last step in the chain. It can combine efforts of people who don't have to know each other. > -- An encryption system for the arranged data. Such a system can't > treat the data as one long stream, because of the segmented nature of > the data. There's also the problem of recovering from errors on the CD. > The ability to mount the CD as a file system would be good > leverage for other programmers. > -- A decryption system to get the data off the CD. Can most CR ROM drives read the raw music format? Many? If not, can the bit stream to the ADC in a CD player be intercepted? Maybe the best hardware from a physical camoflage standpoint would be those little CDROM drives that double as "walkmen". > A system to make rememberable sentences out of an > arbitrary 128 bits (and the inverse) would be useful to facilitate > word of mouth. Isn't it good enough to always start with sentences invented by people and encode into bits? > encoding and error correction systems used in CD's. I do know that > they are not simple, being much more than bit-correcting linear codes. I think when they're not giving you exactly what you put in, they're doing desparate things like repeating the last few milliseconds. So about all you can do is put CRCs and IDs on blocks (maybe small blocks?) and be able to deal with lost and misplaced blocks. It might be useful to have signatures on block boundaries so you could recognize them out of continuous streams. Maybe you would just take two blocks worth of data and slide your buffer along one byte at a time till you got a good CRC...but by then you would have received a lot more data. Better have a long buffer. > -- A standard for the encoding of file system data onto these low > bits. This should be a separate document, even though the design of > this will be influenced by the bit encoding standard. Some adaptation > of existing file system standards may be appropriate. Here, too, you need to deal with lost blocks. Having one copy of the root of the index might not be great. Also, assuming you're using modified CD players instead of CDROM drives, you might want to take advantage of the music track structure. -fnerd quote me - - skip sweet sweetbacks badass skipjack song, jack. 3x, fast. -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

1 0

For Pr0duct Cypher: faster mp_inv
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Pr0duct Cypher wrote: > How big should the blinding factor be? I am not sure. Right now, it is set > to the modulus minus one byte. This is certainly secure, but it takes a > long time to unblind because mp_inv is a slow operation. If you know how > long it needs to be, feel free to change it. PGP's mp_inv is needlessly slow. It works OK for the little numbers they normally use ("e" exponents) but bogs down for big numbers. Fortunately I wrote a fast version of mp_inv some time ago just for this application (blinding). You might say it is "blindingly" fast! Here it is, from my private copy of pgp source. With this you can choose anything for your blinding. You will probably want to change it to use your safemalloc. #ifdef OLD_MPINV /* Replaced by a faster routine, below */ void mp_inv(unitptr x,unitptr a,unitptr n) /* Euclid's algorithm extended to compute multiplicative inverse. Computes x such that a*x mod n = 1, where 0<a<n */ { /* The variable u is unnecessary for the algorithm, but is included in comments for mathematical clarity. */ short i; unit y[MAX_UNIT_PRECISION], temp[MAX_UNIT_PRECISION]; unit gcopies[3][MAX_UNIT_PRECISION], vcopies[3][MAX_UNIT_PRECISION]; #define g(i) ( &(gcopies[i][0]) ) #define v(i) ( &(vcopies[i][0]) ) /* unit ucopies[3][MAX_UNIT_PRECISION]; */ /* #define u(i) ( &(ucopies[i][0]) ) */ mp_move(g(0),n); mp_move(g(1),a); /* mp_init(u(0),1); mp_init(u(1),0); */ mp_init(v(0),0); mp_init(v(1),1); i=1; while (testne(g(i),0)) { /* we know that at this point, g(i) = u(i)*n + v(i)*a */ mp_udiv( g(iplus1), y, g(iminus1), g(i) ); mp_mult(temp,y,v(i)); mp_move(v(iplus1),v(iminus1)); mp_sub(v(iplus1),temp); /* mp_mult(temp,y,u(i)); mp_move(u(iplus1),u(iminus1)); mp_sub(u(iplus1),temp); */ i = iplus1; } mp_move(x,v(iminus1)); if (mp_tstminus(x)) mp_add(x,n); mp_burn(g(iminus1)); /* burn the evidence on the stack...*/ mp_burn(g(iplus1)); mp_burn(v(0)); mp_burn(v(1)); mp_burn(v(2)); mp_burn(y); mp_burn(temp); #undef g #undef v } /* mp_inv */ #else /* OLD_MPINV */ /* Faster mp_inv, based on "Fast Multiplicative Inverse in Modular * Arithmetic", J. Gordon, in Cryptography and Coding, edited by * Henry J. Beker and F.C. Piper, 1989. * The mapping from the variables in that paper to our variables is, * roughly, M->n, X->a, HCF->u(iminus1), U->u(i), temp->u(iplus1), * INV->v(iminus1), V->v(i), temp->v(iplus1). We rotate the assignment to temp * and INV in their 2nd block of code. */ void mp_inv(unitptr x,unitptr a,unitptr n) /* Euclid's algorithm extended to compute multiplicative inverse. Computes x such that a*x mod n = 1, where 0<a<n */ { /* The variable u is unnecessary for the algorithm, but is included in comments for mathematical clarity. */ int shifts; int i = 1; int enterloop; unit vcopies[3][MAX_UNIT_PRECISION], ucopies[3][MAX_UNIT_PRECISION]; #define u(i) ( &(ucopies[i][0]) ) #define v(i) ( &(vcopies[i][0]) ) /* Modify this to do one division at the beginning. That makes it faster. mp_move(u(0),n); mp_move(u(1),a); mp_init(v(0),0); mp_init(v(1),1); mp_init(v(2),1); */ mp_move(u(0),a); mp_init(v(0),1); /* Init U to n%a, V to -n/a. */ mp_udiv(u(1), v(1), n, a); mp_neg(v(1)); mp_move(v(2),v(1)); do { enterloop = 0; shifts = -1; if (mp_compare(u(i),u(iminus1)) > 0) /* if U > HCF then */ mp_init(u(iplus1),0); else { enterloop = 1; mp_move(u(iplus1),u(i)); /* temp := U */ while (mp_compare(u(iplus1),u(iminus1)) <= 0) { /* temp<=HCF */ ++shifts; mp_shift_left(u(iplus1)); /* leftshift(temp,1) */ } mp_shift_right_bits(u(iplus1),1); /* rightshift(temp,1) */ } mp_sub(u(iminus1),u(iplus1)); /* temp := HCF - temp */ mp_move(u(iplus1),u(iminus1)); i = iplus1; /* V := tempV, tempV := INV, INV := V, */ /* U := tempU, tempU := HCF, HCF := U; */ /* (All simultaneous) */ if (enterloop) { while (shifts--) mp_shift_left(v(i)); /* leftshift(V,shifts) */ mp_sub(v(iplus1),v(i)); /* temp = temp - V */ } mp_move(v(i),v(iplus1)); /* V := temp */ } while (testne(u(i),0) && mp_compare(u(i),u(iminus1))!=0); mp_move(x,v(iminus1)); if (mp_tstminus(x)) mp_add(x,n); mp_burn(u(0)); /* burn the evidence on the stack...*/ mp_burn(u(1)); mp_burn(u(2)); mp_burn(v(0)); mp_burn(v(1)); mp_burn(v(2)); #undef u #undef v } /* mp_inv */ #endif /* OLD_MPINV */ -----BEGIN PGP SIGNATURE----- Version: 2.1e iQCVAgUBLVLeoArkCJ6S8691AQH9/QP+LRZ4oXiwNTUkpK7/4uJWhvJCLHPsCNsR YXruZCgY1448DRpbNV4PCtFg/GhDqvJpsWtWOy3lFZIO9zxrDb/tsIfruIJJZr0w lpWhhY+xUJNQYuqgu69EOY2IhJPiyZ+AyMuE4uYscuxEKmAEdLm/BAypX1zNplue NdURpM+pPw4= =f7BH -----END PGP SIGNATURE-----

1 0

Re: Running regularly
by Matthew Bernardini 17 Dec '03

17 Dec '03

> Matthew Bernardini <matthew(a)gandalf.rutgers.edu> wrote: > > > Why not make two shell scripts, one that sleeps for so long (say 20 minutes) > > using the unix sleep command, and then calls the remailer scripts in an > > infinite while loop. This would work if you set it up as a background > > process,and you don't need to be root for it to work. Only downsides are > > that when the machine crashes you have to log back in and restart script, > > your sleep command will always be in the top window if your sys-admin > > is watching, and you have to be careful not to spawn to many processes and > > bring the system down. > > I tried this on the system here, but it killed off the process when I > logged off. > > As for starting too many processes, just don't start them... leave it > as one single process that just repeats itself indefinently with sleeps > in between. > Did the processes get killed BECAUSE you logged off ? Or did they get killed because you left a single process runnning in the background for an extended period of time and an automated script killed the job. Why not ask the sysadmin how to setup a long computational job for a couple of days ? I don't think any sysadmin would have a problem with that. Then you could find out if the jobs are killed automatically somehow. If it turns out that it was just the process that was automatically killed on a time interval, then you could easily write a script that would spawn a new process and then kill the parent. Matt

2 1

clipper_q-and-a.txt
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

Q. Who will hold the escrowed keys? A. The government.

1 0

wh_press_secy.statement
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

The following is a self contradictory statement, if considered to apply for the time period of the next 20 years as the govenment's policy, and it down right PISSES ME OFF. Fuck you, government. >The Administration believes that the steps being announced today >will help provide Americans with the telecommunications security >they need without compromising the capability of law enforcement >agencies and national intelligence agencies. Today, any American can >purchase and use any type of encryption product. The >Administration does not intend to change that policy. Nor do we have >any intention of restrictiog domestic encryption or mandating the use >of a particular technology.

1 0