January 2001 - cypherpunks-legacy

cash by fax info
by cashbyfax22222＠aol.com 16 Jan '01

16 Jan '01

THIS IS THE NEW LINK. TYPO IN THE LAST ONE. http://www.geocities.com/cashbyfax22222/newest.html

1 0

RE: Re: authenticating Real Life(tm) - rhetorical bogosity
by Carskadden, Rush 16 Jan '01

16 Jan '01

>From a rhetorical standpoint, this argument is completely bogus. If you want to be reckless with logic, then you might be able to say that in a perfect world, trust of the proof may result in implicit trust of that's proof's application to an ideal (though this is technically flawed), but the trust is not transitive, nor commutative. Trust of a proof may result in trust of a proven concept, but the two are not indistinguishable. Further, the colloquial connotation of the word trust, which seems to me to be the major rhetorical nightmare here, appears subjective, and thus hard as hell to do anything with from a logical standpoint. Attempting to make a shaky logical argument about someone else's trust (in the colloquial sense) of anything may indicate some properties of the subject's method of assigning trust with which I am not at all comfortable. Defining trust in this sense would require a massive amount of data from the subject, which I (for one) am unwilling to collect. Might we, instead, ask the subject how their trust differs between proof and protocol, and inquire about the potential differences in trust assignments? Granted, this list is a bogon sink. Sorry Jim, the devil made me do it. > -----Original Message----- > From: Tom [mailto:tom@ricardo.de] > Sent: Tuesday, January 16, 2001 10:14 AM > Cc: cypherpunks(a)einstein.ssz.com > Subject: Re: Re: authenticating Real Life(tm) > > > > Jim Choate wrote: > > > so you trust the proof. great. if you trust the proof, > and the protocol > > > has just been proven, then your trust extends to the > protocol. and so > > > on. web-of-trust. > > > > > > please don't say you don't. because if a protocol that > was just proven > > > by a prove you trust has not earned your trust by that > procedure, then > > > obviously you lied when you said you'd trust the prove. > > > > The 'proof' IS the 'protocol'. You act as if 'proof' and 'trust' are > > equivalent. They're not. I 'trust' because I know the protocol won't > > 'lie'. That is the 'trust' and the heart of the 'proof'. > > I don't say trust and proof are identical. what I do say is that proof > extends trust. if you trust the proof, then you can trust whatever it > proves. > i.e. if you trust that you do have some method to determine the truth > value of anything I say, then that means if your method says "he says > the truth" you can trust in what I have said. not because I said it or > because you trust me, but because you trust the method which says I'm > saying the truth. > on a crypto level: if you have a protocol that can verify whether or > not, say, a given coin of a given cyber-money is "ok" (not already > spent, of the value it claims to be, etc.) then you can > accept said coin > from me. even if you do not trust me in any other thing, you just > created a trust in that single coin. your trust in the protocol just > extended to a trust in the coin, by application of the protocol. you > didn't trust the coin before, you trust it afterwards. proof was just > the method. there's a lot of trust that exists without proof (some of > which you mentioned in your last mail). > > > > > For your assertion to be so you still need to prove: > > > > A trust B, B trusts C, therefore A trusts C. > > while I did say that, I also wrote a lengthy clarification about it. > please refer to the full claim, not a single, selective quote > which has > a significantly different meaning. > > the full claim was: > > ===quote start=== > if A==B and B==C then A==C > > if replace == with "trust". if A trusts B and B trusts C then A can > trust C. that's a gross oversimplification, so please don't start any > nitpicking. I said a couple of words about trust not being > binary in the > last mail. in essence, the == should read "total, complete, absolute > trust in everything", something that I doubt you'd see > anywhere in real > life. the more precise formula would be: > > A trusts B (minus margin of mistrust) > and B trusts C (minus margin of mistrust) > therefore A trusts C (minus (margin of mistrust AB * margin > of mistrust > BC) ) > ===quote end=== > > now that's a slightly different thing, don't you think? the > mistrust in > the AC case can be quite large, not zero as your selective quote makes > believe. > > > > After all, simply because you and I trust the protocol > still doesn't mean > > I trust you. It only means I believe you haven't lied in > this particular > > case. > > that is exactly what I mean by "margin of mistrust" above. > you may trust > me with taking care of your dog for a week while you don't trust me > taking care of your wife for an afternoon - that is EXACTLY > what I mean > when I say that "trust in real life is not binary". > > > > I use the protocol not to decide my trust but to give me a > reason to opt > > out of the process. Fundamentally if you have to apply any > of these sorts > > of protocols to an exchange a reasonable person won't want > to be involved > > in the first place. There is a fundamental lack of trust > already extant. > > bullshit. the protocol just needs to be simple enough. returning to my > cyber-money example above, we DO have a protocol of verification of > physical money in real life. it's not perfect, but it works reasonably > well. it works by having specific coins or bills for money so that by > visual identification and verification you can accept money > from a total > stranger in good faith. > yes, forgery does exist. as I've said a couple dozen times so > far: there > are no perfect protocols and no absolute trust in real life. but guess > what, civilization works more or less ok without, unless you > are jim and > apply the maximum threat model to every step of your life. >

