December 2003 - cypherpunks-legacy

Re: NSA/ITAR
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 9:43 PM 3/25/96, Vladimir Z. Nuri wrote: >TCM: > >>* EXPORT OF CRYPTO BEYOND U.S.: This is indeed a thorn in the sides of U.S. >>companies, but is not _per se_ an issue I worry about. So long as I have >>strong crypto, I don't really care too much about export. It would be nice >>to get the ITARs modified, but not at the risk of adding language (such as >>Leahy did) making use of encryption a possible crime (we've debated this, >>so I won't elaborate here). Besides, I think the best way to overturn the >>ITARs is through a court challenge; as I have noted, even the NSA's lawyers >>felt that the ITARs would not withstand court scrutiny. > >hmmmm, I don't recall you saying that. would love to hear more about >"NSA's lawyers feeling the ITAR cannot withstand court scrutiny". My most recent mention of this was a few days ago, where I cited Carl Nicolai, inventor of the suppressed "PhasorPhone," as my source. He and his lawyer got access to papers inside the NSA building, though they could not make copies. They found memos from NSA staffers saying that the ITARs had never been tested in court and would not likely survive a full Consitutional test and that it would thus be best if court cases were avoided. I passed this information along to the Lee Tien, representing Gilmore in various cases, and to Phil Karn. --Medusa

1 0

Re: WSJ on Big Java Flaw
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 11:07 PM 3/26/96, Steve Gibbons wrote: .... >Actually, I suspected and reported the same bug some weeks before the group at >Princeton. <URL: http://www.aztech.net/~steve/java/~>. That said... .... Thanks for the pointer. I found it most interesting. I suppose that I am glad that I am not the only one who doesn't know how DNS works.

1 0

RE: Weapons & Hope
by Eric Anderson 17 Dec '03

17 Dec '03

---------- From: Duncan Frissell[SMTP:frissell@panix.com] Sent: Tuesday, March 26, 1996 8:42 AM To: cypherpunks(a)toad.com Subject: Weapons & Hope While it might be barely possible in the mass production age to control weapons by blocking the flow of these specific products (a Streetsweeper, say) into the marketplace, it will clearly not be possible in the age of custom production. General machines will be available to produce specialized products (often under the direct control of the customer, himself). Some of this custom production will be weapons. I took machine tool operations @ my local community college. suffice it to say, good, high-quality firearms are **EASY** to fabricate (Believe me!) So my point is this: Just as the Gov't CANNOT prevent me from making a gun in my basement, whats to stop some high-school juinor from writing a strong crypto program? I can just see Chuckie Schumer introducing (W/ Sen. Fine-Swine as co-sponor) a bill to ban "Cyberwar Software" i.e. mandatory registration of compilers, mandatory GAK, etc... What an asshole. Take care, Eric

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

The syslog problem is fixed in baseline SunOS 5.5. Sun and HP are apparently doing what the stupid law mandates - and they should do so, whether someone at NSA (or whatever) is on their case or not. :) They should also have someone in their respective legal departments bucking ITAR very hard. "tres-dangerous" must have been typed with a snear, no? ECafe Anonymous Remailer wrote: > > I noticed that Sun's latest libc patch (101759-04) is empty. Previous > versions contained the complete U.S. version of libc, including the > tres-dangerous DES and crypt functions. In the current rev only the > README remains, presumably because: > EXPORT INFORMATION: This patch includes code which performs > cryptographic functions, which are subject to U.S. export > control, and must not be exported outside the U.S. without > prior approval of the U.S. government. Prior export approval > must be obtained by the user of this patch. > > So, you might ask, what fixes is Sun not distributing??? > (Rev 04) > 1190985 gethostbyname() can trash an existing open file descriptor. > 1182835 portmapper silently fails with version mismatch by PC-NFS > client > 1219835 Syslog(3) can be abused to gain root access on 4.X systems. > > Yup, that's right. The syslog hole that was so well publicized by > CERT will remain open indefinitely because the ITAR makes it illegal > for Sun to distribute the fix! > > So did HP and Sun spontaneously, simultaneously develop crypto awareness, > or is some gummint dweeb whispering threats in their ear?

