December 2003 - cypherpunks-legacy

Re: some technical steganography
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Eric Hughes wrote: > > >What does "appears relatively random" really mean? How do you > >measure the randomness of a sequence of bits? > > Randomness is the wrong measure. Suppose I take 2^10 > random bits and prepend 16 zeros. How random is this? > Almost as random, and this can be made precise. How > compressible is it? Almost incompressible. Now, what > about 2^20 bit? 2^30? > > It is not randomness but recognizability which is at issue. > One of my assumptions was that the stuff you're trying to hide is not recognizable. In one of my posts I used the phrase "unremarkable encrypted message". I should have said "unrecognizable encrypted message". I assert that an "unrecognizable encrypted message" will be a random sequence of bits. Is my assertion correct? Should I be using the phrase "high entropy" instead of "random"? Assume for the moment that there is a way to produce an unrecognizable encrypted message using public-key encryption. (I leave it to the experts to figure out the best way do that.) I still believe that if the reverse stego process frequently produces high entropy bit sequences, even if there is no hidden message, then the steganography system is successful. If the reverse stego process *always* produces a high entropy bit sequence, then the steganography system is perfect. Of course, this assumes there is no other way to detect a hidden message besides reversing the stego process and testing the result. Obviously, if the forward stego process (inserting the bits) leaves telltale traces, then it doesn't matter what the reverse stego process produces. To summrise, I believe a successful steganography system will include the following steps and have the following properties: step 1) encrypt you plaintext. step 2) hide the encrypted message in a public message (duh) property 1) the result of the encryption step should be a random sequence of bits. property 2) the bit insertion process must not leave telltale traces. property 3) the reverse stego process should product frequent "false hits". In other words, the reverse stego process should frequently produce high entropy bit sequences, even if there is no hidden message. Am I correct? Jim_Miller(a)suite.com

2 1

Stealth PGP
by Hal 17 Dec '03

17 Dec '03

