December 2003 - cypherpunks-legacy

Study of National Cryptography Policy
by Herb Lin 17 Dec '03

17 Dec '03

February 3, 1994 To: Whom It May Concern Subject: A Study of National Cryptography Policy This message should be forwarded to any and all individuals or groups that may be interested. ----------------------------------------------- In a message broadcast electronically and by fax in December 1993, the Computer Science and Telecommunications Board (CSTB) of the National Research Council (NRC) issued a call for nominations of possible committee members who would undertake a study of national policy with respect to the use and regulation of cryptography. This report was requested by the U.S. Congress in the Defense Authorization Bill for FY 1994. That message said that ALL committee members (and associated staff) would have to be cleared at the "SI/TK" level. Since that time, there has been some discussion of a study that would only require SOME members of the study committee to be cleared. Thus, in the interests of casting the broadest possible net to capture the necessary expertise, we are re-issuing the call for nominations to find those people who otherwise fit the criteria below but who would have been reluctant to accept security clearances or to undergo the required investigation. It is expected that the study committee will be a high-level group that will command credibility and respect across the range of government, academic, commercial, and private interests. The committee will include members with expertise in areas such as: - relevant computer and communications technology; - cryptographic technologies and cryptanalysis; - foreign, national security, and intelligence affairs; - law enforcement; - commercial interests (both users and technology vendors); and - privacy and consumer interests. Committee members will be chosen for their stature, expertise, and seniority in their fields; their willingness to listen and consider fairly other points of view; and their ability to contribute to the formulation of consensus positions. The committee as a whole will be chosen to reflect the range of judgment and opinion on the subject under consideration. Note that NRC rules regarding conflict of interest forbid the selection as committee members of individuals that have substantial personal financial interests that might be significantly affected by the outcome of the study; in addition, individuals currently employed by the federal government are ineligible to serve on the study committee. Please forward suggestions for people to participate in this project to CSTB(a)NAS.EDU by February 11, 1993; please include their institutional affiliations, their field(s) of expertise, a note describing how the criteria described above apply to them, and a way to contact them. For our administrative convenience, please put in the "SUBJECT:" field of your message the words "crypto person". If you would like a copy of the original solicitation, please send a request to CSTB(a)NAS.EDU. On the National Research Council The National Research Council (NRC) is the operating arm of the Academy complex, which includes the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine. The NRC is a source of impartial and independent advice to the federal government and other policy makers that is able to bring to bear the best scientific and technical talent in the nation to answer questions of national significance. In addition, it often acts as a neutral party in convening meetings among multiple stakeholders on any given issue, thereby facilitating the generation of consensus on controversial issues. The Computer Science and Telecommunications Board (CSTB) of the NRC considers technical and policy issues pertaining to computer science, telecommunications, and associated technologies. CSTB monitors the health of the computer science, computing technology, and telecommunications fields, including attention as appropriate to the issues of human resources and information infrastructure and initiates studies involving computer science, computing technology, and telecommunications as critical resources and sources of national economic strength. A list of CSTB publications is available on request.

1 0

Re: contemplating remailer postage
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Matthew J Ghio writes: > How about this: > > Issue numbered stamps sequentially. Encrypt them and > add a cryptographic checksum to each stamp. You then > create a database such that one bit of data corresponds to > one stamp. With a mere 64K database, you could issue and > keep track of 524288 postage stamps. That ought to last > you a few years. (At 100 letters a day, it would last over 14 > years. Most cypherpunk remailers get considerably less > than 100 emails a day.) > > > If the remailer constructs the stamp, rather than just signs it blindly, it could keep a log of which stamps were issued to which users. The remailer could then use this information to figure out the original sender of a stamped message regardless of how many other remailers the message passed through. To thwart this, users would have to purchase stamps anonymously. However, this begs the question: How does the user anonymously purchase stamps for the first remailer? I suppose you could use "free" remailers to send anonymous purchase requests to stamp-issuing remailers. The system I described does not require you to purchase stamps anonymously. You can purchase stamps directly from each remailer without giving the remailer the opportunity to record which stamp went to which user. To understand why this is true you need to understand how blind signatures work. The book "Applied Cryptography (Bruce Schneier)" gives a good description of the properties of blind signatures. That is how I learned about them. The remailer could still record the fact that you purchased stamps, thus alerting the bad guys that you plan to use the remailer system. However, I don't think it is possible to prevent the bad guys from learning that you use remailers. I assume the bad guys will be logging all traffic to the remailers and would learn about your use of remailers, stamps or no stamps. Jim_Miller(a)suite.com

