- cypherpunks-legacy - lists.cpunks.org

Re: WARNING: direct-marketing email address list
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

> According to the Internet Business Report 1.3 (page 4), J.S. McBride and > Company are selling access to a database of Internet addresses, including > demographic information. They claim over one million entries. The net > I receive an unsolicited e-mail from these people just the other day. It said something to effect of "I have heard that you may be interested in implementing UNIX/Mac/PC software...I have a database of contact addresses that may interest you...I am NOT selling anything...If I have mis-read your intentions, I apologize. However, could you forward this letter to someone would may be interested." I deleted it. Jim_Miller(a)suite.com

2 1

trusting software
by doug＠netcom.com 17 Dec '03

17 Dec '03

How does one know that one can trust the software that one is using on one's own machine for encryption, mailing, etc, or worse yet, how can one know whether to trust the software doing anonymous or other remailing on other machines? Web-of-trust schemes are only statistically reliable due to these concerns. These are rhetorical questions; the point is, I just realized that I didn't explain myself last month when I talked about an algorithm for verifying *intentions*. A number of people emailed me to complain that authentication should be a matter of establishing a person's *real* identity -- a valid issue, but I was off on a tangent and neglected to explain my actual point: Imagine you have a single piece of software which runs a dcnet over the internet by being instantiated on many nodes. Imagine that you're concerned that the NSA or someone will spoof a whole bunch of nodes, pretend to be the Real Software (which ordinarily helps guarantee anonymity, defeat traffic analysis, etc), but actually works to defeat the Real Software and the people who use it. One would like to somehow guarantee that when one talks to remote software as part of a web of trust scheme, that the software really is the One and Only True Software, and not some deceitful counterfeit. It is in *this* connection that one might wish to authenticate the unique identity of multiply instantiated *software* by a hypothetical process which ascertains the *intentions* of that software instantiation. I previously phrased this as if it were a person that the hypothetical algorithm was authenticating, leading to understandable objections. Apologies; I had gotten into a digressive train of thought about using it with people before I posted, and it's taken me this long to realize that I never communicated clearly. I still haven't described the algorithm ("this margin is too narrow" :-), but I hope it's more clear that such an algorithm is potentially more realizable for software than it would be for people. Doug

1 0

Er?
by Johan Helsingius 17 Dec '03

17 Dec '03