1 0

Re: Why Americans feel no compulsion to learn foreign languages
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 2:22 AM 3/28/96 -0800, Timothy C. May wrote: >... In any case, the issue is not the >classes taken by _some_ (the few percent who study Russian, Japanese, >Mandarin, etc.), but the topic of this thread: "Why Americans feel no >compulsion to learn foreign languages." I, at least, want to know something of the language of the countries I travel in. Being able to get a meal or a room for the night is useful. As a rock bottom minimum, I want to know the phrases: Hello, Good by, Please, Thank You, More beer please, and Where's the bathroom. The look of pleased surprise on the face of the Budapest resident when I said "Thank you" to in Hungarian as he gave up his seat to me because I was loaded down with caving equipment is something I still treasure. Regards - Bill ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

No Subject
by owner-cypherpunks＠toad.com 17 Dec '03

17 Dec '03

Blanc Weber writes: > Perry, here's a question for you, and I am seriously interested in your > answer: [...] > what, then, would you yourself consider proper for discussion here? > [in the context of digital cash discussion] I'd say that anything directly dealing with digital cash, its implications, deployment, and technical issues associated with it. General discussions of whether the Federal Reserve is a bunch of evil old men and the like are what are out of bounds. This means: "How does blinding work" and "Do you think that digital cash systems will hurt bank regulatory supervision" are fine things to talk about but "Do you think the Federal Reserve issues counterfeit money" are not. Perry

1 0

Re: firewalls and CKE (fwd)
by Adam Shostack 17 Dec '03

17 Dec '03

