- cypherpunks-legacy - lists.cpunks.org

Re: Wired Integrity
by nobody＠cypherpunks.ca 17 Dec '03

17 Dec '03

At 4:35 PM 12/13/1996, Sandy Sandfort wrote: >> What is troubling is that it is written by Sandy Sandfort who >> works at C2Net.... > >...At the time I wrote and submitted the article I neither worked >for Sameer... Thank you for the clear explanation. Just so you know, I did not doubt your integrity for an instant. Wired should have appended a short paragraph explaining the possible conflict of interest. The Little Green Man

2 1

Re: ITARs effects
by Lucky Green 17 Dec '03

17 Dec '03

At 10:06 AM 12/13/96 -0500, Adam Shostack wrote: >This implies that putting something up for FTP == export. Holy >shit. Sure. What did you expect? -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred Make your mark in the history of mathematics. Use the spare cycles of your PC/PPC/UNIX box to help find a new prime. http://ourworld.compuserve.com/homepages/justforfun/prime.htm

1 0

RE: !! Point 'n Crypt -- Win95 Privacy for Everyone !!
by Walt Armour 17 Dec '03

17 Dec '03

There is no arguing that 40 bits is strong security. I agree with that. But we (Soundcode, and anyone else in the business of crypto) have to also look at things from the standpoint of market share and market size. Exportability directly affects market size and weighs in fairly heavily. (Which is why ITAR (oops, Commerce) restrictions bite). Which is why the current offering is 40 bits. As for security, the current release of PnC is primarily targetting privacy, not security. They are two very similar but different approaches. 40 bits is sufficient to encrypt files and keep them away from friends, family and coworkers (unless you work at the NSA). The point of Point 'n Crypt is to attempt to make encryption technology easily useable and widespread. If anything you have is of such a nature that 40 bits isn't enough protection then by all means don't use PnC (at least not this version :). As for your final point, I agree, some people are stupid. But part of the purpose of being a cypherpunk (and SoundCode) is to educate those that can be educated. Sometimes education just has to take pretty small steps... later, walt ---------- From: Matthew Ghio[SMTP:ghio@myriad.alias.net] Sent: Friday, December 13, 1996 4:49 PM To: walt(a)blarg.net Cc: cypherpunks(a)toad.com Subject: Re: !! Point 'n Crypt -- Win95 Privacy for Everyone !! walt(a)blarg.net (Walt Armour) wrote: > Point 'n Crypt uses 40-bit DES-CBC (exportable), salted SHA passphrases, > and conforms to PKCS #5 and PKCS #7. 40bit encryption isn't much security at all. If you've got something important enough to encrypt, then it's important enough to find a proper encryption program. Why would anyone buy this shit? (That's a rhetorical question, of course; the answer is because some people are stupid...)

1 0

Re: Race and IQ
by nobody＠huge.cajones.com 17 Dec '03

17 Dec '03

At 8:30 PM 12/13/1996, Timothy C. May wrote: >(For the curious, I am persuaded that there are minimal differences >in "intelligence" between the several or many races, but that >cultural and sociological factors strongly affect upbringing, >learning, interest in doing well in school, ability on standardized >tests, success in business matters, and so on.) The question is certainly interesting scientifically. Some Africans exhibit skills which are not found elsewhere. For example, in some African societies, I am told, there are people who can do things like play a drum with the left hand to 13 beats a measure and do something like 17 beats a measure with the right hand. Those who aren't amazed by this should try doing three beats on the left hand with two on the right. Call me when you master it. ;-) If you lived in a society where this skill was considered an important component of social success, most of us would appear to be retarded. (Consider, for example, the ancient Chinese civilization. Appointment into the imperial bureaucracy occured only after the applicants passed elaborate tests regarding their knowledge and interpretation of poetry. That was the entire qualification.) It has been claimed that African societies have never been "civilized" in the sense of developing large bureaucracies and cities. When many people make this claim there is an implication that the more with it peoples did this. But is that so reasonable? Read reports of life in European cities in the 18th century, before running water and before sewage systems. Give me the country any day! Many of the readers of this list are anarchistically inclined. When we hear that African societies have tended to be anarchistic, we should applaud their wisdom and insight. Perhaps these people could teach the rest of us a few things. (And maybe teach Hilary Clinton a few things. Is there a history of welfare states in Africa, or did they practice voluntary anarchistic communal charity on the level of villages?) It is not out of the question that once the human genome is decoded and its relationship with human intelligence understood that we will find that Africans beat out everyone else. (Incidentally, I question the claim that African societies never developed cities and bureacracies. The Egyptians are the most prominent example. Mathematically adept and literate they prospered for a couple thousand years. A better run than the Romans managed! We tend to think of Egyptians as being sort of like Europeans. I believe this is because Europeans invented Egyptology. Excuse me for pointing out the obvious, but Egypt is in Africa. What is more, if you study Egyptian statuary, you will find many examples of distinctly African looking royalty. Also, I know that cities like Timbuktoo were centers of Muslim learning and were large enough to have streets and houses. We may know little about them because Europeans were not allowed to visit, and also for racist reasons.) Scientific questions aside, it isn't clear why the racial link to intelligence matters. What are we going to do differently if it turns out that, on average, for genetic reasons, Albanians are less quick on the uptake than other people? The link between intelligence and success is not at all clear. We generally consider mathematicians and computer programmers to be smart, but in terms of total life competence, large numbers of these people live less than ideally. There are many instances in which I prefer to hire somebody who is less intelligent, but better equipped to play on the team, better organized, or just less of a primadonna. The eugenicists propose murder. This doesn't make any sense at all. We all have friends who are both smarter and dumber than ourselves, yet we don't plot their murder. Intelligence is just an excuse for what these people really want to do. If God came down and told us that there was no genetic basis for intelligence, next week there would be some other reason for the same policy. On the flip side are those who want to help the unfortunate with the time and labor of others. A racial link to intelligence will not increase my sympathy for such schemes. The upshot is: If you respect the rights of others, it doesn't matter. Now for some entertainment. Oliver Wendell Holmes, when he was a judge in Virginia, ordered the forcible sterilization of several young women. The state would wait until they became ill and then when they were admitted to a hospital, they were sterilized under the guise of giving them some other operation. Holmes claimed that the grandmothers of the women were imbeciles, their mothers were imbeciles, and that they were imbeciles. His great line was "Three generations of imbeciles are enough!" Curiously, it turns out that the word "imbecile" was a euphemism for "illegitimate". Know your doctor! Red Rackham

3 2

Magic Numbers in MD5
by ph＠netcom.com 17 Dec '03

17 Dec '03

I am curious where some of the magic numbers in MD5 originated. First, we have the four chaining variables, A, B, C, and D which are initialized with apparently random numbers. Are they as random as they look, or are they carefully chosen? Second, we have the t_i values. Schneier's first edition says this: "In step i, t_i is the integer part of 4294967296xabs(sin(i)), when i is in radians. (Note that 4294967296 is 2^32.)" Does abs(sin()) have some properties that are especially conducive to strengthening MD5 or is it just a function to generate mildly random numbers? If the latter, wouldn't the algorithm be stronger if it was used with completely random numbers? Peter Hendrickson ph(a)netcom.com

3 2

new homepage
by Psionic Damage 17 Dec '03

17 Dec '03

Check out This homepage, it's definitely under construction. www.geocities.com/SiliconValley/Heights/2608/ ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------- Zer0 Faith Inc. H/P/A/V/C UNDER-WORLD www.geocities.com/SiliconValley/Heights/2608 MEMBERZ: GATEMASTER, VIRIZZ, KRASH, EVIL TWIN, KORRUPT, PHONEHAZORD, PSIONIC DAMAGE, ORPHEUS (the pirate), MANTICORE, ERADICATOR, PSYCHODROME, BIONIC SMURF, SONIK, §ILVER KAT, kOBRA, & KRYPTIK! EMAIL:zerofaith@nlights.net (headquarterz) hakker1(a)hotmail.com (Delious's Haus!) hackerz(a)juno.com (The Gatemaster'z palace) zerofaith(a)geocities.com (delivery/help/requests/suggestions)

1 0

RRE: The InterNIC: a case study in bad database management
by E. Allen Smith 17 Dec '03

17 Dec '03

I've dropped a note to Jonathan Kamens pointing out that InterNIC is a monopoly, and therefore has no real reason to keep up any databases that don't directly generate money. -Allen From: IN%"rre(a)weber.ucsd.edu" 14-DEC-1996 02:53:56.61 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help(a)weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Fri, 13 Dec 1996 16:44:21 -0800 (PST) From: risks(a)csl.sri.com Subject: RISKS DIGEST 18.67 RISKS-LIST: Risks-Forum Digest Friday 13 December 1996 Volume 18 : Issue 67 ---------------------------------------------------------------------- Date: Thu, 12 Dec 1996 17:07:04 -0500 From: "Jonathan I. Kamens" <jik(a)cam.ov.com> Subject: The InterNIC: a case study in bad database management (This message was also sent to comp.protocols.dns.ops .) The InterNIC (http://www.internic.net) is responsible for Internet domain name service for all top-level domains, as well as for second-level domains underneath all the old ARPA domains except MIL (EDU, GOV, NET, ORG, COM). Until a few years ago, domain registration services were provided by the InterNIC for free. That changed when they convinced the NSF that its grant money wasn't enough to cover their costs, so (amid much hubbub on the Net) they started charging $50 per year for any second-level domain registration, with the first two years (i.e., $100) payable in advance. According to <http://rs.internic.net/nic-support/nicnews/stats.html>, the InterNIC registered 638,788 new domains between August 1993 and September 1996. If I'm doing my math right, at $100 per domain, that's almost $64 million, or over $20 million per year. I would think that with that much money, they'd be able to provide competent service to their customers. Unfortunately, my experience has been that they're simply not doing an acceptable job. Some examples: ***** * Their automated systems do not function properly. They've introduced a PGP-based system for authentication of domain contacts. In other words, they allow domain contacts to register their PGP public keys in the InterNIC public-key database, and then requests which come from those contacts will only be accepted as authentic if they are signed with the corresponding provide key. Unfortunately, this system does not always work. Recently, I submitted a series of twelve database modification requests to the InterNIC in a single day. All of them were correctly signed with my PGP key. Of the twelve requests, three were returned to me in messages beginning, "We are not able to verify the PGP signed message that you sent us." To make matters worse, for one of those three failed requests, I received a message claiming the the modifications I'd requested had been completed, two days *before* I received the message informing me that they were unable to verify my PGP signature. I have asked the InterNIC multiple times why their system randomly fails to verify valid PGP signatures. They have not responded to my inquiries. Interestingly enough, another poster to comp.protocols.dns.ops claimed that when he asked an InterNIC on the telephone about their PGP authentication system, he was told that it is not currently working. That would seem to indicate that the InterNIC is aware that there are problems with it, and yet they continue to advertise it on their Web site without any indication that it might not work for any given request. * There are some data in the database which are impossible to update using the templates they provide. One of the types of data stored in the InterNIC database is hosts; in particular, hosts which act as domain-name servers for domains registered with the InterNIC have records in the database. Host records include an organization name and address associated with the host. And yet, the template for updating host records (available at <ftp://rs.internic.net/templates/host-template.txt>) does not have fields in it for updating that information! I believe that there are a couple of other record types in the database which have this same problem. This organization/address data has been described to me by an InterNIC employee as an "old hold-over;" it seems that new host records do not have organization and address data, but old ones do. Nevertheless, one would think that when switching to a new format for host records, the InterNIC would have either removed the obsolete data from the old records or established a procedure for updating it. Instead, the only way to update this information electronically is to send a plain-text message to hostmaster(a)internic.net explaining what you're trying to do, and then hope that whoever reads your message will be competent enough to understand what you're asking for and do the update by hand. Which brings me to my next point... * When asked how to do something that is not handled automatically by their templates, their staff give incorrect answers (or simply ignore the query) more often than they give correct answers. Of the twelve requests mentioned above, six of them were handled improperly by the InterNIC staff members who processed them. Iwn several cases, I received a response instructing me to use a particular template to make the changes I had requested, when in fact those changes had nothing whatsoever to do with the template they told me to use. I finally had to escalate my requests by sending "out-of-band" E-mail to an InterNIC employee who has resolved problems of this sort for me in the past, and she was able to "bounce" my requests to a high enough level that they actually got processed. Incidentally, the InterNIC introduced one or more typographical errors into the data I sent them when processing six of my twelve requests (i.e., when they were done processing my requests, six of the twelve records I asked them to modify had one or more typographical errors in them). I suppose that sending incorrect answers is better than how things were a few months ago -- then, if you sent a request that the person who read your message did not know how to answer, he/she simply ignored it and sent no response whatsoever. * There are some data in their database which are impossible to update using their current procedures. Imagine this scenario... Joe Admin at Foo, Inc. is responsible for system administration, including DNS administration. He therefore has a contact record in the InterNIC database indicating that he works for Foo, Inc., and he is listed as a contact for various domain, network, and host records, in the InterNIC database. Now, he leaves the company and takes a new job, with no further contact with Foo, Inc. He doesn't bother to update his contact record in the InterNIC database before he leaves. Foo, Inc. would rather not let records remain in the InterNIC database claiming that Joe works for them when in fact he does not. Therefore, they want to contact the InterNIC and tell them, "Look, the information in Joe Admin's contact record which says that he for us is incorrect. You can confirm this by attempting to send E-mail to the address in the record, or by calling the phone number in the record and asking to speak to him. The person who answers will confirm that he no longer works there. Please either delete the contact record completely or remove the information in it which associates Joe Admin with Foo, Inc." Sounds reasonable, right? Well, unfortunately, the InterNIC has *no procedures whatsoever* for allowing a company to remove contact information which incorrectly lists them. I attempted to do just what I described, i.e., to get the InterNIC to remove the contact record for a former employee of OpenVision who no longer works here, and who I cannot contact to ask him to update his own record (and considering that it's not hurting him in any way, I don't see that he'd have any incentive to update it even if I could ask him to). After several rounds of E-mail with the InterNIC, they called me on the telephone to discuss what I was trying to do. Once on the phone with them, I was "bounced up" through several layers of InterNIC staff, until I was finally able to speak to a woman who was perfectly willing to admit that yes, the scenario I described was a somewhat common one, and yes, it was perfectly reasonable for a company not to want the InterNIC database to associate non-employees with the company, but no, there's no way for anyone but the owner of a contact handle to update it. "Perhaps we need to establish a procedure for that, and I'll be glad to discuss that for you with our customer service manager, but we don't have one right now," she said, and she did not offer to make an exception and handle my particular request manually without the blessing of a "procedure". Presumably, this means that I could edit my own contact handle to indicate that I work for any company that I want, and that company would have no way to get the InterNIC to remove the fraudulent information. Similarly, presumably, that means that (to be a little morbid for a moment), if someone listed in the InterNIC database dies, there's no way for anyone else to get the InterNIC to remove the deceased's record from the database. When I pressed the woman about this, she said to me, "If you're a network administrator at this company, you presumably have control over the mail server" (an assumption which is not always true, and indeed isn't true in this case; although I can ask the people who administer the mail server to make changes and hope that they'll listen, I don't have the ability to make the changes directly). "Well," she continued," if you send us a mail message which claims to be from the former employee, asking for his record to be deleted, we'll process it." "Let me get this straight," I responded. "You're telling me that I should forge E-mail to your system in order to delete this record." She confirmed that interpretation. I said, "Surely you see the absurdity of that." She responded, "Well, obviously, ideally we wouldn't want anyone forging requests to our system, but in this case, that's the only way for you to delete the record." "What if the former employee had associated a PGP key with his contact record before he left the company." "Well, in that case, you'd need his private PGP key in order to delete the record." "But surely you know that's impossible -- the whole point of PGP is that only the owner a private key has access to it. Even if I had access to the file in which it was stored, I wouldn't know the correct password to unlock it." "Well, in that case, there would be no way for you to delete the record." ***** There are a number of countries with strict laws about the collection of private information in computerized databases. Database maintainers are required to seek permission from all individuals who have data about them stored in the database, to guarantee the security of the database, and to establish working procedures for keeping the data in the databases up-to-date. The United States has few such laws (there are laws about specific types of databases, such as credit and medical records, but no laws about databases in general). Until I started dealing with the InterNIC, I didn't see much point to them. Well, I've changed my mind. the InterNIC proves rather clearly that left to their own devices, companies will not maintain databases in a responsible manner. Incidentally, nowhere on the InterNIC's WWW site can I find the address or telephone number of the governmental office which oversees their grant and handles complaints about their services. Several months ago, I sent them E-mail asking for them so that I could file a complaint, to be considered the next time their grant comes up for renewal. Like many of my other messages to them, that request was ignored. Jonathan Kamens | OpenVision Technologies, Inc. | jik(a)cam.ov.com ------------------------------ End of RISKS-FORUM Digest 18.67 ************************

1 0

Chek it out
by Zer0.Faith.Inc.＠website.chek.it.out 17 Dec '03

17 Dec '03

www.geocities.com/SiliconValley/Heights/2608 It's Kool, but still under construction.

1 0

Chek it out
by Zer0.Faith.Inc.＠website.chek.it.out 17 Dec '03

17 Dec '03

www.geocities.com/SiliconValley/Heights/2608 It's Kool, but still under construction.

1 0

NTT Develops Secure Public-Key Encryption Scheme
by Nobuki Nakatuji 17 Dec '03

17 Dec '03

http://pr.info.ntt.co.jp/news/news98e/980416.html Nippon Telegraph and Telephone Corporation (NTT) announced today the development of Efficient Probabilistic Public-Key Encryption (EPOC), a highly secure and mathematically verified public-key encryption scheme that encrypts information on the transmission side with a public-key (encryption key) and then decrypts it on the receiver side with a secret -key (decryption key). Encryption technology has become necessary to prevent information on the Internet from being monitored by others without authorization. Public-key encryption is being widely researched as a practical means of encrypting communication for security. The paramount feature of any public-key encryption schemes is ensuring that figuring out the decryption key from the encryption key is as difficult as possible, to prevent unauthorized use of ciphered information. The RSA*1 scheme uses factoring and the elliptic curve encryption scheme*2 uses elliptic curve discrete logarithms, both of which can take a supercomputer a very long time to determine the key. It has not been verified, however, that either scheme provides the necessary security to prevent ciphered information from being broken by a method other than factoring or elliptic curve discrete logarithms. The Rabin encryption scheme*3, which also uses factoring, offers no algorithm other than factoring for computing the complete plain-text, but it has not been proven that any bit of plain-text cannot be computed. EPOC is a practical scheme in that the computer computation workload for encrypting and decrypting is about the same as that for the RSA and elliptic curve encryption schemes. Also, EPOC is a highly secure scheme which uses a trapdoor discrete logarithm*4 as the key mathematical technique and can be broken only by factoring. Factoring is difficult to accomplish, even with a supercomputer, and the probability that an efficient solution to factoring will be found soon is very low, because mathematicians have been studying the problem for years. EPOC ensures that partial, as well as whole, texts cannot be broken. Finally, EPOC uses probabilistic encryption, so re-encrypted text is encrypted differently each time, unlike the Rabin and RSA scheme, which use deterministic encryption. NTT now plans to incorporate EPOC in systems for enhanced security on the Internet. Public-key encryption is used primarily for key distribution, because computation load is greater than that for secret-key encryption*5, so EPOC will be used in existing encryption modules for key distribution. Other applications will also be developed. In particular, EPOC is suitable for electronic voting and anonymous telecommunication since it has a homomorphic property, unlike the RSA, Rabin and elliptic curve encryption schemes. The theoretical details will be presented at Eurocrypt '98 in Finland this June. Notes: *1: The RSA scheme was developed by Rivest, Shamir, and Adleman in 1978 and is based on the difficulty of factoring. It was the first public-key encryption scheme. *2: The elliptic curve encryption scheme was proposed independently by Miller and Koblitz in 1985 and is based on the difficulty of elliptic curve discrete logarithms. The basic technique is based on a scheme developed by Diffie and Hellman in 1976. *3: The Rabin scheme was developed by Rabin in 1979 and is based on the difficulty of factoring. It was the first public-key encryption scheme to verify the impossibility of breaking a complete text without factoring the public-key. *4: A trapdoor discrete logarithm is a newly discovered discrete logarithm problem that can be solved only if a secret-key is known. *5: Secret-key encryption differs from public-key encryption in that the sender and the receiver use the same key for encryption and decryption. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0