Anyone have any idea what this is about? Anon.penet.fi is being bombarded by an endless flow of these... Julf ------- Forwarded Message X-Envelope-To: na26436 Received: from hydra.acs.uci.edu by anon.penet.fi (5.67/1.35) id AA21686; Thu, 4 Nov 93 16:42:48 +0200 Received: by hydra.acs.uci.edu id AA24199 (5.65c/IDA-1.4.4 for na26436(a)anon.penet.fi) Thu, 4 Nov 1993 05:47:52 -0800 Date: Thu, 4 Nov 1993 05:47:52 -0800 From: Mail Delivery Subsystem <MAILER-DAEMON(a)hydra.acs.uci.edu> Message-Id: <199311041347.AA24199(a)hydra.acs.uci.edu> To: na26436(a)anon.penet.fi Subject: Returned mail: Return receipt ----- Transcript of session follows ----- ----- Message header follows ----- Received: from orion.oac.uci.edu by hydra.acs.uci.edu with SMTP id AA24194 (5.65c/IDA-1.4.4 for <athomas(a)hydra.acs.uci.edu>); Thu, 4 Nov 1993 05:47:52 - 0800 Received: from relay2.UU.NET by orion.oac.uci.edu with SMTP id AA28377 (5.65c/IDA-1.4.4 for <athomas(a)orion.oac.uci.edu>); Thu, 4 Nov 1993 05:47:50 - 0800 Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04164; Thu, 4 Nov 93 08:45:13 -0500 Received: by toad.com id AA23509; Thu, 4 Nov 93 05:37:38 PST Received: by toad.com id AA23503; Thu, 4 Nov 93 05:35:10 PST Return-Path: <jik(a)security.ov.com> Received: from pad-thai.aktis.com ([192.231.148.11]) by toad.com id AA23499; Th u, 4 Nov 93 05:35:05 PST Errors-To: na26436(a)anon.penet.fi Received: from gza-client1.aktis.com by pad-thai.aktis.com (8.6.4/) with ESMTP id <IAA14324(a)pad-thai.aktis.com>; Thu, 4 Nov 1993 08:35:27 -0500 Received: from localhost by gza-client1.aktis.com (8.6.4/4.7) id IAA28688; Thu, 4 Nov 1993 08:35:26 -0500 Received: from relay2.UU.NET by pad-thai.aktis.com (8.6.4/) with SMTP id <WAA26264(a)pad-thai.aktis.com>; Wed, 3 Nov 1993 22:05:39 -0500 Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29104; Wed, 3 Nov 93 22:02:57 -0500 Received: by toad.com id AA18024; Wed, 3 Nov 93 18:57:31 PST Received: by toad.com id AA18012; Wed, 3 Nov 93 18:56:25 PST Received: from punisher.caltech.edu ([131.215.48.151]) by toad.com id AA18007; Wed, 3 Nov 93 18:56:20 PST Errors-To: na26436(a)anon.penet.fi Received: from alumni.cco.caltech.edu by punisher.caltech.edu (4.1/DEI:4.41) id AA29935; Wed, 3 Nov 93 18:56:14 PST Received: by alumni.cco.caltech.edu (4.1/DEI:4.41) id AA20137; Wed, 3 Nov 93 18:52:10 PST Date: Wed, 3 Nov 93 18:52:10 PST Message-Id: <9311040252.AA20137(a)alumni.cco.caltech.edu> To: XXXXXXXXXXXXXXX, cypherpunks(a)toad.com X-Mail-Duplicate-From: nobody(a)alumni.cco.caltech.edu Comments: This message is NOT from the person listed in the From line. It is from an automated software remailing service operating at that address. Please report problem mail to <hal(a)alumni.caltech.edu>. Subject: Re: ANON: mail concerns From: Eternal Optimist <na26436(a)anon.penet.fi> Return-Receipt-To: na26436(a)anon.penet.fi Reply-To: na26436(a)anon.penet.fi Errors-To: na26436(a)anon.penet.fi ------- End of Forwarded Message

3 2

