Re: Razor
On Sun, Jun 08, 2003 at 06:00:51PM -0700, A.Melon wrote: I don't care about The Rat's postings like some of my anonymous associates, but someone's razor reporting is inaccurate. Some spam from this list has been revoked at razor so it drops down below 30% confidence, when it shouldn't be revoked at all [1]. Inversely, some legitimate postings are getting reported to razor when they should not be [2]. If you auto-report stuff to razor, please be extra-careful with this list. By pointing out this attack you have guaranteed that our resident cypherpunks attackers will be reporting lots of legit posts to razor. I'd suggest not using razor to filter cpunks mail. While we're talking about spam filtering, please do not reject cpunks mail that your filters id as spam. Dump it in /dev/null instead. Sending reject messages to mailing lists is rude. In another bit of list administrivia, it appears that both aol and rr are not accepting mail this weekend. (their servers accept connections but never send HELO or EHLO). I hear that aol's incoming mail is hosed, I don't know what rr's problem is. Eric
Re: Maybe It's Snake Oil All the Way Down
On Wed, Jun 04, 2003 at 04:32:23PM +1200, Peter Gutmann wrote: James A. Donald [EMAIL PROTECTED] writes: I never figured out how to use a certificate to authenticate a client to a web server, how to make a web form available to one client and not another. Where do I start? There's a two-level answer to this problem. At an abstract level, doing client certs isn't hard, there are various HOWTOs around for Apache, Microsoft have Technet/MSDN papers on it for IIS, etc etc. At a practical level, it's almost never used because it's just Too Hard. That's not the SSL client-cert part, it's the using-X.509 part. It's the I part of PKI that's hard. That the assumptions built into X.509 (i.e. a rigid certificate hierarchy) don't work everywhere just makes it harder. And the obstinance of the standards organizations involved don't help. Too often people see something like Peter's statement above and say oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just do it in XML instead and then it'll work fine which is simply not true. The formatting of the certificates is such a minor issue that it is lost in the noise of the real problems. And Peter publishes a fine tool for printing ASN.1, so the human readable argument is moot. Note that there isn't a real running global PKI using SPKI or PGP either. The largest problem with X.509 is that various market/political forces have allowed Verisign to dominate the cert market and charge way too much for them. There is software operable by non-cryptographers that will generate reasonable cert reqs (it's not standard Openssl) but individuals and corporations alike balk at paying $300-700 for each cert. (yes I know about the free individual certs, the failure of S/MIME is a topic for another rant). This is why lne.com's STARTTLS cert is self-signed. Verisign isn't getting any more of my money. Eric
[eb@comsec.com: Re: Maybe It's Snake Oil All the Way Down]
- Forwarded message from Eric Blossom [EMAIL PROTECTED] - Date: Tue, 3 Jun 2003 13:25:50 -0700 From: Eric Blossom [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Orig-To: John Kelsey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], EKR [EMAIL PROTECTED], Scott Guthery [EMAIL PROTECTED], Rich Salz [EMAIL PROTECTED], Bill Stewart [EMAIL PROTECTED], cypherpunks [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Maybe It's Snake Oil All the Way Down In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.4i On Tue, Jun 03, 2003 at 10:42:01AM -0400, John Kelsey wrote: At 10:09 AM 6/2/03 -0400, Ian Grigg wrote: ... (One doesn't hear much about crypto phones these days. Was this really a need?) Yes, I believe there is a need. In my view, there are two factors in the way of wide spread adoption: cost and ease of use. Having spent many years messing with these things, I've come to the conclusion that what I personally want is a cell phone that implements good end-to-end crypto. This way, I've always got my secure communication device with me, there's no bag on the side, and it can be made almost completely transparent. And for cellphones, I keep thinking we need a way to sell a secure cellphone service that doesn't involve trying to make huge changes to the infrastructure, ... Agreed. Given a suitably powerful enough Java or whatever equipped cell phone / pda and an API that provides access to a data pipe and the speaker and mic, you can do this without any cooperation from the folks in the middle. I think that this platform will be common within a couple of years. The Xscale / StrongARM platform certainly has enough mips to handle both the vocoding and the crypto. Also on the horizon are advances in software radio that will enable the creation of ad hoc self organizing networks with no centralized control. There is a diverse collection of people supporting this revolution in wireless communications. They range from technologists, to economists, lawyers, and policy wonks. For background on spectrum policy issues see http://www.reed.com/openspectrum, http://cyberlaw.stanford.edu/spectrum or http://www.law.nyu.edu/benklery Free software for building software radios can be found at the GNU Radio web site http://www.gnu.org/software/gnuradio Eric - End forwarded message -
[PaulLambert@AirgoNetworks.Com: Re: BIS Disk Full]
- Forwarded message from Paul Lambert [EMAIL PROTECTED] - Subject: Re: BIS Disk Full Date: Mon, 2 Jun 2003 22:50:20 -0700 Thread-Topic: Re: BIS Disk Full Thread-Index: AcMpAGDW0rLn6AHCQFSmRRWCM9LG7QAkdTWg From: Paul Lambert [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Orig-To: Declan McCullagh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] X-MIME-Autoconverted: from quoted-printable to 8bit by gw.lne.com id h535oULl001507 Is it this? http://snap.bis.doc.gov/ The correct URL is: http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html This site contains the full process to export encryption source code that would be considered publicly available The site has you e-mail to three addresses: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] You can also send a disk to both to 14th Street and Pennsylvania Avenue and Fort Meade I've submitted twice and never gotten an acknowledgement ... can't imagine that they are that busy. Paul -Original Message- From: Declan McCullagh [mailto:[EMAIL PROTECTED] Sent: Sunday, June 01, 2003 8:52 PM To: Anonymous Cc: [EMAIL PROTECTED] Subject: Re: BIS Disk Full URL? Is it this? http://snap.bis.doc.gov/ Email to [EMAIL PROTECTED] does not bounce, at least not immediately. -Declan On Sat, May 31, 2003 at 01:34:00PM -0700, Anonymous wrote: I tried to notify the BIS that I was posting some code and I got this error back: [EMAIL PROTECTED]: 170.110.31.61 failed after I sent the message. Remote host said: Can't create transcript file ./xfh4VJhUa02511: No space left on device [EMAIL PROTECTED]: 170.110.31.61 failed after I sent the message. Remote host said: Can't create transcript file ./xfh4VJhVC02512: No space left on device Are our rights suspended until they get their system fixed? :-) - End forwarded message -
[eay@pobox.com: Re: Maybe It's Snake Oil All the Way Down]
- Forwarded message from Eric Young [EMAIL PROTECTED] - Date: Wed, 04 Jun 2003 01:05:24 +1000 From: Eric Young [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en To: [EMAIL PROTECTED] X-Orig-To: [EMAIL PROTECTED] CC: EKR [EMAIL PROTECTED], Eric Murray [EMAIL PROTECTED], Scott Guthery [EMAIL PROTECTED], Rich Salz [EMAIL PROTECTED], Bill Stewart [EMAIL PROTECTED], cypherpunks [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Maybe It's Snake Oil All the Way Down In-Reply-To: [EMAIL PROTECTED] Ian Grigg wrote: It's like the GSM story, whereby 8 years down the track, Lucky Green cracked the crypto by probing the SIMs to extract the secret algorithm over a period of many months (which algorithm then fell to Ian Goldberg and Dave Wagner in a few hours). In that case, some GSM guy said that, it was good because it worked for 8 years, that shows the design was good, doesn't it? And Lucky said, now you've got to replace hundreds of millions of SIMs, that's got to be a bad design, no? Well the point here is that the data encryption in GSM is not relevant to the people running the network. The authentication is secure, so there is no fraud, so they still get the money from network usage. Privacy was never really there since the traffic is not encrypted once it hit the base station, so the relevant government agencies can be kept happy. The encryption was only relevant to protect the consumers from each other. eric (hopefully remembering things correctly) - End forwarded message -
Re: Maybe It's Snake Oil All the Way Down
On Mon, Jun 02, 2003 at 10:09:06AM -0400, Ian Grigg wrote: A lot of the tools and blocks are too hard to understand. Inaccessible might be the proper term. This might apply to, for example, SSL, and more so to IPSec. These have a lower survival rate, simply because as developers look at them, their eyes glaze over and they move on. I heard one guy say that you can read SSH in an hour and understand what's going on, but not SSL. Some who can't understand SSL won't be able to do better. Especially since there is at least one very good book on it. Also, a lot of cryptosystems are put together by committees. SSH was originally put together by one guy. He did the lot. The original SSH protocol had holes so large that you could drive a truck through them. Tatu posted it to various lists and got lots of advice on how to clean it up. It still had holes that were being found years later. SSLv2, which was also designed by an individual, also had major flaws. And that was the second cut! I haven't seen v1, maybe Eric can shed some light on how bad it was. Peer review is not design by comittie. It is the way to get strong protocols. When I have to roll my own (usually because its working in a limited environment and I don't have a choice) I get it reviewed. The protocol designer usually misses something in his own protocol. I'd say that conditions for Internet crypto system success would include: 0. USE EXISTING SECURITY PRIMITIVES which allows you to 4. Concentrate on the application, not the crypto. Rolling your own crypto is where 95% of crypto apps fail... the developers either take too much time on it to the detrimient of the useability because it is the sexy thing to work on, or they write an insecure algorithm/protocol/system.Usually they do both! Eric
Re: The Art of Submarine Warfare
On Fri, Jun 22, 2001 at 06:08:49PM -0400, [EMAIL PROTECTED] wrote: #From: Greg Broiles [EMAIL PROTECTED] #To: Harmon Seaver [EMAIL PROTECTED] #Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] #Date: Fri, 22 Jun 01 16:49PM EDT #Subject: Re: The Art of Submarine Warfare # #At 01:22 PM 6/22/2001 -0500, Harmon Seaver wrote: # # Listen to it again -- doesn't she say I'm recording this?? # #Yes, she does - but the recorder would either have been on her person (in #which case it would have been taken from her before she was sitting in the #back of the police car), or in her car. And the repy at Date: Fri, 22 Jun 01 14:20PM EDT And the repy at Date: Fri, 22 Jun 01 13:59PM EDT What does 'lne' stand for, Late, or NEver? I only received the above due to the direct Cc. There's no cpunks mail in the queue at lne. If you're still subscribed (there's no [EMAIL PROTECTED] in the subscriber list but I assume that's not the address you receive mail at) then it went out to wherever you are or to a site that MXd for you. Eric
Re: The Art of Submarine Warfare
On Fri, Jun 22, 2001 at 07:43:21PM -0400, [EMAIL PROTECTED] wrote: #Subject: Re: The Art of Submarine Warfare #Date: Fri, 22 Jun 2001 16:11:35 -0700 #From: Eric Murray [EMAIL PROTECTED] #To: [EMAIL PROTECTED] # #There's no cpunks mail in the queue at lne. #If you're still subscribed (there's no #[EMAIL PROTECTED] in the subscriber list but #I assume that's not the address you receive #mail at) then it went out to wherever you are or #to a site that MXd for you. I received the above via my subscription route, which is cyberpass.net. Sub name is [EMAIL PROTECTED] So, three emails were dropped, to me at least. That is, they didn't make it from lne thru cyberpass. We don't feed cyberpass directly. I don't remember if there was a problem feeding it or if I just didn't turn it on. I've turned it on now. One drawback of the decentralized kludged-up CDR system is that it's difficult to trace problems. All I can tell is that all the cpunks mail left here in the usual time. What happened on the other nodes I can't say. Maybe the operator of the cyberpass node can? Eric
Re: PeopleLink Applications : Instant Messaging
On Mon, May 14, 2001 at 11:18:14AM -0400, Trei, Peter wrote: This is a wonderful example of the Choate's inability to engage in coherent discussion, and to assume that any reference must be to himself. It also demonstrates his incompetence re cryptography. The 'amusing claim' I refer to is the one made by the PeopleLink folk that their product uses MD5 encryption. MD5 is a hash algorithm, not an encryption algorithm. Yea... except that there are symmetric encryption algorithims based on hashes. Peter Gutmann's MDC is an example of one. I haven't looked at it, so I have no idea if PeopleLink is using something like MDC with MD5 or if they're being clueless at the marketing or engineering level. Eric
