- cypherpunks-legacy - lists.cpunks.org

Re: RSA Prevails In Arbitration Against Cylink
by jordan＠Heuristicrat.COM 17 Dec '03

17 Dec '03

From baldwin(a)RSA.COM Wed Sep 20 09:09:30 1995 Here's an article on the RSA-Cylink arbitration from the business wire. [ ... elided -JMH ] Just a note for those who aren't aware, Business Wire is a pay-per-use "news release" service. That is, RSA wrote the contents of what Bob (Hi!) posted. The clue is at the bottom of the "story": CONTACT: RSA Kurt Stammberger, 415/595-8782 kurt(a)rsa.com This is not to say anything pro or con about the content of the press release; just that it wasn't written by a third party. /jordan

1 0

CLAIMING CHUNKS OF KEYSPACE...
by tcmay＠got.net 17 Dec '03

17 Dec '03

Date: Mon, 28 Aug 1995 23:02:01 -0700 To: cypherpunks(a)toad.com From: tcmay(a)got.net (Timothy C. May) Subject: Claiming chunks of keyspace... Looking at it from the outside, I thought the latest SSL challenge experiences were highly instructive. Nothing to be ashamed of. An interesting question: Is it a valid approach for J. Random User to "claim" some chunk of keyspace to search? If the "reward" of finding the gold buried in the keyspace (a key that meets the challenge) is high and the cost of claiming the keyspace is low (or nil), then game theory tells us that some folks will be tempted to claim a bigger chunk of keyspace than they can possibly process. What can be done to reduce this effect? On the negative side, ostracize or punish those who bite off more than they can chew. This approach is fraught with dangers. On the positive side, let everyone simply attack the keyspace as they see fit, picking random parts to attack. This should not be "worse" than a factor of several from a "perfectly coordinated" attack. (I haven't spent time calculating this, but my intuition is that a random attack, with overlapping keyspace, is not a lot less efficiently attacked than attempting to arrange for no overlaps...just based on my mental picture of dropping line segments randomly on some interval and figuring coverage of the line segment.) In between, market systems where itermediate agents subcontract out chunks of keyspace. Mechanisms for this are lacking. -Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

"CITIZEN-UNIT IDENTIFICATION" A RED HERRING
by tcmay＠got.net 17 Dec '03

17 Dec '03

Date: Mon, 28 Aug 1995 21:44:12 -0700 To: cypherpunks(a)toad.com From: tcmay(a)got.net (Timothy C. May) Subject: "Citizen-Unit Identification" a Red Herring All this paranoid talk about the dangers of thumbprints on ID cards, about driver's licenses, and about magstripes got me to thinking. So, I accessed my NLETS (National Law Enforcement Telecommunications System) and downloaded my own record: Citizen-Unit ASCII Name: "Timothy Christopher May" NLETS Actual Name: G0Yj34C1qm92H7u Known Aliases: "Klaus! von Future Prime," "Lance," "Nick Szabo" Residence: 427 Allan Lane, Corralitos, CA 95075 Driver's License: N4197484 SSN: 227-80-5823 Passport Number: H673qop90 Race: Aryan Origin: Europe Hair: Brown Eyes: Blue Weight: 210 pounds (10/94, recorded at SFO) Known associations: Anarchist Alliance, Young Students for Discordianism, Vernor Vinge Fan Club, Information Liberation Front Magazines Subscribed To: Newsweek, Playboy, The Economist, MacWeek, Anarchy Today, Liberty, FertilizerWorld, Reason, MacUser, NewtonGazette, Bay Aryan Events, Information Week Consumer Preferences: beer (+++), wine (+), cigarettes (-) Electricity Patterns: consistent with either marijuana cultivation or heavy Net usage, or both Threat level: Class 3 Security Threat I don't see what the big deal is. The NLETS record implies I'm some kind of security threat, but also correctly notes that I'm an Aryan, so I guess I'm safe. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

SSL keyspace etc.
by vznuri＠netcom.com 17 Dec '03

17 Dec '03

Date: Tue, 29 Aug 95 12:40:08 -0700 From: "Vladimir Z. Nuri" <vznuri(a)netcom.com> regarding SSL challenge, I am not following this close enough to understand completely, but I thought I would offer a few suggestions for tweaking the code: -- the issue of grabbing keyspace has been raised. what if someone malicious just yanked huge areas of keyspace and didn't search them? it seems that the clients need to return to the server some evidence that they have searched their keyspace in question. the server could verify this evidence. for those that don't return the "evidence", that keyspace could be reallocated to other comers. the simple approach to all this, if you don't have "evidence", is to just have the server keep reallocating the same space over and over to different crackers. hopefully eventually every part of the keyspace would be allocated to a "legitimate" worker. -- the issue of efficiency is very fascinating for this project. essentially the server has no idea what the block size of key blocks it should dole out. obviously the server would want to try to dole out equal *processing chunks* such that the remote machine reports back in a certain amount of time, no matter what architecture. the problem of course is that remote machines all have different efficiency. two possibilities: a sort of "bogomip" calculation is done in the client, and its processor speed is reported to the server. the server uses this in a calculation to determine how much to dole out. it could try to derive a best fit linear relationship between space covered and processor spead, or build up a table of results and interpolate for new requests. note that the efficiency issue also ties into "what if people take keys they don't solve". if the server knows roughly how long a client should take to report back, and it never reports back, it could then reallocate that key space. -- another problem of efficiency is that the server is clearly a bottleneck for servicing requests. the question arises: suppose that the server could determine the precise interval between which machines would go back to it for new keys. what is the optimum interval over the whole project? in other words, give the number of machines participating, and their processor speeds, what size of key space should be parceled out to the next request so that the bottleneck at the server is minimized? this optimum interval must be very hard to derive, because it depends on the contention based on many incoming connections. it would involve some probabilistic approximations of the likelihood of collisions. to model it, you might consider a request as taking [n] seconds of time, and consider that if any two requests are in contention, a retry happens after [m] seconds. you could build up models that would try to minimize the time based on empirical simulations. however I would be exceedingly impressed if someone could derive a formula for this, or give it from some textbook. -- adaptive algorithms for all these situations are possible. the server could use a "hypothesis" in the sense of partitioning out a starting size of keyspace, and then watch how long it took the client machine to respond and then assume a linear relationship or something to compute the size of the next keyspace to hand out to the machine. the server could continually watch how closely its "hypothesis" (i.e. its estimations of how long a given machine will take) match the actual returns. -- more on the idea of evidence: we are working with a hashing algorithm, right? as evidence the client machines could return checksums of all the hashes of all the keyspace it searched. it could break up its own search space into blocks and return the checksums on the hashes for each block. the server, if it wanted to, could verify these blocks running its own computations. if it ever found a client was "unreliable", it could then diminish the keys sent to the unreliable client, or even send it areas of search space it didn't care about anymore (i.e. areas that have already been confirmed searched by a more "reliable" client). -- in fact all this reminds me of the process of intelligence gathering by an agency, which could be formalized as follows: suppose that the agency wishes to identify "quality information". it has a set of sources, A,B,C,D.... now, it can send questions out to these sources and get information from them. some of them however would be "unreliable". the agency must devise some means by which it can weed out the unreliable sources. note that this may even involve sending them bogus instructions to keep them busy so they do not themselves suspect they have been "discovered" and then change their defective plans. obviously, one of the most important intelligence tools in this matter is that of *correlation*. you have to determine "truth" (or "quality information") via the correlation between answers that the different sources give you. also important to correlation is *redundancy*. you sometimes have to ask more than one source the same question, and test the answer. in this model, if A and B give different answers, you know that one of A or B is "unreliable". what is very interesting in our case of cracking keys is that the server can verify the information on its own. in other words, it has a *control* that it knows is correct that it can judge against the answers "out there". unfortunately, in contrast, real intelligence agencies are not always privy to this kind of certain "control" and in fact have to determine "truth" entirely from a set of sources, any of which might be unreliable. in this case one has to have a hypothesis about what is the "truth" and test it to see if it holds up consistently with all information. the approaches of attackers are obvious. the most obvious is that of collusion and infiltration. but I will save the rest for some NSA spook to elaborate. there are certainly enough colluding and infiltrating on this list <g> -- one of the reasons all this interests me is that it really reminds me of some projects I have worked on in the past. in high school I wrote a network mandelbrot set program (client/host). the issue of contention arose and it appeared to me to look like an upside-down parabola after I plotted some points (curving up, that is). i.e. the optimum was at the pit of the parabola, and when too few or too many requests happened, the speed over the overall simulation was increased above the optimum. some very ingenious readers may actually be able to locate this code, which I put in the public domain over 5 years ago. -- another thing I worked on was trying to find the optimal block size of communications protocols such as Zmodem, which generally instead just pick arbitrary block sizes 2^n. I actually was able to attack this problem analytically through the observations of the properties of infinite series and calculus techniques. it is a similar problem but the idea of contention really complicates this issue. (for what I studied, there was only one client and one server, so to speak). I still have this paper in Latex format and if anyone is interested I would be happy to send it to you. it's a really nice example, IMHO, of how if you use your brain and some mathematics, you can really get a far more elegant approach than brute force, and know with much greater certainty that what you are doing makes sense mathematically. an awful lot of programmer just tend to bang on the keyboard with out thinking of the theoretical implications of their work. this is understandable given that the theoretical implications of even trivial programs (such as the SSL client/server interactions) can be mathematically extremely daunting, requiring even differential equations to model fairly simple pieces of code. -- well, that is my contribution of the moment into the cypherpunk annals. one never knows what a little combination of boredom and inspiration can lead to. --V.Z.Nuri

1 0

RE: FLORIDA DRIVERS PERMITS AND A HELLO
by alano＠teleport.com 17 Dec '03

17 Dec '03

Date: Tue, 29 Aug 1995 12:06:42 -0700 To: cypherpunks(a)toad.com From: Alan Olsen <alano(a)teleport.com> Subject: Re: Florida Drivers Permits and a Hello At 01:47 PM 8/29/95 -0500, you wrote: >Alan Olsen writes >>They would not have to include an entire thumbprint. The actual code used >>to verify fingerprints is not very large. All that would be needed is >>enough information to ID into the "official" records and enough checksum >>type information to prevent alteration/counterfitting. Using magnetic media >>for this is a bit foolish as it can be changed/destroyed with the stroke of >>a magnet. I will not say by what means I would think should suit as a >>better encoding scheme because: 1) They are not using it and 2) I do not >>want to give them any ideas. > >What possible value could the LEAs get by having your thumbprint digitally >encoded on your driver's license? It's not like the average cop-on-the-beat >is qualified to lift a fingerprint and compare it. Even if he was, how >does it benefit that the fingerprint is on the license? > >This seems silly. I was pointing out that it was possible. I was not trying to make the point that there was any *USE* for such a thing. (Evidently some ID cards now carry such prints. California does, if memory serves me correctly.) Just because something is silly does not mean it will not be tried by someone in law enforcement. In fact, there seems to be a corelation between silly acts and law enforcement... (Or at least those making the rules about law enforcement.) And if you think it cannot get any worse, Pete "I want to seal the borders" Wilson has announced he is running for president. We will be getting a large number of silly laws and pronouncements if the American people are stupid enough to elect him to high office. > > | Visualize whirled keys! | alano(a)teleport.com | |"The moral PGP Diffie taught Zimmerman unites | Disclaimer: | |all mankind free in one-key-stenography-privacy!"| Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