I never saw the posting below here, only on sci.crypt. It seems relevant to the present discussion. I did take a look at the source code to stealth pgp; it is quite simple and nicely done. However it doesn't do anything special about disguising the encrypted session key. It just strips off the two length bytes PGP puts at the front. Not only is this revealing, it also doesn't always work. Apparently the program can't always reconstruct the original mpi length if the encrypted key's size happens to be much less than the modulus. It does print a warning in that case that the file won't be able to be de-stealth'd successfully. Stealth PGP is a nice start but it needs to be improved to be truly stealthy. > >From: qwerty(a)netcom.com (-=Xenon=-) > >Subject: Stealth for PGP Available. > >Message-ID: <qwertyCLpztC.4n8(a)netcom.com> > >Organization: PGP Info Clearinghouse. > >Date: Thu, 24 Feb 1994 08:34:24 GMT > >Lines: 188 > > -----BEGIN PGP SIGNED MESSAGE----- > > I have placed Stealth1.0 up for anonymous ftp at netcom.com in > /pub/qwerty as stealth.tar.Z. I am not the author of Stealth. "Henry > Hastur" is the author. I will gladly forward mail to him if you tell me to > do so. My address is qwerty(a)netcom.com. So far it is only written for > Unix, so don't e-mail me asking for a DOS version or whatever. I'm just a > cheerleader and propagandist, who finally got some very kind soul to > "write me a real encryptor". > > Why Stealth? Wired magazine just gave a plug for the Mac program "Stego" > (ftp to sumex-aim.stanford.edu in /info-mac/cmp) by Romana Machado, which > will, like any steganograph, hide a message in a carrier message. Problem > is, anybody can reverse it, and if you are using PGP, immediately tell > you are one of those drug dealing, child molesting, cryptography users ;-). > Once Stealth is incorporated into such steganographs, then people can't > easily tell that what they've extracted out of that picture of Madonna is > even a message at all. If they don't have the right secret key to decrypt > it, then all they get is garbage. "What message?!" > > Questions: > > 1) What does Stealth have to do with farming? > 2) How do stealth encryptors make the Clipper chip look like a stupid > waste of YOUR tax money? > > [Answers: 1) Zip, 2) By demonstrating that even if the Clipper keys are > stolen, without your secret key they can't even tell you are using PGP]. > > -=Xenon=- > > Stealth V1.0 by Henry Hastur > ---------------------------- > > Stealth is a simple filter for PGP which strips off all identifying header > information to leave only the encrypted data in a format suitable for > steganographic use. That is, the data can be hidden in images, audio > files, text files, CAD files, and/or any other file type that may contain > random data, then sent to another person who can retrieve the data from > the file, attach headers, and PGP decrypt it. > > Stealth is not intended to replace the standardized methods of using > encryption (e.g. ASCII-armoured PGP email) ; in an ideal world we would > all be able to send openly encrypted mail or files to each other with no > fear of reprisals, however there are often cases when this is not possible, > either because the local government does not approve of encrypted > communication, or perhaps because you are working for a company that > does not allow encrypted email but doesn't care about Mandelbrot > GIFs. This is where Stealth and steganography can come into play. > > > Compiling > - - --------- > > Stealth has currently only been tested on BSD and SVR4 Unix (and as > such should work with most varieties of Unix), with both non-ANSI > compilers and ANSI compilers with 'minimal ANSI' flags. In order to > compile the program, you should just be able to extract the files > from the tar file provided, then type 'make'. If that fails you may > need to change the definition of CC and CFLAGS in the makefile to > get it to compile. On machines with gcc, the GNU C compiler, Stealth > can be compiled by simply changing the 'CC=cc' line in makefile to > 'CC=gcc'. > > Stealth has not yet been tested on MS-DOS, but the only likely problems > are with 16-bit integers (you may need to change some occurrences of > int to long in order to get stealth to work), and you will need to > remove the -DUNIX flag from compilations. Hopefully, version 1.1 > will be released shortly with full DOS compatibility. > > > Usage > - - ----- > > Stealth always reads from its standard input and writes to the standard > output, though when adding headers to data the data has to be stored in a > temporary file (see Security Concerns below). > > Command line arguments : > > -c Conventional encryption used rather than public key > -a Add headers (defaults to strip headers) > -v Verbose output. > > Stealth needs to be able to find your pubring.pgp file, which it does > by first checking in the directory pointed to by $PGPPATH, then the > current directory. > > > Examples > - - -------- > > To encrypt a file with PGP and store it in the file pgp.stl prior to > sending : > > pgp -ef < secrets.dat | stealth > pgp.stl > > To encrypt a file with conventional (IDEA) encryption, and pass to a > steganography program called steg_program : > > pgp -fec < secrets.dat | stealth -c | steg_program > > To take the output from a steganographic extraction tool, add headers > for key "Your Id", and decrypt : > > steg_program | stealth -a "Your Id" | pgp -f > secrets.dat > > To take the conventionally encrypted output from a steg program, attach > headers and decrypt : > > steg_program | stealth -ac | pgp -f > secrets.dat > > > Limitations > - - ----------- > > Files can be signed, but can only be encrypted to one recipient - extra > RSA headers for all but the first recipient will be stripped from the > file. In addition, if you specify conventional encryption but pass an > RSA-encrypted file into the filter the RSA-block will be stripped. In > either case, stealth will print out warnings to inform you of this. > > Stealth provides no support for ASCII-armoured PGP messages - it will > only work with the binary output format, and the output will have to > be converted to a useable form after processing, either with a > steganography program or a standard utility such as uuencode. > > Finally, for technical reasons there are potential problems with public > keys of size (typically) 2^n + 1 or 2^n + 2 (e.g. 513 or 1026). If you > are encrypting to a key of a peculiar size, it's possible that the algorithm > used to add headers could fail, but fortunately this can be detected while > stripping the headers, and a warning will be printed. If this warning > appears, > you will probably want to encrypt the data again until a suitably sized > RSA-block is created. > > It is NOT neccesary to remove garbage data that the steganography program > may have added to the end of the PGP-encrypted data. PGP output contains > an encrypted end-of-file mark that allows the program to decrypt correctly > and ignore any trailing garbage. > > > Security Concerns > - - ----------------- > > After passing through the stealth filter, the PGP-encrypted data is > essentially white noise, with no identifying marks, and whilst it may > well have enough peculiarities for an expert cryptanalyst to recognize > it as encrypted data, the probability is much less than would be the > case with a PGP header identifying the recipient attached. > > One other concern is that stealth has to create a temporary file when > reading in data to attach headers, and depending on the build options > chosen the program will store it in either $PGPPATH, the current directory > or /tmp. On Unix machines, the file will be deleted as soon as it is opened, > making it difficult to capture, but on other operating systems the file > will only be deleted when it has been used. (In either case the file will > be zeroed before being closed). > > In addition, some operating systems will use temporary files on your disk > to emulate unix pipes (e.g. MS-DOS) - these files will not be zeroed when > finished with ! > > > Export Restrictions > - - ------------------- > > Stealth is probably not covered by current export restrictions under the > US ITAR regs, but I'm not a lawyer, so if in doubt check it out yourself. > It was written outside the US and imported, so should soon be available > on some European ftp sites as well as US sites. > > > Henry Hastur > > > > > -----BEGIN PGP SIGNATURE----- > Version: 2.3 > > iQCVAgUBLWwfawSzG6zrQn1RAQEjlQP/d85opZ6aMXfFpDu/KQz0DAzFxXNjiSZy > 9l56kIUkmAx0aT5qF3UAg2UTDagiJlFNz6UXFhEKBkDV4JLJPq5C8HtsdpCiSLWr > vVD2IEdASEd9ALCQMLS/YxVv6GG85n+phyoEV5ALsD1f0y4Nbk2Gfb+rexk5rN3a > hFYRUekVuNY= > =pkdK > -----END PGP SIGNATURE-----

