- cypherpunks-legacy - lists.cpunks.org

Re: The FBI and Lotus cc:Mail
by sDun＠isma.demon.co.uk 29 Jan '93

29 Jan '93

In article ** unknown ** you write: >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. > > Blah Blah Blah > >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 I suppose that really means "Lotus *said* they refused to honour it.." Paranoid? Moi !? Stephen -- +--------------------------------------------------------------------------+ |Stephen Dunne DoD#767 sdun(a)isma.demon.co.uk | |International Securities Market Association I speak for me,thats all| |Voice (+44) 71-538-5656 Fax (+44) 71-538-4902 PGP 2.1 key available | |We are not affiliated to any other Demon.Co.Uk site. (especially Evil!) | +--------------------------------------------------------------------------+

1 0

Radio-isotope OTP generators
by Douglas Sinclair 29 Jan '93

29 Jan '93

I got some mail from someone on the list who told me that about a year ago there had been much discussion of radio-isotope OTP random number generators, and that the conclusion had been that they were too dangerous to use. I replied to that message, but my reply bounced for some reason. So, could anybody please send me a synopsis of the discussion? Thanks. I was talking to my father about this, and we concluded that a simple exposed- silicon photodiode put in reverse bias should provide adequate detection. Put it in darkness, and no current will flow. Hit it with and alpha, and you get a cascade on the order of a million electrons. The alpha source need only be some radium paint on the front of the diode. This is not dangerous stuff. You'd have to go very far out of your way to do yourself any damage with it. If you eat it then bad things might happen, but I can say the same thing about AA batteries... My father designs and builds particle detectors for a living, so he probably knows what he's talking about. BTW: one error in my last message. There is not Californium in a smoke detector, it is Amerecium. Same difference... -- 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

ARA security
by miron＠extropia.wimsey.com 29 Jan '93

29 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- Proposition 1: All remailing schemes are vulnerable in the case that all remailing sites in the chain are compromised before transmission. Proposition 2: With ARAs and direct transmission (one recipient at each hop), if the first n-1 hosts in a chain are compromised then the n_th host identity is known. If all hosts are compromised, the originator is known. Corollary 1: Direct-transmission ARAs are vulnerable to an adversary that can compromise any small subset of all hosts. This is done by sequentially compromising the next host, and using that information to find the identity of the next host after that. No amount of "random" routing has any effect in this case, since the randomness is implemented by each host, but each host is compromised before it makes the delivery. Proposition 3: Normal anonymous transmission (not ARA) is "unconditionally" secure after *one* passage through an uncompromised host, assuming no traffic analysis and no log files. (With log files, normal transmission is as insecure as direct-transmission ARAs.) Therefore, it seems like direct-transmission ARAs are much less secure than normal anonymous transmission. For better security, we must find some other ARA scheme. A proposal: broadcast ARAs and Message Pools - -------------------------------------------- All messages to a message pool are sent to all subscribers to the pool. Messages to the pool are encrypted with the (pseudonymous) public key of the recipient. The ARA can thus belong to any of the subscribers to the pool. The connection between public keys and subscribers is not maintained anywhere. The subscribers have attempt decryption of messages marked with their pseudonyms. Once the key of a subscriber is destroyed, it is not possible to prove that any message was destined for that subscriber, affording a last resort to a subscriber suspecting that an attack is in progress. Pools must have a large number of subscribers in case it is possible to compromise the key of any particular subscriber. Pools can be implemented as Usenet groups for a low-cost delivery medium. Each pool should be geographically limited in order to further minimize costs (the Distribution: header works well here). If costs are minimized, the pools can be increased, affording better security. For experimental, low-volume tests, mailing lists can be used. - -- Miron Cuperman <miron(a)extropia.wimsey.com> | NeXTmail/Mime ok <miron(a)cs.sfu.ca> | Public key avail AMIX: MCuperman | cyberspacecomputingcryptoimmortalitynetworkslaissezfaire -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK2j60ZNxvvA36ONDAQFKiAP+JFWWeke6rADXFfK4d4LPHNUWJ9NwcjH4 5XDC+Veg8h3JgwSQ7f0J8JM9LqwbHBWHObm4bPJKeBa1fSIP2L8xNMsA0dQnriwE EWVR6oUPy3ANMefEa9CHMS+bkOnuGRXV4Ntsi6Eh1kLyK340jUheWKjVMtWl37Cb d9qe12GqSlU= =LHSz -----END PGP SIGNATURE-----

1 0

Biblio re>randomness and OT
by Scott Collins 28 Jan '93

28 Jan '93

