December 2003 - cypherpunks-legacy

CSSPAB meeting of September 1 and 2.
by Peter Wayner 17 Dec '03

17 Dec '03

I'm sorry that this is so late, but I got backed up doing too many other things. Feel free to go to the anonymous mailers and post sarcastic remarks, straight-forward discussions or other comments. --Peter ----------------------- Here's my report from what I saw attending the Computer System Security and Privacy Advisory Board meeting on September 1st and 2nd in Baltimore, MD. This group is a Congressionally chartered organization with the responsibity to render advice on questions of cryptography and computer security. It's members are made up of people from government and industry. One member must be a representative from the National Security Agency. The meeting this time was at the Hyatt in Baltimore and there were several differences between this meeting and the last two which were held at the National Institute of Standards and Technology in Gaithersburg, MD. First, there were coffee, juice and doughnuts available in the morning. Second, I did not notice any recording devices or stenographers keeping track of what was said. Previous meetings at NIST had been both video and audio taped. There were two major parts to the meeting: 1) listening presentations from a variety of different people and 2) debating resolutions about the government's proposed Key Escrow standard. I attended most of the presentations, but I skipped most of the debate about the resolutions. The remarks that follow are basically my personal recollections. The most interesting bit of information I learned on the first day concerned a software version of the Key Escrow system. The strongest and least controversial arguments against deploying all revolve around the fact that the proposed chips we've seen so far are all based in hardware. Adding an additional chip to computers and phones costs money ($25-100), adds weight (bad for portable phones) and increases power consumption. None of these are desirable attributes. More importantly, a hardware standard not very flexible and the nation's entire computer system could be compromised for 6 months to a year if the key escrow agents went bad. That's my estimate for the amount of time it would take us to replace all the chips. NIST, in recognition of these facts, has announced a "Cooperative Research and Development" plan (called CRADA-- the "A" might stand for agreement). This would allow members of industry and academia to join together with NIST and the NSA to try and discover a good, software based, Key Escrow scheme. Ray Bonner, deputy director of NIST, discussed the plan and said that he wasn't sure that it would lead to anything but that it was worth a try. He also said that we should keep a copy of the Federal Register containing the announcement (Vol 58, #162, Tues, Aug 24 1993, pg 44662) because it could be the only CRADA ever involving the NSA. It could become a collectors item. If anyone is interested in getting involved with this project, they should call Dennis Branstad at NIST (301-975-2913). To me, it seems like it is easy to accomplish a key escrow plan in software. It just depends how many features you want to add. A simple method is to encrypt the session key with the government's public key(s)and append this in a LEAF. If the cops wanted to listen in, they could decrypt the LEAF using the private key(s that would be kept by the escrow agency. Naturally, this could be compromised if the keys got out. More sophisticated methods could involve a three-way Diffie-Hellman key exchange at the start of each conversation on the phone system. Or the government might want to explore Silvio Micali's work at MIT. It would also be possible to use Gus Simmon's subliminal channels to implement a signature/escrow scheme. The LEAF would be a DSS signature and the session key would be held in subliminal channel. The other half of the conversation would be able to verify that the LEAF was there and the conversation was authentic, and the LE people could get the key if they so desired. (This could be easily broken. I can't remember the details of Simmons's solution at this moment.) There are several other answers that come to mind. The traditional objections to software implementations of the Key Escrow plan are (1) easy tamperability and (2) publication of NSA secrets. While software may be easier to change, people have also proposed very simple ways to circumvent Clipper. If both halves of the conversation coordinate themselves beforehand, any amount of duplicity is possible whether or not a hardware chip is part of the standard. It is possible to super-encrypt the entire data stream in software and the LEAF would be foiled. It doesn't seem as if there is that much difference on a relative scale. The critical problem to developing a software key escrow system is finding a way to prevent a modified piece of software from working with an unmodified piece of software. This would stop people from establishing links without prior arrangements for extra security. I believe that this may be possible to do this using two different types of LEAFS and shifting session keys every so often. Of course, sending out a software version of an algorithm will leak information from the NSA-- something that really worries them. But the CRADA says that the NSA will work on the software Key escrow plan on a complete unclassifed basis. People on the CSSAB made light of the strangeness of all of this. Other Presentations Most of the rest of the meeting was devoted to people not saying anything on purpose. The plan to give the DSS to the RSA to resolve patent differences and give the nation a standard has not generated any new facts. Mike Rubin, the lawyer in charge, was not at the meeting and he is apparently processing the public comments as I write. Some summarized the comments as uniformly stating, "Free is good, paying is bad." A group of computer scientists from NIST came to discuss their plan for the Federal Criteria for secure systems and the new "Common Criteria" that may emerge. This is an updated version of the old Orange Book classification scheme of C2 and B1 and stuff like that. The scientists said the draft is being finished but it isn't ready for release. But now, they're working on "Something Better." This is a new plan to standardize the grading of secure systems with other countries and evolve a "Common Criteria." In general, the board groused about the fact that the public and industry have never been invited to give comments during the process. The summary of this talk is: "We might be able to tell you something someday." Geoff Greiveldinger took up a whole hour in the afternoon to tell us that it would be impolite for him to discuss the key escrow system with the CSSAB before talking about it with Congress. He is the lawyer from the Justice department responsible for setting up the system. Some members of the board mentioned that the board was chartered by Congress and so he could speak freely, but others refused to be so impolite as to question his polite excuse. He filled the hour with more descriptions with all of the restrictions that they place on wiretaps at the Justice department. Once again, I found myself wondering why they are going through so much trouble over something that just seems to cause them grief. The taps cost money. They divert manpower. Etc. Yet, the FBI and the rest of the community is willing to go through a full court press on this topic. The taps are essential in crime encapsulated in conversations (i.e. influence peddling, bribery). Perhaps those of us outside of government (sadly only 4 out 5 people) should quit worrying about this topic. The crimes we're likely to commit all involve action: grand theft auto, drunk driving, pickpocketting, murder, rape, illegal parking etc. No one really cares what we say. It's just if we _do_ something and violate a property right. Usually, members of the government are the ones who could break the law just by openning their mouth. Some people from the Social Security Agency came to tell the board about their internal security procedures that they use to track down people inside the agency generating information for outsiders like private detectives. They routinely run sting operations where they call up information brokers and ask them to get a Social Security file for an individual. Then they watch for accesses to that record and flag the miscreant. One of the old hobbies at the agency was looking up the records of stars. (When your job is sitting around watching people get old, you've got to have something to do.) The agency keeps a watch list of the celebrity's real name and SS number. Special programs now watch for inquiries into these records. A nice guy from ARPA (Steve Squires) came and showed us complicated slides representing the various factions at ARPA who are going about developing the National Information Infrastructure. It seemed to be more a polite introduction than a fact-based briefing about what might come out of Al Gore's dreams. Dorothy Denning came to say that there was no final report from the outside team performing an outside review of the Clipper algorithm. In general, she said that the comments have been favorable to their work. Several members of the board questioned the independence of the review given that it was done at the NSA using NSA's computers and NSA's programmers. They also wondered about the depth of the review because it was apparent that Denning leaned heavily on the NSA's analysis. The EFF and Clipper The final presentation came from Jerry Berman from the EFF. In reality, he was representing the "Digital Privacy and Security Working Group" which is a group of industry and political groups that have joined together to say something about Clipper. This was the last presentation of the meeting and it became sort of a climax because people kept saying, "We'll see what the EFF has to say." Their statement was simple. The group feels that it can accept Clipper if any participation in the key escrow program is completely volutary. They proposed to test the administration's committment to volunteerism by noting whether they relaxed export requirements. To me, the statement was little more than a political gambit. All of the companies involved in the DPSWG really, really, really want export restrictions eased. So they offered their support for Clipper as a quid pro quo. Let us export anything (not just Clipper) and we'll support it. If you ask me, they shouldn't have been so bald about their horse trading, but then I'm not a regular in Washington log rolling. It should be possible to make a statement about Clipper without involving the other issue, but maybe it's a smart deal. The main members of the group are companies and the group had to standardize its message on what its members want. The Debate The rest of the meeting was centered around the debate on the board's resolution on Clipper. I missed most of this because it really seemed very petty. Most of the board wanted to say that the Clipper chip was a pain in the neck that wasn't worth the trouble but they couldn't come up with the right words. Is it "expensive", "more expensive than software", "more expensive than other alternatives", etc. The fight seemed to break down between government employees and non-government employees. Those outside the government kept arguing for stronger language and those inside kept saying things like, "But expensive relative to what? We don't have any concrete cost estimates." In the end, they passed resolutions that recorded reservations and a call for "public" debate on the topic including a decision by Congress on the needs of key escrow. If you have any questions about this summary, feel free to contact me at pcw(a)access.digex.com. --Peter Wayner

1 0

Abstract: of The Digital Silk Road
by norm＠netcom.com 17 Dec '03

17 Dec '03

Existing and proposed mechanisms for digital money all require large overhead to transfer money between parties. This overhead makes them unsuitable for extremely low cost activities such as delivering and routing packets. We propose a money system with extremely low transaction cost built into the communication protocols. The money introduced by this system is much more like coins than like bank accounts; it supports only small transactions, requires limited trust among the participants, and requires no central bank. With this as a foundation, we then describe elements of an open system that fully supports network resource management, routing, interconnection with the Internet, and other information services, across trust boundaries with competing providers for all services. This supports a style of informal information commerce. To appear in "Agoric Systems: Market Based Computation", edited by Wm. Tulloh, Mark S. Miller and Don Lavoie. A draft of this paper is available thru anonymous ftp at netcom.com:pub/joule/DSR1.ps.gz, DSR1.rtf and DSR1.txt. The file format, .rtf, (Rich Text Fotmat) can be read by many different word processors including those from Microsoft, MacWrite II, and some Unix systems. I will produce other formats with a bit of pressure.

1 0

Fortune Mag Article
by Duncan Frissell 17 Dec '03

17 Dec '03

Foutune Magazine has a special issue (dated Autumn 1993) called Making High Tech Work for You on the stands now with much of interest to our activities. Look particularly at the last non-ad page (162) "Your Wallet in the Year 2000" filled with digital signatures, public key crypto, and digital cash. Likewise gambling, remailers, etc. Sample quote: "The global cash economy is growing so fast that President-elect Clinton says she's worried about the government's ability to regulate and tax commerce." There's also an article on the movement of commerce and enterprise networks to Internet. Be sure to catch the hot hot tub photo of JG and the profile of Cygnus Support on page 57. Duncan Frissell What is the most toxic hazardous waste dump on earth? Highgate cemetary in north London. Karl Marx's brain (the earth's most hazardous substance) is buried there (together with the rest of him>. --- WinQwk 2.0b#0

1 0

How to use cipher programs without trusting them.
by norm＠netcom.com 17 Dec '03

17 Dec '03

The shortest summary of all this is that cipher program should be deterministic and written to a public spec so that they may be checked short of the hazardous task of reading code. This may be quixotic but that has never stopped me. I propose here a way to choose secret random numbers and random primes without having to trust a single program exclusively. Suppose that you want to choose a random n bit number. You type text while trying to make it random in some subjective sense. The text accepts only space and letters and ignores all else. The text is interpreted as a base 53 number and reduced modulo 2^n. Note that 53 and 2^n are relatively prime. Experiments have shown that this type of "typewriter random" produces about one or two bits of information per character depending on the typist. This assumes an unspecified form of information compression which I do not recall. It did, however, look for patterns that were specific to people trying to type random characters at a keyboard. One caution: if choosing random numbers this way becomes routine one falls into habits that makes the numbers no longer independent. Different programs can easily be written according to such a standard and their results compared. The skeptic runs two or three programs and compares the output. After a few trials it may be reasonable to trust one of the programs. A natural adjunct of such a program is a prime tester that seeks primes in some arithmetic sequence. The sequence is chosen according to published rules from keyboard selected random numbers. I hear that PGP pads messages with random information in order to thwart known plaintext attacks. This is wise but the paranoid wonders how the random information is selected. The padding prevents output from two programs from being compared for compliance. Some will argue that if the cipher program were malicious it could stash your secrets somewhere on your disk that was destined for export for reasons unrelated to ciphering. The SoftPC story below indicates that there are problems even when the cipher program is programmed to spec. I know of operating systems where cipher programs may be installed so as not to have the authority to stash your secrets away. I don't know whether such operating systems will ever see commercial use. There are several problems with keyboard timing. The first that I saw mentioned arises when running such a program on SoftPC which is a clever program to execute programs designed for IBM PCs on the Macintosh. The clock appears not to run (I think the story is) and while the random numbers look impressive they depend only on the number of keystrokes and nothing else! There is much more technology such as SoftPC coming down the pike.

1 0

KEY ESCROW PROCEDURES
by L. Detweiler 17 Dec '03

17 Dec '03

(Disclaimer: in no way should any of my own writings on this subject be construed as supportive of key escrow.) Key escrow procedures as revealed in Congress, received via M. Godwin and J. Berman of EFF. First is J. Berman analysis followed by text itself, covering the various types of interception under 3 laws: omnibus Crime Control & Safe Streets (1968), Foreign Intelligence Surveillance Act (FISA), and finally under state statutes. (Perhaps someone can identify the differences in the various procedures buried in the bureacratese, but they are all largely verbatim copies.) Notes: 1) escrow agencies (finally) IDENTIFIED: NIST and `non-law enforcement component of the Dept. of Treasury' as `tentative' choices to be finalized in `the next few days'. 2) LE agents have to get `black boxes' (a PC) to extract/read the LEAF (ID field) of the communications. Each box has an ID. 3) according to Berman, the LE agency *faxes* (?) the device ID number to the agents along with certifications on interception authority, ID of the black box, and the length of authorization. 4) agencies transmit the keys to the black box in a secure, encrypted channel. `key components will only work with that particular black box, and only for the state duration of the intercept'. 5) the most ominous sounding paragraph is the following, which specifically *revokes* any rights or guarantees to privacy or `due process' based on the technology & procedures: >These procedures do not create, and are not intended to create, >any substantive rights for individuals intercepted through >electronic surveillance, and noncompliance with these procedures >shall not provide the basis for any motion to suppress or other >objection to the introduction of electronic surveillance evidence >lawfully acquired. that is, this disclaimer seems to be an attempt to evade the `exclusionary rule' and `poisoned tree' legal doctine (the practice of courts in excluding evidence illegally obtained and other evidence therefrom) by legislative fiat. Major criticisms *not* addressed by this protocol: - why isn't the link *to* the encryption agencies, wherein the Clipper phone ID is sent, secure & encrypted itself? If police `fax' these ID's, what is to prevent them from trading them and misrepresenting them on the warrants seen by the agencies? - Berman writes that the LE agents tell the key escrow agencies how long they are requesting the warrant. Now, this is strange. Does the escrow agency ever refuse a warrant if the time period is not legal under the applicable law? and is any police agent going to request *less* than the maximum period allowed by law? - we have claim that records are kept on many sides, such as the requesting side and the granting sides. are records kept of *failed* requests? or do all `illegally-phrased requests' rejected by the key escrow agencies simply disappear? - In fact, do the key escrow agencies *ever* reject a request? this plan below says nothing of the grounds under which requests may be denied. What's the point? - NO indication of the critically important key generation protocol. Are we to take Denning's American Scientist article as authoritative? if so, forget it. - If there is no legal penalty in court for violating the protocols, as the disclaimer seems to attempt to evoke, what's the point? at the *bare minimum* there is required exclusion of tainted taps, and other penalties for infringing parties are wholly in order. Berman also reveals very fascinating glimpses: `The Administration rejects the argument that voice encryption is readily available.' The AT&T product `posed a unique threat in terms of voice quality, affordability, portability and strength of the encryption' -- strong confirmation of the theories that Clipper was rushed out, prematurely, to face it. They are clearly strongly concerned about new Motorola products, the `next voice encryption product in the pipeline'. (NSA is in *big* trouble when there is more than one pipeline to choke, as is rapidly becoming the case). Interesting insights into administration psyche with Berman's quotes of government officials: 1) `Clipper market share' will cause momentum to the standard (hee, hee) 2) `careless bad guys' will use Clipper (yeah, right) 3) why private key agencies rejected, but also the NSA: the former, concerns on longevity and security related to profit, the latter, `for credibility reasons' (snicker) 4) `key criterion' for escrow agents: `experience in and an infrastructure for handling sensitive information' 5) `briefers admitted it is not really a key escrow system'. (!) escrows' obligation `will be to the government' with `no duties or responsibilities to users' (?!) > Both John Podesta and Mark Richard stated that there is no plan on >or over the horizon to outlaw non-escrowed encryption. 6) International aspects `thorniest to deal with'. Clipper exportable with a license (surprise). `Other nations would not participate in the escrow system.' Hm, I doubt it. Not if the NSA can help it. Cypherpunks: one can sense the undertone of confusion, hopelessness and despair in these accounts. Let's keep up the heat until the omelette has completely vaporized. ------- Forwarded Message Date: Thu, 16 Sep 1993 17:31:54 -0400 From: jberman (Jerry Berman) Subject: CLIPPER ESCROW AGENTS CHOSEN In the next several days, the Administration will announce it has chosen at least one escrow agency and has developed procedures for accessing escrow keys pursuant to warrant. Here is an account of an Administration hill staff briefing on September 16, 1993 and the draft procedures for law enforcement, foreign intelligence, and state and local law enforcement wiretapping. We are looking for comments and analysis. Please circulate widely. Jerry Berman, EFF. ================== RE: Clipper Escrow Agent Briefing for Congressional Staff Yesterday, September 15, 1993, a briefing was held for congressional staff regarding the status of the Clipper project. The lead briefers for the Administration were Mark Richard, Deputy Assistant Attorney General, Criminal Division, DOJ; Jim Kallstrom, FBI; Geoff Greiveldinger, Special Counsel, Narcotic and Dangerous Drug Section, DOJ; and John Podesta. Also present were Mary Lawton, Counsel for Intelligence Policy and Review, DOJ; Mike Waguespack, NSC; and Dwight Price, National District Attorneys Association. The Administration has tentatively settled on NIST and a yet to be determined non-law enforcement component of the Department of the Treasury as the "escrow agents." The Administration will finalize the choices in the next few days, according to John Podesta. The Attorney General will make an announcement, in what form has not been determined, but it will probably not be a Federal Register notice. The Attorney General will announce that she has adopted, and the escrows have agreed to follow, the attached procedures. The system will work as follows: (1) A black box (actually a PC) in the possession of a law enforcement agency will be able to read the Law Enforcement Access Field in a Clipper encrypted data stream and extract the identification number specific to the Clipper chip being used by the intercept target. Cost of the black box yet undetermined. How many will be purchased by law enforcement yet undetermined, although if use of Clipper becomes common, the black boxes will be in great demand, by federal as well as state and local agencies. They will be available only to law enforcement, with yet to be specified controls on their sale. Each black box will have a unique identifier. (2) The law enforcement agency will fax the device ID number to each of the escrow agents, along with a certification that the agency has authority to conduct the intercept, the ID number of the intercepting agency's black box, and the time period for which the intercept is authorized (in the case of Title III's, up to thirty days, with extensions). (3) The escrow agents will transmit the key components by encrypted link directly into the black box of the requesting law enforcement agency. The key components will only work with that particular black box, and will only work for the stated duration of the intercept. If the intercept is extended, the law enforcement agency will have to send a new request to the escrow agents to extend the life of the key components. The escrow agents will maintain logs of the requests. Greiveldinger stressed that the system is "replete with recordation of the transactions that will occur." The escrow agents also have a responsibility for maintaining the integrity of the chip manufacturing process. In opening remarks describing the need for the Clipper escrow system, Kallstrom had stressed that the AT&T product posed a unique threat in terms of voice quality, affordability, portability and strength of the encryption. The Administration rejects the argument that voice encryption is readily available. The AT&T product, which isn't available yet, is unique, and competing products, the Administration argues, are yet further in the future. The next voice encryption product in the pipeline is Motorola's, and Motorola has expressed interest in using Clipper in its product. The Administration argued that the need for compatibility would drive a significant share of the market to Clipper or Capstone-based products. Escrow coverage will not be complete, but the bad guys are careless and are expected to use Clipper products. The key criterion used in selecting the escrow agents was whether the agency had experience in and an infrastructure for handling sensitive information. The Administration did not want to use a law enforcement or national security component, for credibility reasons. It did not want to use private entities based on concerns about longevity and not wanting security to be governed by the need to make a profit. The briefers admitted that the proposed system is not really an escrow. The agencies holding the key components will not have any duties or responsibilities to the Clipper users. The escrows' obligation will be to the government, and they will be liable to Clipper users only under the Bivens doctrine, where any failure must be shown to be wilful. Both John Podesta and Mark Richard stated that there is no plan on or over the horizon to outlaw non-escrowed encryption. John and Mark said that the international aspects of the escrow/encryption issue are the thorniest to deal with, and there are no answers yet. Clipper products would be exportable with a license, although other countries may try to keep them out. (Nobody asked questions about changes in the rules governing export of non-Clipper encryption.) Other nations would not participate in the escrow system, nor, presumably, would they be allowed to buy the black boxes. E.G., if the British intercepted an IRA communication that appeared to be encrypted with Clipper, and came to the FBI for help, the anticipated escrow system would not allow the FBI to get the key from the escrow agents. ================== PROPOSED PROCEDURES AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUNCTION WITH INTERCEPTS PURSUANT TO TITLE III The following are the procedures for the release of escrowed key components in conjunction with lawfully authorized interception of communications encrypted with a key-escrow encryption method. These procedures cover all electronic surveillance conducted pursuant to Title III of the omnibus Crime Control and Safe Streets Act of 1968, as amended (Title III), Title 18, United States Code, Section 2510 et seq. 1) In each case there shall be a legal authorization for the interception of wire and/or electronic communications. 2) All electronic surveillance court orders under Title III shall contain provisions authorizing after-the-fact minimization, pursuant to 18 U.S.C. 2518(5), permitting the interception and retention of coded communications, including encrypted communications. 3) In the event that federal law enforcement agents discover during the course of any lawfully authorized interception that communications encrypted with a key escrow encryption method are being utilized, they may obtain a certification from the investigative agency conducting the investigation, or the Attorney General of the United States or designee thereof. Such certification shall (a) identify the law enforcement agency or other authority conducting the interception and the person providing the certification; (b) certify that necessary legal authorization has been obtained to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorized; (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key escrow encryption chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the law enforcement agency or other authority for decryption of the intercepted communications. 4) The agency conducting the interception shall submit this certification to each of the designated key component escrow agents. If the certification has been provided by an investigative agency, as soon thereafter as practicable, an attorney associated with the United States Attorney's Office supervising the investigation shall provide each of the key component escrow agents with written confirmation of the certification. 5) Upon receiving the certification from the requesting investigative agency, each key component escrow agent shall release the necessary key component to the requesting agency. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification of the requesting agency, as well as the subsequent confirmation of the United States Attorney's office. In addition, the requesting agency shall retain a copy of the certification and provide copies to the following: (a) the United States Attorney's office supervising the investigation, and (b) the Department of Justice, Office of Enforcement operations . 7) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the requesting agency to decrypt intercepted communications shall terminate, and the requesting agency may not retain the key components. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUNCTION WITH INTERCEPTS PURSUANT TO FISA The following are the procedures for the release of escrowed key components in conjunction with lawfully authorized interception of communications encrypted with a key-escrow encryption method. These procedures cover all electronic surveillance conducted pursuant to the Foreign Intelligence Surveillance Act (FISA), Pub. L. 9S-511, which appears at Title 50, U.S. Code, Section 1801 et seq. 1) In each case there shall be a legal authorization for the interception of wire and/or electronic communications. 2) In the event that federal authorities discover during the course of any lawfully authorized interception that communications encrypted with a key-escrow encryption method are being utilized, they may obtain a certification from an agency authorized to participate in the conduct of the interception, or from the Attorney General of the United States or designee thereof. Such certification shall (a) identify the agency participating in the conduct of the interception and the person providing the certification; (b) certify that necessary legal authorization has been obtained to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorized; (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key escrow encryption chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the agency participating in the conduct of the interception for decryption of the intercepted communications. 4) This certification shall be submitted to each of the designated key component escrow agents. If the certification has been provided by an agency authorized to participate in the conduct of the interception, as soon thereafter as practicable, an attorney associated with the Department of Justice, office of Intelligence Policy and Review, shall provide each of the key component escrow agents with written confirmation of the certification. 5) Upon receiving the certification, each key component escrow agent shall release the necessary key component to the agency participating in the conduct of the interception. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification, as well as the subsequent written confirmation of the Department of Justice, Office of Intelligence Policy and Review. 7) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the agency participating in the conduct of the interception to decrypt intercepted communications shall terminate, and such agency may not retain the key components. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. AUTHORIZATION PROCEDURES FOR RELEASE OF ENCRYPTION KEY COMPONENTS IN CONJUCTION WITH INTERCEPTS PURSUANT TO STATE STATUTES Key component escrow agents may only release escrowed key components to law enforcement or prosecutorial authorities for use in conjunction with lawfully authorized interception of communications encrypted with a key escrow encryption method. These procedures apply to the release of key components to State and local law enforcement or prosecutorial authorities for use in conjunction with interceptions conducted pursuant to relevant State statutes authorizing electronic surveillance, and Title III of the omnibus Crime Control and Safe Streets Act of 1968, as amended, Title 18, United States Code, Section 2510 et seq. 1) The State or local law enforcement or prosecutorial authority must be conducting an interception of wire and/or electronic communications pursuant to lawful authorization. 2) Requests for release of escrowed key components must be submitted to the key component escrow agents by the principal prosecuting attorney of the State, or of a political subdivision thereof, responsible for the lawfully authorized electronic surveillance. 3) The principal prosecuting attorney of such State or political subdivision of such State shall submit with the request for escrowed key components a certification that shall (a) identify the law enforcement agency or other authority conducting the interception and the prosecuting attorney responsible therefore; (b) certify that necessary legal authorization for interception has been obtained to conduct electronic surveillance regarding these communications; (c) specify the termination date of the period for which interception has been authorized (d) identify by docket number or other suitable method of specification the source of the authorization; (e) certify that communications covered by that authorization are being encrypted with a key-escrow encryption method; (f) specify the identifier (ID) number of the key escrow chip providing such encryption; and (g) specify the serial (ID) number of the key-escrow decryption device that will be used by the law enforcement agency or other authority for decryption the intercepted communications. 4) Such certification must be submitted by the principal prosecuting attorney of that State or political subdivision to each of the designated key component escrow agents. 5) Upon receiving the certification from the principal prosecuting attorney of the State or political subdivision, each key component escrow agent shall release the necessary key component to the intercepting State or local law enforcement agency or other authority. The key components shall be provided in a manner that assures they cannot be used other than in conjunction with the lawfully authorized electronic surveillance for which they were requested. 6) Each of the key component escrow agents shall retain a copy of the certification of the principal prosecuting attorney of the State or political subdivision. In addition, such prosecuting attorney shall provide a copy of the certification to the Department of Justice. 7) The U.S. Department of Justice may, to assure conformance with these procedures, make inquiry of the certifying prosecuting attorney regarding, inter alia, the genuineness of the certification and confirmation of the existence of lawful authorization to conduct the relevant electronic surveillance. The inquiry of the U.S. Department of Justice will not involve intrusion into matters that must, under relevant statute, be kept from public disclosure. 8) Upon, or prior to, completion of the electronic surveillance phase of the investigation, the ability of the intercepting law enforcement agency or other authority to decrypt intercepted communications shall terminate, and the intercepting law enforcement agency or other authority may not retain the key components. These procedures do not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance, and noncompliance with these procedures shall not provide the basis for any motion to suppress or other objection to the introduction of electronic surveillance evidence lawfully acquired. - ----------------------------------------------------------- ------- End of Forwarded Message

1 0

Re: Random Numbers
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> mjr(a)TIS.COM writes: > > One possibility is to treat part of the random seed as > > if it was your secret RSA key. Systems like PEM store the RSA > > key encrypted on disk someplace - you could also store an > > encrypted random seed which you decrypt when you retrieve the > > secret key, use to bootstrap your PRNG, and then replace with > > some output from the PRNG when you're done. That way, the seed > > is (by definition) hidden, and an attacker is going to have > > much more trouble attacking your PRNG by searching your random > > seed space. > > You don't want to do that... that would amount to using one seed [...] I was under the impression that mjr's suggestion was to use the randseed the same way it's being used now, only to store it encrypted instead of clear. This has some advantages - stealing it is now much less useful. On the other hand, it means you need to use your secret key when encrypting files, as well as when decrypting or signing them, which increases the exposure of your secret key as well as being annoying. > Since the relationship between a random seed and the IDEA key is > known, one can be reproduced from the other. If the IDEA key is generated by a one-way function such as MD5, it's ostensibly 2**128 work to duplicate an MD-5 hash, and potentially 2**400-2**500 work to generate the input to the hash (which is essentially impossible, since the input:hash is N:1, not 1:1.) Of course, it's still easy to implement wrong, leading to lossage :-) But even something as simple-minded as sessionkey = MD5(randseed+constant) newrandseed = MD5(randseed+differentconstant) would be pretty secure (and the real thing also includes timestamp and MD5 of the message, further randomizing it; haven't looked at the randseed code.) # Bill Stewart wcs(a)anchor.ho.att.com +1-908-949-0705 Fax-4876 # AT&T Bell Labs, Room 4M-312, Crawfords Corner Rd, Holmdel, NJ 07733-3030

1 0

Trust fund to support free software. Backed, in part, by PGP.
by stig＠key.amdahl.com 17 Dec '03

17 Dec '03

Path: key!amdahl!pacbell.com!decwrl!decwrl!concert!samba.oit.unc.edu!sunSITE!mdw From: callis(a)noc.usfca.edu (Kim C. Callis) Newsgroups: comp.os.linux.announce Subject: Re: The Linus Fund (EVERYONE READ THIS THREAD) Followup-To: comp.os.linux.misc Date: 13 Sep 1993 18:09:55 GMT Organization: Linux. It's not just for breakfast anymore. Lines: 76 Approved: linux-announce(a)tc.cornell.edu (Matt Welsh) Message-ID: <272d1j$2i5(a)samba.oit.unc.edu> References: <270rt7$jrv(a)vixen.cso.uiuc.edu> <270sih$do(a)nigel.msen.com> NNTP-Posting-Host: calypso.oit.unc.edu Keywords: Linux fund money donations Originator: mdw@sunSITE [Forwarded from c.o.l.d at request of Jeff Kopmanis. --mdw] In article <26ung9$n2m(a)noc.usfca.edu> callis(a)noc.usfca.edu (Kim C. Callis) writes: >> >> Fellow Linux Users, >> >> I have read the messages regarding donations to Linus in order for hime >> to continue the development of Linux. I will even admit that I am >> surprised that people are genuinely interested in rewarding the creator >> of Linux for his contributions. >> This has moved me in ways I can understand, so I am going to do the >> following. On Monday, September 13, I will open and deposit $100.00 in a >> trust account. Anyone interested in contributing to the Linus Dream >> Machine Fund can send a donation which will be deposited in the account. >> During this time, we will find out from Linus what his dream machine >> consists of and figure out the ammount of money needed to achieve this >> machine. At the time when we receive the amount, a machine will be >> configured to meet Linus' specifications and sent off to him. >> >> Of course the question will be how can you confirm that I am not taking >> this money in Linus name and going to have a big party with it. Well, I >> am hoping that the goodwill of the net will out-weigh any pessimistic >> views but if not, I have come up with a plan. >> >> All monies received will be amounts will be publicly posted. When money >> is received, I will send the person a receipt which will be signed with >> a public key signature of mine (using PGP 2.0). Each week, I will post >> to the net a total of all monies received, and a person can check to see >> if his or her name is on the list. The account will be set up as a trust >> account with myself as administrator limited to withdrawing of funds to >> be distributed to one Linus Torvald (Sorry, I have the spelling of the >> name somewhere...) in Finland. So, that will limit the money >> distrubution. Also to all interested parties in the united States, I >> will send via e-mail the (800) automated account inquiry number for BoA, >> as well as account information and any needed access number need to find >> the status of the account. >> >> As mentioned above, when an amount is reached which will allow Linus to >> purchase his dream machine (Please bear in mind Linus, that you need to >> monitor the posting and vary your list according to funds available), >> BoA will cut a certified funds check to Linus, and only to Linus. >> >> Considering what we have received from Linus, I think that this would be >> a noble gesture on the part of all of us who without Linus would have >> been doomed to buying some version of Un*x and paying a stiff prices for >> all the add-ons which the Linux provides us for free. Furthermore, this >> would serve to show the goodwill of a community based not on race, >> color, or creed, but upon content of character. Let's face it, few of us >> ever get to meet people who post via netnews or write programs which we >> tend to use day to day. Yet we communicate with each other as if we have >> known each other for long periods of time. We instruct each other, we >> learn from each other, we argue (flame) each other, and we grow from all >> of this. I believe that the Internet serves as a moderator of >> internation goodwill. Let's see if we can take it one step forward, and >> see if the goodwill extends all the way to rewarding someone for a great >> contibution to our community. >> >> If anyone has any suggestions, rebuttals, or general comments on how to >> make this idea of mine work, please feel free to e-mail me or post for >> general discussion. >> >> -- >> ******************************************************************* >> * Kim C. Callis * >> * Univ. of San Francisco, San Francisco, CA * >> * EMAIL: callis(a)usfca.edu or callis(a)dons.ac.usfca.edu * >> ******************************************************************* >> DISCLAIMER: As long as nothing I say attempts to represent the >> views of the Univ. of San Francisco, they could care less what I >> have to say. Meaning that anything said, like it or not, is strictly >> my own personal opinion and views. -- Send submissions for comp.os.linux.announce to: linux-announce(a)tc.cornell.edu

2 1

No Subject
by kelly＠netcom.com 17 Dec '03

17 Dec '03

------- Forwarded Message Subject: (fwd) *FLASH* Moby SUBPOENA served Newsgroups: comp.org.eff.talk,sci.crypt,alt.security.pgp,talk.politics.crypto Organization: NETCOM On-line Communication Services (408 241-9760 guest) Xref: netcom.com comp.org.eff.talk:20002 sci.crypt:17638 alt.security.pgp:4909 talk.politics.crypto:102 Newsgroups: comp.org.eff.talk,sci.crypt,alt.security.pgp,talk.politics.crypto Path: netcom.com!grady From: grady(a)netcom.com (Grady Ward) Subject: *FLASH* Moby SUBPOENA served Message-ID: <gradyCDHF2s.Gto(a)netcom.com> Organization: Moby lexicons X-Newsreader: TIN [version 1.1 PL8] Date: Fri, 17 Sep 1993 04:56:51 GMT Lines: 22 FLASH At 10:30 PM EST 9/16/93 a subpoena was served on the Austin Code Works of Austin TX relating "any and all correspondence, contracts, payments, records, incluing computer data relating to Moby Crypto and any other commercial product relating to PGP and RSA" you are commanded to give to Michael J. Yamaguchi United States Attorney Northern District of California served by Theodore R. Siggins, special agent Department of Treasury, US Customs Service More details later. - -- Grady Ward grady(a)netcom.com 3449 Martha Ct. compiler of Moby lexicons Arcata, CA 95521-4884 e-mail or finger grady(a)netcom.com (707) 826-7715 (voice/24hr FAX) for more information ------- End of Forwarded Message

1 0

(fwd) pgpwin11
by kelly＠netcom.com 17 Dec '03

17 Dec '03

Path: netcom.com!netcomsv!decwrl!usenet.coe.montana.edu!netnews.nwnet.net!henson!news.reed.edu!usenet From: pwilk(a)reed.edu (The Cannibal) Newsgroups: alt.security.pgp Subject: pgpwin11 Date: 13 Sep 1993 21:02:23 GMT Organization: Reed College, Portland, Oregon Lines: 12 Message-ID: <272n4v$pco(a)scratchy.reed.edu> NNTP-Posting-Host: reed.edu I just downloaded pgpwin11.zip from garbo.uwasa.fi. It is in the /windows/util directory i think. I haven't tried it out, but I am all in a froth to try it out. just thought you might like to know. it's a windows pgp shell you ninny. -- The _O_ "Darkness may cover me: midnight may steal along my living veins; Cannibal | yea and the ultimate futility, the ghastly nothing on which all things play may break ice-thin crust and freeze my soul" pwilk(a)reed.edu -=public key available on finger=- - John Cowper Powys

1 0

(fwd) New pgp-public-keys server!
by kelly＠netcom.com 17 Dec '03

17 Dec '03

Newsgroups: alt.security.pgp Path: netcom.com!netcomsv!decwrl!uunet!pipex!sunic!trane.uninett.no!news.eunet.no!nuug!news.eunet.fi!KremlSun!kiae!relcom!rd.relcom.msk.su!blaster From: blaster(a)rd.relcom.msk.su (Victor A. Borisov) Subject: New pgp-public-keys server! Sender: usenet(a)newcom.kiae.su (Mr. Usenet) Organization: Relcom R&D Date: Thu, 16 Sep 1993 09:21:20 GMT X-Newsreader: TIN [version 1.1 PL6] Message-ID: <1993Sep16.092120.15509(a)newcom.kiae.su> Lines: 28 Hello everybody. I am glad to introduce my pgp public keys server. This server has Internet address: "pgp-public-keys(a)kiae.su". It physically placed in Relcom corp. (Moscow). I will maintain this server (my name is Victor Borisov aka blaster, my Internet address is "blaster(a)rd.relcom.msk.su"). For beginning of interaction with server, you can (as usually) send empty letter with header: To: pgp-public-keys(a)kiae.su From: your(a)internet.address Subject: help I use 0.16a version of Michael Graff server as software. My server exchange added keys with other servers. All messages from server will also contain Russian text. Sincerely your, Victor Borisov. -- Victor A. Borisov aka blaster; Relcom R&D; Email: blaster(a)rd.relcom.msk.su; Phone: +7(095)-943-4735; +7(095)-198-9510; === Don`t panic! ==

1 0