2 1

No Subject
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Everyone's talking about encrypted telnet. Has anyone at least READ the Kerberos FAQ? It's been in use for a while, and, to quote... > Kerberos is a network authentication system for use on physically > insecure networks, based on the key distribution model presented by > Needham and Schroeder.[3] It allows entities communicating over > networks to prove their identity to each other while preventing > eavsdropping or replay attacks. It also provides for data stream > integrity (detection of modification) and secrecy (preventing > unauthorized reading) using cryptography systems such as DES. > Practically speaking, Kerberos is mostly used in application-level > protocols (ISO model level 7), such as TELNET or FTP, to provide user > to host security. It is also used, though less frequently, as the > implicit authentication system of data stream (such as SOCK_STREAM) or > RPC mechanisms (ISO model level 6). It could also be used at a lower > level for host to host security, in protocols like IP, UDP, or TCP Being more 'official' than PGP, only a totally export-safe version has got out to ftp.funet.fi. Of course, it could be possible to patch PGP or something else into Bones, as the non-encrypting Kerberos is called. > An experimental Telnet Authentication Option has been > defined, and is described in RFC1416. (see also RFC1411). > These RFC's only define how > /authentication/ is to be performed; the standard for full encryption > is still under development. > An implementation of Kerberos V4 telnet is available via anonymous ftp > from ftp.uu.net, in /networking/telnet.91.03.25.tar.Z, but it predates > The IETF Common Authentication Technology Working Group is > currently defining security extensions for the FTP protocol. An > Internet Draft describing their work, and the source code for a > modified ftp/ftpd with the extensions, are now available > thumper.bellcore.com:pub/lunt/ftp.tar.Z > net-dist.mit.edu:tytso/ftp-wg/ftp.tar.Z ----------------------------------------------------------------------- Rishab Aiyer Ghosh "What is civilisation rishab(a)doe.ernet.in, rishab(a)dxm.ernet.in but a ribonucleic Voicemail +91 11 3760335; Vox/Fax/Data 6853410 hangover?" H-34C Saket New Delhi 110017 INDIA -----------------------------------------------------------------------

1 0

No Subject
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

