December 2003 - cypherpunks-legacy

Re: NetManage & Cylink Crypto
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <9510060012.AA02236@ch1d157nwk>, andrew_loewenstern(a)il.us.swissbank.com (Andrew Loewenstern) wrote: > Anonymous wrote: > > The link with Cylink will allow NetManage to license and include > > the Cylink public key encryption technology in its applications > > with a variety of ciphering systems to be used in the NetManage > > suite, including: DES, Triple DES, Safer, IDEA, Skipjack, RC-2, > ^^^^^^^^ > > and RC-4. > > Hey, this is interesting... will Skipjack be included in future NetManage > products or is this press-release only mentioning Skipjack as an example of a > possible encryption algorithm for use with NetManage? It probably requires a PCMCIA card. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMHSpfCoZzwIn1bdtAQHhuAGAk64TLT89fxllmp1WhLxT/QJCrUuz3RmG MPI9irXcFyldaHEIlnDGpk7OQug5uTY1 =dyzf -----END PGP SIGNATURE-----

1 0

Re: Certificates, Attributes, Web of Trust
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <ac9961b42202100433c4(a)[205.199.118.202]>, tcmay(a)got.net (Timothy C. May) wrote: [...] > But I go further: a huge number of interesting applications of strong > crypto have no connections at all with physical persons, let alone with > True Names. Agents in computer transactions, applets fired across networks, > agoric entities in computational ecologies, BlackNet sorts of markets, and > on and on. This is true. Some of the most interesting applications of crypto don't involve True Names at all. The only reason, IMHO, why crypto is often thought of in terms of communicating between two True Names is because it is an obvious application to the layman. But it are the Blacknet type of uses where crypto really shines. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMHSr6CoZzwIn1bdtAQECCAF+Jok52IdshM4nLGjwqiImzw93dy/zSy9E QBmUR1yzX+17uuUoflSRE3R0bpx3uv+F =UM4a -----END PGP SIGNATURE-----

1 0

Re: Certificate proposal
by Hal 17 Dec '03

17 Dec '03

Bob Smart <smart(a)mel.dit.csiro.au> writes: >Consider the IPSEC case. The current situation is: >1. We go through some process, let's call it Process A, where we determine > that we want to talk to IP address 192.9.8.7. This would be, say, a DNS lookup on www.egghead.com. >2. We go through another process where we obtain the public key of 192.9.8.7. I get it by connecting to that IP address and asking for it, or perhaps I have it cached or I get it from some public cache. >3. We then try to decide, based on one or more certificates, whether we > trust the public key to be the correct public key for 192.9.8.7. I see the certificate is signed by someone I trust and it certifies that this key is good for connections to Egghead Software at www.egghead.com. >Now consider the key-centric version. >1. Process A returns a public key which denotes the destination we want to > talk to. OK, maybe this is some DNS variant that given www.egghead.com, returns a public key 0x12345678. >2. We then go through a process to obtain the IP address that belongs to > that public key. We probably won't use the public key as an index to > get that information. We probably use the information that was input > to Process A. In fact this information may fall out as a byproduct > of Process A. [However if we needed to make a scalable distributed > database of RSA public keys then I have a design to do this - > available on application.] OK, so now I do another DNS lookup on www.egghead.com to get the IP address. Or maybe I even use key 0x12345678 as an alternative index to get that address. >3. We don't need to trust any certificates or anything else at this stage. > The fact that the IP address belongs to the Public Key is signed by > the Public Key itself. Now you've lost me. Are you saying that the key is self-certifying, saying "I belong to 192.9.8.7"? That is, it is accompanied by a signature issued by that key itself on this IP address? I hate to be difficult, but this does not provide me with a warm feeling. Anyone could have issued that key, claiming to belong to that IP address. If the person who did so is able to interpose himself between me and that address then my messages are not secure. >The same thing happens with e-mail. If "Process A" gives us an e-mail >address to send to then we worry about whether we have the right public >key to go with it. If Process A gives us a Public Key then we can >have certainty about the associated e-mail address because the association >is signed by the Public Key. Again, I don't follow how we gain this certainty. >And a big win that just falls out of this is that I can have a >continuous exchange of information with one IP destination even if >it keeps changing its actual IP address (mobile computing) or I >can have an e-mail conversation with a person who keeps changing >their e-mail address. The things you want just fall out instead of >requiring clever software solutions. This can be dealt with in the certificate context by having a certificated key sign a statement that the IP address is now such-and-such. >In the key-centric world a certificate binds some attribute as a property >of a publc key. So an X.509 certificate would say "The owner of this >public key [i.e. person who knows the corresponding private key] owns >the following point in the X.500 namespace", rather than that "the >person identified by this DN owns the following publc key". Experience >has shown that the latter interpretation is a mine-field. It really >doesn't work. I don't really care whether the name is called an attribute, a distinguished name, or an ooblek. I just don't see how you're going to get along without it. The fact is, we live in a world populated by people and companies and we use names to identify them. I will grant that there are problems with uniqueness but I don't think the solution can be to just give up on the whole idea of names since they are so messy. Pretending that keys are communicating beings is not going to work. Hal