ANON: random remailing...
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >if every single site knows the final address, so what? >how is this going to help them track down the original sender?? >anyone at the final destination who wants to track down the original sender >would need to hop-scotch backwards through the numerous sites and try to >track down the path the message took. this is of course, IF someone really Yes, this is true, but the key point in the anonymous remailers is they can be used for two-way communication. Presumably, both you and your friend intend to email each other. If mail proceeds randomly throughout the network, then the final destination must be available to every remailer. This may be fine if A only sends to B (announces to every remailer B's address), but when B responds to A, A's address is similarly announced to every remailer. Now it is simple to figure out A and B are communicating. If all you want is one-way communication (i.e. you just want to send and don't expect any replies), you may be better off faking mail with telnet, or using a newsgroup. Karl Barrus <klbarrus(a)owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNk0qoOA7OpLWtYzAQF17wP/eittrsJRkRuKSXH0V1bSiEEc1+ZAYGj9 4+aTctisX0QG2LholGDHqxti02SyEH+iQO8qjAkY5vyHNDVM6pH4tr2xzF2W9prx 1A91KNXHdiZPAvsUWgv32+B5IJYZqarRVmLjuI7PnydTiKX9/24bffl8TUtoidln syJ3O/cVoyA= =iz1j -----END PGP SIGNATURE-----

2 1

PC Magizine.....
by Wizard＠falcon.lhup.edu 17 Dec '03

17 Dec '03

...just to let all know, the November issue of PC Magazine mentions PGP in the Trends section. (pg 29) '....in fact, cryptography is included on the State Departments' list of weapons that could compromise the country's security.' '..Despite attemps to keep the technology stateside, 84 products that employ Digital Encryption Standard (DES) are available overseas, says the Software Publishers Association. But the regulation has succeeded in keeping U.S. companies out of the globabl marketplace. And recently, the makers of a software encryption program called Pretty Good Privacey(PGP) have been investigated for possible export violations. (Both DES and PGP are available on the Internet.)' The article also talks some about Clipper, but nothing new to my ears. The Skip-Jack algorithm is mentioned, and the fact that the NSA is keeping mum on how it works. Sean wizard(a)falcon.lhup.edu

1 0

Auto Reply
by jim_mcbr＠netmail.com 17 Dec '03

17 Dec '03

Thank you for your mail to Jim McBride at JS McBride & Company. Due to the volume of mail be handled by this account, this is an automatic reply. PLEASE READ CAREFULLY!! 1. JS McBride is NOT collecting demographic information on email addresses. Due to the controversy surrounding this practice, we have discarded the product demographics we collected. We are however still collecting email addresses and user names. 2. The information collected (name and email address) will be offered in a printed white pages directory and in a white pages server on the net. 3. You DO NOT need to ask to have your name removed. BEFORE your name is used in the directory, you will receive mail asking for your permission. If you reply to the inquiry, your information will be used. If you do not reply, your name will NOT be used. 4. Comments regarding the white pages should be sent to Tom Manning at JS McBride & Company. <tmanning(a)netmail.com> 5. Mail to Jim McBride should be sent to <jimm(a)netmail.com> 6. Information regarding the purchase of the white pages directory should be sent to <listinfo(a)netmail.com> or telephone us at 415-949-4295 Thank you for your time, Jim McBride ___________ end forward __________

1 0

Re: Allegations of PGP Weaknesses
by edgar＠spectrx.saigon.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A few days ago, Victor Borisov posted here the following allegations or rumors about "weaknesses" in PGP. >He made same program (LanCrypto). That why, I hear only bad >words from he. :) You can read about this program in >cypherpunks. >From other KGB-men, I hear, that prophesor >Sidelnicov (the well known cryptoanalisist from Russia) saw, >that PGP has some weak places: > - random number is`t "good" random number. > - md5 has hole (but here man lapse into salence:( ). > - PGP for DOS don`t have any anti-overloking tools. > >BTW: LanCrypto play on last weakness: thay wrote litle >resident DOS program. This program crack PGP and than pgp >sign (and check) only part of message. LanCrypto public >this resalt in buziness newspaper and show program on the >big computer-show. I think this is rough market, but it >work well (as all, that KGB made:))!!! Since then, I have checked with other members of the PGP development team and here is a summary of what they (and I) say: The random number handling in PGP was beefed up in the 2.2 release. We don't know if there were any real weaknesses before that, but the improvements were added anyway. We suspect that if there were any problems, they are gone now. The guy who complained about it, Dr. Sidelnikov, never cooperated with requests for details on what he found wrong with PGP. In fact, he was pointedly uncooperative when contacted with questions asking him for details. If MD5 has a hole, we'd like to know about it. It would be publishable in any crypto journal. At Eurocrypt93, someone did find some slight weakness in MD5, but in realistic situations, this would not be a significant weakness. Future versions of PGP may use the SHA hash algorithm, instead of MD5. MD5 should be kept around for backwards compatibility. MD5 is still a good hash function, and the weaknesses found were not applicable to any real-world uses of it. An old version of PGP did not detect if material was appended to a signed message. This was a bug that was fixed, around version 2.2, or maybe 2.1, I'm not sure which. We're not quite sure what "anti-overlooking" tools are, but based on Boris' example, we guess it would be code added 1) to insure that the code is unmodified and 2) make analysis of the code (e.g. with debugging tools & disassemblers) difficult. Since PGP is distributed with source code, it's obviously open to analysis and modification by anyone even moderately skilled in programming. "Overlooking" attacks are easily countered by 1) making sure you have a "clean" PGP.EXE by checking it against the detached signature packed with it. 2)Running PGP with a freshly booted MSDOS from a factory diskette. This is especially true if you run into "suspicious" actions when running PGP in your normal configuration. (Like you get back a copy of something you signed which seems to have text added you don't remember). -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNeRXt4nNf3ah8DHAQE+0QP/csLY4hw6AHGTdkoZu2koETv2q/ohnVl8 yGDwR65VVeuuiSANHjSmhUbA2w7DcbOaIxamzi1PSY6OHosB1ve4d2hOHKzdMrv1 m38x0iQLPZdGuuX0mCxRqvIJ47W8xKj49CxXIB+Khrva0nn+pAmQF6+IYonPGSAE 7uRREQnIzCU= =7ogP -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0

Re: ViaCrypt PGP has arrived
by Dark 17 Dec '03

17 Dec '03

I was with you all the way until you said: -> I realize that by not compiling the code myself on my own machine I basically have to trust the ViaCrypt PGP implementation. So be it. If there is something wrong with ViaCrypt PGP I believe it will eventually be discovered. Someb ody will no doubt disassemble it and look for backdoors. If someone finds one, ViaCrypt's reputation will be worthless. It's in ViaCrypts best interest not t o put in any backdoors. <- Call me paranoid: I'd never take what it's in someone's "best interest" as a major factor in predicting actions. Look at the crime section of the local paper or that bit called "news of the wierd" I happen to agree with you this time, though it would be nice if ViaCrypt had included the code and a compling mechanism. I suppose this is outside the realm of marketing possibility though. -uni- (Dark)

1 0

ANON: pools
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >address). This means that you will have to trust the person running the >remailer. One point is being missed here - a chain of remailers is as strong as its STRONGEST link. As long as even ONE remailer in the chain is trustworthy, hiding the connection between incoming and outgoing messages, your anonymity is preserved. The suggestion that remailers themselves choose the routing path means that you have to trust the remailer that chooses the path. If it is corrupt, it can defeat the effect of the path. To protect yourself, you want to use many remailers in the chain, and use a system which does not require you to trust any one remailer. Having the remailers choose the path does not really help. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNnDFKgTA69YIUw3AQFDWQP/fCdoob+6zBSTFIlvnWLmXEL5+KPzMOgf AOImZJlFDOSAbAL2GK/+Pm/tsOiLEQ0MD7yEvUjafpM0D2qEtsxzz7FJvJl09+gd GFoGrMmbkCavFqajYGK89aq+8ESGIc4Gefyob4izeAOOWXIhZpS2CjX16CQ2s0DZ U2xTGaO67/Q= =0MVk -----END PGP SIGNATURE-----