sdw(a)meaddata.com (Stephen Williams): > on pictures with few colors and a large amount of a small number of > colors (like cartoons, etc. with a backround), you could use the > unused color table entries. You set these to be the same colors as > the correspondingly largest used colors and use them when juxtaposed > with their color. This, and other similar methods will of course only work with GIFs; the problem is that GIFs compress, and the loss of compression caused by adding to the color table could be noticed, as could the fact that there are multiple entries with the same value. It's also somewhat more complicated for stego users to figure out where the data is - unless you use a 'standard' header or format, which is as known to the NSA as to cypherpunks. What worries me more about many stego methods is their assumption that 'stegging' a picture will not be noticed. I am not so sure, even if you stick to the LSB of an 8-bit blue channel of a 24-bit hi-res scan. Things like the abnormal frequency of 1s as mentioned earlier, are almost as easy to build into your stego program as to detect. I've worked a lot with images, particularly image recognition, and have seen many surprising similarities among pictures of some category that are human-noticable only after considerable statistical analysis (or filtering through sophisticated neural networks). It may well be possible to develop highly CPU-intensive techniques that can detect, or indicate suspicion towards, 'stegged' images. Unless, of course, equally complex stego techniques are developed, which will probably have the extremely low message-to-image ratio of the old 'letter to granny' codes. (Message in third letter of alternate words, etc., in innocuous, plausible letter.) This whole cat and mouse game with the authorities reminds me of the reaction I had to the story in Wired 2.02 on the Stealth watchers. OK, intrepid renegades take zoom-lens photos and listen in to secret frequencies, but only because US authorities don't REALLY mind. Come on, if Big Brother were really serious, Phil Zimmerman (and most of us on this list) would have been shot long ago, democracy be damned. As it so happens, PEOPLE still vote, not SPIES.

1 0

Re: Update on user-level hack to do telnet encryption posted recently
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

> OK folks, I've started tidying up that hack code I posted recently which > outlined a method for rolling your own telnet-style encryption. I really think this project is a serious mistake. People should, if they insist, produce software compatible with the draft RFCs on telnet encryption and authentication -- although such code has already been written. The notion of putting in all this effort just to avoid having to deal with your system administrator, especially when he should be happy to install such code given the recent rash of internet breakins, seems misplaced to me. Perry, I'm no longer interested in what you have to say. You've been a wet blanket and have pooh-poohed every practical suggestion I've ever seen anyone making - weren't you one of the first people to post to the netphone project telling us we were all wasting our time? Cypherpunks write code, except when asked not to by Perry Metzger. The point of this code, in case you missed it, is so that people can take responsibility for their own encryption and not have to trust software installed by someone else, just like we all use pgp rather than Clipper. Now, if you don't have anything useful to contribute, shut up and stop trying to discourage those who do. G

3 4

Re: Update on user-level hack to do telnet encryption posted recently
by Graham Toal 17 Dec '03

17 Dec '03

As for this current "idea", with an implementation of an encrypted STANDARD telnet already written and likely available soon for anonymous FTP, I think I'm being sane, not "a wet blanket". You can already get a version of the Cray telnet that implements the authentication code and hack in a reimplementation of the encryption code if you wish. See below for that. However, producing silly non-standard telnet hacks makes little sense. Perry, I *already* have the bsd4.4 Kerberized telnet with DES that comes with the BSDI distribution (original code in the US, a re-implementation on supplementary floppies in the UK) - I've had it for half a year now, and you know what? - it's of no use to me at all. Not *one* of the dozen odd sites I telnet to is running it. Maybe in several years time we'll all be running the same encrypted telnet, but for now I want *something* to keep the nosey little kids from reading my packets and if I have to ftp a short source and compile it every time I log in somewhere then that's what I'll do. I bet my telnet sessions are secure a lot sooner than yours are. The degree of that security depends to some extent on how much help I get implementing a stream cypher because I'm not sure I trust myself to do it properly. So I would really appreciate if you don't think this project is worthwhile, that you simply don't contribute rather than going out of your way to encourage others not to as well. G

2 1

Update on user-level hack to do telnet encryption posted recently
by hughes＠ah.com 17 Dec '03

17 Dec '03

Perry doesn't like Graham's hack for telnet style encryption. Graham doesn't like Perry's attitude. Such a _small_ teapot. For the forseeable future, there will be the need for link encryption where one is connecting to a site where the far end doesn't have encrypted telnet available, _for_whatever_reason_at_all. There are lots of reasons, e.g. site managers are busy and the user did not plan in advance. It doesn't really matter. If you can't alter the remote end except by a user process, that's what you use. Perry is absolutely correct that this hack is very bad as a long-term solution, but it is labelled a hack, after all. Nevertheless, there is need for a short term solution. Graham seems to have provided one part of that. Great. Just because you shouldn't need to be using it in two years is no reason to say it shouldn't be written. Eric

3 2

