May 1993 - cypherpunks-legacy

WER #79
by Mr. Noise 21 May '93

21 May '93

Having received my copy of the latest Whole Earth Review yesterday, I expected to see a pile of messages about the article by Kevin Kelly on "Cypherpunks, E-Money, & Technologies of Disconnection"...but maybe, like me, you've all been too busy to read the article all the way through. Anyway, I thought those of you who don't subscribe would appreciate a mention of the article so you could run right out & buy the mag. There's also some good sci-fi stuff (they give it some kind of fancy name, you know WER...) by Kelly & Brian Eno. & the cover is by R. Crumb! Well, anyway, it seems Mr. Kelly has spent some time talking to list member (guru?) Tim May, Phil Zimmerman, & a bunch of other cypherpunk folk, so how about some reactions to the article from those he talked to? ...& is it me, or is the WER/WELL/cypherpunks/Wired/EFF/etc. crowd starting to get just a *little* inbred? (In a nice way, of course...) I feel as though Kelly, Sterling, Brand, Levy, et al. are my best buddies & I don't think we've ever exchanged e-mail (well, once or twice maybe), they just keep popping up everywhere I turn. Heck, I may even have to write R.U.Sirius into my will, he feels like such an old pal...

2 1

hello, all
by esr＠snark.thyrsus.com 21 May '93

21 May '93

