December 2003 - cypherpunks-legacy

Re: properties of FV
by Nathaniel Borenstein 17 Dec '03

17 Dec '03

Excerpts from fv: 15-Dec-94 Re: properties of FV Eric Hughes(a)remailer.net (3987) > I'm not trying to imply that you couldn't cobble something up fairly > quickly, but I have my doubts that a good quick hack will scale > appropriately for even a modest sized operation. Assuming that thing that you're "cobbling together" is based on a reasonably robust database engine, it should scale a long, long way. Basically all you need is a set of three-part records: account-id, cumulative amount, and timestamp of oldest transaction. (You might want a fourth field that gives all the purchasing details as text, if your services sells a range of different kinds of things). Any good commercial db system should be able to handle a LOT of such records. > > The very nature > > of such a net billing system requires linkability of transaction to > > transaction, or in other words generates identity. So FV is > > unsuitable for small value anonymous transactions. > I would still like to you address this issue, if only to acknowledge > the above characterization. This goes back to the two kinds of anonymity that you so usefully defined in your earlier message. These small transactions would have counterparty anonymity -- all that the seller knows is your first virtual id, which is essentially a user-chosen pseudonym -- but not issuer anonymity. > As I had recalled from reading your materials, you were charging 29 > cents plus 2% on one leg of the transaction plus an additional 2% on > the other. Rereading, this is not the case. Am I remembering a > previous situation? No, you're just confused. Our charges have not changed, this is what they've always been. Probably our materials weren't clear enough somewhere, in which case I apologize. > Partial security is better than no security. That's a *very* interesting statement. I'm not at all sure what it means, so I'm not sure if I believe it or not. Sometimes partial security is worse than no security because it gives people a false *sense* of security. (People who know their email is going in the clear are likely to be more prudent than people who believe their email is "encrypted" even though the encryption algorithm might be a very poor one. I've even known people to pass real secrets around using rot13, amazingly enough. People can be quite naive.) > One of the underlying conceptual problems with allowing a key to be at > risk is some sort of belief that compromises of secret keys should > never ever EVER be allowed to happen. This is ludicrous. When the > benefit of the use of a private key means that it might be > compromised, don't rely upon it's not being compromised. This is a very good point. It is one that is often missed in analyses of digital banks, in particular, where the consequences of compromising the bank's keys are often not sufficiently considered. > In particular, if a digital signature does not, by agreement, carry an > implied warrantee of identity, then there's no problem at all. Use > the crypto entirely for transit security. If someone hacks your > machine and grabs your passphrase and forges a transaction, at least > the intruder has to grab your passphrase. This is exactly the way we would expect to use crypto layered on top of First Virtual's protocols, if and when such cryptographic protocols are deployed widely enough to have penetrated af meaningful portion of our market. -- Nathaniel

3 2

On criticizing SSL, and insecure transport layers
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

kipp(a)mcom.com: > Is [SSL] insecure? If so, how? > > Is there some cipher techonology that it absolutely must support? If > so, which one? why? While I'm not going to say anything about SSL's qualities as a secure transport layer as such (I've not looked at it carefully enough) I think that the criticisms are on larger issues. 1. Standards - the reinventing the wheel criticism; if other methods for more or less the same thing exist (and swIPe source has been around for all to test to their hearts' content) why try a new one? This point seems to have mutated into general criticism of NCom's attitude to / knowledge of IETF proceedings and the technology 2. Security - the basic insecurity of _any_ transport layer. "If Netscape had to come up with a new secure protocol, why did they choose the transport layer?" The transport layer is insecure because: it is less under the control of a user, it happens 'automagically'; it is at a lower level and so generally implemented by central authorities - sysadmins etc, and does not suit the web of trust model (nor does X.509) which is much better outside dictatorships; it is provided by the telco or net service provider who, as I suggested earlier, are prone to arm-twisting by the authorities, whether by legislation, or while 'cooperating'. Transport layer security does not provide data authentication, it only provides server authentication; nor does it provide data security and privacy between users, it only provides network security. To rebut Kipp's favourite justification, insecure transmission of passwords: transport layer security does _not_ improve password security/privacy, but only ensures that once a plaintext password is received by the transport layer, usually at a service provider, then it will not be intercepted. Secure transmission of passwords could (but as far as I know is not widely) be implemented at the client level, through DH handshaking or something, which would ensure a completely secure and _private_ transaction. Transport layer security is nice because it is conveniently automatic and transparent, but it can lead to a false sense of security for precisely that reason. Of course these are quintessentially Cypherpunk objections. A bank, or Singapore, would be quite comfortable with such a system for internal networks. "We know everything about you that we need to know" - Coleta Brueck, IRS ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "In between the breaths is rishab(a)dxm.ernet.in the space where we live" rishab(a)arbornet.org - Lawrence Durrell Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

