December 2003 - cypherpunks-legacy

This is a test
by Robert A. Hayden 17 Dec '03

17 Dec '03

I apologize for this test. But, in the end, it will probably serve a good purpose :-) ____ Robert A. Hayden <=> hayden(a)vorlon.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> I do not necessarily speak for the \/ Finger for PGP Public Key <=> City of Mankato or anyone else, dammit -=-=-=-=-=-=-=- (GEEK CODE 2.1) GJ/CM d- H-- s-:++>s-:+ g+ p? au+ a- w++ v* C++(++++) UL++++$ P+>++ L++$ 3- E---- N+++ K+++ W M+ V-- -po+(---)>$ Y++ t+ 5+++ j R+++$ G- tv+ b+ D+ B--- e+>++(*) u** h* f r-->+++ !n y++**

1 0

Re: CreditCard info
by alano＠teleport.com 17 Dec '03

17 Dec '03

> > An interesting sideline - > I ran into an interesting situation at a local video rental place >yesterday. If you give them your credit card number they charge you .25 >less a tape to rent it(2.75 compared to 3.00) Your number goes into their >customer databse. > > I laughed, and said i'd rather pay the .25 a tape than take the chance >of some part-time HS kid getting ahold of my CC number. > > It's unbelieveable (to me anyway) that people would give this kind of >information out and trust that it can't be abused. It's bad enough that >we're asked to hand out our SS number for everything. > There are businesses that are just as clueless. I work for a mailing company that gets credit card orders from a telemarketing firm. All of the information that I would need to commit major credit card fraud flows across my computer every morning. (I actaully do the processing via computer to the bank. The bank program was written in Microsoft Basic by someone in California.) The company I work for wanted to print ALL of the credit card information on the packslips. This means that anyone along the production line could have taken that information and done with it what he/she will. The information is not stored in any sort of encrypted form on the computer. Anyone who has access to the system and the least amount of knowlege could get to it. Now you know why I do not have any credit cards. /========================================================================\ |"I would call him a Beastialic Sadomasochistic | alano(a)teleport.com | |Necrophile but that would be beating a dead | Disclaimer: | |horse." -- Teriyaki (What's up Tiger Lily?) | As if anyone cares! | \========================================================================/

1 0

Re: No more NSA supra-computer?
by tcmay＠localhost.netcom.com 17 Dec '03

17 Dec '03

>>Yesterday I was talking with a friend, and the subject of supercomputers >>came up. Naturally, I mentioned the NSA 7000 Y-MP equivalent and Gunter >>Ahrendt's list of supercomputers worldwide (finger >>gunter(a)yarrow.wt.uwa.edu.au) My friend sent me a note this morning saying >>that he couldn't find that machine on Gunter's list; sure enough, it's been >>removed. >> > >My guess, and this is only a guess, is that it disappeared for "security" >reasons. They have a habit of keeping the smallest bit of light from >emerging. For instance, no one knows the "Black" part of the budget. It's >classified. But you can take the total budget amount and subtract the >non-Black section and get the result. They make you do the math. I was intrigued by this disappearance, so I sent an e-mail message to Gunter Ahrendt. Through the joys of time zones, my message this evening was answered within minutes, from Australia. He told me the NSA machine remains, though it has been renamed, has been put under another site, and its performance rating has been recalculated based on a new metric. Gunter's latest report (in comp.sys.super) explains the new metric. Grepping for the name "SMPP," here's where I found it: 58) 16.46 - (APR-1994) [SRC] Supercomputing Research Center,Bowie,Maryland,US,root(a)super.org 1) Cray 3/4-128 [-4Q96] 11.46? 2) SRC Terasys ~ 5 3) SRC SMPP-4/2M [+4Q96] 503.33? This is also very intriguing. The machine formerly called the "NSA SMPP-2/2M" and expected to be located at NSA Central Security Service, is now to be located in nearby Bowie at the Supercomputing Research Center. I guess that means the SRC is doing more than just "academic computing"! --Tim May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

1 0

No Subject
by David Downey 17 Dec '03

17 Dec '03

unsubscribe cryptography-politics-pgp-l ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

iterated prisoner's dilemma
by John Douceur 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >From: Hal <hfinney(a)shell.portal.com> >Date: Monday, August 29, 1994 12:03PM >Another argument sometimes advanced in favor of trustworthy escrow >agents is the "iterated prisoner's dilemma". This refers to Axelrod's >simulations of computer program agents which repeatedly interacted in >a simple "prisoner's dilemma" game which captures much of the essence >of the trust relationship (see his book "The Evolution of Cooperation"). >His results generally have consistently shown that agents which are >never the first to "cheat" in a relationship do better than those >which try to take advantage of their counterparts. . . . >Axelrod's tournaments were predicated on the implicit >assumption of an indefinite number of interactions. (This is my >recollection; I'd be interested in whether experiments have been tried >with a known fixed number of interactions, and the agents knowing how >many more there were.) It had long been recognized (pre-Axelrod) that >the prisoner's dilemma might reach a stable cooperative solution with >multiple interactions, but that this becomes unstable if the parties >know that they are reaching the end of their interaction period. Axelrod's second tournament had a variable number of interactions, precisely to defeat penultimate-interaction attacks. He added this specifically because his first tournament had a fixed and known number of interactions, and several programs took advantage of it. However, even in the first tournament, the "nice" programs did better than the "mean" programs, and Tit-for-Tat was the winner. I suppose this doesn't prove much, insofar as a Tit-for-Tat-but- Screw-Em-on-the-Last-Round program would probably have come in first had it been entered. Even so, I expect that the marginal increase in score over Tit-for-Tat would have been vanishingly small for a large number of interactions. JD -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLmJSsEGHwsdH+oN9AQGIAAQAkT6GC1xOdmCh5Zp7LU17oKRH7WAqeYoK 6FypHPqfUK688uFUAUz61MhGaMkr9ZoCcnRdsmejOGq9zQ9sW6D3SnGvTtkgGyGD zNjle57RVxG8sqkaei8kKszCyVIxZfms2RkdrmQyC/GHwAo9i/5yOszdqFotWfVJ HRe05Pfrano= =zsiI -----END PGP SIGNATURE-----