I've just joined the list. I did so because I'm mad as hell about the Clipper proposal (some of you may have seen my incendiary post to RISKS on the topic). Some of you know me. Others have probably seen my work, which includes (among much else) major packages in Emacs 19, a moderately popular netnews suite, the /dev/speaker driver for PC-clones, and editing the Jargon File. I want to know what I can do to help block the Feds from `surveilling' everybody and to spread crypto-anarchy. I'm not up to speed on technical cryptography yet (though I know a lot about the pre-computer kind, Vigenere ciphers and such) but I'm chasing references and hope to be soon. There may be other ways I can contribute. Besides being a skilled hacker, I'm also good with English. I have a lot of experience at maintaining successful FAQs (I'm handling six now, including the monthly three-part buyer's guide for ISA UNIX software and hardware). If the cypherpunks FAQ is still in preparation, I can probably be of substantial help with it. -- Eric S. Raymond <esr(a)snark.thyrsus.com>

1 0

Re: TEMPEST and other "neat stuff"
by wcs＠anchor.ho.att.com 20 May '93

20 May '93

Paul Ferguson, fergp(a)sytex.com, posts excerpts from an article on TEMPEST. With all due respect :-), the article is largely nonsense. > 8<------ Snip, Snip ------[ edited ]------ > (c) 1990 Christopher J. Selin cjs(a)cwru.cwru.edu cjs(a)cwru.bitnet > Eavesdropping On the Electromagnetic Emanations of Digital Equipment: > The Laws of Canada England and the United States > This document is a rough draft. The Legal Sections are overviews. > ..... > In the United States it is illegal for an > individual to take effective counter-measures against > TEMPEST surveillance. This leads to the conundrum that it > is legal for individuals and the government to invade the > privacy of others but illegal for individuals to take steps > to protect their privacy. This is distinctly not the case. You can take any countermeasures you want. The precise standards are classified (some SECRET, some CONFIDENTIAL COMSEC), so you can't find out how good the government's abilities to eavesdrop are, or precisely what level of protection the government thinks is necessary to protect classified information, or how good the NSA thinks the Russians are, but as long as you're not using classified information as your sources, you can do anything you want. (If you're not protecting yourself *enough*, the FCC will get on your case, but over-protection is fine.) > 2. TEMPEST is an acronym for Transient Electromagnetic Pulse > Emanation Standard. TEMPEST isn't particularly about transients or electromagnetic pulses, it's about overall electromagnetic emissions. Electromagnetic Pulses are the big fast spikes you get from nuclear explosions (or similar slower spikes from lightning, etc.) and the techniques you use for protection against EMP don't solve your TEMPEST problems, and vice versa, though both kinds of protection are some help for the other. In my previous incarnation as a Tool of the Military-Industrial Complex, I never saw TEMPEST expanded as an acronym in any of the documents I read. > TEMPEST is a defensive standard; a device which > conforms to this standard is referred to as TEMPEST Certified. More specifically, a device that's been tested by an NSA-approved testing lab and has all the paperwork blessed by the NSA is TEMPEST-certified. The NSA puts out an "Evaluated Products List" (the name changes every couple of years) which has approved TEMPEST hardware, NCSC-Orange-Book rated operating systems, etc. > The United States government refuses to release details > regarding TEMPEST and continues an organized effort to censor the > dissemination of information about it. For example the NSA > succeeded in shutting down a Wang Laboratories presentation on > TEMPEST Certified equipment by classifying the contents of the > speech and threatening to prosecute the speaker with revealing > classified information. [cite coming]. The Wang Labs people probably had access to the classified documents - if you have them, you're responsible for not giving out classified information, and material derived from classified information might deserve classification. But that's not the same as saying it's "born classified", which is how nuclear weapons design information is treated (no comments on the legality of that approach...) Now, it may be that the NSA are overzealous in presuming the classified nature of the material in the presentation before hearing it; I don't know the details of the case, but access to classified material legitimately affects your ability to discuss its contents in public. > 3. This Note will not discuses how TEMPEST relates to the > Warrant Requirement under the United States Constitution. > Nor will it discuss the Constitutional exclusion of foreign nationals > from the Warrant Requirement. (*My* copy of the Constitution doesn't say that foreign nationals are excluded from "the people" who have specific rights to due process, and the 14th Amendment clearly requires at least the States not to deprive *any* person of life, liberty, or property without due process, and not to deny equal protection to anyone within its jurisdiction, as well as not abridging privileges or immunities of U.S. citizens. Somehow the recent governments haven't felt that applies to them or something...) In the case of the Crippler Chip, however, you knew it had a built-in wiretap when you bought it, which changes some of the reasonable expectations about privacy a bit. Bill Stewart

1 0

Large Scale Implementation of PGP
by James Still 20 May '93

20 May '93

> Does anyone have any experience/advice w/ this tpye of large scale > implementation of PGP? I know the need to encrypt most of the messages > will be small, but I think it is important to get these people so > familar w/ encryption, they won't be scared and will defend it when > the need arises. Bravo! Widespread use of PGP now is analogous to Ben Franklin's pre- revolutionary attempts at setting up and popularizing a post office. People are interested, but aren't ready to take the initiative and accept "new" ideas. If I might put in a selfish plug, get ahold of PGPSHEL2.ZIP at the soda.berkeley.edu site and give it to co-workers and "Windows types" (you all know who those newcomers are :-) ) who are vaguely interested in secure communications. I've discovered that non-DOS folks will let PGP sit on their hard drives for months without exploring it, but once they use PGPShell, begin taking an active interest in what PGP is and does. With all the discussion about what the difference is between Usenet and BBS's, this is probably an important difference as well. BBS users are still enamored with the *concept* of public key encryption, while the more experienced Usenet users take it for granted. They know there's something going on "up there" but aren't too sure what all this PGP talk is all about. The BBS users are an excellent place to "spread the word" about encryption and shouldn't be ignored. With their help encryption will be as normal and every day as the post office is today.

1 0

strong encryption as virus protection
by baumbach＠atmel.com 20 May '93

20 May '93

Hello all, It seems that an easely available (legal) software verification system needs to be made. If one were widely used, virus worries of people could be channeled into a demand for strong encryption. Tell people that the Crippler Chip might prevent this from ever happening. Peter Baumbach baumbach(a)atmel.com

1 0

DE encryption method
by meyer 20 May '93

20 May '93

The Dolphin Encryption Process The encryption process is a symmetric block cipher, where the block is any size from 1 byte to about 16K. The encryption key consists of a string of from 10 to 60 ASCII characters. The key is converted into six seed numbers using the MD5 message digest algorithm. These numbers are used to seed several pseudo-random-number generators (PRNGs). The key is also used to randomize other elements of the system. During encryption a series of extended and encrypted derivatives of the key are used to scramble the plaintext. The resulting ciphertext is further combined with a portion of the adjacent plaintext (in a way that depends on the key). The enciphered block is then expanded by the random addition of random bytes. Finally the enciphered block is shuffled in a way depending on the key. The explanation of the encryption process has the following sections: (a)PRNGs used (b)Key input (c)General initialization (d)Block initialization (e)Block encryption (a) PRNGs used The process employs two kinds of PRNG: (i) Multiplicative congruential This kind of PRNG is described in D. Knuth, The Art of Computer Programming, Volume 2, pp. 9-20, and in S. Park and K. Miller, "Random Number Generators: Good Ones are Hard to Find", Communications of the ACM, Vol. 31 No. 10 (October 1988), pp. 1192-1201. Three multiplicative PRNGs are used in the encryption process. (ii) Additive This kind of PRNG is described in D. Knuth, The Art of Computer Programming, Volume 2, pp. 27-31, and in S. Kirkpatrick and E. Stoll, "A Very Fast Shift-Register Sequence Random Number Generator", Journal of Computational Physics, 40 (1981), pp. 517-526. Five additive PRNGs are used in the encryption process. (b) Key input The process makes use of a user-input key and six seed numbers which are derived from that key. The user may enter any string of typeable characters. All lower case characters are converted to upper case, and all characters except the following 68 are eliminated: ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789`~!@#$%^&*()_+|-=\[]{};':",./<>? The resulting string is called the input key. The input key must consist of at least ten characters and at most sixty, and it must contain at least six different characters. If not then it is rejected. (c) General initialization Once an acceptable input key has been entered, there are two operations that are performed using this key before any actual data encryption occurs. (i) Six seed numbers in the range 4,000,000 through 1,431,655,765 are generated from the input key using the MD5 message digest algorithm. (ii) The three multiplicative PRNGs are used in different ways in the encryption process. Based on the key the particular ways in which they are to be used are determined at this stage. (d) Block initialization The block size must be specified. For each block the encipherment process occurs as follows: (i) The block is assigned a number in the range 0 - 65,535. (ii) The three multiplicative PRNGs are initialized using three of the seed numbers and the block number. (iii) A set of five additive PRNGs is randomly chosen from a set of thirty. They are initialized using five of the seed numbers, the block number and numbers generated by the multiplicative PRNGs. (iv) A sub-block length is randomly selected using one of the multiplicative PRNGs. Its value depends on the key, but lies in the range 30 through 180. (e) Block encryption Block encryption consists of three processes: scrambling, interpolation and shuffling. (i) Scrambling Scrambling involves two parallel encipherment processes: (1) A series of character strings are generated from the input key. The length of each string is at least 250 and at most 500 bytes and is chosen so as not to be divisible by the previously mentioned sub-block length; otherwise the length of the string is random. Each byte in this string is derived from a combination of a byte randomly selected from the input key and a value returned by one of the additive PRNGs. As each string is generated its MD5 message digest is also generated. The block is divided into a set of non-overlapping variable-length sub-blocks corresponding to the lengths of the strings thus generated. Each byte in each sub-block is modified by combination with a byte in the string, a byte in the MD5 message digest of the current string and a value obtained by using one of the PRNGs. (2) In the second, concurrent, process the block is divided into fixed-length non-overlapping sub-blocks which have the previously mentioned sub-block length. The bytes in each ciphertext sub-block are combined with some or all of the bytes in the corresponding plaintext sub-block in a manner involving the use of one of the PRNGs. (ii) Interpolation Meaningless bytes are now interpolated among the bytes of the ciphertext. This is done in a random way using one of the PRNGs and so that these interpolated random bytes can be eliminated during decipherment. This step generally increases the size of the block by 2% to 10%. (iii) Shuffling The bytes are then permuted (or in other words, shuffled) randomly by a process that again uses one of the PRNGs and the input key, and which is reversible if and only if the key is known. The completes the encipherment of the data block. This process may be performed on each block of data making up any larger block, such as a disk file.

