January 1993 - cypherpunks-legacy

is this true???
by Fan Li TAI 29 Jan '93

29 Jan '93

Hiya.... I found this post in a newsgroup that I try to follow. Don't know about etiquette about how this should have been edited, so it's all here, headers and all. Anyway, I would like to know if the info is accurate, bull or what? FYI, the ISA means Internal Security Act (back in Malaysia) and they have had UUCP for a few years (but UUCP's hardly enough for the kinds of traffic they are talking about, but then a few private companies *did* have full Internet, so..... it's possible that the "thingy" was there without public knowledge.... ________begin reposting________ X-NEWS: msuvx1 soc.culture.asean: 11533 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS A5.5-2; site memstvx1.memst.edu Path: memstvx1!cs.utk.edu!gatech!swrinde!zaphod.mps.ohio-state.edu!darwin.sura.n et!haven.umd.edu!uunet!mcsun!fuug!anon Newsgroups: soc.culture.asean Subject: ?? Electronic Monitoring ?? [The article] Message-ID: <1993Jan20.211138.20587(a)fuug.fi> From: an3284(a)anon.penet.fi (legend) Date: Wed, 20 Jan 1993 19:40:25 GMT Sender: anon(a)fuug.fi (The Anon Administrator) Organization: Anonymous contact service X-Anonymously-To: soc.culture.asean Lines: 181 sorry about the previous post. The mailer cut off everything after any "--" line, which I used to separate the forwarded message. Here'e the complete message. legend. In article <1993Jan20.041347.19567(a)husc3.harvard.edu>, on(a)husc.harvard.edu writes: |> |> Now with Malaysia officially on Internet, I wonder if the ISA patrol |> will be monitoring this (and maybe s.c.malaysia) newsgroup. If so, then |> I guess there'll be no more criticizing the government -- that could |> get you detained without a trial. And since posting here could be |> interpreted as publishing, I guess there'll be no more talk on "sensitive" |> issues or you'll be in hot soup under the Seditions Act. Of course, now |> we can't talk about freedom or basic human rights either because Mr. |> what's-his-name here has declared that it has no place in Malaysian |> society; therefore it has no place in s.c.a or s.c.m too! |> |> SIGH! Soc.culture.asean will never be quite the same again... But hey, |> look on the bright side... we can always talk about food. |> |> Goodnight... |> |> Ahmad Zulqarnain b. Che On GO HOOSIERS!! |> on(a)husc.harvard.edu NO MORE DOOK... NO MORE DOOK... NO MORE DOOK ! When in doubt, assume they will (or for that matter, have been). In fact, Malaysia has *ALWAYS* been capable of monitoring Usenet news since a long time ago, since Malaysia has long been connected via UUCP, which is capable of providing a news feed. Included below is an article that appeared in alt.bbs.allsysop. It's source has NOT been validated. It is included here for your pondering only. PLEASE TREAT IT ONLY AS A RUMOR UNTIL THERE IS EVIDENCE. The possibility of the scenerio described in the article happening is up for debate. Again, the article is included for discussion purposes only. Please use your own discretion in deciding the truthfulness/falsefulness of the content. I am only forwarding an article that appeared in another newsgroup. This article was NOT originated from me. legend. ************************************************************************ * ************************************************************************ * *** ** * *** IF YOU WISH TO QUOTE/RE-QUOTE PART/ALL OF THE FOLLOWING ARTICLE, ** * *** PLEASE ALWAYS INCLUDE THIS DISCLAIMER/WARNING WITH IT. THANKS. ** * *** ** * *** The following article appeared in alt.bbs.allsysop in ** * *** September '92 and is re-post here without permission. ** * *** It has been included here for DISCUSSION PURPOSES ONLY. ** * *** The validity of the information included has NOT BEEN ** * *** VERIFIED. The reader should at best treat it as a RUMOR ** * *** at this point, and conduct his/her own investigation if ** * *** felt necessary. ** * *** ** * ************************************************************************ * ************************************************************************ * ORIGINAL POST FOLLOWS: Newsgroup: alt.bbs.allsysop In article <1992Sep30.033757.24139(a)bnlux1.bnl.gov>, foxworth(a)bnlux1.bnl.gov (Bob Foxworth) writes: |> |> The following message was received over our local Amateur Radio TCP/IP |> VHF Radio network on 26 Sept. It came there from the Amateur AX.25 protocol |> Packet Radio network, the originating radio BBS station (at Canton Ohio) |> entered it into the Amateur packet network on 16 Sept. I am passing it |> on "as received". I am not vouching for, nor am I disclaiming any statements |> in this message. I hope it is not a repeat of anything...any replies, post |> to the net, not to me. I tried to post it 3 days ago but it never |> appeared here. It did also go to a moderated group who rejected it, however. |> |> [begin included tex] |> - From n8ecw%kc2fd(a)kc2fd.ampr.org Sat Sep 26 14:05:28 1992 |> - Received: from n2mdq.ampr.org by k2euh.ampr.org with SMTP |> id AA9736 ; Sat, 26 Sep 92 13:59:54 UTC |> - Received: from kc2fd.ampr.org by n2mdq.ampr.org |> - (n2mdq(a)n2mdq.ampr.org) with SMTP |> - id AA10034 ; Tue, 22 Sep 92 13:49:44 UTC |> - Date: 26 Sep 92 13:51:00 UTC |> - Message-Id: <6087(a)kc2fd.ampr.org> |> - From: n8ecw(a)kc2fd.#nli.ny.usa.na |> - To: nli@n2mdq |> - Subject: CP KC2FD: BBSs, Privacy, and You! |> - X-BBS-Msg-Type: P |> - Status: R |> |> - R:920926/1351Z @:KC2FD.#NLI.NY.USA.NA [Coram, LI, NY] FBB5.14d #:18091 |> |> - From: N8ECW(a)KC2FD.#NLI.NY.USA.NA |> - To : NLI@N2MDQ |> |> - Original from N8ECW to ALL@USBBS |> - R:920926/0848Z @:N2BQF.#NLI.NY.USA.NOAM [Copiague] FBB5.14d TELINK #:18005 |> - intermediate headers deleted |> - R:920916/1944z @:KA8Z.OH.USA Canton, Oh. #:26846 Z:44705 |> |> I found the following message on a land line BBS. Since many packet users |> also have modems and call land line BBSs, and many sysops also run such |> BBSs I think that the information in the following message is something |> we should all be aware of. |> |> *** |> |> As someone involved in the telephone industry on the level of security |> and data integrity... I would like to inform everyone that uses modems |> and/or are bbs operators of some information. |> |> The first thing that everyone that uses a modem should know is that |> every time you fire up your modem your activating monitoring equipment |> somewhere in the U.S. I have worked for several large telephone |> networks that routinely monitor and reroute modem and fax transmissions |> through devices that allow them to view what is being transmitted and |> even decodes encrypted data and fax packets used by major corporations |> and governmental agencies. This is allowed under the heading of |> "Maintenance Monitoring" and may be continued for up to 6 months without |> the need of any legal paperwork being generated. Under an obscure |> pre-WWII ruling by the agency that is now the FCC... "No information may |> be encoded or transmitted over PUBLIC or PRIVATE forms of telephony or |> radio with the exception of those agencies involved in the National |> Security" a further designation goes on to say "with the exception of |> the MORSE system of 'transmittal', any communication that is not |> interpretable by the human ear is forbidden and unlawful." |> |> The information gathered goes to 3 seperate database facilities...1 is |> codenamed Diana and is located in Brussels, the 2nd is named Fredrick |> and is located somewhere in Malaysia, the 3rd is named Elizabeth and is |> located in Boulder, Colorado. The information stored in these systems |> is accessable by the US Government, Interpol, Scotland Yard and various |> other such agencies. Your credit rating is also affected by your modem |> usage... if you ever get a copy of your credit history and find a |> listing that has HN06443 <--= this is a negative risk rating. or a code |> 87AT4 <---= an even more negative risk rating.... these will usually |> have no description on them... and if you inquire about them they will |> tell you that it just comes from the system that way. |> |> I am currently working for another major carrier as a consultant and |> have been able to watch these systems operate...at one unnamed long |> distance carrier here in Columbus Ohio in their NCC, Network Control |> Center, you can see several rows of computer terminals which have |> approximately 30 to 40 separate windows in each... these windows have |> data transmissions that are being monitored... banks of 9 track tapes |> are going constantly to record everything. Everyone should realize that |> even if a sysop posts a disclaimer at the beginning of his bbs about no |> access to governmental agencies or law enforcement...that it isn't worth |> the time it takes to type it in... looking forward to hearing reactions |> to this. |> |> ****** |> |> I apologize for the length of this message, but it's information that I |> feel is important, especially for any land-line BBS sysop. Anytime you |> enter a message, even if it's private, always do it with the assumtion |> that it's going to be seen by anyone and everyone, everywhere. |> |> Tnx |> 73s |> de Tom, N8ECW(a)KA8Z.#NEOH.OH.USA.NA |> [end included message] |> Standard disclaimers apply. My employer, above, has no connection or |> responsibility with anything I say or relay here. Of course. ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind system, any replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. _______________________________________________________________________________ |___ ___ _____ ___ ___ | User Services, Room 134, Adm Bldg| || \/ | / ____\ | | | | Fan Li TAI | Memphis State University | || \ / | \____ \ | |_| | Campus Box 528039 | Internet: USTAI(a)MSUVX1.MEMST.EDU | ||_|\/|_| \_____/ \_____/ Memphis, TN 38152 | Bitnet : USTAI@MEMSTVX1 | |___________________________________________|__________________________________|

2 1

Re: OTP Generators
by tcmay＠netcom.com 29 Jan '93

29 Jan '93

Hal Finney writes: > Douglas Sinclair asked about the earlier discussion re the use of > radiation to generate true random numbers for one time pads. > > The problem, as I recall, was with the quantity of bits needed. OTP's ...stuff elided... > So, the needed particle emission rate is 40,000 divided by the > efficiency of your detector. Perhaps Douglas could get some efficiency > figures from his father, and judge whether this rate of radiation > emission would be safe. Yes, we've discussed this a couple of times. For a 2 pi detector geometry, about 100,000 decays per second are needed to give the 40,000 or so that the detector could see. This is about 3 microcuries (1 curie = 3.7 x 10^10 disintegrations per second), which is far higher than the Am-241 smoke detector sources have (0.1 microcurie, if I remember correctly...but I could be wrong on this, as it's been years...). (There's also the issue of detector drift, with such high levels causing changes in the detector properties.) Obviously, multiple detectors could be used, each generating perhaps several thousand bits pers second. It'll still take a week or so to fill a single CD-ROM. Not too practical. Nor is the production and distribution of CD-ROMS very convenient. Using this for "Cypherpunks"-type activities would be a nightmare of inconvenience for all concerned. -Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: waiting for the dust to settle. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: waiting for the dust to settle.

1 0

digital banking
by Karl Barrus 29 Jan '93

29 Jan '93

-----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, It looks like a few people are trying out the bank...but there is only so much you can try as a single user...so there needs to be a way to contact other bank users and remain anonymous. Being able to contact other bank users will allow bank customers to conduct real transactions, etc. So, what I plan to do is create a remailing header using my remailer's public key for everyone who uses the bank. I will send the appropriate remailing header to each user, which can then be attached to correspondence between bank customers. Then, each user can be contacted via an anonymous remailer (mine) and the remailing header. Following that I will send to each user the total list of remailing headers, so each bank customer will be able to contact the other bank customers. Then, each user can contact the other users, and include their own remailing header to receive responses. Right now we're just experimenting so I'd like the bank customers to be able to interact with each other. How does this system sound? I'd like to hear any comments about the bank or ways the bank's customers may transact with each other (preferably privately). Also, a few weeks ago, maybe even two months, someone posted anonymously :-) that they were nearly complete with an implementation of Chaum's digitcal cash (RSA encryption, decryption, blinded signatures, etc.) scheme. I'd like to hear from that person the status of their project, and whether it is feasible to incorporate their code into my bank server. Remain anonymous if you prefer, and include a remailing header so I can write you back. Incorporating Chaum's method, and cypherpunk-style remailers to conduct business with the bank are two of my goals for this project. /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK2lw84OA7OpLWtYzAQE67gP8DHXoSmvacMO4BlSMFDRwpf9rifEpbwqS Z8IocT5PnAsxhHY407KfKj6KQKT6WhZZ/zxDnm8UCWynwCXYAw8ASn6lqzKWW4Ds 7S9Gdnxv4ue12WqCZIFXF/Lg1AKXMch2q9IF/UN9Tx6b2n2r+IS+D+Gm7XTCksuR 5EP+Qtqhagg= =ox9u -----END PGP SIGNATURE-----

1 0

OTP Generators
by hal＠alumni.cco.caltech.edu 29 Jan '93

29 Jan '93

Douglas Sinclair asked about the earlier discussion re the use of radiation to generate true random numbers for one time pads. The problem, as I recall, was with the quantity of bits needed. OTP's eat bits like crazy. People have talked about filling CD-ROM's or other optical media with hundreds of megabytes or even gigabytes of random numbers. Now, the problem is how long it will take to produce that much random data. A few bits per second won't be fast enough. Suppose you wanted to produce 100 megabytes per day (which would take over a week to create a gigabyte). That requires about 10,000 random bits per second. Now, your detector is not going to be 100% efficient. Only a certain fraction of the emitted particles are going to be detected. So you will need more decays than this, possibly many more. Also, relying on a half-life calculation in which we wait a certain time interval, and see if there is a decay or not, won't be that accurate. If your time is off a little, it could bias the results. Tim May posted the best (IMO) fix for this. You collect bits in pairs; discard 00 and 11; for each 01 output a 0, for each 10 output a 1. This way even if there is a bias where, say, 60% of the bits are 0's and 40% are 1's you still get 50-50 0's and 1's out. This means you get about 1 output bit for each 4 inputs, so you have to increase the necessary decay rate by a factor of 4. So, the needed particle emission rate is 40,000 divided by the efficiency of your detector. Perhaps Douglas could get some efficiency figures from his father, and judge whether this rate of radiation emission would be safe. Hal Finney 74076.1041(a)compuserve.com {.

1 0

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