December 2003 - cypherpunks-legacy

Re: PGP in UK - snooped as unSTEALTHed?
by Bill Stewart 17 Dec '03

17 Dec '03

At 06:29 AM 9/12/95 -0400, Perry wrote, replying to Gary: >> When are the PGP designers and coders going to get serious >> and develop STEALTH PGP inside PGP itself!? >Never, I hope. It would dramatically lower the utility of the >system. Can you imagine how disgusting it would be to try decrypting >something if you have a dozen keys outstanding? I disagree - if it's done right, the degree of stealth can be user-selectable, and even moderately stealthy options can tell which key to use without giving away much information. (For instance, 4 bits of keyid isn't very revealing, but will tell you which one or two of your dozen keys to try.) Have the most non-stealth options indicate that it's PGP-encrypted and addressed to keyid 0x12345678, Joe User <joe(a)foo.com>, blah, blah. The basic problem is that stealth wasn't an original design criterion, so many parts of the PGP data format reveal at least that PGP is being used, and occasionally other information as well. Some things are easy to work around (----- BEGIN PGP etc.), and some aren't. Changing this takes a substantial amount of redesign. >Not to mention how >hard it would be to deal with figuring out that you should even try to >decrypt things in the first place. As you say a couple paragraphs later: >If someone sees a bunch of random numbers in mail sent by me, it's going >to be pretty obvious what the hell is inside anyway. Similarly, if someone emails you a bunch of random numbers.... >I very much see this whole thing as a non-issue. Most of the time, for most users now, it's not an issue. But there are people who will need to hide encrypted messages, and as anti-privacy laws in the US become stronger, that may be us. Is this an issue for PGP 3.0.1, or an issue for Privacy:TNG? Probably the latter, given the state of the PGP world, and certainly ranting at the developers to do it now is uncool. But it should be a design goal. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Check Cloning frenzy and attack on anonymous accounts
by Black Unicorn 17 Dec '03

17 Dec '03

Cypherpunks might want to take note of the recent flurry of news program stings on banks which do not demand 12 pieces of identification in order to open an account. The latest horseman, check "cloners." Two networks have now run hidden camera stings on banks where they offer all manner of obnoxious fake identification and open accounts in silly names. The "purpose" being to expose the ease with which a dreaded check "cloner" can open an account to transfer your funds into. The process goes something like this: Check cloner gets account number from ATM slip or otherwise. Check cloner prints up 30 "checks" in any name at all with magnetic ink account number on the bottom for the benefit of automatic readers at the bank. Checks are written to the account in false name and withdrawn. For some reason, the focus seems to be on the ease with which one opens an account- rather than with the need to safeguard account information, and the lack of oversight by banks. Of course, the liability for these crimes is with the bank, which cleared a check without the proper signature. Of course, the immediate solution, rather than insuring the banks pay their liability for their insecure payments and check clearing system, and their printing account information on any piece of paper they can find, is going to be a crackdown on account identification- and probably legislation. (Note that often banks take months to pay the shortfall- when they do at all). New accounts can expect to have to cough up significant identification and I predict a re-newed call for national identification credentials. Tell the banks they have to pay within 2 days of the presentation by the duped depositor of the fraudulent checks and I would lay odds that the banks would be screaming bloody murder for a more secure payments and check clearing system than the trash they have now. Of course, because of the ignorance of the media, this will never happen. Of course, paying in cash will never be looked to as an answer either. Typical creeping statism. I suggest those of you who open clandestine accounts open a flurry now, before things get tough.

1 0

