- cypherpunks-legacy - lists.cpunks.org

CDR: Re: ssz.com network trouble
by auto58194＠hushmail.com 20 Nov '00

20 Nov '00

Neil Johnson wrote: > > Is there something wrong with ssz.com. I haven't gotten any list mail and I > can get to the site. > ICANN action. Jim has become dangerous.

1 0

CDR: Carnivore not as selective as FBI said, privacy group charges
by anonymous＠openpgp.net 20 Nov '00

20 Nov '00

http://www.computerworld.com/cwi/story/0,1199,NAV47_STO54114,00.html Carnivore FOIA Docs http://www.epic.org/privacy/carnivore/foia_documents.html By JENNIFER DISABATINO (November 17, 2000) Carnivore, the FBI's e-mail surveillance software, is capable of capturing "all unfiltered traffic," despite assurances from the FBI this summer that the program only captures e-mails going to people on whom the FBI has a warrant. The Electronic Privacy Information Center (EPIC) in Washington requested all FBI documents on Carnivore through a Freedom of Information Act request, and those documents are being released piecemeal after a judge's order (see story). An independent review team from the Illinois Institute of Technology Research Institute (IITRI) is due to file a draft "technical report" on the Carnivore system with the U.S. Department of Justice today. "The little information that has become public raises serious questions about the privacy implications of this technology," said David Sobel, general counsel for EPIC. "The American public cannot be expected to accept an Internet snooping system that is veiled in secrecy." The latest release of documents to EPIC was posted online yesterday. According to the released document, which summarizes tests done to the Carnivore software in May, "The PC [running Carnivore] could reliably capture all unfiltered traffic to the internal hard drive (HD) (words deleted)." "I think they just ran a test just to see the capabilities," said a spokesman at the FBI, who confirmed the release of the documents to EPIC. He added that the test may not be how Carnivore is actually deployed. Previously released documents reveal that Carnivore was originally created in February 1997 under the name Omnivore, and it was originally proposed for a Sun Microsystems Inc. Solaris X86 computer. In June last year, Omnivore was replaced by a system the FBI now calls Carnivore, which runs on a Windows NT-based computer. The data released by the FBI also includes a discussion of interception of voice over IP and reviews of tests for performance and recovery from attacks and crashes for both Omnivore and Carnivore. The existence of Carnivore was revealed when an attorney for Atlanta-based Internet service provider Earthlink Inc. told a House Judiciary Committee in April that the FBI was requiring the company to install the system on its network to fulfill court-ordered surveillance of criminal suspects. But the company resisted the installation of the secretive system because it caused performance problems on its network. It also couldn't examine the technology to determine if its capturing of e-mail, IP addresses and other traffic violated the privacy of other customers.

1 0

CDR: Re: Public Key Infrastructure: An Artifact...
by obfuscation＠beta.freedom.net 20 Nov '00

20 Nov '00

Bram Cohen <bram(a)gawth.com> writes: > Unless that problem is fixed, man in the middle is hardly made more > difficult - for example, Mallory could break into some random machine on > the net and steal it's public key, then hijack local DNS and when someone > goes to amazon.com redirect them to amazon.hackeddomain.com, and then > proxy to amazon.com - now even SSL says the connection is safe. Are you sure that works? I would think the SSL client would do a connection to the URL the user typed, www.amazon.com, and check the name in the cert to see if it (approximately) matches. If some DNS redirection is done in the background so that amazon.com gets mapped to amazon.hackeddomain.com, the client will not be aware of this (will it?) and so it will still throw up a warning when it sees a cert for hackeddomain.com on a connection to amazon.com. Ob

1 0

CDR: " WE currently hiring SERIOUS HOMEWORKERS Position: Home Typist, Clerk, Secretary, Mail Processing, Supervisor, Manager...
by trueopps＠lycos.com 20 Nov '00

20 Nov '00

Earn $3,500 -$5,000 per month! Experience is NOT necessary. Part time/full time. ANYWHERE in the world! This is a GREAT and EASY home business to start and REAL job for everyone. Apply now Please, be serious in accepting this job, because we are only hiring serious homeworkers. We offer you a REAL job that you can do at home and increase your income. If you are looking for a get-rich-quick scheme or MLM program, please do not e-mail me. If you are not interested please hit "Reply" and type in the word "Remove" in the subject field and you will not be contacted again. For more infomation please apply to homeworker65(a)alloymail.com Please provide a valid E-Mail Address so I may respond to you. Subject:homeworker Please write short text those who are serious. Thank you for your time Rachel Mother of 1

1 0

CDR: Initiative - key to Become Successful Home Worker! -AYXK
by gar1ry＠hotmail.com 20 Nov '00

20 Nov '00

Don't delay, don't lose Your Chance! Use Your FREEDOM of Choice! Get Clear Home Work! Start Perfect Own Internet Home Business! Make FREE money as partner! Boost your Internet Connection Speed! Speed up your computer! Go to: http://www.virtue.nu/garry/ http://www.geocities.com/garryusar/ ***************************************** Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply with the word REMOVE in the subject line.

1 0

CDR: Key-Address correspondence in networks?
by Ray Dillinger 19 Nov '00

19 Nov '00