1 0

No Subject
by The.Ghost 17 Dec '03

17 Dec '03

testing...

2 1

Message returned to sender (fwd)
by Jim choate 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Re: SASE Suggestion
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Lance Cottrell writes: > One SASE scheme recently suggested involved sending a > request for a SASE to a ramailer, stating the number of > jumps required. It then sent it to another remailer, and > so on. Each adding a layer, and eventually sending the > results to the desired correspondent. I mentioned that > if the first remailer was corrupted, that the whole chain > was (it would only send to other corrupt remailers). > Oh, I see. I was confused as to which scheme you were talking about. You were refering (I think) to the "prepaid mailer" idea Tim May described in his "Re: Anonymous Anonymous ftp" post of Jan 27. Jim_Miller(a)suite.com

1 0

Re: A question of ethics.
by pgpkeys＠wasabi.io.com 17 Dec '03

17 Dec '03

>Ok, I'm in a bit of a quandry. While surfing the net last week, I >happened across an address addached to a machine that belongs the the >federal reserve. No big deal. I telnetted there on a lark, and entered >'guest' for the account. It dropped me into a shell. It didn't ask for >a password. Intrigued, I did a little looking around. Nothing special, >a CDRom and about 80 accounts. But(!!), /etc/passwd was there and >available and not using shadows. No, I didn't snatch a copy. > >Quandry(ies) > >1) Should I alert someone there about the obvious (and, IMHO serious) >seciruty hole? > > or > >2) Should I ignore it? > >3) Should I take advantage of it (well, maybe not) > >---------- > >I don't like to see systems so open, no matter who they belong too, and >the fact that the governments (whether you like them or not) has one this >open REALLY bothers me. > >But, I also wonder what kind of trouble I could get into. Technically, I >violated something just by being there as I didn't have permission, and >the fact I accessed the passwd file makes it even worse. If I report it, >I could be in deep shit. > >I could mail to them via a remailer (like penet.fi, so that they could >answer for more information if needed). That is a little securer and >Julf is out of jurisdiction of the FBI hunting me down. > >Yes, I'm a little paranoid, but Uncle Sam likes to make examples out of >white-collar hackers, and for me it was pure and dumb luck (like a jury >would believe a 22 year-old computer geek isn't trying to gain illegal >access). > >Any suggestions? Please? I consider this to be serious (most may not). Go to a COCOT and call Ms Flanagan below. *Not* the Tech contact, who is most likely the person who fucked up and will want to cover his butt. The admin contact should be more sympathetic... 20th and C Streets, NW Washington, DC 20551 Domain Name: FRB.GOV Administrative Contact: Flanagan, Elizabeth R. (ERF7) erf(a)FED.FRB.GOV (202) 452-2672 Technical Contact, Zone Contact: Drzyzgula, Robert P. (RPD5) rcd(a)FED.FRB.GOV (202) 452-3425 Record last updated on 14-Aug-91. Domain servers in listed order: NS.UU.NET 137.39.1.3 UUCP-GW-1.PA.DEC.COM 16.1.0.18 UUCP-GW-2.PA.DEC.COM 16.1.0.19

1 0

Canadian voice recognition article
by cmckie＠ccs.carleton.ca 17 Dec '03

17 Dec '03

Spy Agency works on eavesdropping device for phones, faxes New snoop gadget would identify voices carried through air The Canadian Press Used on page 1, Ottawa Citizen, Monday January 31, 1994 An elite wing of Canada's spy agency is secretly developing devices that can monitor and identify voices carried through the air by phone, fax and radio signals, according to a broadcast report citing government documents. The Communications Security Establishment is a super-secret branch of the Canadian Security Intelligence Service that specializes in gathering signals intelligence - SIGINT to insiders. Since 1989, the CSE has awarded three contracts worth $1.1 million to a Montreal firm to make machines that can quickly isolate key words and phrases from the millions of signals the CSE monitors each day, CTV reported Sunday. In May 1983, the CSE awarded the Centre de Recherche Informatique de Montreal a contract to develop a "speaker identification system," which can pick voices from the electronic haze and identify them. "Its frightening," says Bill Robinson, a researcher with the peace group, Project Ploughshares. "It has Orwellian potential to sweep through everybody's conversations. As computers get faster and faster, theoretically, one would be able to keep records of all conversations." The CSE is supposed to provide the federal government with foreign intelligence, but parliamentarians have often voiced concerns about the agency's potential to violate the privacy of Canadians. Liberal MP Derek Lee, the head of a Commons committee that oversees Canada's spy agency, said the CSE is overstepping its mandate. "Have they been asked, or have they decided for themselves to take on a new role that requires them to analyse the human voice? And if they have, they've gone beyond what I think they've told us." The CSE is accountable to Parliament through the defence minister. But Defense Minister David Colonette told CTV her was unaware of the CSE's latest electronic snooping projects. "This is the first I've heard of this," Collenette said. "It is certainly something I'll discuss with my officials." While in Opposition, the Liberals pledged to make the CSE more accountable. With a budget of about $250 milliojn and more than 800 employees the CSE operates out of a building on Heron Road in Confederation Heights surrounded by a barbed-wire fence. Its work is considered so sensitive that employees are told not to take commercial flights, in case the plane is hijacked and they are held hostage.

1 0

Remailer Tearline Conventions
by anonymous＠extropia.wimsey.com 17 Dec '03

17 Dec '03

* Reply to msg originally in CYPHERPUNKS Uu> From: edgar(a)spectrx.saigon.com (Edgar W. Swank) Uu> Someone (not me) asked about remailer tearline conventions to Uu> eliminate automatic sigs: Uu> I'm the one who brought this up "months ago" and the short answer to Uu> your question is "no." Uu> Hall Remailer <nowhere(a)bsu-cs.bsu.edu> Uu> added a "cut line" of Uu> --ignore-- Uu> At the time I brought this up, the attitude of most remailer operators Uu> (Chael Hall and Miron Cuperman notably excepted) was that anyone who Uu> couldn't figure out how and remember to turn off their auto sig didn't Uu> deserve any privacy. An astonishing bit of Internet provincial fuckheadedness, I must say! When one considers that there are _many_ other nets that gate into Internet these days and innumerable store-and-forward host systems whose message handling processes are _completely_ beyond the control of the end user (even smug Cypherpunk geniuses), this attitude mystifies me. Uu> I recommend that you always use the wimsey (extropia) remailer as the Uu> first (or only) leg of a remailer chain. It is also the only Uu> Cypherpunks remailer outside the USA (it's in Canada) which will make Uu> tracing msgs a little more difficult for USA authorities. That remail(a)extropia.wimsey.com is in Canada specifically makes communications with it fair game for NSA interception, however.