1 0

NIST KEY ESCROW MEETING
by remailer＠flame.alias.net 17 Dec '03

17 Dec '03

Date: Wed, 30 Aug 1995 07:51:07 +0200 To: cypherpunks(a)toad.com From: Flame Remailer <remailer(a)flame.alias.net> Subject: NIST Key Escrow meeting Subject: NIST Key Escrow Meeting Discussion Papers Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #1 Issues -- Export of Software Key Escrowed Encryption On August 17, 1995, the Administration announced its proposal to permit the ready export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. Under the proposal, products will be reviewed to verify that they satisfy the criteria and, if so, they will be transferred to the Commodity Control List administered by the Department of Commerce where the products can be exported under a general license (in much the same way that 40-bit RC2/RC4 encryption is licensed today). We are working toward creating broadly stated criteria that are in the nature of performance specifications. To meet these criteria, encryption products will need to implement key escrow mechanisms that cannot be readily altered or bypassed so as to defeat the purposes of key escrowing. The criteria, when finalized and published, will state the objectives, but not the exact technical method(s), by which those objectives are satisfied. This is to provide software publishers the flexibility to design methods for meeting our stated objectives in a manner that is compatible with the design of their products. There are, therefore, a number of questions we must work together to answer in order to draft effective criteria. These questions are: * Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm? * Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested? * Access to escrow information -- What mechanisms must be designed into encryption products to allow authorized access to escrowed keys? This likely includes the identity of the key escrow agent(s) and a serial number for the key escrow agent to use to identify the key(s)/component(s) necessary to decrypt the message. What other information will be necessary to be provided to the escrow agent to identify the necessary key(s)/component(s)? Are there other comparable viable approaches? * Non-escrowed use -- How can products be made so that they do not function with non-escrowed products (or tampered escrowed products)? How can this be tested? * Limiting surveillance -- How can products be designed so that information both sent and received by the user can be decrypted without release of keys of other users? * Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period? * Assurance that keys are escrowed -- How can it be assured that key escrow products are indeed satisfactorily escrowed? For example, products could be required to be escrowed at time of manufacture or be made inoperable until properly escrowed. * Ability to re-escrow keys -- How can products be designed so that new keys can be escrowed at the user's discretion with a U.S. Government approved escrow agent? * Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent? -------------- With your input, we are hopeful that this effort will lead to definitive criteria, which will facilitate the development of exportable products and help minimize the time required to obtain export licenses. The Administration seeks to finalize such criteria and make formal conforming modifications to the export regulations before the end of 1995. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e- mail: carlton(a)micf.nist.gov. 8/25/94 ----------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #2 Discussion Issues: Desirable Characteristics for Key Escrow Agents In the government's recent announcement of its intent to allow the export of 64-bit software key escrow encryption products, one stipulation was that the keys would be escrowed with an approved key escrow agent.(*1) Exactly what qualifications/considerations are appropriate for approval as a key escrow agent have not been defined. Some of the issues which need to be discussed and resolved include the following: * What kinds of organizations should be excluded from consideration as approved key escrow agents? * What sort of legal agreement between the government and the key escrow agent is necessary to stipulate the responsibilities of the agent? Should this include the terms and conditions under which release of a key is required? * How will liability for unauthorized release of key be handled? * Should, for example, intentionally misreleasing or destroying a key be criminalized? Should this include other actions? * How can the government's needs for confidentiality of key release be handled? * Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? * What procedures need to be developed for the storage and safeguarding of keys? * What are the acceptable performance criteria (e.g., around- the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? * Under what circumstances will key escrow agents in foreign countries be approved? * What process will be used to approve escrow agents? Costs/who pays? --------- (*1) "Approved," for the purposes of this discussion, means that the government (or its agent) has formally granted permission for an organization to hold keys for exportable encryption products. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e-mail: carlton(a)micf.nist.gov.