Re: Why ecash is traceable
by Donald M. Kitchen 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Excellent discussion on the subject, actually. However, your idea of the "first person to the bank" maintaining anonymity via remailer block is flawed. First of all, if a collusion with the bank is being taken into account, presumably sufficient enough resources are involved that someone may try and track the reply block. Mixmaster (as your messages mentioned by name) would be necessary to eliminate the chance of tracking the block through combinations of replay attacks etc. (Which reminds me, has anyone implemented an Expiration date on Type I remailers yet?? I remember someone telling me it was being put into the RFC) However, mix does not have a reply block system. Nor are there any Type I -> Mix gateways, for reasons mentioned months ago. (PS, For historical sake, I was a strong supporter of a Shamir Sharing Shell Game[tm] with the type I message. Everything during those months came out of a rant program, so I can hardly expect you to have saved them) Soooo... Anyone up for a Shamir Sharing Shell game? Of course, a drop box system would be *much* sexier. Combined with, say, an encrypted socket, or maybe MIXing a packet straight to your door. (Every client a mix site, remember? Just make yourself a mix key and give it to the drop box. I figure if the TLA has you by then, you might as well trust the drop-box operator too) ObMiscCrypto: Cypherpunk archives seem to have been down for a month, and a mailto:// didn't wake anybody up. I got a message from Bob Silverman, apparently he would not be opposed to giving his software to the C-punk key Cracking Ring, Inc. as a group on the understanding that the group lend him some factored numbers. He reports having no PGP key, so getting a PGP sig won't be happening. Perhaps someone who knows him or someone who knows about factoring software would volunteer to get the goods? ObHiMom: Hi Mom. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMFk9cMLa+QKZS485AQHEpgL8C2N2eioUPaMqLlbzFL29F5zvq50J1o1+ nyoVxV51U4mglT40J8XZmF3/+15mN0aDbbA1NbOzd/7x20TeXnOwGGRHB2iHF0NB k++VRMrwX85MZ5snlf/c0l5XGnxKEuU6 =7hGk -----END PGP SIGNATURE----- <don(a)cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY PGP key - http://bert.cs.byu.edu/~don or PubKey servers (0x994b8f39) June 7&14, 1995: 1st amendment repealed. Death threats ALWAYS pgp signed * This user insured by the Smith, Wesson, & Zimmermann insurance company *

1 0

Re: Why ecash is traceable
by Bill Stewart 17 Dec '03

17 Dec '03