SLIP [Was: McCoy is Right! New Mail Format to Start Now.]
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

Black Unicorn wrote: >So, I'm running a Mac //cx with a shell account at the moment. I have a >lowly 14.4k connection. All I got is 9600. >What solution do you have for the user who has no direct connection to >the net, has merely a modem speed bandwidth, and is in a non-isdn area? > >I often need to pull large files over 3 megs into my shell account at >high speeds. (60-100 kb/sec) Impossible with SLIP. Well, perhaps I can interested you in QuickNet (16MEGAbps, thats an Ethernet, two video channels and several phonelines, all running over the very same 4 wires that are already in your wall) but in order for that to become available, you have to help convince Congress that local telco de-regulation is a Good Thing. Seriously, how do you get 100 kbps over a 14.4 kbps line? Even with the best compression you won't get that kind of throughput. >Are you telling me that I can do this and still have the advantage of SLIP? Whatever througput rate you get from the shell, you can get via SLIP. >Forgive my ignorance, but you'll have to enlighten me. Gladly :-) >> > >> >For reasons I just addressed in another post, I foresee being on a >> >dial-up (not a SLIP or PPP, that is) for a while. And I have relatively >> >few complaints about it. My service provider keeps the 9446 current >> >newsgroups, provides ftp and suchlike tools, and I don't have to be a >> >sysadmin. Frankly, if I have to choose between not being able to see >> >someone's MIMEd GIF and becoming a Unix sysadmin for my own site, I'll >> >skip the GIFs. > >Same balance for me when it comes to the transfer rate. Lets assume for a moment that you get much faster throughput by zmodem'ing a file from the shell than by ftp'ing it via SLIP (some users have reported that zmodem from the shell is faster than ftp, but the differece is marginal at best. I have never been able to verify the claim.) Having tia on your shell account doesn't affect your ability to use the shell in any way. If you are so inclined, you can still download files from the shell as you did before. You can also turn the shell into a SLIP connection with in seconds. Nothing lost, plenty gained. [...] >So how much am I expected to "shell out" ? You don't have to shell out at all. If you ever need to use the shell (to change your .profile, .plan, password, etc) you can just telnet to your account. I usually just hang up and call via the terminal emulator the one time per month I do that, but there really is not need to do so. >I'll come around when I'm sure I'm not losing anything. > >Convince me. As for MIME, which started this tread, no SLIP is needed, There are several dial-up mailers that handle MIME just fine. As for SLIP, in many areas it has become as cheap as a shell account. In San Francisco, SLIP is cheaper than a shell account ($15/month flat rate). For those with an overpriced local SLIP provider, or those who also want a shell there is TIA. Convinced? -- Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred.

1 0

Re: FV & PGP (was Re: First Virtual email security)
by Nathaniel Borenstein 17 Dec '03

17 Dec '03

