January 1993 - cypherpunks-legacy

(fwd) RISKS DIGEST 14.29
by tcmay＠netcom.com 28 Jan '93

28 Jan '93

I found this in RISKS. Apparently, law enforcement types are approaching software vendors and seeking backdoors and other compromises. Note that Lotus is a licensee of RSA, so the encryption algorithms worrying the FBI are probably the main RSA algorithms. Cypherpunk activities are becoming more important than ever. -Tim May From: risks(a)CSL.SRI.COM (RISKS Forum) Subject: RISKS DIGEST 14.29 Date: 27 Jan 93 22:05:31 GMT ------------------------------ Date: Wed, 20 Jan 93 17:58:49 EST From: joltes(a)husc.harvard.edu Subject: The FBI and Lotus cc:Mail An interesting tidbit came to light while I was attending a demonstration of Lotus' cc:Mail and Notes products at the Boston NetWorld this month. During the Notes portion of the presentation someone asked how secure the information in the various databases was, and how the encryption was done. The presenter said that the data was considered very secure, so much so that the FBI had approached Lotus to ask that a "back door" be left in the software in order to give the Bureau a method for infiltrating suspects' filesystems. She said they were specifically targeting "drug dealers and other bad people." Given this backdoor, what was to stop the Bureau from inspecting confidential materials on any system? The risks seem obvious. Additionally, it makes one wonder how many other vendors of supposedly "secure" software have been similarly approached by various Federal organizations, and how many have agreed to create the back doors as requested. Happily, the presenter said that Lotus refused to honor the FBI's request. Bravo! Dick Joltes, Manager, Networks and Hardware, Harvard University Science Center joltes(a)husc.harvard.edu ------------------------------

1 0

Limiting "white" noise runlength
by Eric Fogleman 27 Jan '93

27 Jan '93

Mr. Thug, In talking about "white" noise, you mentioned: > Yes I do think the idea of making a "more random than random" stream > by filtering out long runs of 0's or 1's weakens the the key stream > in theory, but in practical use it strengthens it, because if the stream > is left alone, runs of 500 bits of 0's or 1's can come through, and any > fool can then extract plain text using XOR in this area of the cyphertext. > LZW compression of the plaintext helps, but I feel that it is far better > to reduce the possibility of a key stream containing long runs of 0's or > 1's, than to leave it alone. Why not feed back the previously encrypted bits to perform the "present" encryption (something like cipher block chaining) to keep this from happening? Then any particular encrypted character will depend on *all* previous characters and break up runs of "plaintext". That seems much better than un-whitening your white noise... Eric Fogleman

1 0

Randomness and RE>OTPs
by Scott Collins 27 Jan '93

27 Jan '93

Subject: Randomness and RE>OTPs >Does anybody remember a good recipe for converting a biased RNG into an >unbiased one? I can't think of one off the top of my head, and that's >what Thug's friend seems to need. This has been discussed at length in >the literature. 1. If you want randomness, introducing order is bad. As Eric Hughes pointed out, trimming runs reduces the entropy of the sequence. You want to increase the entropy i.e. maximize the surprise. One good way to increase the entropy is to compress the 'random' sequence. The output of a good compressor has greater entropy than the input. If the input is already random, no harm done (again, with a GOOD compressor... otherwise it is easy to accidentally introduce order). If the input has some subtle bias or regularity, the compressor will get rid of it (at the cost of reducing the total volume of the sequence). Good compressors are much better at detecting regularity (and eliminating it) than human beings. 2. Of course (as Thug stated) you are (also) compressing the plaintext before you encrypt it. It is best to do this with an adaptive scheme and an arithmetic encoder so that a) the entropy of the plaintext is maximized and so that b) accidentally decrypting something correctly in the middle of the stream is useless. My recommendation for a good binary scheme is DMC (dynamic markov compression) feeding into almost any binary arithmetic encoder (e.g. the Q-coder, et. al.). I would use this to compress both the plaintext stream before encryption, and a 'suspect' random number stream. If there is interest, I will post a bibliography of papers and books relating to this. Scott Collins (Scott_Collins(a)genmagic.com)

1 0

[surfpunk-0036] CRYPT: Sci Am on Public Key Cryptosystems
by surfpunk＠osc.versant.com 27 Jan '93

27 Jan '93

