- cypherpunks-legacy - lists.cpunks.org

the whole list
by Jeff Young 17 Dec '03

17 Dec '03

I would like to be added to the list

1 0

SecureWeb
by nobody＠myriad.pc.cc.cmu.edu 17 Dec '03

17 Dec '03

We'll just see.... =========Begin forwarded message========= >Date: Fri, 16 Dec 94 07:51:27 -0800 >From: more(a)newsmaster.tgc.com >To: SQUEAL(a)eek.eek.com >Subject: 4989 Web Security Toolkits Available Late December from Terisa >Systems Dec. 16 > >Web Security Toolkits Available Late December from Terisa Systems Dec. 16 >SUPERHIGHWAY REPORT HPCwire >============================================================================= > >A news release from Terisa Systems and SPRY -- > > Washington, D.C. -- Terisa Systems has announced that its SecureWeb >Toolkits for World Wide Web transaction security will be available later >this month. > > The company also said that CyberCash Inc., Open Market Inc., O'Reilly & >Associates, SPRY Inc., Spyglass Inc. and Verity Inc. will be the first >companies to use the toolkits to build Web servers or clients with security >features. > > Terisa Systems was launched earlier this year by RSA Data Security Inc. >(RSA) and Enterprise Integration Technologies Corp. (EIT). The company's >toolkits provide an implementation of Secure HTTP (HyperText Transfer >Protocol) for commercial products. Secure HTTP (S-HTTP), which was developed >by EIT, is a security-enhanced version of the World Wide Web's internal >communications language. > > David Pool, president of SPRY, said S-HTTP will be incorporated into the >company's Internet software -- Internet In A Box, the AIR Series and AIR >Mosaic Express -- in the first quarter of 1995. Consumers using Internet In >A Box will be able to purchase products safely over the Internet with a >credit card. In addition, companies or publishers using the AIR Series and >AIR Mosaic Express can market, sell and support their products. Pool said, >"Currently, the Internet is a vast, untapped marketplace still lacking >security and payment services. However, the S-HTTP protocol addresses both >encryption and authentication making electronic commerce a reality for our >customers." > > According to Douglas Colbeth, president of Spyglass, his company will offer >S-HTTP as a module in its Enhanced Mosaic Security Framework, making Mosaic >suitable for applications requiring confidentiality and authentication. >Enhanced Mosaic is the commercial version of NCSA Mosaic, the popular World >Wide Web browser from the National Center for Supercomputing Applications at >the University of Illinois. Colbeth said, "Our customers see the huge >potential in commerce on the Internet, but are very concerned about security. >An industrial strength solution such as Secure HTTP will let Mosaic handle >a wide range of applications requiring uncompromising security." > > At O'Reilly, Dale Dougherty, publisher for the Digital Media Group, said >S-HTTP will be used for a secure version of the GNN Direct service, that >allows subscribers to order from publishers or advertisers who market and >sell products over GNN Direct. He said, "We've been looking for a security >solution that will allow our subscribers to order safely online. Secure HTTP >provides the capabilities needed for our GNN service." > > Concerning plans of other licensees, CyberCash will use the technology to >provide a system for safe electronic payments over the Internet and Open >Market, a developer of electronic commerce solutions, plans to sell a Web >server that incorporates S-HTTP. Verity is introducing Verity Mosaic, a >Mosaic client offering user authentication and secure communications for use >with Verity's Topic Information Server for the World Wide Web, also announced >today. > > SecureWeb Toolkits include an implementation of EIT's Secure HTTP, which >ensures the authenticity of transactions and the confidentiality of >information exchanged via the World Wide Web. With a secure HTTP-enabled >application, users and information providers can encrypt and sign messages >and other material digitally. Binding agreements are possible because >communications are secret and tamper-proof and cannot be repudiated. > > SecureWeb kits incorporate RSA public key cryptography technology to permit >spontaneous, secure communications between unfamiliar correspondents. >SecureWeb also supports other cryptography systems such as traditional shared >password and Kerberos. A SecureWeb run-time license is required; run-time >license pricing is volume-based. Toolkits will be available on a limited >basis in December 1994. > > Additional information on Terisa Systems is available at URL >http://www.terisa.com. Those interested can also send e-mail to >infoterisa.com or telephone 415/617-1836. Additional information on Secure >HTTP is available by sending email to <shttp(a)infoeit.com>. > > For more information, contact Deanna Leung of SPRY, Inc. at 206/442-8231 >or email her at: <deannaspry.com>, or contact Nancy Teater of Terisa Systems >at 415/321-0252, or email her at: <nrthamilton.com>. > >***************************************************************************** > H P C w i r e S P O N S O R S > Product specifications and company information in this section are > available to both subscribers and non-subscribers. > > 900) Ampex 915) Genias Software 905) Maximum Strategy > 912) Avalon Computer 930) HNSX Supercomputers 906) nCUBE > 921) Cray Research Inc. 902) IBM Corp. 932) Portland Group > 907) Digital Equipment 904) Intel SSD 935) Silicon Graphics > 909) Fujitsu America 916) MasPar Computer *931) Sony Corporation > > *Updated information within last 30 days >***************************************************************************** >Copyright 1994 HPCwire. >To receive the weekly HPCwire at no charge, send e-mail without text to >"trial(a)hpcwire.tgc.com". ==========end forwarded message========== ==================Thomas Jefferson================== The strongest reason for the people to retain their right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government. ==================================================== _/_/_/ _/_/_/ _/ _/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/ _/ _/_/_/ _/