1 0

Signing keys for nyms
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Eric Hughes writes, regarding the problem of determining whether the key of a "nym" is valid: > If a provider of any sort is the sole means of access to a series of > communications, there will be the possibility of tampering. If some > public key must issue forth through this channel only, it is possible > to alter the pseudonym's public key each time it is passed throught > that channel. Since every protocol which uses communications only > through the server won't work, every solution needs another channel. Eric goes on to describe a solution based on sending the key through two different channels, with a return message via the pseudonym server channel. I think this is a good solution, but there is the possibility that the evil pseudonym server could corrupt the return message so that the nym did not find out that his key was being mangled (although other people would find out, which may be good enough). A more general solution is to use more than one pseudonym server. Assuming they aren't both colluding, you can send your nym1 key to nym2, and vice versa. By providing two or more channels back to you as well as out from you, you are able to detect corruption of your messages. Eric suggested that if the pseudonym server signed the user's key, then corruption of the key could be proven to third parties. I'm not sure this is the case, because it would seem that a user could falsely incriminate a pseudonym server by claiming that he had never created the key which the pseudonym server signed, that it was a bogus key. I suppose reputations would have to play a role then, in weighing the credibility of the pseudonym server against that of the nym. Hal hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNm4NagTA69YIUw3AQFGOwQApSwLHzBfQKStZd6g/17dsL3WUtgCvy6D OyQjFQ3dRd6VRGrEaQ7aRbnae9If0NqF2qbaxeHAKNP/Uiyo/cGBWvFjAxWeVyY0 hddLRBygxIyqjkDkxAEBGaYRruly8TC4TEU45ChwSUz2Smh0rDm8S2GINgXe340P a1peTNDPSlI= =Ywbw -----END PGP SIGNATURE-----

2 1