Re: SIGINT planes vs. radioisotope mapping
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
Re: Maybe It's Snake Oil All the Way Down
At 04:24 PM 6/6/2003 -0700, James A. Donald wrote: >I don't think so. ??? public key registered in place of shared-secret? NACHA debit trials using digitally signed transactions did it with both software keys as well as hardware tokens. http://internetcouncil.nacha.org/News/news.html in the above scroll down to July 23, 2001 ... has pointer to detailed report? X9.59 straight forward establishes it as standard with some activity moving on to ISO http://www.garlic.com/~lynn/index.html#x959 pk-init draft for kerberos specifies that public key can be registered in place of shared secret. following has demo of it with radius with public keys registered in place of shared-secret. http://www.asuretee.com/ the radius implementation has been done be a number of people. in all of these cases, there is change in the business process and/or business relationship doesn't introduce totally unrelated parties to the business activities. the is digital signing on the senders side (actually a subset of existing PKI technology) and digital signature verification on the receivers side (again a subset of existing PKI technology). To the extent that there is impact on existing business process ... it is like in the case of introducing x9.59 authentication for credit transactions that have relatively little authentication currently ... and as a result would eliminate major portion of the existing credit card transaction related fraud. The big issue isn't the availability of the technology ... although there is a slight nit in the asuretee case being FIPS186-2, ecdsa and having support in CAPI and related infrastructures. It not working (easily) is like when my wife and I were doing the original payment gateway with this little client/server startup in menlo park (later moved to mountain view and have since been bought by AOL) and people saying that SSL didn't exist ... misc ref from the past http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Micropayments and the incentive program at e-gold
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 mg4854 (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 [EMAIL PROTECTED] (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
Re: Maybe It's Snake Oil All the Way Down
-- On 4 Jun 2003 at 20:58, Anne & Lynn Wheeler wrote: > it is relatively trivial to demonstrate that public keys can > be registered in every business process that currently > registers shared- secrets (pins, passwords, radius, kerberos, > etc, etc) I don't think so. 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. 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. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG q1a1Whb1YeRws7qoDm6h15qfDstFHciUyP2I4fte 42lCFXf0IqXfh5Mz2mFtznxv6N40EuqpKvQJhLBgS
Re: Maybe It's Snake Oil All the Way Down
-- 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
Re: Maybe It's Snake Oil All the Way Down
Derik asks the pertinant question: > The question is: how do we convince M$ and Netscape to include something > else in their software? If it's not supported in IE, then it wont be > available to the vast majority of users out there. My view, again, IMHO: ignore Microsoft. Concentrate on the open source solutions: KDE, Mozilla, Apache. These groups will always lead in security, because they are not twisted by institutional conflicts; they can examine historical security model from the point of view of interested professionals, rather than commercial actors trying to preserve this or that revenue stream. The trick is to understand whether HTTPS as it currently is can be improved. If it can, then those above guys can do it. Once the improvements are shown to work, Microsoft will follow along. They are a follower company, not an innovator, and they need to see it work in practice before doing anything. As Derik suggests, the vast majority of users will have to wait. Along those lines, there's one piece of excellent news: Eric Rescorla wrote: > One can simply cache the certificate, exactly as > one does with SSH. In fact, Mozilla at least does exactly > this if you tell it to. That's fantastic! I never knew that. How does one set that option on Mozilla? (I'm using 5.0 / 1.3.1.) -- iang
Re: Maybe It's Snake Oil All the Way Down
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.
Re: [dgc.chat] Micropayments and the incentive program at e-gold
Dear James, Jay Wherley is the head tech guy at e-gold.com so wwe can rely on his views below. The incentive payments and the payment receive fee are not counted as "spends" for the statistics on the e-gold.com/stats.html page. One correspondent suggested to me that there may be one or more "spread spectrum" accounts. The way such an account would work is that a 'bot would create 10,000 e-gold accounts. Other software for bulk payments would be used to spend one ten thousandth of each payment from each of these accounts to the intended recipient. Why do so? Doing so would diversify the risk of any one account being closed, make the process of tracking the account history data much harder for prosecutors and others with court orders, and generally enhance privacy to some extent. Of course, this idea was indicated as a chimera, something that has been discussed but no one knows if anyone has ever implemented it. Meanwhile, I suggest a few games of poker at http://8715605.thegoldcasino.com I hope this message has been helpful. Jay's detailed response below. Regards, Jim http://www.ezez.com/ From: "Jay W." <[EMAIL PROTECTED]> Date: Sat Jun 7, 2003 06:19:33 US/Central To: [EMAIL PROTECTED] Subject: Re: [dgc.chat] Micropayments and the incentive program at e-gold I realize you have explained this at least 10 times, every time it comes up every few months, but I alwasy forget and like hearing it over and over :-) -BEGIN PGP SIGNED MESSAGE- then hopefully this post is a paroxysm of joy for you JP! ;) : the deduction of the e-gold spend fee is not included in velocity numbers. the distribution of any incentive payments per http://www.e-gold.com/unsecure/incentive.htm is not included in velocity numbers. the *only* thing counting as a "spend" in "e-metal spends" is an e-metal spend (aka payment) from one account to another initiated by a user doing one of: a) manually signing into his account and performing a "Spend" b) checking out at a merchant using e-gold SCI c) using phone access to make a spend d) using a program and the e-gold Automation Interface to make a spend those velocity numbers are totals for the amounts users are spending to other users. they do not include any other thing like fees, storage charges, or incentive payments. http://stats.e-gold.com possibly the most informative, accurate and timely economic statistics on earth - possibly the universe!! ;) -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQEVAwUBPuHKNMyM0YPqVE7FAQHEyQf+Pqv7O8gvEhIQFjooHgx3MR5yHppGSqna 3ewMf7WBlNVZuSfTecUiu/nkzdaiwjnB4ugtbXxIYS58Wn2ZdcQnu+9VGzjjw8K2 mwcQTUMauWjUMKLr8v+NiDPh6Mp8S1IJxHgsVqg1K5QgoAtrheSCUSJuejvS3BnQ Ph1SosCahUoZ7xrolAlfFcwq/RUm769L4ohJu8CUnVeM/9ZOoEl/uFX8E/ogS52G b9iJQGmPv0odjEsPkmIH20IbrweAL16pxkT7eQkJGZF+NP5GRuRChg6qOFKKYWKW ThegIPl6arOAaliy02j/PcJl93EgNmZ/212KyQ3GqmZu/tVl0UClow== =9U0c -END PGP SIGNATURE- subscribe: send blank email to [EMAIL PROTECTED] unsubscribe: send blank email to [EMAIL PROTECTED] digest: send an email to [EMAIL PROTECTED] with "set [EMAIL PROTECTED] digest=on" in the message body
Re: Maybe It's Snake Oil All the Way Down
Anonymous Sender wrote: > James A. Donald writes: > 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, Nope. 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. > 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. Not so much that as have a much bigger security issue. Maintaining keys securely would then become a task for the client, and while keeping a written password secret is something most people can handle the concept of, keeping a block of computer data safe from random trojans while exporting it to be transported between machines is much, much harder. Of course, you *could* generate the key entirely locally on the server, protecting it with a HTTPS download, and protect it with the enduser's password (not sure how secure the PKCS password is - if it isn't, then use some self-decoding-exe like the 7z one) but that still wouldn't force the end user to do more than hit "import" and have it stored insecurely on their client machine. > 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. 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.
Re: Maybe It's Snake Oil All the Way Down
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 [EMAIL PROTECTED]
Re: Maybe It's Snake Oil All the Way Down
-- James A. Donald: > > Certificate caching is not the problem that needs solving. > > The problem is all this spam attempting to fool people into > > logging in to fake BofA websites and fake e-gold websites, > > to steal their passwords or credit card numbers On 6 Jun 2003 at 15:04, Tim Dierks wrote: > I don't think this problem is easier to solve (or at least I > sure don't know how to solve it). It is a hard problem with many well known solutions, none of which have to my knowledge been implemented in HTTPS. For example one can use SPEKE, in which case setting up the account involves sharing (or issuing) a password, but logging in to the account does not require one to reveal the password to the site where one is logging in. In this case the fake website would gain no useful information by luring the user to login to it. The most HTTPS like solution would be to generate a keyfile containing a self signed private key on one's computer, and whenever one hit the website, it would do the HTTPS handshake to log you in to that website's account for the public key corresponding to your private key, however HTTPS does not seem to directly support this model. In this case the bogus web site could log you in, but this would not leak any information that would enable the operators of the bogus web site to login to the real web site. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /JhekrYM+sQCMQKXhiWzhB3RnOv6PZROgxYwprXj 4LHJfuGlcn7fO4tcfo20/t0cdEy/HyK++XiBVvMFy
Re: Maybe It's Snake Oil All the Way Down
On Fri, Jun 06, 2003 at 06:08:34PM -0400, Ian Grigg wrote: > Derik asks the pertinant question: > > The question is: how do we convince M$ and Netscape to include something > > else in their software? If it's not supported in IE, then it wont be > > available to the vast majority of users out there. > > My view, again, IMHO: ignore Microsoft. Concentrate > on the open source solutions: KDE, Mozilla, Apache. Mozilla already has a pretty neat interface to gnupg, called Enigmail. See http://enigmail.mozdev.org/ -- Harmon Seaver CyberShamanix http://www.cybershamanix.com
Re: Maybe It's Snake Oil All the Way Down
James A. Donald wrote: > Could you point me somewhere that illustates server issued > certs, certification with zero administrator overhead and small > end user overhead? Been a while since I played with it, but IIRC OpenCA (www.openca.org) is a full implimentation of a CA, in perl cgi, with no admin intervention required. Obviously, that involves browser-based key generation. If you want server-based key generation, then take a look at http://symlabs.com/Net_SSLeay/smime.html If you are iis/asp rather than perl, then there are activex components that will give you access to x509 certificates - EBCrypt is probably the easiest, but there is a activex wrapper for cryptlib too, iirc.
PGP8 paranoia ?
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 ?
Re: Maybe It's Snake Oil All the Way Down
Derek Atkins <[EMAIL PROTECTED]> 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.
The perils of anonymous, not-so-digital cash
Two million in bearer bonds stolen along with the safe that held them: http://www.timesunion.com/AspStories/story.asp?storyID=140587&category=FRONTPG&BCCode=HOME&newsdate=6/6/2003
RE: SIGINT planes vs. radioisotope mapping
On Wed, 4 Jun 2003, Trei, Peter wrote: > It appears that they can't tell the medical isotopes from others They have no chance to distinguish isotope type with just a plain Geiger. For an identification, they would need a gamma spectrometer, which is a toy that AFAIK is not yet portable and cheap enough for mass deployment.
Re: SIGINT planes vs. radioisotope mapping
On Friday, June 6, 2003, at 08:26 AM, Thomas Shaddack wrote: On Wed, 4 Jun 2003, Trei, Peter wrote: It appears that they can't tell the medical isotopes from others They have no chance to distinguish isotope type with just a plain Geiger. For an identification, they would need a gamma spectrometer, which is a toy that AFAIK is not yet portable and cheap enough for mass deployment. 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. As for portability, the one I used in my lab in 1979-82 was not terribly heavy. The heaviest part was the LN dewar, which was large and floor-standing. A large dewar is certainly not needed. The rest of the assembly, even 20 years ago, was mostly portable: the germanium detector head, some preamps and pulse-height analyzers, and a multichannel analyzer. Most of this stuff is now done on laptops, the MCA and analysis software part. Without researching this on the Net, I would thus conjecture the entire gamma ray spectrometer could fit in a small carry-on case, using a small dewar. Certainly for the cost of operating a light plane, such a spectrometer would be a minor cost by comparison. 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. I expect most of the N.E.S.T. detectors are also gamma ray spectrometers, probably now so portable they fit unobtrusively into briefcases for use in crowded areas. As we discussed a few months ago (and I think I discussed this in _particular_ with Thomas!), the S/N advantages of using a spectrometer are enormous. Thousand-to-one improvements in general S/N are easily achievable. Even more if the MCA software is looking for pairs or triples or n-tuples of gamma peaks and inferring likely radioisotopes. (I used this approach in 1981 to solve a major problem in IBM computers which were using Intel chips...and I don't mean the alpha particle soft error problem. This was a different problem, involving a beta source trapped in some of the packages. For this I used a pair of large sodium iodide crystals (which my well-equipped lab just happened to have in a storage cabinet, fortunately for us) and looked for a specific decay mode that resulted in a pair of gammas sent out in opposite directions. By using coincidence logic over microsecond intervals, enormous improvements in S/N could be achieved. Basically, background radiation vanished and only the specific beta decay mode we were looking for appeared.) --Tim May --Tim May "Extremism in the pursuit of liberty is no vice."--Barry Goldwater