Excerpts from fv: 15-Dec-94 Re: FV & PGP (was Re: First.. Ben(a)CS.YALE.EDU (1253*) > If you have to call, what would be the difference between this and normal > mail order save tha the catalog is digital? That's not a significant > enough of a change to have it considered a new form of commerce. The difference is that you only have to call ONCE, ever, and then you can order from any seller on that net accepts First Virtual accounts, with no encryption required. It's really silly for people to try to discuss FV's security without even understanding how it works. Please send mail to info(a)fv.com or spider over to http://www.fv.com. -- Nathaniel

1 0

Re: McCoy is Right! New Mail Format to Start Now.
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 5:27 PM 12/15/94, Timothy C. May wrote: >For example, I could spend some number of hours switching from my >current mail progam (elm) to some other editor which perhaps >better-supported the MIME messages seen here. But if all I got for >several hours of using, learning, and becoming comfortable with, say, >"pine," was the ability to see an _italicized_ word, or a word in >Cyrillic, then I would consider this a poor ROI. Well, I certainly agree with you, and I expect most everyone else does too. No one expects anyone to spend lots of time with minimal returns on that time. But the reason I think you are meeting so much animosity is because there are lots of people here who think MIME is the solution to making encryption easier to use. Whether or not Joe Random User switches to a MIME compliant app so he can see italicized words is irrelevant. But what _is_ relevant is whether Joe Programmer writes his mail reader to be MIME compliant, and specifically, writes it to appropriately deal with the about-to-be-standardized PGP types. We all agree that it's currently much too hard to deal with PGP on a regular basis, for most people. Some people are satisfied with the tools they have, but the vast majority of people either don't have access to those tools, or dont' think the available tools are sufficient. It's not currently easy to use PGP on a regular basis, and this is a big problem. A lot of people are convinced that MIME is the solution to this problem, and rightly so in my opinion. And they take many of your comments to be counter productive, in that we "should" be encouraging MIME, and we "should" be excited about MIMEs possibilities in this area. And of course people like MIME for other reasons too. But I don't think anyone is trying to blame Tim C. May, or anyone else, for thinking the current tools suck, and for not wanting to deal with MIME with the current tools. Everything is a cost benefit equation, and it's up to you to weigh the costs and benefits. But people see MIME as exciting technology, which if properly implemented, can do lots of really cool things. Not the least of which is make it easy/possible for mailers to deal with PGP correctly. Steve Dorner, who writes Eudora, is working on a new version that will interact with PGP transparently. He's been talking about it a bit on the MCIP list, and I'm very excited about it. It should make using PGP with Eudora incredibly easy. And he's relying on MIME, and the incipient PGP and encryption MIME standards, to make it work.

1 0

PGP Docs in HTML???
by Claborne, Chris 17 Dec '03

17 Dec '03

I am currently working on turning the PGP documentation into a HTML document with clickable table of contents.... Someone has probably already done this. I am doing it here for my "Security" home page at AT&T GIS San Diego, mainly for educational purposes. Do you know of anyone that has done this? If not I can post somewhere when I complete. It's a big task. ... __o .. -\<, chris.claborne(a)sandiegoca.attgis.com ...(*)/(*). CI$: 76340.2422 PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server. PGP-encrypted e-mail welcome!

2 1

Re: McCoy is Right! New Mail Format to Start Now.
by bshantz＠spry.com 17 Dec '03

17 Dec '03

Perry Metzger writes: >Sorry, Tim, but this isn't true. I know people who still own VIC-20s >that can't handle 80 columns. Also, users of ASR-33 teletypes might be >left out by the requirement to handle full ASCII. I was using an >ASR-33 full time only 15 years ago. 15 years ago, I was a 9 year old in the fifth grade who called the teacher a "nasty" name and was told to write 500 sentences as a reprimand. I asked if they could be typed, she said yes. So, I prompt;y went up to the 40 column display on the Apple IIe and wrote a four line, Apple Basic program that would repeatedly print 500 sentences saying, "It is not right to call the teacher names." When I handed it to her, she new she'd been set up. That didn't go over well as I remember. Anyway, that's not really what I wanted to say. I wanted to say that as a company that writes a Mail package. One of the biggest complaints of our customers has been lack of MIME support. Also, we have been severely "wrist slapped" for not formatting our mail messages to 80 characters so "normal people" could read it on their mail readers. So, my point, the market right now is for MIME support and user setting message widths. You can't please everyone all the time. >Now, I know that all usenet postings in Japan these days use ISO-2022 >encoded characters, and MIME and all that, and that people in Russia >use similar methods to carry their stuff, but they are just >bounders. Japanese characters are considerably different. I've been on some Japanese news servers that you just can't read with a normal news reader just because they require graphical Japanese characters. (Kanji, Katakana, or Hiragana ... depends on the group.) By the way, I was testing a news reader, I can't read Kanji. -- Brad >>>>>>>>>>>>>>>>>>>>>INTERNETWORKING THE DESKTOP<<<<<<<<<<<<<<<<<<<<<<< Brad Shantz bshantz(a)spry.com Senior Software Engineer SPRY Inc. Direct #: (206)-442-8251 316 Occidental Ave. S. Main #: (206)-447-0300 Suite 316 Fax #: (206)-447-9008 Seattle, WA 98104 WWW URL: http://WWW.SPRY.COM ---------------------------------------------------------------------- PGP Public Key at: http://www-swiss.ai.mit.edu/~bal/pks-toplev.html Or email: pgp-public-keys(a)pgp.ai.mit.edu Subj: GET bshantz >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

1 0

Re: properties of FV
by Andrew Lowenstern 17 Dec '03

17 Dec '03

> This goes back to the two kinds of anonymity that you so usefully > defined in your earlier message. These small transactions would > have counterparty anonymity -- all that the seller knows is your > first virtual id, which is essentially a user-chosen pseudonym -- > but not issuer anonymity. That would make this counterparty pseudonymity, not anonymity. The merchant, while not knowing the true identity of his clients, is still able to correlate the transactions of individual accounts (and must be able to under FV's policies). A malicious merchant, for instance, could recognize that a particular account is more interested in certain types of information and charge accordingly. andrew

1 0

Re: properties of FV
by Nathaniel Borenstein 17 Dec '03

17 Dec '03

Excerpts from fv: 15-Dec-94 Re: properties of FV Andrew Lowenstern(a)il.us. (718*) > > This goes back to the two kinds of anonymity that you so usefully > > defined in your earlier message. These small transactions would > > have counterparty anonymity -- all that the seller knows is your > > first virtual id, which is essentially a user-chosen pseudonym -- > > but not issuer anonymity. > That would make this counterparty pseudonymity, not anonymity. The merchant, > while not knowing the true identity of his clients, is still able to > correlate the transactions of individual accounts (and must be able to under > FV's policies). A malicious merchant, for instance, could recognize that a > particular account is more interested in certain types of information and > charge accordingly. Good point. I stand corrected, at least as far as the terminology is concerned. However, as far as the particular malicious-merchant scenario is concerned, I must say I'd be skeptical about any merchant who didn't tell me the price up front, *before* he asked me for my account-id... -- Nathaniel

1 0

Re: McCoy is Right! New Mail Format to Start Now.
by Amanda Walker 17 Dec '03

17 Dec '03

Tim May writes: > "Actual" terminals is not the issue, but "virtual" terminals *is*. > I haven't done a poll lately, or ever in fact, but my hunch is that 70% > of the list is emulating some form of terminal, e.g., a VT-100 or 102, > or maybe something slightly more exotic. Or a shell program, as in > America Online, which has its own standard. I'd actually be interested in a poll, but I know better than to actually ask for one :). > Perry made the same point that Amanda makes, that my Macintosh _should > be_ usable as a graphics system, not just for ASCII text. Well, I > agree, but so what? I have to admit some bias here--our flagship product for the Macintosh contains a very MIME-aware mailer (which I am working on making crypto-aware as well), and which was designed to make MIME seamless. No helper software, no extracting pieces and finding a viewer for them, it just works. > I note that all of Perry's messages, and most > of Amanda's messages, fit this ASCII model. In my case, it's because I intentionally make them fit. Most mailing lists have a general expectation of plain ASCII. When I send mail to other people at InterCon, I (and the recipients) see something that looks like any other Mac document--nice formatting, diagrams and screen shots displayed inline, and so on. And when someone sends me a file via email, even if they're not using a MIME mailer, it shows up as an icon I can drag to a folder in the Finder. This isn't really a commercial for my product, though :). This is how I think MIME was meant to be implemented, and it's analogous to how I think encryption should be implemented. Forget helper applications, macros, and so on. There should be two popup menus on the envelope: "sign with" and "encrypt with". When you select them, you get prompted for your passphrase, and it just works. This is the same direction that other commercial vendors are headed, and it's this kind of simplicity that I think will finally get people to start using the technology (just as with MIME). On this, I suspect the Netscape folks and I are in violent agreement :), as probably are you from some of your comments to this list... > (The MIME stuff I'm not saying shouldn't be used, just that some of > us--perhaps most of us, is my hunch--will not be adopting the > latest bleeding edge technology. Right now, PGP is more of a bleeding edge technology than MIME is, IMHO. > Finally, Amanda mentioned "being away from out desks." Well, many of > us are _always_ away from our desks when we post. From home machines, > not from T3-connected Indigos on our desk. Indeed, that's why I brought it up; at the moment, I'm sitting in my study at home posting over a dialup (14.4K) PPP link. I've also posted from 37,000 feet sitting in a DC-10 (in coach :)), with my mail being queued up until I could jack into a phone when I land. > One thing I would like very much is the ability to include simple > diagrams and drawings in my posts, but this is clearly an _ > unsolved_ problem, from a practical point of view. Hmm. I'd say it's a partially solved problem. Newsgroups like clari.features.dilbert are popular enough that there's at least a significant fraction of people who can handle MIME messages with embedded graphics. > and ask yourself where all these posts-with-diagrams are > if they're so easy to do.) Well, I could start posting some, if you want existence proofs :)... Amanda Walker InterCon Systems Corporation

1 0