1 0

Reply to queries concerning DE
by meyer 20 May '93

20 May '93

>From: Stanton McCandlish <anton(a)hydra.unm.edu> >Subject: Dolphin Encrypt >To: cypherpunks(a)toad.com >Date: Wed, 19 May 93 6:39:04 MDT > >> The recipient captures the entire message as, say, G.ENC, then runs: >> >> DE D G.ENC G.DEC /t >> >> (Of course, she has to know the encryption key.) Dolphin Encrypt >> skips over P1 to get at C2 and writes G.DEC containing P2. Voila! > >My question is, how does the recipient get the key, >and how do they (she, whatever) know to use that long de command? >What would happen if they didn't, just get gibberish? 1. I'm sure Stanton is aware (though perhaps there are some people who are not) that there were cryptosystems in existence before PGP, and before public key cryptography was invented. DES is an example. Such cryptosystems (in contrast to PGP) are called "symmetric key" systems since the key used to encrypt is the same as the key used to decrypt. This being so, there is the problem of how to get the key to the person decrypting the received ciphertext. (This is as true for DES as for any other symmetric key system.) There are ways, more or less secure. A secure way is to use PGP to transmit the encrypted key. If your only encryption need is transmitting encrypted email then PGP may be all you need. If you want to encrypt lots of 1MB database files, either to keep around or to transmit, then a faster encryption process is needed. 2. They know how to use "that long de command" (actually I think it's quite short) because they've RTFM or had it explained to them, just as for PGP. 3. If they didn't use it they'd just have a block of what looks like uuencoded stuff in the middle of the received message. If they put a wrapper around it and uudecoded they'd get *real* gibberish. >From: Eric Hughes <hughes(a)soda.berkeley.edu> >To: cypherpunks(a)toad.com >Subject: Mixing ciphertext and plaintext > >>If you wish to mix plaintext and ciphertext in an email message then >>you can use Dolphin Encrypt. > >What cryptosystem does Dolphin Encrypt use? Is the algorithm >published somewhere? > >Eric The encryption process was developed and refined, with no input from any government agency, during the last few years. A general description of it is given in the manual that comes with Dolphin Encrypt. I shall post this description in the following message. Comments are welcome. Although this description is quite detailed, it is not sufficient to work through the process with pencil and paper, since it is too complex. The complete details can only be understood from a study of the C source code, which is provided with the Dolphin Encryption Library, a C library usable by programmers to add encryption capabilities to application programs. More details available by snailmail; requests by email or to 512-479-9208. (We finally had our cute executive secretary record the message; sounds better now - and, no, she doesn't throw the Selectric typewriter ribbons in the trash. In fact, we feed *all* our cast-off confidential data to the hogs out back. Best security method we've ever used, though the dobermans are pretty good too.) -- Peter Meyer P.S. Info going out by snailmail to all who requested it.

1 0

MCI, Sprint or bust ...
by fergp＠sytex.com 20 May '93

20 May '93

I changed my telco service to MCI yesterday. "We want you back." AT&T won't get my business until they discontinue using Clipper. Somehow, I get the feeling that may be when hell freezes over. It leaves a bit to the imagination what the "i" in the "i" plan really stands for. Intelligence? Integrity-busters? Insecurity? I urge anyone who is seriously concerned over Clipper to put their money where their mouth is - boycott AT&T. Cheers. Paul Ferguson | "... certain unalienable Rights, Network Integrator | that among these, are Life, Liberty, Centreville, Virginia USA | and the pursuit of Happiness." fergp(a)sytex.com | -- The Declaration of Independence Stop the Wiretap (Clipper/Capstone) Chip.

4 3

Re: TEMPEST and other "neat stuff"
by smb＠research.att.com 20 May '93

20 May '93

This is an interesting extract that I came across this morning. I thought that I'd post a portion of it (the entire paper is almost 900 lines) to the group since the topic of TEMPEST had surfaced - I'd like to see the whole thing, but I don't guarantee I'll read it. In fact, I don't believe it. The use of TEMPEST is not illegal under the laws of the United States[3], or England. Canada has specific laws criminalizing TEMPEST eavesdropping but the laws do more to hinder surveillance countermeasures than to prevent TEMPEST surveillance. In the United States it is illegal for an individual to take effective counter-measures against TEMPEST surveillance. I can't speak for England or Canada, but neither statement is true about the U.S. Note the text of footnote [3]: 3. This Note will not discuses how TEMPEST relates to the Warrant Requirement under the United States Constitution. Nor will it discuss the Constitutional exclusion of foreign nationals from the Warrant Requirement. The ``warrant'' requirement is precisely the point. Spying on individuals who have a reasonable expectation of privacy is prohibited. In the case of wiretaps, that was in a Supreme Court ruling in, as I recall, 1967. In fact, the original wiretap statute (18 USC 2510 et seq), later amended by the ECPA, was passed (as part of the Ombnibus Safe Streets and Crime Control Act of 1968) in direct response to that ruling, to set forth procedures, grounds, etc., for legal wiretaps and surveillance. I don't have the citation handy, but the concept was discussed clearly and at some length in Kemp v Block (1985) 607 F Supp 1262. A TEMPEST pickup would appear to run afoul of the wiretap laws. Consider the following language in 18 USC 2511(2)(f): procedures in this chapter and the Foreign Intelligence Surveillance Act of 1978 shall be the exclusive means by which electronic surveillance, as defined in section 101 of such Act, and the interception of domestic wire and oral communications may be conducted. I'll return to the FISA later; note, though, that it and 18 USC 2510 are the *only* means by which anything resembling TEMPEST surveillance can be performed. The only grounds on which such intercepts can be justified, given the language of this section, is from 18 USC 2511(3)(g): It shall not be unlawful under this chapter or chapter 121 of this title for any person -- (i) to intercept or access an electronic communication made through an electronic communication system that is configured so that such electronic communication is readily accessible to the general public; Is TEMPTEST ``readily accessible to the general public''? At least since the adoption of the FCC requirements on spurious RFI, I'd tend to doubt it. And as I noted earlier, eavesdropping of any sort is legal if and only if the targets have no reasonable expectation of privacy; given that 99+% of the American public has never heard of TEMPEST, I'd call it a fair bet that someone using a computer in a private room does, in fact, assume that he or she has such an expectation. The Foreign Intelligence Surveillance Act (50 USC 1801 et seq.) specifies the conditions under which foreign agents may be subject to surveillance. Unless there is ``no substantial likelihood'' that an American's conversations will be observed, an order from a special court is needed. Again -- for the most part, there is a requirement for due process. Now -- I'm certainly not going to claim that these niceties are always observed. But that they're ignored doesn't make them legal. Finally, the claim that taking counter-measures against TEMPEST is illegal strikes me as balloon juice, plain and simple. Last I heard, the FCC wanted you to do anything you could to reduce spurious emissions. True, they're not telling how sensitive their detectors are -- but that's a far cry from saying you're not allowed to try to defeat them. Please -- there are real enemies to personal freedom. Let's not waste energy chasing chimeras. --Steve Bellovin

1 0

The New Mykotronix phones...
by Mr. Noise 20 May '93

20 May '93

Please forgive me for replying to a message that's already a month old, but I was in the process of wading through the messages that have swamped my mailbox while I was doing end-of-the-semester stuff & didn't come across any replies...so just a brief note or two before I submerge again to study for my last Ph.D. comprehensive: > Okay, let's suppose that the NSA/NIST/Mykotronix Registered > Key system becomes standard and I'm able to buy such a system > from my local radio shack. Every phone comes with a built in > chip and the government has the key to every phone call. > I go and buy a phone and dutifully register the key. > > What's to prevent me from swapping phones with a friend or > buying a used phone at a garage sale? Whooa. The secret registered > keys just became unsynchronized. When the government comes > to listen in, they only receive gobbledly-gook because the > secret key registered under my name isn't the right one. This is a good, creative response to fascist technology, but I wonder if I'm the only one on this list who's noticed a parallel between the government's attitude toward small arms & its attitude approach to cryptography? (After all, cryptographic technology *is* dealt with as a 'munition' in the export laws, right?) While this means that many of the same defenses apply to crypto as to arms--as in "When codes are outlawed, only outlaws will have codes," a tagline I made up when I first started using PGP--it also means that we can expect the government (& other opponents) to use similar tactics in trying to deny us our right to privacy. So how might the government respond if we were to use the tactic described above? Well, just consider what they would do if you loaned someone your handgun & they committed a crime with it: they hold you responsible as well. If we allow a system of key registry to be instituted in any form, I think we can expect the same boneheaded legislation restricting our freedom to use cryptography as is currently inflicted on would-be gun owners. If nothing else, "key permits" would represent a new source of revenue for the tax-crazed Clinton administration & governors across the fruited plains! Consider that, in order to obtain local & state permits to carry a handgun in my home state of Connecticut it costs a total of $50 for the first year alone & $25 per year to renew the liscence (it may cost even more in other towns, I don't know)! & then there's the paperwork, & the wait, &....

1 0