I first reacted to Hal's posting about the way Tim did. I got confused by the "Charlie" issue, but I think I see it. >Why not "online clearing" as the preferred model, then? It's probably still possible to do _some_ tracing in an online system. As in the previous example, Alice is going to conspire with the bank to catch Bob, _before_ she pays Bob the money; afterwards is too late. Alice creates an account Alice2 and spends the cash. Then she pays Bob the same cash. When Bob tries to deposit it, the bank notices it's already been spent, and does one of 1) rejects the payment using the normal double-spending prevention (not very useful for kidnapping/ransom cases, since Bob may kill the victim or whatever) 2) detects the double-spending but uses special-case software to tell Bob they're accepting the payment, and trace his account or trace the place he's depositing it from, or not actually credit it the money they're sending him a receipt for, or whatever. If Bob wants to prevent the bank from tracing his deposit back to him, he'll need an anonymous on-line connection; this would probably need to be some sort of packet laundry, which is easy enough to implement, or at least a fancy firewall. If Bob is a real Bad Guy (as opposed to Alice being the Bad Guy), Bob will probably set up some kind of temporary account at the bank to deposit the money in, followed rapidly by withdrawing the money and abandoning/closing the account. If Bob is a kidnapper, he probably kills the kid; if he's just an undocumented retailer, he may not ship the pharmaceuticals, or may start announcing that Alice is a probable narc. >[online clearing vs. double-spender detection] >I'm persuaded that the second approach, involving protocols for revealing >double spending, is much messier than the "he who gets there first" >protocol. The online clearing model largely emulates how real physical cash There are difficulties, with online clearing, though - with physi-cash, Bob can look at it and say "it looks good/bad" without actually possessing it; with online clearing, he can lie about "it was pre-spent", and there's no way to let him check the cash except by either giving it to him or using messy all-or-nothing-disclosure-of-secrets techniques (e.g. Alice and Bob flip a coin to decide whether Bob gets to spend a pre-committed digibuck or Alice gets to demonstrate that it's ok and spend it first) though an online system could reduce this problem substantially by recording the time that a given digicash was spent and reporting that time in double-spending rejections (a first-spending at approximately the same that Alice gives Bob the money and he deposits it is obviously suspicious; it doesn't actually identify which one of them cheated, though they'll both know (unless it was the bank cheating). A first-spending time substantially before that implicates Alice.) >Well, since Alice knows her own blinding factors, she will always be able >to say to the bank: "My cash will look like this. Watch for it." Unfortunately, it's probably a lot harder to design a blinding system that lets the payee blind the cash without allowing him to create forged bills (at least forged bills based on a hard-to-identify original bill.) >My hunch, just a hunch, is that Chaum has been concentrating on the >particular protocols which avoid online clearing and which avoid avoid the >payer/payee untraceability for pragmatic reasons. Pragmatic as in >"politically wise." maybe so... #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: Scientology/Wollersheim as test case for key disclosure
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:42 PM 9/9/95 -0400, Phill wrote: >One solution to this problem would be to modify PGP so that the session key for >the document was released rather than the passphrase for the public key. The >former would provide only read access, the latter would allow th scientologists >to forge Wollerstein's signature on other material. In addition many of the >documents may be subject to privillege. It wouldn't be hard, though I'm not sure it's much different from requiring the owner of the public key to decrypt the document in the first place. It does give you some verifiability (somebody else can take the session key and demonstrate that encrypting it with the recipient's public key does or does not produce the encrypted-key string in the document being verified.) If that's what you plan to use it for, you would also need to have the entire padded session key and not just the session key itself. Total amount of work to implement - another command-line option, a print statement, and maybe another command-line option and bit of code to allow decryption of a public-key-encrypted document using a command-line-supplied session key. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

RE: Mixmaster status
by Alan Olsen 17 Dec '03

17 Dec '03

>Let me be crystal clear. >1) I will not support any version of Mixmaster that is weakened. >2) All future clients will be able to generate the current message format. >3) All future servers will be able to read the current message format. >4) There will always be a free version of the client with source code. But will the commercial version of the server come with source code? >While I have not discussed it, I can not imagine that there would not also >be a free version of the server code (with source). Without remailers what >is the point of the client software? Will Mixmaster become the Netscape(tm) of remailers? And when is the IPO? ];> | Visualize whirled keys | alano(a)teleport.com | |"It's only half a keyserver. I had to split the | Disclaimer: | |other half with the government man." - Black Art | Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

1 0