1 0

List Dead Again!??
by j.hastings6＠genie.geis.com 17 Dec '03

17 Dec '03

Wow man. No letters waiting? No way. Could be GEnie, or majordomo again. Anyone get this? Please respond. Kent - j.hastings6(a)genie.geis.com

1 0

Re: e$ : NetBank
by analyst＠Onramp.NET 17 Dec '03

17 Dec '03

>There's an outfit called NetBank, which is selling e-cash-like *certificate >numbers*, 8 digit numbers only. No internal checksums or verification. Merchants must send an email message to verify that the money is previously unspent and receive fresh bills. >It's extremely ungainly, and it looks userous too, to the extent that they >charge 20% (each way?) to cash you in and out. I hoovered out all the >stuff in their infobot (netbank-info(a)agents.com) >Bob Hettinga > Agree about ungainliness. They aren't yet set-up with PGP or PEM, although they say they are looking into it, so they currently suggest that if you want to send encrypted mail, that you generate a key to be XOR'd with all messages to and from. They do provide the C code for the encryption, though ;) >From reading all of the info from the above infobot, it looks like they only charge the 20% once, to the merchant when he tries to redeem e-certificates for $USD, which they will pay out at the end of each month. They claim in their docs that the 20% is the cost of their 900 number service, so I suppose their business plan is to make money on the float, since they are not charging transaction fees for making change, verifying e-cash, etc. If they accepted credit cards they might be in much better shape. I would much rather see real Chaum-style electronic money, but have not yet received a response after signing up for their beta test. I wonder if NetBank's style of serialized e-certificates provide the 75% of the functionality that most people need to ignore better alternatives, especially if, as with Pr0duct Cypher's money, their is a big learning curve to go up before they can use it. Any pointers to other near-term e-cash systems? I am very interested in setting this up for relatively small transactions (<$50) in the not-to-distant future. Thanks for info. -- Benjamin McLemore <analyst(a)onramp.net>

1 0

