June 2003 - cypherpunks-legacy

Re: Maybe It's Snake Oil All the Way Down
by Anonymous Sender 07 Jun '03

07 Jun '03

James A. Donald writes: > Suppose the e-gold, to prevent this sea of spam trying to get > people to login to fake e-gold sites, wanted people to use > public keys instead of shared secrets, making your secret key > the instrument that controls the account instead of your shared > password. > > They could not do this using the standard IE webbrowser. They > would have to get users to download a custom client, or at > least, like hushmail, a custom control inside IE. Why do you say that? You were already given pointers to how they could configure their web servers to use certificate based client authentication. These techniques work with standard browsers. I have used Netscape to access corporate-internal sites which required me to have a client certificate. > HTTPS assumes that the certificate shall be blessed by the > administrator out of band, and has no mechanism for using a > private key to establish that a user is simply the same user as > last time. HTTPS is just HTTP over SSL/TLS. It says nothing about the trust model for the certificates; it merely specifies how each side can deliver its cert(s) to the other side. Deciding which ones to trust is out of scope for TLS or HTTPS. E-Gold could set things up to allow its customers to authenticate with certs issued by Verisign, or with considerably more work it could even issue certs itself that could be used for customer authentication. Why doesn't it do so? Well, it's a lot of work, and it would have some disadvantages - for one thing, customers would have difficulty accessing their accounts from multiple sites, like at home and at work. Further, it would require customers to use some features of their browser that most of them have never seen, which is going to be difficult and error-prone for most users.

3 4

Re: Maybe It's Snake Oil All the Way Down
by t.c.jones＠att.net 07 Jun '03

07 Jun '03

my site has one. ca0.net ..tom > -- > On 7 Jun 2003 at 19:05, Dave Howe wrote: > > issuing certs to someone is trivial from both a server and a > > user endpoint - the user just gets a "click here to request > > your key" and hits ok on a few dialog boxes; the server > > simply hosts some pretty off-the-shelf cgi. > >[...] > > its surprisingly reliable and easy - particuarly if your end > > users are just using the MS keystore, which requires them to > > do no more than double-click the pkcs file and hit "next" a > > few times. > > This sounds more like what I was looking for. > > Probably someone has already pointed out the url to this, but > if they did, I when I looked at it I was snowed under by > verisign oriented shit, which assumes a large budget and ample > administrator time for face to face contact with certified > people, a very small number of clients, some hours of work by > each client, a manual, user training, etc, and failed to grasp > it. > > Could you point me somewhere that illustates server issued > certs, certification with zero administrator overhead and small > end user overhead? > > Also, I have many times heard that public key operations were > surprisingly easy, and have been key administrator for several > companies, and have unfailingly found that I was the only > person capable of doing these operations at that company. > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > v6gZFuZoUgyGH55ME+JoilJSfw5LrufrbWWB454U > 4FhiB65yyXwp1RgeJrLADfEYBoqz0YAch8fJ0Fisp > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

Re: Maybe It's Snake Oil All the Way Down
by t.c.jones＠att.net 07 Jun '03

07 Jun '03

my site has one. ca0.net ..tom > -- > On 7 Jun 2003 at 19:05, Dave Howe wrote: > > issuing certs to someone is trivial from both a server and a > > user endpoint - the user just gets a "click here to request > > your key" and hits ok on a few dialog boxes; the server > > simply hosts some pretty off-the-shelf cgi. > >[...] > > its surprisingly reliable and easy - particuarly if your end > > users are just using the MS keystore, which requires them to > > do no more than double-click the pkcs file and hit "next" a > > few times. > > This sounds more like what I was looking for. > > Probably someone has already pointed out the url to this, but > if they did, I when I looked at it I was snowed under by > verisign oriented shit, which assumes a large budget and ample > administrator time for face to face contact with certified > people, a very small number of clients, some hours of work by > each client, a manual, user training, etc, and failed to grasp > it. > > Could you point me somewhere that illustates server issued > certs, certification with zero administrator overhead and small > end user overhead? > > Also, I have many times heard that public key operations were > surprisingly easy, and have been key administrator for several > companies, and have unfailingly found that I was the only > person capable of doing these operations at that company. > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > v6gZFuZoUgyGH55ME+JoilJSfw5LrufrbWWB454U > 4FhiB65yyXwp1RgeJrLADfEYBoqz0YAch8fJ0Fisp > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

PGP8 paranoia ?
by Anonymous 07 Jun '03

07 Jun '03

PGP 8 on XP declares all public (encrypting) keys created by 2.6.2 in 1998 or earlier to have "revoked user ID" and will not encrypt with them. 1999 keys work. A bug or strong keys ?

1 0