Re: Stealth PGP
by Matthew J Ghio 17 Dec '03

17 Dec '03

There are actually several clever ways that you can get around the problem with the RSA encrypted data being less than the modulus. The simplest is to encrypt it more than once. Suppose you have a modulus m of legnth n. You then create a block of data to encrypt, b, of legnth n. If b is less than m, encrypt it with RSA. If not, don't encrypt it. Then take 2^n-b-1 (which, btw, is the same as xoring b with all one-bits). If that result is less than m, encrypt it with RSA. Since m is greater than half of 2^n (it must be, otherwise it would be less than legnth n), all possible plaintexts will be encrypted at least once with RSA, some twice. This does leave a somewhat uneven distribution of values when comparing plaintext and ciphertext (which can be minimized by more encryptions), but that only shows up when and if the message is decrypted; as long as you use random padding properly before encrypting, the encrypted data will look completely random. My ideal "Stealth-PGP" would work something like this: Take a file, encrypt it with a random session key, prepend the session key to the file, encrypt the first n bytes (which include the session key and part of the encrypted data) with RSA if it's less than m, XOR it (reverse all bits), and then encrypt with RSA if that's less than m. Actually, putting the data inside the RSA might not be a good idea, it would not work well for small files unless you added a legnth byte. Maybe the RSA part could just be filled with random padding...

1 0

Time Article on Clipper
by Dave Banisar 17 Dec '03

17 Dec '03