2 1

Re: On return addresses
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Eric Hughes writes: > I've been troubled for many months by an invariant in all forms of > return address schemes: The outside world contains sufficient > _persistent_ information to find a real adress. > > [stuff deleted] > > So how do we solve it? By abandoning return addresses and > using mail spool facilities. > > [more stuff deleted] > > 1. I have a machine and I'll sell you an address on it... > > 2. When mail come in for you, it sits in a spool... > > 3. Your mail sits in the spool until you access it with... a > mail server command of "send me a mailbox file of my > waiting mail". > > [even more stuff deleted] > > The elimination of persistent identifying information > for return paths is a worthwhile design objective. I > propose that we start thinking about it more thoroughly. > > Eric > Let me see if I understand your idea correctly. I am picturing something like the following: There will exist a bunch of remailers that, in addition to forwarding mail, will also sell mailboxes. (I'm combining the remailer with the mail spools to add to the mix of messages to and from). The "mailboxes" are actually e-mail addresses referring to a pseudo-account on some machine that hosts a remailer/mail spooler. Bob would purchase a number of mailboxes scattered throughout the remailer/mail spooler system. Bob would give out the address of one of these mailboxes to people so they can send "reply" messages to him. Messages addressed to Bob's "public" mailbox would be spooled by the remailer hosting that mailbox. Periodically (perhaps frequently), Bob would send an anonymous message (via other remailers) to the remailer hosting his public mailbox to command the remailer to send the contents of his mailbox to one of his other mailboxes. The remailer wouldn't necessarily know it's sending to another mailbox, it's just sends to an address supplied in the command message. Bob repeats this process to move his messages from his second mailbox to his third mailbox, and so on. Eventually, he moves his messages from his Nth mailbox to his "real" address. Is this approximately what you had in mind? I left out IP redirectors and POP clients because I'm not familiar with them. Jim_Miller(a)suite.com

1 0

CRYPTO - New US keyserver now fully operational -
by fringeware＠illuminati.io.com 17 Dec '03

17 Dec '03

Sent from the cyberdeck of: pgpkeys(a)wasabi.io.com (PGP Slave Key Server) The US-based keyserver 'pgp-public-keys(a)io.com' is now open to the public. Come one, come all! Here is the current file as returned by 'Subject: help'. This site is a PGP key server SLAVE site. It behaves very similarly to the European PGP master sites, but there are a few small differences which will be noted below. The most noticable difference is that it answers your requests immediately instead of waiting for a daily batch job to run :-) The particular installation at io.com does *not* log the details of requests for keys, however the fact that you have sent mail to the key server at all is logged in the daily sendmail logs. These logs will be erased automatically after one week. PGP Public Keyservers --------------------- There are PGP public key servers which allow one to exchange public keys running through the Internet and UUCP mail systems. This service is NOT supported in any way whatsoever by the schools or organizations on which these servers run. It is here only to help transfer keys between PGP users. It does NOT attempt to guarantee that a key is a valid key; use the signators on a key for that kind of security. This service can be discontinued at any time without prior notification. Each keyserver processes requests in the form of mail messages. The commands for the server are entered on the Subject: line. To: pgp-public-keys(a)io.com From: johndoe(a)some.site.edu Subject: help Sending your key to ONE server is enough. After it processes your key, it will forward your add request to other servers automagically. For example, to add your key to the keyserver, or to update your key if it is already there, send a message similar to the following to any server: To: pgp-public-keys(a)io.com From: johndoe(a)some.site.edu Subject: add -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 <blah blah blah> -----END PGP PUBLIC KEY BLOCK----- COMPROMISED KEYS: Create a Key Revocation Certificate (read the PGP docs on how to do that) and mail your key to the server once again, with the ADD command. Valid commands are: Command Message body contains ---------------------- ------------------------------------------------- ADD Your PGP public key (key to add is body of msg) *** Note: your update is forwarded to a master server and may take a few days to reappear INDEX List all PGP keys the server knows about (-kv) VERBOSE INDEX List all PGP keys, verbose format (-kvv) GET Get the whole public key ring GET 0xA1B2C3 Get a single key by Key ID *** Note: the master servers allow you to omit the 0x in front of the Key ID. The slave servers do not. GET userid Get a single key by User ID MGET substr List all keys which match "substr" *** Note: this is different from the master servers which return the keys themselves, not just a listing of their Key IDs. Also the master servers accept a wild-card expression; at the moment we do not. LAST days Get the keys updated in the last `days' days *** Note: not yet implemented ------------------------------------------------------------------------ Examples for the MGET command: MGET michael Lists all keys which have "michael" in them MGET @iastate.edu Lists all keys which contain "@iastate.edu" Check the Usenet newsgroup alt.security.pgp for updates to this system and for new sites. Based on a document originally by Michael <explorer(a)iastate.edu>

1 0