Marcus Ranum posted this to firewalls. Contains some interesting technical arguments against key escrow at the firewall level. ----- Forwarded message from Marcus J. Ranum ----- >From firewalls-owner(a)GreatCircle.COM Mon Mar 25 21:26:27 1996 From: "Marcus J. Ranum" <mjr(a)clark.net> Message-Id: <199603252204.RAA01115(a)clark.net> Subject: Re: firewalls and CKE To: mckenney(a)smiley.mitre.org (Brian W. McKenney) Date: Mon, 25 Mar 1996 17:04:41 -0500 (EST) Brian W. McKenney writes: >I missed the jist of the original message The gist of the first message was that software key escrow is here, and it is the greatest thing since the discovery of fire. :) Granted, it's nice that someone has found a way of convincing the government to let them export good crypto, but in this particular application it makes no sense. >For the firewall-to-firewall encryption >scenario, the data recovery component (DRC) may be a machine that >intercepts (in real-time) the traffic and then decrypts the data (recovers >the data). The interception of encrypted data makes sense for this type of >communication since the data is not really stored on the firewall (it is >wrapped/unwrapped quickly). [the intercepted packet may be copied and then >decrypted] That's completely brain-damaged if you think about it for a second. Let's suppose I have a file and it is unencrypted. I FTP it through my SKE-equipped firewall to the Paris office. My file gets transparently encrypted as it is broken into packets and sent across the 'net. Then - what - someday I need the file back so I get the escrowed key and reassemble the file from raw packets? That's dumb! I dunno about you but I'd just recover the clear file from a backup tape. :) Firewall-to-firewall encryption is a link-layer security technology. It encrypts data in transit: before it leaves and after it arrives you *already* have a clear-text un-escrowed version of the data. If I have a corporate requirement to "escrow" my telnet sessions then I'll use a version of telnet that logs keystrokes. But I can't see any reason (unless I'm a spook) to de-archive, de-escrow, and reassemble a telnet session for archival purposes. It gets worse since all the "escrowed" packets will be mishmoshed in with DNS queries (all "escrowed") and NFS packets and lordy knows what else. If it came to having packet records, why not simply log all packets *before* they get encrypted at the firewall, while they are still in the clear? Easier, no? At least LOTUS' "key escrow" approach is openly designed for the spooks and doesn't pretend to add value to the end user. I appreciate that TIS has made a successful deal with the devil to export some strong encryption, but it's unfortunate that they're showcasing it in a way which makes absolutely no sense at all. It's a shame, because basically we're seeing smart people doing technically goofy things in order to comply with some ridiculous laws. mjr. ----- End of forwarded message from Marcus J. Ranum -----

1 0

Returned mail: User unknown
by Ben Srour 17 Dec '03

17 Dec '03

Spelling is the KEY to life. >>X-Sender: issup5@mail >>Date: Mon, 26 Feb 1996 11:32:17 +0200 >>To: "cypherpunks(a)toad.com" <cypherpunks(a)toad.com> >>From: Nibiru <nibiru(a)columbus.co.za> >>Subject: unsubscrive >>Sender: owner-cypherpunks(a)toad.com >> >>unsubscrive cypherpunks >> >> >>------------------------------------------------------------------- >>NIBIRU >>E-Mail : nibiru(a)columbus.co.za >>South-Africa >>-------------------------------------------------------------------- >> >> >> > >

1 0

Re: Why Americans feel no compulsion to learn foreign languages
by mike＠fionn.lbl.gov 17 Dec '03

17 Dec '03

On Mar 27, 10:57pm, Jonathon Blake wrote: > One other advantage to knowing a language other than > English. Legal encryption. << Unless a federal law > encrypt it with PGP. Would the cryptanalysts recognise > the plain text, even if they had it? >> Well, it's a special case of security by obscurity, isn't it? If the language is something unusual, maybe that helps, but if the language is too obscure, you may be identified (by your ethnicity, your history, or your friends/community) as a speaker of it. I guess it does raise the economic cost of "decipherment" some. But many immigrant parents have learned to their embarrassment that this kind of encoding doesn't work too well %^) The Navajo/Na Dene codetalkers (WW II) developed a real arcane jargon, so I was told. Maybe it was because the conditions of war were completely different than their language's environment so they were forced to invent words, or maybe they thought it was a good idea, or whatever. But I believe transcripts of their transmissions are often mostly unintelligible to native Navajo speakers who weren't in the know.

1 0

Re: The Law Loft: Surviving the Biometric I.D. Card
by Hal 17 Dec '03

17 Dec '03

I have been surprised not to hear more about this aspect of the immigration reform laws. Unfortunately the alert which Tim forwarded is out of date, and I believe the reforms did pass in some form. I view biometric identification as a very disturbing development and I'd like to hear more about the wording of the bills as finally passed. If they really want to give people a card which proves their legal residence in the US, a less intrusive approach is possible. Rather than set up a database of all employees, and/or give each person an official identity card, instead have people come and prove their residency, then give them a card with the biometric information and a blind signature. No other information goes on the card, no information goes into a database. The signature is a certificate testifying that the person with the particular thumbprint is legal to work in the US. The card can't be transferred since no one else has that thumbprint. But no identifying information is recorded. There is no advantage in people coming in twice to get more than one card since their print will be the same each time, so no database is needed. A simpler approach dispenses with the blind signature and just issues a regular signature on the thumbprint or other biomarker. This is about as good since proving residency will probably require at least an incidental display of identity papers, so you are already trusting the agency not to log you, and you can just as easily trust them not to log the signature. This is an approach which accomplishes the goal with a minimal intrusion into people's privacy. I don't know how it compares with current biometric concepts - maybe this is similar to what they are proposing, minus the database. But there is a general principle that government regulations should use the least restrictive means where they violate people's rights, such as the seriouss privacy violations in the current proposals. So I think it should be possible to make a strong argument that privacy protecting alternatives which accomplish the objective must be considered. The key concept is to unlink identity from the credential. That is the crucial idea of credentials, one which has not yet pentrated the popular consciousness. Maybe we need to start pushing it more. You don't have to prove your identity to prove you have certain qualifications. There is no need to tie everything to a central identifier. A system of dispersed, stand-alone credentials will be far better at protecting privacy. Blind signatures can help protect against cheating, but policy can work too, especially when credentials are issued by a public agency on a large scale, so systematic and secret record keeping is impractical since so many people are involved. I know a lot of people will oppose even this form of biometric information, which is not tied to identity. Perhaps we could have some discussion on the degree to which people see this kind of system as a privacy threat. If the credential concept is new we could discuss that, too. Hal

2 1