1 0

[COMP.SECURITY.UNIX] ADVICE ON PASSWORD SECURITY GUIDELINES
by alano＠teleport.com 17 Dec '03

17 Dec '03

Date: Wed, 30 Aug 1995 20:55:24 -0700 To: cypherpunks(a)toad.com From: alano(a)teleport.com (Alan Olsen) (by way of Alan Olsen <alano(a)teleport.com Subject: [comp.security.unix] Advice on password security guidelines I found this on alt.humor.best-of.usenet. It seemed like something that would be appreciated here. (And it is not that far off topic.) Enjoy! ----------------------------------------------------------- In alt.humor.best-of-usenet, Artur Pioro <artur(a)thp2.if.uj.edu.pl> wrote: >From: Paul Ashton <paul(a)argo.demon.co.uk> >Newsgroups: comp.security.unix >Subject: Advice on password security guidelines >Hi, >my boss has asked me for comments and improvements on his new password >security policy. To me, it seems a bit severe. If anyone can offer any >additional suggestions please do, here goes... >For immediate issue: >Password changing guidelines V2.2b >Due to new security policies, the following guidelines have >been issued to assist in choosing new passwords. Please follow >them closely. >Passwords must conform to at least 21 of the following attributes. >1. Minimum length 8 characters >2. Not in any dictionary. >3. No word or phrase bearing any connection to the holder. >4. Containing no characters in the ASCII character set. >5. No characters typeable on a Sun type 5 keyboard >6. No subset of one character or more must have appeared on > Usenet news, /dev/mem, rand(3), or the King James bible (version 0.1alpha) >7. Must be quantum theoretically secure, i.e. must automatically change > if observed (to protect against net sniffing). >8. Binary representation must not contain any of the sequences 00 01 10 11, > commonly known about in hacker circles. >9. Be provably different from all other passwords on the internet. >10. Not be representable in any human language or written script. >11. Colour passwords must use a minimum 32 bit pallette. >12. Changed prior to every use. >13. Resistant to revelation under threat of physical violence. >14. Contain tissue samples of at least 3 vital organs. >15. Incontravertible by OJ Simpsons lawyers. >16. Undecodable by virtue of application of 0 way hash function. >17. Odourless, silent, invisible, tasteless, weightless, shapeless, lacking > form and inert. >18. Contain non-linear random S-boxes (without a backdoor). >19. Self-escrowable to enable authorities to capture kiddie-porn people > and baddies but not the goodies ("but we'll only decode it with a > court order, honest"). >20. Not decryptable by exhaustive application of possible one time pads. >Due to the severity of the restrictions, if the password is entered >incorrectly 3 times at login time, you will be asked if you would like to >pick a new one. >Please add guidelines to the above and adjust the minimum conformation >requirement, if applicable. >-- >Moderators accept or reject articles based solely on the criteria posted >in the Frequently Asked Questions. Article content is the responsibility >of the submittor. Submit articles to ahbou-sub(a)acpub.duke.edu. To write >to the moderators, send mail to ahbou-mod(a)acpub.duke.edu. | Spam is the Devil's toothpaste! | alano(a)teleport.com | |"It's only half a keyserver. I had to split the | Disclaimer: | |other half with the government man." - Black Art | Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

1 0

RE: CIA & ESPIONAGE
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

Date: Thu, 31 Aug 1995 02:31:07 -0700 To: cypherpunks(a)toad.com From: Bill Stewart <stewarts(a)ix.netcom.com> Subject: Re: CIA & Espionage >> >It was said that Pres. Clinton had given a speech while >> >visiting the CIA HQ in Langley/Virginia. He allegedly >> >said in this speech that obtaining industrial >> >informations has the highest priority and this were the >> >new task for the spies. Did he really say the priority was stealing information from other people, or only protecting Big American Companies from those nasty French Spy Agency persons? (Clinton being who he is, I'd expect him to say a politically correct version of the latter, whether he means the former or not, just like his predecessor.) #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

3 2

SSL and MIPS...
by cwe＠csli.stanford.edu 17 Dec '03

17 Dec '03

Date: Tue, 29 Aug 1995 23:03:59 -0700 From: Christian Wettergren <cwe(a)Csli.Stanford.EDU> Hi! How much computing power did we actually use, in terms of MIPS/FLOPS*hours? An unloaded SS10 that didn't swap went at approximately 16400 keys/s. How many MIPS is an SS10 approximately? How does different algoritms compare? DES, RC40, RSA512 etc? Or if I pose the question differently, what can you do with 30 GIPS for a day? /Christian

1 0

Re: CIA & Espionage
by hallam＠w3.org 17 Dec '03

17 Dec '03

Date: Wed, 30 Aug 95 11:16:01 -0400 From: hallam(a)w3.org >In a german weekly news magazine (Focus 34/1995, p. 178-181) I read an >article about industrial espionage. It is said that the secret >services have lost their main task when the east/west cold war had >gone. Their new task is the industrial espionage. The russian, french, >and american services were referenced in the article. The cold war isn't so decisive. Much of espionage has always been industrial. I is an essential component of political espionage in any case. Millitary espiong may get the headlines but the bulk of the work is trawling through trade stats and various open networks in embassies etc. In any case with the breakup of the USSR there are now more states to watch and because they are unstable more need to watch them. Phill

1 0