2 1

Rapid5 Networks, Inc.
by Jerry Talesfore 16 Jan '01

16 Jan '01

Hello- I am looking for a CDR Team Lead. Do you know who can do this job? If you please feel free to provide me with the individuals information ASAP. Here is the task at hand: CDR Team Leader (Call Detail/Data Record) (San Jose, CA) Description: Design, develop, test, and release CDR generation applications in the next generation multi protocol traffic switch. Help build voice and data convergence applications. Help in developing the product roadmap for Rapid5 in voice and data network convergence using the next generation multi protocol switching router. Build teams, motivate them, and energize their enthusiasm to complete the delivery of the first generation of products from Rapid5 and beyond. Requirements: Many years of management experience in building and directing a team of software engineers. Proven track record of successful product delivery and deployment in the telecom industry. Knowledge of several CDR generation technologies: AMA, BAF, etc. Experience in developing CDR generation application for new generation telecom switches. You will have a distinct edge over the other candidates if you possess: Experience working in a small company or a start-up. Previous development experience for CDR software integration for carrier-class telecommunications equipment. Experience in evaluating and integrating 3rd party CDR generation tools. Thanks, Jerry Talesfore Rapid5 Networks, Inc. w(408)519-6753 c(408)464-1640 www.rapid5.com jerry(a)rapid5.com

1 0

could you help me??
by dhiraj gupta 16 Jan '01

16 Jan '01

i am studing in college and working for a project on electromagnetic eavesdropping. please would you guide me on the cicuitry and the equipment required for getting a model for the appratus? i would really be grateful to you for the help. thanx in anticipation dhiraj ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1

2 1

Re: Voice over OTP during WW2.
by Steven M. Bellovin 16 Jan '01

16 Jan '01

In message <F504A8CEE925D411AF4A00508B8BE90A91EB3E(a)exna07.securitydynamics.com> , "Trei, Peter" writes: >http://www.nsa.gov/wwii/papers/start_of_digital_revolution.htm > >Fascinating article at the NSA site about the >heroic efforts to provide long-distance secure voice >communications over radio. > >The good folks at Bell Labs essentially invented >digitized, compressed voice, and encrypted it >using synchronized pairs of records of >random data at each end. Each terminal site >had 55 *tons* of equipment! > >Apparently this astounding - and apparently >successful - effort was mostly declassified >back in '76, but I first heard about it in >Stevenson's Cryptonomicon last year. There's an exhibit on this system in the War Room museum in London. --Steve Bellovin, http://www.research.att.com/~smb

3 2

SPORT.TELEGRAPH.CO.UK IS GIVING AWAY PLAYSTATION 2 CONSOLES
by Sport 16 Jan '01

16 Jan '01

Dear Joe Cypherpunk We have recently launched sport.telegraph.co.uk, our new sports channel dedicated to providing the best online sports coverage from our team of award-winning journalists. The new channel will cover more than 50 sports, and has many new features to provide even better coverage of sporting events from the UK and around the world. To celebrate our launch we are giving away four Sony PlayStation 2 consoles. To win, simply follow this link to <http://www.telegraph-info.co.uk/default.asp?S=297145&C=1001> sport.telegraph.co.uk and register for our new services before February 12th 2001*. (*Terms and conditions apply) Registering with <http://www.telegraph-info.co.uk/default.asp?S=297145&C=1001> sport.telegraph.co.uk will also give you access to: Email bulletins Personalised headlines and content Interactive statistics Clipboard to save articles Bookmarks for your favourite websites Online Betting Forthcoming attractions will include video and audio streaming of live sporting events and celebrity interviews. I hope you enjoy the many new features we have introduced and I look forward to your comments. Yours faithfully Tom Gadd Channel Head for sport.telegraph.co.uk **************************************************************************** ********************** We apologise if you have received this email by mistake. To stop receiving future emails from sport.telegraph.co.uk, please send an email to " Unsubscribe(a)telegraph-info.co.uk <mailto:unsubscribe@telegraph-info.co.uk> " with unsubscribe in the subject line. **************************************************************************** **********************