Time Magazine June 7, 1994 TECHNOLOGY WHO SHOULD KEEP THE KEYS? The U.S. government wants the power to tap into every phone, fax and computer transmission BY PHILIP ELMER-DEWITT Until quite recently, cryptography -- the science of making and breaking secret codes -- was, well, secret. In the U.S. the field was dominated by the National Security Agency, a government outfit so clandestine that the U.S. for many years denied its existence. The NSA, which gathers intelligence for national security purposes by eavesdropping on overseas phone calls and cables, did everything in its power to make sure nobody had a code that it couldn't break. It kept tight reins on the ''keys'' used to translate coded text into plain text, prohibiting the export of secret codes under U.S. munitions laws and ensuring that the encryption scheme used by business -- the so-called Digital Encryption Standard -- was weak enough that NSA supercomputers could cut through it like butter. But the past few years have not been kind to the NSA. Not only has its cover been blown, but so has its monopoly on encryption technology. As computers -- the engines of modern cryptography -- have proliferated, so have ever more powerful encryption algorithms. Telephones that offered nearly airtight privacy protection began to appear on the market, and in January U.S. computermakers said they were ready to adopt a new encryption standard so robust that even the NSA couldn't crack it. Thus the stage was set for one of the most bizarre technology-policy battles ever waged: the Clipper Chip war. Lined up on one side are the three- letter cloak-and-dagger agencies -- the NSA, the CIA and the FBI -- and key policymakers in the Clinton Administration (who are taking a surprisingly hard line on the encryption issue). Opposing them is an equally unlikely coalition of computer firms, civil libertarians, conservative columnists and a strange breed of cryptoanarchists who call themselves the cypherpunks. At the center is the Clipper Chip, a semiconductor device that the NSA developed and wants installed in every telephone, computer modem and fax machine. The chip combines a powerful encryption algorithm with a ''back door'' -- the cryptographic equivalent of the master key that opens schoolchildren's padlocks when they forget their combinations. A ''secure'' phone equipped with the chip could, with proper authorization, be cracked by the government. Law-enforcement agencies say they need this capability to keep tabs on drug runners, terrorists and spies. Critics denounce the Clipper -- and a bill before Congress that would require phone companies to make it easy to tap the new digital phones -- as Big Brotherly tools that will strip citizens of whatever privacy they still have in the computer age. In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it. The battle lines were first drawn last April, when the Administration unveiled the Clipper plan and invited public comment. For nine months opponents railed against the scheme's many flaws: criminals wouldn't use phones equipped with the government's chip; foreign customers wouldn't buy communications gear for which the U.S. held the keys; the system for giving investigators access to the back-door master codes was open to abuse; there was no guarantee that some clever hacker wouldn't steal the keys. But in the end the Administration ignored the advice. In early February, after computer- industry leaders had made it clear that they wanted to adopt their own encryption standard, the Administration announced that it was putting the NSA plan into effect. Government agencies will phase in use of Clipper technology for all unclassified communications. Commercial use of the chip will be voluntary -- for now. It was tantamount to a declaration of war, not just to a small group of crypto-activists but to all citizens who value their privacy, as well as to telecommunications firms that sell their products abroad. Foreign customers won't want equipment that U.S. spies can tap into, particularly since powerful, uncompromised encryption is available overseas. ''Industry is unanimous on this,'' says Jim Burger, a lobbyist for Apple Computer, one of two dozen companies and trade groups opposing the Clipper. A petition circulated on the Internet electronic network by Computer Professionals for Social Responsibility gathered 45,000 signatures, and some activists are planning to boycott companies that use the chips and thus, in effect, hand over their encryption keys to the government. ''You can have my encryption algorithm,'' said John Perry Barlow, co-founder of the Electronic Frontier Foundation, ''when you pry my cold dead fingers from my private key.'' The seeds of the present conflict were planted nearly 20 years ago, when a young M.I.T. student named Whitfield Diffie set out to plug the glaring loophole in all traditional encryption schemes: their reliance on a single password or key to encode and decode messages. Ultimately the privacy of coded messages is a function of how carefully the secret decoder keys are kept. But people exchanging messages using conventional coding schemes must also find a way to exchange the key, which immediately makes it vulnerable to interception. The problem is compounded when encryption is employed on a vast scale and lists of keys are kept in a central registry. Diffie's solution was to give everybody two keys -- one that could be widely distributed or even published in a book, and a private key known only to the user. For obscure mathematical reasons, a message encoded with either key could be decoded with the other. If you send a message scrambled with someone's public key, it can be turned back into plain text only with that person's private key. The Diffie public-key encryption system could solve one of the big problems facing companies that want to do business on the emerging information highway: how to collect the cash. On a computer or telephone network, it's not easy to verify that the person whose name is on a credit card is the one who is using it to buy a new stereo system -- which is one of the reasons catalog sales are rife with fraud. But if an order confirmation encoded with someone's public key can be decoded by his or her private key -- and only his or her private key -- that confirmation becomes like an unforgeable digital signature. However, public-key encryption created a headache for the NSA by giving ordinary citizens -- and savvy criminals -- a way to exchange coded messages that could not be easily cracked. That headache became a nightmare in 1991, when a cypherpunk programmer named Phil Zimmermann combined public-key encryption with some conventional algorithms in a piece of software he called PGP -- pretty good privacy -- and proceeded to give it away, free of charge, on the Internet. Rather than outlaw PGP and other such programs, a policy that would probably be unconstitutional, the Administration is taking a marketing approach. By using its purchasing power to lower the cost of Clipper technology, and by vigilantly enforcing restrictions against overseas sales of competing encryption systems, the government is trying to make it difficult for any alternative schemes to become widespread. If Clipper manages to establish itself as a market standard -- if, for example, it is built into almost every telephone, modem and fax machine sold -- people who buy a nonstandard system might find themselves with an untappable phone but no one to call. That's still a big if. Zimmermann is already working on a version of PGP for voice communications that could compete directly with Clipper, and if it finds a market, similar products are sure to follow. ''The crypto genie is out of the bottle,'' says Steven Levy, who is writing a book about encryption. If that's true, even the nsa may not have the power to put it back. Reported by David S. Jackson/San Francisco and Suneel Ratan/Washington Copyright 1994 Time Inc. All rights reserved. Transmitted: 94-03-06 13:04:08 EST

1 0

Re: Time Article on Clipper
by Dave Banisar 17 Dec '03

17 Dec '03

> Message-Id: <9403061401.AA55948(a)Hacker2.cpsr.digex.net> > Date: Sun, 6 Mar 1994 14:01:55 -0500 > From: Dave Banisar <banisar(a)washofc.cpsr.org> > To: clipper(a)washofc.cpsr.org > Subject: Time Article on Clipper > Sender: owner-cypherpunks(a)toad.com > Precedence: bulk > > Time Magazine June 7, 1994 > > > TECHNOLOGY > > WHO SHOULD KEEP THE KEYS? > oops I got ahead of myself there. That should be March 14. Look for it on your newsstand tomorrow.

1 0