+ + Cypherpunks don't care if you don't like the + software they write. Cypherpunks know that + software can't be destroyed. Cypherpunks know + that a widely dispersed system can't be shut + down. + -- the cypherpunk manifesto + (cypherpunks-request(a)toad.com) ++++++++++++++++++++++++++++++++++++++++++++++++ Here's a short piece from Scientific American on RSA, PEM, PGP etc. Notice towards the end this article says "The U.S. is the only nation that permits the patenting of mathematical algorithms." That threw me at first -- it's not *supposed* to be permitted, but in practice, it is. So I suppose this is a true statement. (The cover article of this Sci Am is on a team at the Science Museum in London that did a 3-ton implementation of Babbage's Difference Engine.) -- strick ________________________________________________________________________ ________________________________________________________________________ Source: Scientific American, February 1993, beginning at the 30th page. For fair use only. Electronic Envelopes? The uncertainty of keeping e-mail private Recent legislative efforts to mandate remote wiretapping attachments for every telephone system and computer network in the U.S. may have been the best thing that every happened for encryption software. "We have mostly the FBI to thank," says John Gilmore of Cygnus Support in Palo Alto, Calif. Gilmore is an entrepreneur, hacker and electronic civil libertarian who helped to found the Electronic Frontier Foundation (EFF). He is now watching closely the development of two competing techniques for keeping electronic mail private. As matters now stand, computers transmit messages from one user to another in plain text. If a geneticist in Boston sends e-mail to a molecular biologist in San Diego, any of the half a dozen or so intermediary machines that forward the letter could siphon off a copy -- and so could any of the dozens of workstations that might be attached to the local-area network at the sender's or recipient's university or company. The Electronic Privacy Act of 1986 prohibits snooping by public e-mail carriers or law-enforcement officials, except by court order. Nevertheless, many people are becoming uncomfortable with the electronic equivalent of mailing all their correspondence on postcards and relying on people to refrain from reading it. They are turning to public-key encryption, which allows anyone to encode a message but only the recipient to decode it. Each user has a public key, which is made widely available, and a closely guarded secret key. Messages encrypted with one key can be decrypted only with each other, thus also making it possible to "sign" messages by encrypting them with the private key [see "Achieving Electronic Privacy," by David Chaum; Scientific American, August 1992]. Two programs -- and two almost diametrically opposed viewpoints embodied in them -- are competing for acceptance. Privacy Enhanced Mail (PEM) is the long-awaited culmination of years of international standard setting by computer scientists. Pretty Good Privacy (PGP) is a possibly illegal work of "guerilla freeware" originally written by software consultant Philip Zimmermann. The philosophies of PEM and PGP differ most visibly with respect to key management, the crucial task of ensuring that the public keys that encode messages actually belong to the intended recipient rather than a malevolent third party. PEM relies on a rigid hierarchy of trusted companies, universities and other institutions to certify public keys, which are then stored on a "key server" accessible over the Internet. To send private mail, one asks the key server for the public key of the addressee, which has been signed by the appropriate certification authorities. PGP, in contrast, operates on what Zimmermann calls "a web of trust": people who wish to correspond privately can exchange keys directly or through trusted intermediaries. The intermediaries sign the keys that they pass on, thus certifying their authenticity. PGP's decentralized approach has gained a wide following since its initial release in June 1991, according to Hugh E. Miller of Loyola University in Chicago, who maintains an electronic mailing list for discussion among PGP users. His personal "keyring" file contains public keys for about 100 correspondents, and others have keyrings containing far more. As of the end of 1992, meanwhile, a final version of PEM has not been officially released. Gilmore, who subscribes to the electronic mailing list for PEM developers, says he has seen "only five or 10" messages actually encrypted using the software. Although PGP's purchase price is right -- it is freely available over the Internet and on electronic bulletin boards throughout the world -- it does carry two liabilities that could frighten away potential users. First, U.S. law defines cryptographic hardware and software as "munitions." So anyone who is caught making a copy of the program could run afoul of export-control laws. Miller calls this situation "absurd," citing the availability of high-quality cryptographic software on the streets of Moscow. Worse yet, RSA Data Security in Redwood City, Calif., holds rights to a U.S. patent on the public-key encryption algorithm, and D. James Bidzos, the company's president, asserts that anyone using or distributing PGP could be sued for infringement. The company has licensed public-key software to corporations and sells its own encrypted-mail package (the algorithm was developed with federal support, and so the government has a royalty-free license). When Bidzos's attorneys warned Zimmermann that he faced a suit for developing PGP, he gave up further work on the program. Instead PGP's ongoing improvements are in the hands of an international team of software developers who take advice from Zimmermann by e-mail. The U.S. is the only nation that permits the patenting of mathematical algorithms, and so programmers in the Netherlands or New Zealand apparently have little to fear. U.S. residents who import the program could still face legal action, although repeated warnings broadcast in cryptography discussion groups on computer networks have yet to be superseded by legal filings. Meanwhile, Gilmore says, the only substantive effect of the patent threat is that development and use of cryptographic tools have been driven out of the U.S. into less restrictive countries -- Paul Wallich ________________________________________________________________________ ________________________________________________________________________ The SURFPUNK Technical Journal is a dangerous multinational hacker zine originating near BARRNET in the fashionable western arm of the northern California matrix. Quantum Californians appear in one of two states, spin surf or spin punk. Undetected, we are both, or might be neither. ________________________________________________________________________ Send postings to <surfpunk(a)osc.versant.com>, subscription requests to <surfpunk-request(a)osc.versant.com>. MIME encouraged. Xanalogical archive access soon. Cypherpunks love to practice. ________________________________________________________________________ ________________________________________________________________________ #define DA_MD2 3 #define DA_MD5 5 #define MIN_RSA_MODULUS_BITS 508 #define MAX_RSA_MODULUS_BITS 1024 #define MAX_RSA_MODULUS_LEN ((MAX_RSA_MODULUS_BITS + 7) / 8) #define MAX_RSA_PRIME_BITS ((MAX_RSA_MODULUS_BITS + 1) / 2) #define MAX_RSA_PRIME_LEN ((MAX_RSA_PRIME_BITS + 7) / 8)

1 0

Randomness
by pmetzger＠shearson.com 27 Jan '93

27 Jan '93

> From: thug(a)phantom.com (Murdering Thug) > > Yes I do think the idea of making a "more random than random" stream > by filtering out long runs of 0's or 1's weakens the the key stream > in theory, but in practical use it strengthens it, because if the stream > is left alone, runs of 500 bits of 0's or 1's can come through, and any > fool can then extract plain text using XOR in this area of the cyphertext. The odds against a run of 500 1's is one in 2^500th, which is a number so large I can't imagine a real random number source creating it in the lifetime of our universe. Presumably, your problem is that your random number source is crap. Perry

1 0

Re: Computerized OTP (was 5th AMENDMENT & DECRYPTION)
by nobody＠alumni.cco.caltech.edu 27 Jan '93

27 Jan '93

Murdering Thug wrote: > Yes I do think the idea of making a "more random than random" stream > by filtering out long runs of 0's or 1's weakens the the key stream > in theory, but in practical use it strengthens it, because if the stream > is left alone, runs of 500 bits of 0's or 1's can come through, and any > fool can then extract plain text using XOR in this area of the cyphertext. Thug is wrong about this, but it's a common mistake. It does seem like those runs of 0's (and, to a lesser extent, 1's) are dangerous - there's your plaintext, totally exposed to the prying eyes of strangers! But, what is forgotten is this: for every run of 0's which would reveal your plaintext, there is an equally likely pattern of 1's and 0's which transforms your plaintext into one of Shakespeare's plays. Or into the Declaration of Independence. Or into anything else you like. You see, xor'ing your message with a random stream means that the resulting output is equally likely to be _any_ original message. There is no way in theory or in practice to determine what the message originally was; that is, all bit patterns are equally likely to be the original message. To see an example of this, suppose you had one of the simplest possible original messages: all 1's. Now you xor this with a random pattern. To your dismay, your random stream happens to come up with a large block of 0's. This is what would happen: Original message: 1111111111111111111111111111111111 Random stream: 0011010010000000110111010111001010 Resulting output: 1100101101111111001000101000110101 Look at that big block of 1's in there. Won't that give it away? No. Such a block of 1's is expected to occur occasionally no matter what the original message. It's just as likely that the original message and random stream looked like: Original message: 1010101010101010101010101010101010 Random stream: 0110000111010101100010000010011111 Resulting output: 1100101101111111001000101000110101 There is no way to tell what the original message was, even when you see a block of output which seems to match some pattern. It doesn't tell you anything. Hal 74076.1041(a)compuserve.com

2 1

Random OTP sources
by Douglas Sinclair 27 Jan '93

27 Jan '93

Much discussion has been going on about creating a truly random OTP key by tuning in to dead TV channels, etc. There is a much simpler, and more secure way. Look at the decay of a small radioactive source. Find a time period in which there is a 50% chance of seeing an event, and then clock a 1 if you do, or a 0 of you don't. Radioactive sources and detectors are easily obtained from smoke detectors, and it should be fairly easy to set up (though I havn't done it). If our understanding of quantum mechanics are correct, the resulting bitstream is truly random. RF noise may be random. Also, if the NSA or other Big Brother organization knows what you are doing, they can try listening in on the same channel and deducing your key. To my knowledge, there is no way to see what is going on in a small Californium source if you have more than a few meters between the source and detector. Anyhow, a given event will probably only produce one particle, or maybe two, so your point detector will only see a portion of the events and knowledge of particles in another direction doesn't tell you anything. Hm. I hope that was coherent. Any comments? -- Vercotti: I was terrified of him. Everyone was terrified of Doug. I've seen grown men pull their own heads off rather than see Doug. Even Dinsdale was frightened of Doug. Interviewer: What did he do? Vercotti: He used sarcasm. He knew all the tricks, dramatic irony, metaphor, bathos, puns, parody, litotes and satire. -- Monty Python, Episode 14 PGP 2.1 Key by finger

1 0

Re: a few good weasels
by edgar＠spectrx.Saigon.COM 27 Jan '93

27 Jan '93

Dave del Torto said here: A world of absolutes is not a fun world and it's not a safe world. Someone's gotta break the rules every once in a while or we all go down the tubes. Of course, I _personally_ would _never_ break any of the fine laws of our beloved nation, but I know deep in my heart (but not anywhere on my hard disks) that such brave people exist and that the effect of their less-than-legal efforts is the delicate equilibrium in which we continue to prosper and innovate. I agree completely. So would Ollie North, who is a fine example of "such brave people". -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

PRACTICAL DECRYPTION
by John.Nieder＠f33.n125.z1.FIDONET.ORG 27 Jan '93

27 Jan '93

from: john.nieder(a)f33.n125.z1.fidonet.com > (commenting on the strategy of "taking the 5th" on the matter of > decrypting one's files) > > > . Recently this question came up in another forum on encryption & an > > "authority" on communications law claimed the probable scenario would be > > that the arresting agency would have the encrypted material decrypted by > > a competent government or academic agency & the costs of said decryption > > would eventually be recovered from the defendant through civil suits, > > presuming the defendant had sufficient assets. It is my memory of the > > thread that he claimed this had been done in previous cases. > > With strong crypto, e.g., with 300 decimal digit moduli, the "costs" > of decryption by brute force could easily exceed the GNP/GDP of the > U.S. # Since none of us have ever been inside the NSA, we cannot underestimate # their power and resources. For all we know... This is somewhat beside the point. In actual fact, much of the seized encrypted evidence in criminal cases employs built-in encryption programs in major software packages (WordPerfect is a good example) rather than obscurer stuff like PGP/IDEA/RSA. Even highly-touted commercial programs like Norton Utilities DiskReet w/DES use simple passwords of a maximum ten-character size. . Much of this decryption may be trivially accomplished, though many "experts" charged law enforcement agencies stout fees for the service. It is now known that those specializing in WordPerfect files were using a simple program available on most BBS file bases which will crack the "secret" WordPerfect password in seconds on an old XT. . Apparently, the consulting fees for breaking bad crypto in most cases is not prohibitive. . Tim's objections about high-end decryption are indeed valid, at least theoretically, but we can not tell if a given encryption program has been backdoored or if a fatal flaw has been uncovered that reduces the security of the cyphertext. If any cryptanalysts might find such flaws, they would probably be those in no position to reveal their findings. . Jean-Loup Gailly [an original PGP team member in France] informs me that the same general criticisms of PGP soundness voiced in the Moscow State University report have been independently suggested in sci.crypto, though he is aware of no instance of these alleged weaknesses being exploited to break a PGP message. The jury is still out on PGP's ultimate security, I suppose. . Personally, I am not counting on PGP's brute-force decryption being a task of the magnitude Tim suggests, though I _hope_ he's right. I sure wish some well-equipped crypto labs like Marty Hellman's would turn their attentions to an evaluation of PGP... JN --- Blue Wave/Opus v2.12 [NR] -- John Nieder - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!33!John.Nieder INTERNET - John.Nieder(a)f33.n125.z1.FIDONET.ORG

1 0

SunExpress to expand "unlockable" software distribution
by gnu 27 Jan '93

27 Jan '93

It would probably be a public service if some interested parties were to determine the ``encryption'' method that Sun Express, the standard Sun ``license manager'', and other packages use. At the moment, the details of these technologies are not described in the public literature (as far as I know). Rather than have these companies discover years too late that their "unlockable" software is really unlockable by anyone who understands cryptography, it'd be better for them to learn it this year, while they are still handling low volumes of programs that way. Also maybe they will stop dumping these programs-that-you-have-but-must-pay-to-run on us. John ---------------------------------------------------------------------------- The Florida SunFlash SunExpress Unveils One-Stop Shopping From the Desktop SunFLASH Vol 49 #21 January 1993 ---------------------------------------------------------------------------- New CD-ROM and facsimile services make it easier than ever to select and purchase products CHELMSFORD, Mass. --January 26, 1993-- SunExpress, a subsidiary of workstation industry leader Sun Microsystems, Inc., today announced two new customer services which simplify information retrieval and product ordering. FaxInfo(SM), which allows SunExpress customers to access product information and order product through their fax machine, is available now. A second program will allow SunExpress customers to "unlock" software applications directly from SunSoft's Catalyst CDware(TM), the most widely-distributed demo CD for users of the UNIX(R) operating system. The CD-ROM program is being implemented in twenty customer sites on a trial basis and will be generally available later this year with Catalyst CDware Volume 5.0. The integration of these technologies, coupled with other electronic ordering innovations planned for release later in 1993, will allow SunExpress to process orders more efficiently and provide a higher level of customer satisfaction. Eventually, these process innovations will result in drastically fewer written orders, smaller inventories, less postage, phone and freight costs, resulting in reduced costs for SunExpress customers. "SunExpress is committed to providing its customers with leading-edge technologies that will make it easier than ever for them to select and purchase products. The new programs announced today are just the beginning," said Dorothy Terrell, president of SunExpress. "In the near future, our customers will be able to browse through full color on-line catalogs, watch video demonstrations and try out software all without leaving their workstation." FaxInfo The FaxInfo program allows SunExpress customers to access detailed product information about catalog offerings within minutes. By calling into the regular SunExpress ordering and information number (800-USE-SUNX), customers can access FaxInfo and have technical data sheets faxed back to the location of their choice by using the touch-tone keypad on their phone. SunExpress maintains up-to-date datasheets on all of the products that it offers and makes revisions to product specs as they are made available. SunExpress joins with SunSoft's Catalyst CDware Program Sun(TM) workstation users currently have access to SunSoft's Catalyst CDware program which allows them to run demo versions of a range of UNIX software applications from several major ISV's and decide whether it is something they would like to buy. With SunExpress' participation in the program, interested customers can purchase and obtain a fully-functional version of their chosen software -- all in one toll-free phone call. Currently this program is being tried out at twenty customer sites with limited software product offerings including: Clarity's Rapport(TM), and Ta-Dah!(TM) and SimCity(TM) from Dux Software. The program is targeted for full implementation with many more titles this summer, and will be attractive to ISVs who are already marketing their product through Catalyst CDware from SunSoft. Catalyst CDware currently carries 73 product presentations from 54 different vendors. "We feel that this service from SunExpress can only enhance the effectiveness and impact of our Catalyst CDware program," said Peter Schakow, Manager of CD programs at SunSoft. "We look forward to providing this added service to our Catalyst CDware partners." ISVs are interested in the SunExpress distribution strategy as a new sales channel. "This program will greatly facilitate our marketing efforts into the Sun installed base," said Bob Adams of DUX Software. "In addition to assisting with new product sales, it will be extremely useful and cost effective for distributing product enhancements and upgrades." SunExpress, a subsidiary of Sun Microsystems, Inc. provides customers with easy access to a wide range of Sun and innovative 3rd party products at low competitive prices and same day shipping. SunExpress supports SPARC(R), Solaris(R), and other computing environments based on the UNIX operating system. The company offers a 30-day no fault return policy and is currently serving customers in the United States, Europe and Japan. SunExpress can be reached at 1 (800) USE-SUNX and is headquartered in Chelmsford, MA. Press Contact: Hi-Tech Communications Mark Lederhos (508) 251-8278 Kathryn Lang (415) 904-7000 x204 Sun Lisa Ganier (415) 336-5637. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ For information send mail to info-sunflash(a)Sun.COM. Subscription requests should be sent to sunflash-request(a)Sun.COM. Archives are on solar.nova.edu, uunet.uu.net, sunsite.unc.edu, src.doc.ic.ac.uk and ftp.adelaide.edu.au All prices, availability, and other statements relating to Sun or third party products are valid in the U.S. only. Please contact your local Sales Representative for details of pricing and product availability in your region. Descriptions of, or references to products or publications within SunFlash does not imply an endorsement of that product or publication by Sun Microsystems. John McLaughlin, SunFlash editor, flash(a)Sun.COM. (305) 776-7770.

1 0