Micropayments and the incentive program at e-gold
by Jim Davidson 07 Jun '03

07 Jun '03

Dear Friends, James A. Donald points out that tens of thousands of micropayments are being made on the e-gold system every day. If we assert that less than a tenth of a gram of gold is a micropayment, then the web page http://www.e-gold.com/stats.html gives us some information. Spend size quantity value involved 0 mg - 1 mg 6959 (Total: 5.60 g) 1 mg - 10 mg 4854 (Total: 23.73 g) 10 mg - 100 mg 21825 (Total: 1.04 kg) A question arises, where do these events come from? Mr. Donald offers the thought that the spends involve the e-gold incentive program, but thinks some other activities such as per-click micropayments for banner ads might be involved. He writes, "Some proportion of these payments must be e-gold's own referral scheme." JP May offers the thought that the HYIP or "neoteric gaming" or, in my view, Ponzi scheme activity may be the major factor. Let's talk a bit about those events. Every time a spend takes place at e-gold.com, there are several activities which report through. First, an account holder authorizes a spend of metal (we'll stick with gold in this example) from his account to another account. Second, e-gold.com records a "payment receive fee" against the account of the person receiving the payment in the amount of 1% of the amount spent, capped at 50 cents. Third, e-gold.com captures half of this receive fee and divides the other half between two other accounts: the account which sponsored the spender and the account which sponsored the receiver. However, I don't believe that payment receive fees, spender-sponsor incentive fees, or receiver-sponsor incentive fees can be involved in *any* of these micropayments. Why not? If that were true, then every user initiated spend event would generate two or three automatic spend events on the e-gold system. A user-initiated spend would generate two auto-spends in the form of incentive fees to the sponsors of the spender and the receiver. It would generate those two plus a payment receive fee spend to the e-gold account. However, that would only represent the situation if the number of e-gold spends were always evenly divisible by three or four. Since the number of spends I see right now is 72470, and that number isn't evenly divisible by three nor by four, I think the incentive program cannot be involved in the "spends" figure. Help me out here, Jay Wherley or Jim Ray, if you would, since you guys at e-gold know the whole story. I think "spends" is user-initiated events, and that *none* of the incentive payments are counted as spends. That makes sense, since if the incentive payments were "spends" on the e-gold system, they would incur payment receive fees, and generate further incentive fees, in a rather recursive fashion - an infinite loop. What's more, they would show up in "payments received" in the account history, whereas they show up only in the "incentive fees" history. And, the number of spends, if incentive fees are counted, would have to be invariably a number evenly divisible by three, which is not the case in the instance cited here. So, it is just a total non-starter. The e-gold incentive program is not a part of the "spends" figure on the stats.html page at e-gold.com. Next we have to ask whether micropayments arise as a part of the Ponzi activities. That may be true, since we can suppose that Ponzi operators would want to provide incentive payments to these jerks who violate the e-gold user agreement and keep sending spam around. If there were not incentive fees paid to spammers, there would be no reason for the spammers to spam, QED. Thus, I suppose that if a Ponzi scheme takes in, say, $25, it pays out to the referrer some fee like $1 or twenty-five cents. I'd have to be a lot more interested in Ponzis to do the research on this matter. Based on the fact that spams which promote Ponzis are sent out, even though the account holder risks losing his account if the spam is reported to abuse(a)e-gold.com (see the account user agreement), then there must be some sort of incentive payment involved. As the spams are a form of advertising, and as there are probably opt-in lists for Ponzis and web sites describing various Ponzis, I do agree with Mr. Donald that "these are mostly ... payments for ads" though I suspect they are on a commission-only basis rather than on a per-click-through basis in most instances. Finally, we have the question of "anonymity." Mr. Donald says, "These are non anonymous, in that e-gold can link payer to payee, but anonymous in that it laborious to link e-gold account numbers to true names." I agree with the first half of this comma splice sentence. These payments are not anonymous. The payer knows whose account is being paid, and the payee knows where the payment came from. Since the e-gold.com system records an account history, and since those records are kept in one of the most litigious jurisdictions on Earth (the USA), any prosecutor or defense attorney or other party equipped with a court order can get account histories. There is no privacy to the system, certainly not in comparison to a wholly offshore-hosted system like GoldMoney.com or 1MDC. However, there is the e-gold.com registration process, which allows anyone with a working e-mail address to get set up with an e-gold account. Thus, accounts may be pseudonymous, or opened with a pseudonym. They might even be opened with fake IDs or the like, depending on what sort of due diligence gets imposed by e-gold.com. Nevertheless, pseudonyms can be penetrated. Not easily, as Mr. Donald points out, but with some effort, I think. That's especially true where some exchange provider converts one of the e-gold account holder's gold to some other form of funds. The payment to the exchanger is in the e-gold account history. Most exchangers have web sites where there locations can be found, and all can be located by anyone offering to buy gold from an exchanger because some coordinates for a wire or a money order are going to be forthcoming. Then it is only a matter of a court order to get that exchanger's record of where the payment was sent. Even if that is only an intermediary account, further record searches can be undertaken to track the pseudonym back to some individual. Of course, if the account holder uses an exchanger in a different jurisdiction, or runs several accounts in series so that there is an e-gold > exchanger > bank > e-gold > exchanger > bank series before the recipient gets his funds, the problem can be made more difficult, especially if the exchangers and banks in the series are in different countries. Finally, I suspect that a large percentage, perhaps 20% of all spends involve an exchange provider. Given that the total inventory of e-gold turns over in less than a week, I think a lot of account holders are replenishing their accounts with gold from exchangers. Some exchangers may be paying incentive fees, too. Regards, Jim http://www.ezez.com/