1 0

Re: authenticating Real Life(tm)
by Tom 16 Jan '01

16 Jan '01

Jim Choate wrote: > > you will have to trust something. then you use that something to verify > > something else, that is what: > > No, I don't have to trust at all. I should have a protocol that I can > PROVE (which is distinct from trust). I trust the proof. I love it when you conflict with yourself. :) so you trust the proof. great. if you trust the proof, and the protocol has just been proven, then your trust extends to the protocol. and so on. web-of-trust. please don't say you don't. because if a protocol that was just proven by a prove you trust has not earned your trust by that procedure, then obviously you lied when you said you'd trust the prove. > > means. > > Which means you feel comfortable enough with people you know to give them > your key. That doesn't mean that because I know you and trust you that I > should trust them. An enemy of my enemy is NOT my friend. And a friend of > a friend is not my friend. the PGP web-of-trust is a specialized version of the above. if you trust me, and I say that key X really belongs to person Y, then your trust extends to the validity of the key. not further, it doesn't mean you trust person Y, it just means that because you trust me you decide to believe that the key really belongs to that person, because I say so. > But then again, sharing a key with somebody you wouldn't trust with your > wallet is probably more than a tad problematic. we're talking PUBLIC keys here. my public key is available to anyone who knows what "finger" means. > > see above. or check what web-of-trust means. for for this problem, we > > have the following steps (in no specific order): > > See what above? Your making statements and then self-referencing them as > 'proof'. Not acceptable. Make an assertion and demonstrate the flow of > dependence. Saying it over and over doesn't make it any more acceptable > than the first time. And it's harder to tune out, familiarity breeds > contempt. still didn't get it? ok, so here's the same in math form: if A==B and B==C then A==C if replace == with "trust". if A trusts B and B trusts C then A can trust C. that's a gross oversimplification, so please don't start any nitpicking. I said a couple of words about trust not being binary in the last mail. in essence, the == should read "total, complete, absolute trust in everything", something that I doubt you'd see anywhere in real life. the more precise formula would be: A trusts B (minus margin of mistrust) and B trusts C (minus margin of mistrust) therefore A trusts C (minus (margin of mistrust AB * margin of mistrust BC) ) > Bottem line, if Bob trusts you, and you trust me, is no reason for Bob to > trust me (or me to trust Bob). Trust/Reputation is NOT transitive (that's > actually why it's worthless). why not? please tell. > > I've known this person for over 10 years. I'm pretty confident that any > > attempts to replace him with someone else in such a way as to fool me > > would be several orders of magnitude more expensive than the gain is > > worth. > > How do you know that he hasn't been undercover for 10 years? There are > cases of undercover cops being submerged for years, spies for much longer. > How would you KNOW. Maybe he's been making 1am burst transmissions to the > 'enemy' for this entire time. Maybe his 'wife' or 'SO' is his contact > point. How well do you know THEM? How well do you know his other friends? > Would you trust them with your key? Does he trust them with access to the > key? If so, even if you don't trust them, they've got it. again, you're applying the wrong threat model. if this were about whether or not I should tell him about the new superweapon that I've been developing in my function as a super-secret scientist, your threat model might apply. since we're talking about a simple question about ammunition here, your threat model is way off. in german, we say "mit kanonen auf spatzen schiessen" - roughly translated as "firing cannons on sparrows". > > how you do this depends mostly on your threat-model. for this example, > > the threat is small - it's not like any TLA would throw a couple million > > dollars at this in order to fool you, right? ergo I can assume that a > > replacement by someone who can fool me for several hours is extremely > > unlikely. > > How do yo know that THIS is their target? How do you know that you haven't > just stumbled into it? How do you know they aren't using YOU for cover? > How do you know that using you will not further the gain? I don't. since I'm not omniscient, I can live with that fact. we're all living our lifes on assumptions, or we'd be insane. maybe you should get in touch with reality every once in a while? > > > Which means nothing, your PGP key is no more trustworthy than your words. > > > > dumb jim. :) > > it's not meant to be any more trustworthy than my words. in fact, it's > > sole purpose (in this case) is to ensure that my words are really my > > words. it's part of step 3 above. > > If the key itself can't be trusted then I can't trust it to authenticate > your words. If I can't trust your key any better than your words then why > am I asking you to sign it? It clearly doesn't add security at any level. excuse me? all the signature says is "these words were really written by Tom". in short: it's "trust" is on a completely different level than those of my words. I can sign a fictional story. you wouldn't trust my words, but you could trust that they are, indeed, *my* words. > > if they are stamped with an official seal (which in the case of the > > military I'm quite sure they are) then you can be sure that any of 3 > > cases is true: > > History is full of 'official seals' not being so official. that would be case b) or c), depending on who's responsible. > > a) they are valid > > b) the government (or other place of origin of the seals) is in on the > > conspiracy > > c) a forger with more skill than your forgery-detection method is in on > > the conspiracy > > Or somebody stole it, or there is an accomplice with access to a > legitimate seal to use for illegitimate uses. subcase of c). > Or somebody has transient > access to one without official access. And that ain't all the ways one > could gain access to an 'official' seal besides the three you listed. you're missing the point. this is not about a complete list of all possible ways to get an official seal on some document. > > wrong. we can solve your problem IF you present us with a list of those > > things that you DO trust. > > Who says trust has to be about 'things'? "things" in the broadest possible sense of "pretty much anything". > I trust those things which can be > independently verified by an arbitrary 3rd party or a process which I can > impliment myself. > > In short, things that can 'prove' other things must be at least isotropic > and homogenious. > > I trust the sun will rise, I trust that we'll all die. I trust that > politicians are inherently crooked. I trust that what happend yesterday > will not be exactly the same as today. I trust that people are both good > and bad, as a result the most good person can in the right circumstances > do the most heinous act (which on another line is ultimately the reason > that the way we treat our prisoners is a moral and ethical failure of the > 1st magnitude). lots of that is not trust, but believe, but let's ignore that. :) > Demonstrate how you authenticate your friend, his material, the channel > he gave it to you with, that I should trust you, and the channel you > provide it to me with. What sorts of things do YOU need to succesfully > authenticate anything? ok, let's focus: the question was: what kind of ammunition does the G3 use? the proposed solution was: I know someone who should know, I can ask him and relay the answer. your problem is: you trust neither me nor - should he even exist - the one I proposed to ask. solution to your problem: we need a protocol that you can verify ("prove") that will in return prove that the someone exists and does know what he's supposed to know and that he is speaking the truth. I at this stage ignore the "official document" crap and every other actual means of verification, since you wouldn't trust them anyhow. as a matter of fact, I think it would be much more simpler if you'd just buy a G3 and check for yourself. > > > from there on, trust can be extended. e.g. if > > Demonstrate trust is transitive. That if I trust Bill and you trust me, > then you should trust Bill. correct if trust is binary. since it's not, the trust I have in you would have to include a "grant option", i.e. if I trust you to have friends that are trustworthy, then yes I would trust bill. > I use PGP as a one-shot transaction security generator. I give you a key > you're the only one who got it (unless you give/lose it to somebody) and I > don't share keys and they retire in the short term (usually after the one > shot use). I never send keys over the network. secret keys - of course not, that's why they're called "secret". you've never sent a public key over the network?

2 2

None
by Cristina Navarro 16 Jan '01

16 Jan '01

1 0

Data Cracer
by 007 16 Jan '01

16 Jan '01

_ dsl`~ bqel ono`d`khq| opncp`ll{, Jnrnp{e unrekh p`anr`r| rnk|jn nopedekemmne jnkhweqrbn dmei. R`j bnr dk sqlhpemh r`jhu opncp`ll qsyeqrbser l`kem|j` opncp`llj` ............... ee lnfmn qj`w`r| bnr qdeq| www.dowland23.newmail.ru

1 0

Freeware barcode scanner utility
by Jonathan Wienke 16 Jan '01

16 Jan '01

Many of you may be familiar with the cuecat barcode scanner being given away at Radio Shack and elsewhere. It reads most types of barcodes including UPC, ISBN and even the tracking numbers on UPS packages. The software that comes with the cuecat is supposed to be snoopware--it is designed to send everything you scan to an internet database, which points you to a web site related to the product you just scanned. I never installed the driver software, but instead wrote a VB program that reads the output of the scanner, displays the data in a text box, and optionally automatically copies it to the clipboard without generating any network traffic. Enjoy!

1 0