1 0

Re: Announcing Bellcore's Trusted Software Integrity (Betsi) System
by brains＠male.org 17 Dec '03

17 Dec '03

>> - provide accountability by linking the author of a program >> to a real person whose identity is verified off-line > >This is unnecessary, and I would claim undesirable. A unique anonymous > ID is just as good as a "real" one -- since you're relying upon PGP > anyway, the mapping from signature to a known identity is one-to-one. > >The only reason I can see to require this "real human" mapping is > to try to prosecute people for bugs in their code or some contamination > that seeps into their release. > >That's not an aspect of the world I want to live in. Or to warn potential virus "authors" that *their* anonymity is no longer assured - not a bad thing. Not enough to justify the rest of it, IMHO, but certainly not Evil Incarnate (not to be flinging misinterpretations or aspersions :-) Dave Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)metronet.com for PGP/RIPEM public keys and fingerprints. Unencrypted Email may be ignored without notice to sender. PGP preferred. Remember: It is not enough to _obey_ Big Brother; you must also learn to *love* Big Brother.

4 5

MIT PGP - PGP UI - VIACRYPT mime
by Gary Jeffers 17 Dec '03

17 Dec '03

Cypherpunks, Question concerning MIT PGP 6.2 & PGP 6.2 ui. If it is known that the PGP that encrypted a msg is one of these two versions, then can it be determined which of these two versions did the encrypting? Also, can it be determined that it was not VIACRYPT that did it. Note: If it can be determined that PGP 6.2 ui did it, then it might be a neat trick to change the ui version to mimic either of the other two at user command. Yours Truly, Gary Jeffers

2 1

Re: Statistics on remail message sizes
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

>In article <9408291623.AA29767(a)ah.com>, Eric Hughes <hughes(a)ah.com> wrote: >>Based on Hal's numbers, I would suggest a reasonable quantization for >>message sizes be a short set of geometrically increasing values, >>namely, 1K, 4K, 16K, 64K. In retrospect, this seems like the obvious >>quantization, and not arithmetic progressions. Live and learn. > >A brief suggestion: Code the progression, not the four values. As > time goes on (and lossy sendmails disappear), people are sending larger > and larger messages; it's easily conceivable that people could be > swapping multiMB files at some point in the not too distant future > (indeed, I do occasionally send out files that are 4-5 MB large, > uuencoded binaries and tar files). > >No point in limiting future behavior due to current usage. Except that coding only the progression and not the actual values lessens the usefulness of quantizing. We may have one group of remailers/users which uses the Hughes sequence: 1, 4, 16, 64, and another group that uses another sequence: 3, 9, 27, etc. I'm not saying we'll ever get everybody to agree, but there are times when it's better to converge on solid, actual numbers and not on the more-elegant abstract progressions. But maybe I'm misunderstanding the point here. --Tim May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

2 1

Re: Announcing Bellcore's Trusted Software Integrity (Betsi) System
by David K. Merriman 17 Dec '03

17 Dec '03

> >Certainly not enough to justify the rest: Can you name one example of an > author of a package including some virus? Not someone putting one > post-production (individual signing will prevent that), but the original > author? > >It's a straw man. Well, there was that CD-ROM program of a couple months ago that professed to be from one of the drive manufacturers (but wasn't) containing some kind of Binary Nasty (tm). The mfr's finally had to post (far and wide) the fact that it was *not* their program. The program was posted using a false ID, etc. Don't know if the Bellcore system would prevent that, but it is *one* example, anyway. I'm not arguing that the Bellcore system is the answer to Life, the Universe, and Everything; just that there are some small pieces to it that have *some* perceivable merit to them. Personally, I wouldn't want anything to do with it - as you note, the costs and hazards _far_ outweigh any benefits, and there are easier and more secure ways of accomplishing the same things. Dave Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)metronet.com for PGP/RIPEM public keys and fingerprints. Unencrypted Email may be ignored without notice to sender. PGP preferred. Remember: It is not enough to _obey_ Big Brother; you must also learn to *love* Big Brother.

2 1

e$: e-cash underwriting
by John Young 17 Dec '03

17 Dec '03

Responding to msg by hughes(a)ah.com (Eric Hughes) on Sun, 28 Aug 10:9 PM >Turn fraud attempts from a security cost to a profit >center. Brilliant statement, Eric. My mouth fell open. This is the best synopsis I've seen for the conversion of our national security capitalism into democratic capitalism. It makes all the pleasurable, if demanding, digicash correspondence I've read here fall into place. John

1 0