1 1

Re: Maybe It's Snake Oil All the Way Down
by pgut001＠cs.auckland.ac.nz 07 Jun '03

07 Jun '03

Derek Atkins <derek(a)ihtfp.com> writes: >Actually, the ASN.1 part is a major factor in the X.509 interoperability >problems. Different cert vendors include different extensions, or different >encodings. They put different information into different parts of the >certificate (or indeed the same information into different parts). Does the >FQDN for a server cert belong in the DN or some extension? What about the >email address for a user cert? That doesn't really have anything to do with ASN.1 though. You can make just as big a mess with XML (actually even bigger, in my experience), or EDIFACT, or whatever. The problem isn't the bit-bagging format, it's that it's accumulated such a mass of cruft that no two people can agree on what to put in there. Whether the resulting mess is wrapped in ASN.1 or XML or EDIFACT or plastic pooper scooper bags doesn't really make any difference. Peter.

1 0

Re: Maybe It's Snake Oil All the Way Down
by pgut001＠cs.auckland.ac.nz 06 Jun '03

06 Jun '03

Ian Grigg <iang(a)systemics.com> writes: >It's also very much oriented to x.509 and similar certificate/PKI models, >which means it is difficult to use in web of trust (I know this because we >started on the path of adding web of trust and text signing features to x.509 >before going back to OpenPGP), financial and nymous applications whereby >trust is bootstrapped a different way. That's a red herring. It happens to use X.509 as its preferred bit-bagging format for public keys, but that's about it. People use self-signed certs, certs from unknown CAs [0], etc etc, and you don't need certs at all if you don't need them, <blatant self-promotion>I've just done an RFC draft that uses shared secret keys for mutual authentication of client and server, with no need for certificates of any kind</blatant self-promotion>, so the use of certs, and in particular a hierarchical PKI, is merely an optional extra. It's no more required in SSL than it is in SSHv2. >Has anyone read Ferguson and Schneier's _Practical Cryptography_ ? Does it >address this issue of how an outsider decides how to "make or buy"? I just >read the reviews on Amazon, they are ... entertaining! They spend a nontrivial portion of the book reinventing SSL/SSHv2. I guess they lean towards the roll-your-own side of the argument :-). I'm firmly in the opposite camp (see "Lessons Learned in Implementing and Deploying Crypto Software", links off my home page at http://www.cs.auckland.ac.nz/~pgut001/) I think that providing an abstract description of a fairly complex security protocol *in a book targeted at security novices* and then hoping that they manage to implement it correctly is asking for trouble. OTOH it's fun going through the thought processes involved in designing the protocol. I just wish they'd applied the process to SSL or SSHv2 instead, so that at the end of it they could tell the reader to go out and grab an implementation that someone else has got right for them. Peter. [0] The vendor of one widely-used MTA once told me that 90% of the certs they saw used in STARTTLS applications were non-big name CA-issued ones (self- signed, etc etc).

7 17

Re: Maybe It's Snake Oil All the Way Down
by pgut001＠cs.auckland.ac.nz 06 Jun '03

06 Jun '03