Re: cryptography eliminates lawyers?
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Brian Davis wrote: <snip> >Last I checked, FDA, UL, or state bar association approval does not >*require* you to take, use, or hire the approved drug, toaster or lawyer. >Market forces are still at work, albeit in a filtered environment. The filter is weakest from UL, yet I trust its output the most. >Just a first cut. And even that can usually be gotten around. Getting around David KeSSler involves about $30 million and a *bunch* of lawyers. Skipping this first cut, even with far safer products (IMO) than "Proscar," can lead to an armed raid of your doctor's office. If state bars can usually be gotten around, why take three of them? JMR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Freedom isn't Freeh iQCVAwUBMFk2Jm1lp8bpvW01AQESMwP/abBCBbhGKOjVFFkjl4elOcTA3oD9WgEa e+AsmtuLSEstvSfZ6u3CxO5sfu0lka0erBsVyDjqWs97WlvQOD0qX+3O91hoURp4 pytfTSE+MtTlIQCIoxVBMgjOYplNLOOYmnomksypJFpOzyuofoYnIScfRLkAWvAB SFEqvrCtfP8= =cfgW -----END PGP SIGNATURE----- Regards, Jim Ray "When making public-policy decisions for the government, I think one should ask oneself which technologies would best strengthen the hand of a police state. Then, do not allow the government to deploy those technologies." -- Phillip Zimmermann, talking to himself. (Congress sure-as-hell wasn't paying attention!) ----------------------------------------------------------------------- PGP key Fingerprint 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 Key id. # E9BD6D35 James M. Ray <liberty(a)gate.net> ----------------------------------------------------------------------- Help Phil! email zldf(a)clark.net or see http://www.netresponse.com/zldf _______________________________________________________________________

1 0

Re: Linking = Showing = Transferring?
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Rich Salz <rsalz(a)osf.org> writes: > >Suppose we interpret Linking = Showing as > > > >For all web pages x and y, > >Showing(x) and Linkto(x,y) --> Showing(y) > > Then we would be fools. No more so than buying a book means you > have instant access to all resources mentioned as footnotes or in > the bibliography. > > Put more simply, *you have to click on Y* so they're not the same. Another even more subtle problem is inline images, can you say that a page with an inline image sourced from a foreign site must obey the foreign jurisdiction. I would assert this is so, because the web surfer's *browser* imports the relevant parts of the page from whatever locations (and jurisdictions) they are in, and displays them as one page. Take a look at: http://www.obscura.com/~shirt/ which is the www space Lance kindly donated for the UK munitions-T. The relevance to this discussion is that www.obscura.com is of course in the US, whilst the inline graphic is in the UK for ITAR reasons, the is of: #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2) ie the html looks like: <img src="http://www.dcs.ex.ac.uk/~aba/obscura/rsa.gif"> So that the image is *imported* by the *viewer*, and not supplied by www.obscura. This means that people outside the US can also view the page with out anyone breaking any laws, even though it appears to contain (allegedly) ITAR contravening material. Same would apply quite nicely to porn from the netherlands etc. [as an aside, any one got info on how you go about converting gifs to transparent gifs - I want the above to be transparent so that it still works on other than a black background in case other people use it on other backgrounds] Adam

1 0

Some informed comments on RSA's S/MIME
by Rich Salz 17 Dec '03

17 Dec '03

Date: Thu, 14 Sep 1995 08:39:49 -0700 (PDT) >From: Ned Freed <NED(a)innosoft.com> Subject: Re: Re[2]: MOSS conformance testing Cc: pem-dev(a)TIS.COM Message-id: <01HV9F2PHBSU8Y4Z8U(a)INNOSOFT.COM> > I just got wind of RSA's draft for Content-Type: application/x-pkcs7-mime. > Has there been any discussion on this - comparison to PEM etc.? If so > where's the list, URLs of archives....? Or did I just go "deaf" for a while > here on thist list? (The last could of months have been caught up in > changing companines...) S/MIME was developed privately by RSA in conjunction with a number of other companies. To the best of my knowledge all discussion has occurred on closed, private lists. As a potential customer of RSA I recently managed to get myself added to one of these lists (it may or may not be the only one where S/MIME is discussed) but I haven't had time to post anything there yet. I plan to post this message there in the next couple of days. I'm not saying this approach to protocol development is a good thing or a bad thing, but I do believe that it has led to the production of a specification that is seriously flawed, and that those flaws would have been detected and probably corrected had the discussion been more public. More on this below. > I browsed through the IETF drafts & personal contributions & search tool... > didn't find anything on RSA's "S/MIME". > I did get the PostScript file from RSA's pages & had a read.... > http://www.rsa.com/pub/S-MIME/ The specification, at least, is public. Given the amount of press surrounding this proposal and the strong liklihood of it being widely used I strongly recommend that everyone who is interested in email security obtain a copy of the specification and read it. However, the proposal is simple enough that it can be summarized in just two paragraphs. S/MIME is based on PKCS #7, which in turn is based on classic PEM. The significant difference between PKCS #7 and PEM is that it uses an ASN.1 encoding for the entire security object rather than the header/text encoding of RFC1421. In fact the specification states that mechanical conversion between RFC1421 formats and PKCS #7 should be possible as long as the proper set of algorithms are used. I think that mechanical conversion into and out of the PEM-derived subset of MOSS is also feasible but I haven't checked up on the specifics of this. S/MIME in turn is a simple encapsulation of PKCS #7 in MIME, consisting of an application subtype label and an encoding of the PKCS #7 object using standard MIME encodings. The inner secured content is then seen as another MIME object. This is almost identical to Jeff Schiller's earlier proposal for embedding PEM in MIME. There is only one significant twist -- in the case of signed but not encrypted data the specification calls for the use of multipart/alternative, with the first part being an unsigned copy of the signed data and the second part being the PKCS #7 object, including the signed data. Two obvious flaws in this approach should be obvious from this description. The first is simply one of excessive overhead -- sending signed material in such a way that it can be read on vanilla email systems as well as with an S/MIME system introduces something on the order of 133% overhead. The second flaw is more serious. The data that a user without S/MIME reads is not signed. This opens the door to attacks where the unsigned version is tampered with but the signed version is left alone. This turns into a really insidious problem when you consider how privacy services are likely to be deployed in some environments. One model I expect to be rather popular is that of having a remote signature verification service within a secure enclave. That is, most of the user agents that people use won't have the ability to validate a signature. Users will, however, have secure access to an agent that will validate the signature on a message for them. (The service may well be a different application on the same machine.) They simply submit the message to this service and it tells them whether or not the signature matches. The problem, of course, is that the material the user of the unextended agent reads isn't what's signed. And in general there is no way to correlate this material with the signed copy -- since it was exposed to the message transport layer without any special tagging to indicate its signed nature the transport may well have changed it so its no longer a byte-for-byte copy of the signed version (which is inherently protected against such munging). Comparing this approach with security multiparts is quite instructive. Security multiparts only introduces the overhead necessary to encode the single copy of the data -- at most 33% in the case of base64 -- plus of course the fixed overhead of the signature information. As such, it is far more efficient than S/MIME when it comes to signed but unencrypted material. Security multiparts can be processed in a single pass as well. I'm not sure this is true of S/MIME -- it depends on the specifics of the ASN.1 structure that's used. But by far the most important difference is that security multiparts do not suffer from this vulnerability when used in an environment with remote security servers. You can of couse avoid this problem by not including the extra copy of the signed material. The problem with this approach is that you won't be able to read such a message on anything short of an agent that knows how to take apart a PKCS #7 structure. I note in passing that there was absolutely no reason why security multiparts could not have been used in S/MIME instead of the chosen encapsulation. PKCS #7 explicitly provides a facility whereby the secured data is stored outside of the ASN.1 object. This then fits seamlessly into the security multiparts methodology. I do not propose to debate the relative merits of PKCS #7 versus MOSS. Modulo the MIME issues this is essentially the same as debating the merits of PEM versus MOSS, and I've had more of that than I care for. Besides, I think folks should use whatever security service they feel like using. I've maintained all along that my interest is primarily that of standardizing on a single embedding methodology for use with MIME. I'm very disappointed that S/MIME has seen fit to use what to my mind is a technically inferior embedding solution when compared to security multiparts, and I'd really like to try to get the S/MIME folks to switch to a security multiparts approach if its not too late for them to do so. I'm very interested in any and all comments on what I've written here. I intend to post them to the S/MIME list I'm now on. Ned

1 0

Re: Why ecash is traceable
by Pat Farrell 17 Dec '03

17 Dec '03

tcmay(a)got.net (Timothy C. May) writes: > Hal, a very nice summary! Yes, good job Hal. > Why not "online clearing" as the preferred model, then? Because you lose most (all?) anonymous abilities. (I think) > (There are more abstract ways of viewing this advantage. While mere > software is always duplicable, and cash numbers are of course duplicable, > one thing that is not duplicable is this: "the first agent to present a > valid number at this bank." There can be only one of these, and this > uniqueness is what keeps the currency from collapsing, what introduces > _conservation_ into the system.) > > Well, since Alice knows her own blinding factors, she will always be able > to say to the bank: "My cash will look like this. Watch for it." So when the money Alice gave to Bob gets deposited by TCMay, That it was Alice's is instantly known. This is not how physical cash works. There is a chain from TCMay through some number of steps to Bob. Even if you can't find it with this single case, you could use a zero-knowledge type proof to slowly uncover Bob's identity. I keep wanting to believe in ecash, but I'm not convinced it can exist. Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

3 2