Subject: Biblio re>randomness and OTPs Response was sufficient to merit posting this (brief and specific) bibliography pertaining to a) randomness; b) testing for randomness; and c) compression and coding as it relates to privacy and maximizing entropy. The items are listed in the order that *I* think represents their helpfulness on this topic. Two interesting quotes from Knuth (book [1] below): (sec3.2.2 para2 p25) One of the common fallacies encountered in connection with random number generation is the idea that we can take a good generator and modify it a little, in order get and "even-more-random" sequence. (sect3.3 para4 p38) ...The point of these remarks is that we cannot be trusted to judge by ourselves whether a sequence of numbers is random or not. Some unbiased mechanical tests must be applied. Books ========== [1] "The Art of Computer Programming, vol 2: Seminumerical Algorithms" by Donald Knuth. ISBN 0-201-03822-6 Sections of interest: (3) Random Numbers [2] "Text Compression" by Bell, Cleary and Witten. ISBN 0-13-911991-4 Sections of interest: (5) From Probablilities to Bits, especially (5.2) Arithmetic Coding (7.3) Dynamic Markov Modeling (10.1.5) Privacy and Compression [3] "Adaptive Data Compression" by Ross N. Williams. ISBN 0-7923-9085-7 Sections of interest: (1.9) Arithmetic Coding (1.10.6.8) DMC (1.16) Error Correction, Data Compression and Cryptography [4] "Image and Text Compression" edited by Storer. ISBN 0-7923-9243-4 Sections of interest: (4) 'Practical mplementations of Arithmetic Coding' by Howard and Vitter. Papers ========== [5] "A note on the DMC data compression scheme" by Bell and Moffat. [6] "Universal Coding, Information, Prediction, and Estimation" by Rissanen. [7] "Linear Time Adaptive Arithmetic Coding" by Moffat. [8] "A Simple General Binary Source Code" by Langdon and Rissanen. [9] "An overview of the basic principles of the Q-Coder adaptive binary arithmetic coder" by Pennebaker, Mitchell, Langdon and Arps. [10] "Software implementations fo the Q-Coder" by Mitchell and Pennebaker. [11] "Optimal hardware and sofware arithmetic coding procedures for the Q-Coder" by Mitchell and Pennebaker. [5] "Probability estimation for the Q-Coder" by Pennebaker and Mitchell. I hope you find this information helpful. Scott Collins (Scott_Collins(a)genmagic.com)

1 0

Remailer Changes
by nowhere＠bsu-cs.bsu.edu 28 Jan '93

28 Jan '93

The following changes have been made to the remailer running here at bsu-cs. Note that they are effective immediately. If some of you would please just try sending a few messages through the remailer so I can be sure it is working (I don't care if you remail it to yourself, but I want to look at the debug output so that I can turn off the logs. Changes: - Thanks to a suggestion on here, I have changed to the more standard "::" format. If and only if the first line of the message after the header contains "::" will the lines following it up until a blank line *OR* another "::" on a line by itself be parsed as though they are part of the header. - Any "X-Anon-To," "X-Anonymously-To," or "Request-Remailing-To," lines in the main header or the secondary header will cause the recipient's name to be set to its value. The last one listed will be the one to which the mail is sent (I haven't decided whether or not multiple recipients are going to be supported yet) - Any "From" line in either header will be stripped. - Any line except the "Subject" line will be stripped from the main header before being sent. - Any lines aside from those already described above that are contained in the secondary header will be appended to the header before the message is sent out. - No X-Anon-To, X-Anonymously-To, or Request-Remailing-To header lines will be passed on in case this remailer is being chained onto another remailer (which would cause an endless loop if it found its own address as the X-Anon-To field and didn't strip it on outbound mail). Please let me know what you think. Once again, this software is written in C and I plan to release source code when the project is completed. Chael Hall -- Chael Hall nowhere(a)bsu-cs.bsu.edu, 00CCHALL(a)LEO.BSUVC.BSU.EDU, CHALL(a)CLSV.Charon.BSU.Edu (317) 285-3648 after 4 pm EST

2 2

Re: Computerized OTP (was 5th AMENDMENT & DECRYPTION)
by thug＠phantom.com 28 Jan '93

28 Jan '93

Timothy Newsham wries: > Murdering Thug writes: > > The only way to thwart the NSA is to use an encryption scheme which has > > been _proven_ uncrackable. The only one I know of is the One Time Pad. > > didnt shannon prove that the only "unbreakable" encryptions (or > encryptions with "zero knowledge") have to have a key at least > as long as the message? The key stream for a OTP system is infinitely long, and if a real random source is used (e.g. RF noise/static) no bit in the key stream has any relationship to any other bit in the key stream, unlike a pseudo-random-gen key stream where there is a relationship and this relationship can be found and the seed for the PRNG extracted and thus the key is broken. Since TV static on unused channels is basically amplified RF garbage coming in from outer space radio sources and is in fact "white noise", it makes the perfect encoding stream for a one time pad system, it's infinitely long, never repeats, and is never reused. 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. The other possibility is to find a truly random RF source that has all the properties you want, the more important being that the >average< length of a homogenous bit run (0's or 1's) is around 4 or 5 bits. Of course you should let run lengths of 12 bits come through to screw the stat guys, but the >average< run length should be below 8 bits. Such a highly variable stream of white noise makes the perfect key stream in my opinion. Thug

2 1

(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