3 2

Re: FORGED CANCELS of posts on n.a.n-a.m
by jms＠tennis.opus1.com 17 Dec '03

17 Dec '03

In article <V0BgcD4w165w(a)bwalk.dm.com>, dlv(a)bwalk.dm.com (Dr. Dimitri Vulis) writes: > I'd like to remind everyone of the well-thought-out scheme for authenticating > cancels proposed some time ago by Taneli Hujskonen and Benjamin Franz, that can > also be integrated into a Lazarus-like system for tracing forged cancels. Maybe. On the other hand, there's nothing to keep certain well-connected news administrators from removing the appropriate header line, or, even more interestingly, substituting values such that the cancel equation is well known. Fundamentally, though, what I've discovered is that any significant change to the news system is impossible to do, because installed base restricts what people are willing to change. Look at the dozens of extensions to NNTP which all conflict, are non-standard or ill-described, yet are demanded by moronic software such as Netscape's news reader. When will we see NNTP v3? Never... jms Joel M Snyder, PhD, 1404 E Lind Rd, Tucson, AZ, 85719 Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX) jms(a)Opus1.COM http://www.opus1.com/jms Opus One PLEASE NOTE: The useful parts of Arizona changed from area code 602 to area code 520 on March 20, 1995.

1 0

Re: Simple Hardware RNG Idea
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 8:20 PM 10/5/95, Simon Spero wrote: >On Thu, 5 Oct 1995, Norman Hardy wrote: .... >> You presumably use the oddness of the count for your random bit in some >> predetermined time interval. External radiation can change, but not bias >> the parity. If the counter saturates, the counter may be biased towards one > >Hmmm. But isn't this method slightly biased? If the probability of N >events < the probability of N+1 events, wouldn't you need a large number >of events per bit to make the bias insignificant? .... What you really need is entropy (information). I propose concatenating several counts and sending them thru MD5. The counts are distributed the same way but are independent so that the entropy of the concatenation is the sum of the entropies. Each count has a Poisson distribution. That tells you how many bits of entropy there are in the input to the MD5. Take that many bits, rounded down, as your random bits. If there are an average of x bits in a time interval then the probability that the count will be exactly K is (x^K/(K!))exp(-x). That is the Poisson distribution. The entropy is then: - sum[i=0 to infinity] (x^K/(K!))exp(-x)log( (x^K/(K!))exp(-x)) = - sum[i=0 to infinity] (x^K/(K!))exp(-x)(log(x^K/(K!)) - x) = - sum[i=0 to infinity] (x^K/(K!))exp(-x)(K*log(x) - log(K!) - x) Here is a klutzy Scheme program to evaluate these: (define (sum g)(letrec ((ss (lambda (n) (if (= n 0) (g 0) (+ (g n) (ss (- n 1))))))) (ss 30))) (define (log2 x)(/ (log x)(log 2))) (define (fact n)(if (= n 0) 1 (* n (fact (- n 1))))) (define (p x k) (* (/ (expt x k)(fact k))(exp (- x)))) (define (en n)(sum (lambda(x) (let ((c (p x n))) (if (= c 0) 0 (* c (log2 c))))))) (en 1) => 2.07 (en 3) => 2.92 (en 10) => 3.73 (en 15) => 4.0 I.e. if 1 count is expected on average there are two bits of entropy in the count (supprising!) and if the count averages 10 then there are 3.7 bits worth. It goes up as the log. Before you bet your enterprise on this scheme consider that the math was done at 03:30 AM.

1 0