Re: My anonymous remailer
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: Still, though, I think this would do more harm than good. I get about : 20 to 40 messages a day through my remailer, and only 5 or 10 of those are : encrypted. Switching to a policy that would require chaining and encrypt- : ing to make it useful would make it a lot harder to use the remailer. If Agreed, but it would also force us to get off our butts and make integrated remailer-aware mailers work properly, as opposed to the broken kludges we have at the moment. In the long term it would be for the better. (Every single time I've tried anything fancy with chaining and encryption, it hasn't been delivered. And I don't consider myself incompetant.) : The other problem I see with Graham's idea is that I'm not sure the : technology is there to provide good security in the face of this much : information. Not many of the remailers add delay, and a lot of people don't : like it when they do. In that case it may be easy to figure out what Again, fixing this up would be for the better good. You can just imagine that the FBI is already watching all remailers closely under arm-twisting from the Software Publishers Association, not to mention the NSA doing likewise for their own reasons. I think we *should* force ourseles to make traffic analysis visibly impossible. If we can crack an anon posting path with the same information available to an attacker who can monitor all the lines, our system is broken. We should put it up for peer-group testing just like a new encryption algorithm. I believe the security of current remailers is a joke against a real attack. It's *only* good enough to hide identity from other usenet readers. We might as well all use only one-hop remailers and stop kidding ourselves that the multi-hop stuff does any good at all. (I don't believe the anti-traffic analysis support of the current remailers is any good, which is why any postings I've made through remailers have been single-hop in clear. I just don't post anything that would get me in legal trouble. OK, maybe a couple of posts I've made would be personally embarrassing if I were outed, but I wouldn't be by any LEAs that were watching. They'd just be able to use logged postings in criminal cases) : path even a chained encrypted message took. Even the delaying remailers, : if they published message sizes, would usually reveal their in-to-out : correspondance. So I think it is premature to do this. Until we have : remailers which can support cryptographically strong message padding : with standard message sizes, running on un-hackable systems with delays : and batching to confuse the in-out relationships, it would be counter- : productive to do what Graham suggests. Precisely my point. Except I see it the other way - as long as we're not forced to implement these measures properly, they'll never happen. : service it's hard to know what features to provide. In particular, if : cleartext output is prevented, how much does that impair the usefulness of : the network? My instinct is that it hurts a lot, although it would be nice : for the operators since it would eliminate most sources of complaints. I meant that cleartext *input* should be prevented. Cleartext output however can be 'outed' in accordance with policy, even if it's personal mail. Also it can be silently dropped on the floor by the last-hop admin without any comeback, for whatever egregious reason he chooses, or even randomly. It's up to the sender to pick a route that works. If some remailer admin (like JGdeA, or was it John Stanley?) choses to allow M.M.F postings, then he can take the heat for them personally. It's impossible to tell an email recipient apart from a mail to news gateway, so we can't enforce encrypted output only, if we allow posting. However, the 'outing' policy makes it in people's best interests to encrypt to the destination user if they can. Unencrypted *mail* as well as news is also fair game for the last-hop remailer admin to delete on his personal whim. G PS When I say we should out all information, I'm only talking about information that's visible going in and out. If we ever get my earlier idea of chained encrypted reply-addresses to work, with time-sensitive keys that are deleted after a few days, I'm not suggesting publishing those keys. Certainly, we should assume that a few sites will be broken into, or even many sites, but as long as one site remains uncompromised, there's a strong link in the chain that holds up the entire chain.

2 1

Re: CYPHERPUNKS TO THE RESCUE
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 14:43 1994/07/25 -0700, Sandy Sandfort wrote: >The questions are: Could standard auto and garage door openers >easily be retrofitted? Could a "crypto remote" with its own CPU >be made small enough to fit into a hand-held unit? Could such a >system be made for a reasonable cost? ... Sounds like an application for a "challenge-response" system. But that would require transmission from garage unit to car unit. If there were syncnronized clocks then the signal could be a function of time so that the above replay would fail. That requires only a PRNG. Both units could compute the next password from the same PRNG but this would require a "backspace" button on the car unit for those occasions where the garage unit failed to hear a broadcast signal. A "reset to new known state" for both units would be required for when the state became hoplessly confused.

5 4

Re: CYPHERPUNKS TO THE RESCUE
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Matt Blaze describes a couple of possible attacks against the simple one-way authenticating garage door opener. The attacks are basically the ones that are often suggested against one-way login authentication protocols. However, I think the garage door opener scenario is just different enough that the attacks he describes can be ignored or eliminated without overly complicating the devices. (The following idea is a combination of ideas stolen from earlier posts. plus a couple of new ones. Anyone following this thread should recognize the earlier ideas and hopefully mentally credit the original posters.) The transmission is one-way, from hand unit to base. There is no encryption involved, no hash functions, no counter values to transmit, no loosely synchronized clocks. The hand unit consists a transmitter, a memory chip, a simple cpu chip, and some kind of jack or plug used to initialize the unit. Initialize the hand unit and base with identical sets of large random numbers using a wall mounted panel. The random numbers will be arranged in groups of, say, ten. I'll call each group a "family". Since memory is cheap, load hundreds of families of random numbers. Both the hand unit and the base will maintain an internal counter of the "current family number". As numbers from a family are used, the "current family number" is incremented. If the two "current family numbers" get off, then the hand unit and base will have to be re-initialized. To open the door, push the button on the hand unit (duh) to send the first random number from the "current family". The base unit opens the door if the received number is in the "current family" of random numbers. If the door opens, the "current family number" counter in the base unit is incremented and the remaining numbers in the previous "current family" become invalid for opening. The "current family number" in the hand unit automatically increments after about a minute from the time of the button push. If the first button push/transmission didn't get received, a second button push (within a minute) will send another number from the same family, activating the door. If the first transmission is successful, but the driver continues to push the button, the subsequent transmissions are useless to an interceptor/man-in-middle because the numbers transmitted are from a family that has just become invalid for opening. To close the door (within a minute of opening): pushing the button sends another random number from the original family (i.e. the same family used to open the door, now invalid for opening). Since the door is in the open position, the base unit interprets the transmission as a request to close the door. NOTE: the base unit ignores all button pushes while the door is in the process of opening. WRINKLE: If you wait more than a minute before trying to close the door, the hand unit increments to the next family number. Therefore, when the door is in the open position, the base unit will actually check the received random number against both the previous "current family" and the current "current family". The major flaw I see in this scheme is that the "current family number" in the hand unit may become off frequently due to accidental button pushes. ... Now that I've gotten to the end of the description, I'm not so sure this scheme is practical. I get the feeling that the delayed auto-increment of the hand unit will create situations that violate the principle of "Least Surprise". In other words, the hand unit may not always do what you expect it to do. Oh well, I'll post my description anyways in case it induces some better ideas in others. Jim_Miller(a)suite.com

1 0

Re: Local Cypherpunks (?) group
by donald goldhamer 17 Dec '03

17 Dec '03

>Is there any interest in establishing a local (Chicago area) equivalent of >the bay area Cypherpunks which meets in physical (as opposed to cyberspace ) >form. Topics to be addressed include issues of privacy, security, >cryptography and .... Since the Chicago chapter of CPSR (Computer Professionals for Social Responsibility) has decided to develop a project (public education, etc.) in the area of privacy (among others), it would seem to me to be more productive to work with them. Donald H. Goldhamer d-goldhamer(a)UChicago.EDU Academic Information Technologies 312-702-7166; fax: 312-702-3219 University of Chicago, Culver Hall 206, 1025 E 57th St, Chicago IL 60637

2 1

Re: GUT and P=NP
by nzook＠math.utexas.edu 17 Dec '03

17 Dec '03

>berzerk(a)xmission.xmission.com writes: > > One last word on this. Try and represnet a continum of states by an > > infinite turing machene. Go ahead, I dare you. You can't.<=big period. >Could I not let each position on the tape represent a real value in >[0...1]? >| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5(a)tivoli.com> | >| TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | >| (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" | HAHAHAHAHAHAHAHAHAHAHA ROFL HAHAHAHAHAHAHAHAHAHAHA Okay. So I should be so rude. People please. When someone, especially like berzerk or tcmay makes a strongly definitive statement, PLEASE try not to show your ignorance to the whole group. Cantor demonstrated, near the turn of the century, that no such system can represent all reals in [0,1]. Boring technical explanation follows. Let f be a function from the integers to [0,1]. Note that the Turing tape has precisely one space for each integer, so this function cooresponds to your idea. I claim that f is not onto. (ie: you cannot represent all reals this way.) Write a decimal expansion for each elment in the range of f, and order them as follows: f(0) = .d(1,1) d(1,2) d(1,3) d(1,4) .... f(1) = .d(2,1) d(2,2) d(2,3) d(2,4) .... f(-1)= .d(3,1) d(3,2) d(3,3) d(3,4) .... f(2) = .d(4,1) d(4,2) d(4,3) d(4,4) .... f(-2)= ..... construct a, in [0,1], as follows: let g be a function from {0,1,2,3,4,5,6,7,8,9} to {5,6} s.t. g(x) = 5 if x>5, g(x) = 6 if x < 6. Let a = sum for i = 1 to infinity of g(di,i)/10^i. I claim that a is not in the range of f. Is f(0) = a? No, the first digits differ. Is f(1) = a? No, the second digits differ. Is f(-1)= a? No, the third digits differ. You get the picture. There are a couple of small details left out, you should be able to fill them in. Historical note: I believe that is the original construction. Further historical note: You can see the germ of Godel's work here. Nathan

4 3

Re: GUT and P=NP
by wrevans＠oceanus.mitre.org 17 Dec '03

17 Dec '03

>berzerk(a)xmission.xmission.com writes: > > One last word on this. Try and represnet a continum of states by an > > infinite turing machene. Go ahead, I dare you. You can't.<=big period. > >Could I not let each position on the tape represent a real value in >[0...1]? > Nope, You'd still have only a countable number of states and the cardiality of [0..1] is not countable. I think that a simple diagonalization argument would show that one would need an uncountable number of infinite turing machines to represent a continum of states. Ward R. Evans wrevans(a)mitre.org voice: (703) 883-7631 fax: (703) 883-1363

1 0