"James A. Donald" <jamesd(a)echeque.com> 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. To save having to type in a long explanation, I'll lift a representative paragraph from a (not-yet-published, don't ask :-) paper on PKI usability: There is considerable evidence from mailing lists, Usenet newsgroups and web forums, and directly from the users themselves, that acquiring a certificate is the single biggest hurdle faced by users [1]. For example various user comments indicate that it takes a skilled technical user between 30 minutes and 4 hours work to obtain a certificate from a public CA that performs little to no verification, depending on the CA and the procedure being followed. Obtaining one from non-public CAs that carry out various levels of verification before issuing the certificate can take as long as a month. A representative non-technical user who tried to obtain an (unverified) certificate from a public CA took well over an hour for the process, which involved [...] eventually the user gave up. and that doesn't even get into the mess of managing private keys, handling revocation, etc etc etc ad nauseum: The problems that this creates are demonstrated by what happens when technically skilled users are required to work with certificates. The OpenSSL toolkit [2][3] includes a Perl script CA.pl that allows users to quickly generate so-called clown suit certificates (ones that 'have all the validity of a clown suit' when used for identification purposes [4]), which is widely-used in practice. The cryptlib toolkit [5][6] contains a similar feature in the form of Xyzzy certificates (added with some resistance and only after the author grew tired of endless requests for it), ones with dummy X.500 names, an effectively infinite lifetime, and no restrictions on usage. Most commercial toolkits include similar capabilities, usually disguised as 'test certificates' for development purposes only, which end up being deployed in live environments because it.s too difficult to do it the way X.509 says it should be done. Certificates used with mailers that support the STARTTLS option consist of ones that are 'self-signed, signed-by the default Snake Oil CA, signed by an unknown test CA, expired, or have the wrong DN' [7]. The producer of one widely-used Windows MUA reports that in their experience 90% of the STARTTLS-enabled servers that they encounter use self-signed certificates [8]. This reduces the overall security of the system to that of unauthenticated Diffie-Hellman key exchange, circa 1976. In all of these cases, the entire purpose of certificates has been completely short-circuited by users because it.s just too difficult to do the job properly. The problematic nature of X.509 is echoed in publications both technical and non-technical, with conference papers and product descriptions making a feature of the fact that their design or product works without requiring a PKI. For example, one recent review of email security gateways made a requirement for consideration in the review that the product 'have no reliance on PKI' [9]. As an extreme example of this, the inaugural PKI Research Workshop, attended by expert PKI users, required that submitters authenticate themselves with plaintext passwords because of the lack of a PKI to handle the task [10][11]. >As a result we each have a large number of shared secret passwords, whereby >we each log into a large number of webservers. Was this what the people who >created this protocol intended? The assumption of the protocol's creators was that someone would figure out how to make X.509 PKI work by the time SSL took off, and everyone would have their own certificates and whatnot. At least they got *most* of the design right :-). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

9 9

Re: SIGINT planes vs. radioisotope mapping
by Major Variola (ret) 06 Jun '03

06 Jun '03

t 10:23 AM 6/6/03 -0700, Tim May wrote: >I certainly never implied in any way that a simple G-M tube would be >useful for this. Implicit in my radioistope mapping comment was that a >gamma ray spectrometer would be used. > >And note that this is just what can be easily bought on the open >market...N.E.S.T. (Nuclear Emergency Search Team) and similar LEO >people almost certainly have more miniaturized detector setups. Indeed, there is a group of GeigerCounterEnthusiasts on Yahoo whose members have/make this kind of thing. You use scintillation plastic & photomultiplier tubes; you can get these on eBay. Sometimes they mount their detectors in cars and find that some sections of roads are hotter than background, or a hot railroad car. >For this I used a pair of large sodium >iodide crystals which also show up on eBay >mode that resulted in a pair of gammas sent out in opposite directions. Also the principle behind PET scans. Mr. positron meets Ms. electron, and bang, two little Gammas carry the momentum away... GM tubes use avalanche to amplify; the scintillators, NaI, semiconductor junctions measure analogue energy, so you get an energy spectrum. Add a few comparators and a logic gate and you get a channel. ... Pierre Curie didn't die from radiation poisoning, he was hit by a horse drawn cart

1 0

Re: Maybe It's Snake Oil All the Way Down
by pgut001＠cs.auckland.ac.nz 06 Jun '03

06 Jun '03

Bodo Moeller <moeller(a)cdc.informatik.tu-darmstadt.de> writes: >Using an explicit state machine helps to get code suitable for multiplexing >within a single thread various connections using non-blocking I/O. Is there some specific advantage here, or is it an academic exercise? Some quirk of supporting certain types of hardware like nCipher boxes that do async crypto/scatter-gather? I have a vague idea from discussions with some OpenSSL-engine developers that they had some requirement for supporting async hardware in non-threaded environments, but from hearing the complaints about how hard this ended up being I had the impression that this was a major rewrite rather than something the state-machine implementation had been specifically designed for (sorry, I don't have that much technical info, the discussions tended to devolve into griping sessions about how hard async crypto hardware was to work with, not helped by comments like "That's because you're taking the path of most resistance, just use threads" :-). I also don't know if that explains why, years before this was an issue, everyone was already treating SSL as a state machine problem. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

3 2