Re: subjective names and MITM
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:24 PM 10/5/95 -0400, Adam Shostack <adam(a)homeport.org> wrote: > The key does indeed have a high likelihood of being unique, >but dealing with 1024 bit identifiers could strain database systems, >especially when 100 well chosen bits would be than enough. If everybody in the world has a 1024-bit key, that's 750 GB; that's not bad at all by the time everybody in the world would have one, and you could do MD5s in about 100 GB, which is a little more convenient. Today, for 750 GB, you'd probably have tape in your system, or optical jukebox. But not everybody has one; on the other hand, I suppose individuals in well-heeled countries might end up with dozens of their own. On the other hand, the number of 1024-bit primes is something like 2^1023/log(2^1024) (if I remember right), or roughly 2^1013. The probability of two independent uniformly distributed primes matching is about 2^1023/2^32, which is still an astoundingly mindbogglingly LARGE number. If you've got 1024 bits of entropy in your input process, there will not _be_ any matches. (If people insist on using sources of randomness like clocks or user names, the chances are a lot higher....) Now, for 128-bit hashes, whether it's MD5 or just the near-bottom 128 key bits, by the time you get 2^64 of them together, you've got a 50% chance of a match. Not a problem, since you'll not likely need that many, even for the 2^33 people in the world. Still not a problem. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: FORGED CANCELS of posts on n.a.n-a.m
by Erik E. Fair 17 Dec '03

17 Dec '03

An NNTP v2 protocol specification effort is underway in the IETF now. Strictly to clean up existing extended practice - not to do new things. Erik Fair

1 0

PCMCIA Crypto
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

PCMCIA Establishes Security Card Working Group The dream of a standardized encryption interface may soon be realized! San Jose, Calif., Oct. 5 /PRNewswire/ -- PCMCIA has formed a new Working Group dedicated to standardizing and promoting the PC Card as an interface for data encryption and digital signature applications. The Working Group was formed to work within the PCMCIA Technical Committee to help the Association define and standardize the capabilities and requirements for PC Card Security Card devices. The Group's immediate goals are to define the necessary extensions to the PC Card Standard that will allow easy identification of Security Card devices, and to proactively identify other vendors in the market and solicit their support for standardizing PC Cards as a security device. The formation of this Group represents the formalization of an industry trend. A standardized form factor and interface for security devices is finally an attainable goal thanks to the widespread acceptance of PC Card technology," said Gary Visser, a senior software engineer with Spyrus Communications and Co-Chairperson of the Working Group. "It is this high level of host support that will promote PC Cards as a solution for electronic banking and commerce." PC Cards are seen by many experts as an ideal solution for digital signature and data encryption applications due to the established base of PC Card slots, and because most security applications are math intensive and require the processing power and storage of computers. The proposal to form the Group was presented to PCMCIA by Spyrus, Inc. of San Jose, California. The group will be co-chaired by Edward Tuggle of IBM Corporation and Visser of Spyrus, Inc. Visit PCMCIA's World Wide Web site at <http://www.pc-card.com>. Contact: Greg Barr, Public Relations Coordinator, of PCMCIA, 408-433-2273, ext. 114, or <gbarr(a)pcmcia.org>.

2 1

FON_tap
by John Young 17 Dec '03

17 Dec '03

10-6-95. WSJaper has a report on the global rise of unions between banks and telcos for exploiting electronic marketecture. Quotes: "Being in partnership with these phone people is like shooting adrenalin into your veins," gushes one banker who recently invested in the national phone company. "Bricks and mortar won't do it," says another banker, "you have to drive down the transaction cost." FON_tap

1 0

Trust company banks on Internet
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Fri, 6 Oct 95 08:10:41 -0400 From: "GORD JENKINS" <jenkins(a)fox.nstn.ca> X-Minuet-Version: Minuet1.0_Beta_14.1 Reply-To: <JENKINS(a)fox.nstn.ca> X-Popmail-Charset: English To: www-buyinfo(a)allegra.att.com Subject: Trust company banks on Internet First Internet Banker ?? !! Check out http://www.bayshore.com >From the Toronto Globe and Mail page B 1 Fri 6 Oct 95 "Bayshore set to become first Internet banker - Trust promises approval in as little as two minutes" >From the Ottawa Citizen Page B7 Fri 6 Oct 95 " Trust company banks on Internet -Financial shopping in cyberspace arrives in Canada next week with the first intractive banking sevice on the Internet. Analysts say there is a lot more coming soon. Bayshore Trust Co.plans to take applcations for loans up to $15,000 and orders for guaranteed investment certificates directly from customers on the World Wide Web" Gordon Jenkins jenkins(a)fox.nstn.ca http://www.infop.com/karoma -- GORD JENKINS e maik JENKINS(a)fox.nstn.ca tel 613 794 6735 fax 613 723 8938 --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0