I want to run this idea past some knowledgeable people and see if it looks like a good idea.... In an application which passes encrypted messages from one host to another, it is desirable to have the message differently encrypted at each 'hop' along the way (to defeat traffic analysis). But, this link-to-link encryption requires keeping track of an enormous number of keys, and that introduces complexity which a cracker could use to get into the system. Bluntly, after reviewing PKI and x.509 certs, I don't think that there is a sufficient reason to trust that the machine I'm talking to is actually the machine its cert claims it to be. The proposal is to use longer keys for each machine, and have the IP address of each machine be part of its key. (or in another network environment, assign it an "address" which happens to *be* its key...) That way, you can instantly spot at least one class of bogus requests and constrict the possibilities for an attacker. (ie, "if the key presented does not match the address it's presented for, refuse no matter what DNS or the key database say about the name-to-key correspondence and the name-to-entity correspondence".) Note, these keys are for asymmetric encryption - probably elliptic- curve or RSA. The IP address will be on the public-key side. The actual packets will be encrypted under a symmetric algorithm, with the key for the packet encrypted under the asymmetric algorithm and transmitted with it. My questions: 1) Is using a longer key just paranoia in this case, or is there an actual weakness in constricting the choice of public key that makes the private key easier to derive? 2) Is there a reasonable class of attacks and spoofs that this protects against? 3) If so, does this protection make the system noticeably harder to break? (ie, does it protect against what would otherwise be the easiest attacks?)

2 1

Re: Public Key Infrastructure: An Artifact...
by Kevin E. Fu 19 Nov '00

19 Nov '00

Of relevance to SSL and trust in DNS... Even without stealing keys, there are unconventional ways of circumventing SSL server authentication. That is, pretending to be an SSL server that you are not. For instance, a client might forget to verify in a resumed SSL session that the server hostname matches the CN involved with the original connection. If the client starts a resumable session with a server, that server can pretend to be other hosts. Examples: http://www.cert.org/advisories/CA-2000-05.html http://snafu.fooworld.org/~fubob/netscape-ssl.html There is not a well-defined trust model for proxied SSL content. SSL authenticates servers, not content. Example: http://www.mit.edu:8008/menelaus/bt/17272 Even if SSL were perfect, implementing certificate management will remain tricky. -------- Kevin E. Fu (fubob(a)mit.edu) PGP key: https://snafu.fooworld.org/~fubob/pgp.html >Unless that problem is fixed, man in the middle is hardly made more >difficult - for example, Mallory could break into some random machine on >the net and steal it's public key, then hijack local DNS and when someone >goes to amazon.com redirect them to amazon.hackeddomain.com, and then >proxy to amazon.com - now even SSL says the connection is safe. > >-Bram Cohen

1 0

Re: Public Key Infrastructure: An Artifact...
by Lynn.Wheeler＠firstdata.com 19 Nov '00

19 Nov '00

specifically with respect to SSL server certificates ... their primary objective was supposedly to overcome shortcomings in the domain name infrastructure integrity (and as stated, most of the SSL server certificate issuing entities actually also have dependencies on that integrity). Fixes for the integrity of the domain name infrastructure ... eliminates the domain name infrastructure as a business case/justification for the existance of those certificates. Specifically with respect to SSL server certificate, the remaining issue is possibly merchant/server trust (not trust with respect to internet operational integrity ... but fusiness/fraud trust with respect to the business operation of the merchant/server). Establishing that trust goes beyond just having the comfort that if you are defrauded that you might be able to identify the guilty party. That can be addressed with an online BBB &/or consumer report type of service providing real-time information. Eliminating both justifications for SSL server certificates ... then makes the vast majority of the existing SSL server certificates redundant and superfulous (and I believe would severely impact the business case justification for setting up an operation to provide such a service). Now this is applicable to the current existing dominant PKI deployment in the world today (possibly accounting for 99.999999999% of instances where there is a certificate transmitted and a client checks the contents of that certificate). It possibly is not applicable to any other hypothetical PKI implementation which may or may not currently exist. Ben Laurie <ben(a)algroup.co.uk> on 11/19/2000 05:03:20 AM

1 0

Re: Public Key Infrastructure: An Artifact...
by Lynn.Wheeler＠firstdata.com 19 Nov '00

19 Nov '00

actually ... not really ... this was discussed early this summer as to what they actually check ... and how trivial it is to fabricate necessary details to pass such checking random ref: http://www.garlic.com/~lynn/aadsmore.htm#client3 in general it is sufficient to have registered any DBA name & have a d&b entry plus some misc. other stuff ... all relatively easy to establish. Since the DBA name & d&b entry aren't cross-checked as part of the SSL certificate validation ... just the domain name in the certificate against the domain name used ... you could be really surprised at what comes up for DBA names. I've had credit card statements that listed the DBA names which had absolutely no relationship to the name of the store I had been to ... which i eventually had to call both the credit card company/bank and the store to figure out what was going on. Ben Laurie <ben(a)algroup.co.uk> on 11/19/2000 04:08:39 AM

2 1

Re: Public Key Infrastructure: An Artifact...
by Lynn.Wheeler＠firstdata.com 19 Nov '00

19 Nov '00

oh yes, as to the other kinds of certificates. basically this is an issue of trust establishment. there are various forms of trust establishment, advertisement, brand, word-of-mouth, previous history, etc ... not just BBB or consumer report like stuff. Transactions are highly skewed ... with the majority of transactions having some form of trust establishment not needing BBB, consumer report, etc. (i.e. previous history, brand, etc) on the internet, for the minority of transaction w/o other forms of trust establishment and which would benefit from a BBB, consumer report, etc solution ... there can actually be two approaches: 1) offline paradigm; certificates are offline paradigm solution ... they've been manufactored at some time in the past with potentially out-of-date and/or really stale information. 2) online paradigm; a BBB, consumer report, etc online web site that gives up-to-date, real-time information about a merchant. these would be well-known web-sites and merchants could even have buttons that take the consumer to such a web-site. Some number of the certification, licensing, & trust organizations have actually expressed preference for the online paradigm, in part because it creates a tighter bound with the consumer, they have better tracking of consumer reliance on their services, and the information provided is current & up-to-date.

1 0