December 2003 - cypherpunks-legacy

ANON: pools
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >address). This means that you will have to trust the person running the >remailer. Well, you can always run your own remailer or two... :-) >used which can solve this problem. I call it the "message depot" paradigm. Actually, this is quite similar (identical to?) anonymous pools. The stuff about interfacing different pools sounds good. Miron is running one at extropia.wimsey.com (mail to pool0-request or pool0-help). Basically, it is a mailing list with several subscribers. If you want to send a message to one person, encrypt it and send it to the pool. Everybody gets the message, but only one person can decrypt it. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNk3FoOA7OpLWtYzAQENwgQAoYV+LeTQ2XguY5OtXgiW1pkMuZYxwifl pmmoHvUiFN5JdOBnyII4JgFjWpU1vqzAuUaZxR7yG1/c6Uaq+IluADGsu9NdSUVX NM7UGKffDMmE0bdlfzmlZJtP7+bbUK5kNE7gJkseyZ6q8cU9qjftUlFgASNrUCH9 w75nM8tMM68= =x9BH -----END PGP SIGNATURE-----

2 1

Re: message depots
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

It seems the message depot idea is not terribly original. Oh well, I'm not too surprised. I suspected this and that's why I put "new(?) idea" in my post. I can at least pat my self on the back for reinventing it a few years late. :-) Jim_Miller(a)suite.com

1 0

Next Step show
by crunch＠netcom.com 17 Dec '03

17 Dec '03

Saw Eric Hughes on the Next Step science show on the Discovery Channel last Tuesday. Good job Eric...!! Wish they would have mentioned PGP and how easy it was to get it... Cheers CC

1 0

Jim McBride
by Anonymous 17 Dec '03

17 Dec '03

Got this in the mail today: -- cut -- Date: Wed, 03 Nov 1993 22:11:07 From: jim_mcbr(a)netmail.com Subject: Auto Reply To: <me> 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 -- David Sward sward+(a)cmu.edu Finger or email for PGP public key 3D567F Encryption is an envelope for your email; read alt.security.pgp for details. GCS: -d+ -p+(---) c++(++++) l+ u+ e+ m+()@ s+/++ n+@ h+ f !g w+@ t+@ r+ y?

2 1

Re: UPDATE: direct-marketing email address list
by Stanton McCandlish 17 Dec '03

17 Dec '03

Here's what you get if you send mail to J.S. McBride's posted address to query about the direct-marketing email address list: ______ begin forward ______

1 0

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

ViaCrypt PGP has arrived
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

My copy of ViaCrypt PGP arrived yesterday (Nov 3). Since I worked late, I haven't had a chance to play with it yet. I looked through the manual. The commands look similar (if not identical) to "classic" PGP's, as far as I could tell at a glance. The bulk of the text for the manual was taken from the documentation that comes with PGP, except all occurances of "PGP" where replaced with "ViaCrypt PGP". The box looks pretty good. :-) Looks like they hired a real graphics designer. I suppose some of you are wondering why I'd fork over 100 bucks for something I could get for free. First of all, I can afford it. Second of all, I simply feel more comfortable using a licensed shinkwrapped software product than a quasi-legal freeware one. Call me a coward. 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. Somebody 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 to put in any backdoors. Jim_"Rebel without a spine"_Miller(a)suite.com

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

unsubscribe
by crypto＠fizbin.fredd.com 17 Dec '03

17 Dec '03

Please unsubscribe me. Thanks! -- Red Rover crypto(a)nowhere.com

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

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

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

message depots, packet routing?
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A few discussions of DC-Nets here show a small misconception. The network topology does not have to be the same as the DC-Net topology. What I mean is this: the communication in the network may be a ring or any other topology. But that does not mean that you only share random numbers with your neighbors on the ring. You can share random numbers (on a pairwise basis) with every other participant in the network, in the most extreme case. Look at this diagram, showing four people communicating in a DC-Net. The lines represent shared random number one-time pads. A---------B | \ / | | \ / | | / \ | | / \ | C---------D Each person shares random numbers individually with every other person in the network, in this example. A and B share their own random numbers, A and C share a different set, A and D have their own, B and C do, and so on. But that does not mean that the network communication topology has to be all to all. Instead, a ring topology could be used, with packets passing around the network A-B-D-C-A-B-D-C-.... At each step, A would xor in the next random number from each of the three pads that he is using, then xor in his message bits if he has anything. Then he would pass it on to B. After the packet has gone all the way around, the message (if any) would be revealed. And in this case it doesn't matter who your "neighbors" are in the communication network. B and C colluding can't distinguish whether messages come from A and D despite the fact that they separate them in the comm network. So this concern about "knowing your neighbors" in the DC-Net is not as serious as it sounds. If truly paranoid people want to participate in a DC-Net (and who else would?) then they can use a DC-Net topology which does not allow partitioning. This adds overhead and inconvenience of distributing shared random numbers, but it does not require the communication pattern to change. BTW, I like the name someone proposed for a DC-Net: "Ouija Net". The idea is that messages appear in a DC-Net somewhat like messages appearing on a Ouija board. The true source of most Ouija board messages, IMO, is people pushing the indicator around. But because everyone is touching it, each person has plausible denial. You know that SOMEONE is moving it, but there is no way to tell who. This is similar to DC-Net messaging. Hal hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNnG0qgTA69YIUw3AQFigQP+LDMO6S7HkS4YkLdctLus4GamIvb/BxSX uG8VcZ/0eujQt8ZEIlNEzwNZvBR3Sio8gKko2jjvmWDGyobibSpctfqcr5Qf42xz 42TWVzYCjg+tka6FttosZ0phwGP1m7Dy+sC/zE0YmEQagS6jDSn/RiqR2PDMSJZn FEo2lfh8tmQ= =ZUfW -----END PGP SIGNATURE-----

1 0

bouncing mail?
by ateel＠nyx10.cs.du.edu 17 Dec '03

17 Dec '03

Dear cypherpunks(a)toad.com: I read the following message and then followed itss instructions and the messages after it were the result. Any ideas? BTW: What is cypherpunks? +---------------------------------------------------------+ | With Explicit Reservation of All Rights (U.C.C. 1-207), | | Regards, -A. J. Teel-, Sui Juris (ateel(a)nyx.cs.du.edu) | | Call (303) 687-4935 anytime! Finger for PGP PUBLIC KEY. | | Please use "ateel(a)nyx.cs.du.edu" NOT ".@nyx10." Thanks. | +---------------------------------------------------------+ --------------------- Msg 1 --------------------- Date: Tue, 2 Mar 93 00:09:27 CST From: dclunie(a)pax.tpa.com.au (David Clunie) Message-Id: <9303011339.AA15227@britt> To: cypherpunks(a)toad.com Subject: Mail server for PGP sources I gather some people have had trouble obtaining sources for PGP. I have accumulated those I can and they are available from my mail server. If you can get these somewhere closer then great, but if desperate feel free to get them from here (as long as the load doesn't get out of hand I will keep it going). The address is "mail-server(a)pax.tpa.com.au". Help is available by sending in the message body: send help end An index of PGP files is available by sending in the message body: index pgp end And results in something like the following ... Date Size Index: pgp ---------- ------ ---------------------------- 1992/12/25 216K security/pgp/macpgp2.0.sit.hqx 1992/12/25 160K security/pgp/msiguide.zip 1992/12/25 33K security/pgp/ngclon11.zip 1992/12/25 168K security/pgp/pgp-ng.zip 1992/09/13 184K security/pgp/pgp20.zip 1992/09/13 376K security/pgp/pgp20src.zip 1992/12/25 536K security/pgp/pgp21.tar.Z 1992/12/25 192K security/pgp/pgp21.zip 1992/12/25 656K security/pgp/pgp21ami.lha 1992/12/25 240K security/pgp/pgp21os2.zip 1992/12/25 440K security/pgp/pgp21src.zip 1992/12/25 224K security/pgp/pgp21_next.tar.Z 1992/12/25 256K security/pgp/pgp21_sparc.tar.Z 1992/09/13 464K security/pgp/unix_pgp20.tar.Z Probably pgp21.tar.Z or pgp21.zip are what you want for unix or pcdos respectively. If anyone has a more recent mac version I will put that up too. david --------------------- Msg 2 -----------------

1 0

Returned mail: Host unknown
by Mail Delivery Subsystem 17 Dec '03

17 Dec '03

----- Transcript of session follows ----- 550 pax.tpa.com.au (TCP)... 550 Host unknown 554 <mail-server(a)pax.tpa.com.au>... 550 Host unknown (Authoritative answer from name server) ----- Unsent message follows ----- Received: from nyx10.cs.du.edu by mordor.cs.du.edu with SMTP id AA26753 (5.65c/IDA-1.4.4 for <mail-server(a)pax.tpa.com.au>); Fri, 5 Nov 1993 01:16:14 -0700 Received: by nyx10.cs.du.edu (4.1/SMI-4.1) id AA26238; Fri, 5 Nov 93 01:16:38 MST Date: Fri, 5 Nov 93 01:16:38 MST From: ateel(a)nyx10.cs.du.edu (A. J. Teel - Sui Juris) Message-Id: <9311050816.AA26238(a)nyx10.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. To: mail-server(a)pax.tpa.com.au Subject: ... send help end ------------------------------------------------

1 0

Returned mail: Host unknown
by Mail Delivery Subsystem 17 Dec '03

17 Dec '03

----- Transcript of session follows ----- 550 pax.tpa.com.au (TCP)... 550 Host unknown 554 <mail-server(a)pax.tpa.com.au>... 550 Host unknown (Authoritative answer from name server) ----- Unsent message follows ----- Received: from nyx10.cs.du.edu by mordor.cs.du.edu with SMTP id AA26759 (5.65c/IDA-1.4.4 for <mail-server(a)pax.tpa.com.au>); Fri, 5 Nov 1993 01:16:46 -0700 Received: by nyx10.cs.du.edu (4.1/SMI-4.1) id AA26298; Fri, 5 Nov 93 01:17:11 MST Date: Fri, 5 Nov 93 01:17:11 MST From: ateel(a)nyx10.cs.du.edu (A. J. Teel - Sui Juris) Message-Id: <9311050817.AA26298(a)nyx10.cs.du.edu> X-Disclaimer: Nyx is a public access Unix system run by the University of Denver. The University has neither control over nor responsibility for the opinions or correct identity of users. To: mail-server(a)pax.tpa.com.au Subject: ... index pgp end ---------------------- Msg 3 ----------------------

1 0

Commerce models
by szabo＠netcom.com 17 Dec '03

17 Dec '03

Here's a copy of a post I made to imp-interest(a)thumper.bellcore.com (among other reasons to refute Detweiler, who is on imp now promoting his "tag the criminals" agenda). I hope I've given a fair overview of some of the things we're interested in, but from a "pro-commerce" rather than "pro-cypherpunks" point of view. (I find the ends and means to be very similar, but the point of view is different. imp-interest is interested in pushing Internet commerce, not ideological agendas). ----------------------- > 1. Can anyone else come up with some other Internet commerce models? You mentioned one of the original digital cash shemes. There are wide variety of offline (2-party transactions) and online (realtime connection of buyer & seller with bank) digital cash proposals, many by David Chaum, his students, and colleagues (cf. Eurocrypt and Crypto proceedings). Some of these can be implemented securely in software, without the need for smart cards or other kinds of physical security. (For example, one's own digital cash can be encrypted with one's own private key & passphrase, making it as difficult to rip off as any other form of electronic money). Also, Chaum has an interesting per-organization pseudonym/transferrable credentials system that could allow checking credit ratings without revealing identity. Another, much simpler concept, is "digital postage", where tokens would be sold per service provider, perhaps from physical stores or vending machines, or online in exhange for other tokens, or by a non-private means like credit card as long as there is a fluid market for such tokens. These would be much like the token cards used now in subways, copy machines, etc. Although this is not as general as digital cash, client software might allow a wide variety of tokens to be maintained and used automatically, and the basic software would be less complicated (the underlying security protocols easier to understand and implement purely in software). > 2. Do you think that the IBS model is good? (Forgive me if I'm misunderstanding the nature of Internet Billing Service; I'm basing my comments on your comparison of it to credit card billing). I'm very concerned that IBS and on-line checks would, like credit cards, lack privacy, allowing dossiers to be easily collected on customer buying patterns. Under such systems there would be incentive for those seeking privacy to spoof (eg by creating false credentials and/or credentialling agencies), as well as for those seeking to defraud to spoof. A good net commerce model should be able to deal with the fact that many Internet users can easily create pseudonyms, and credentials (digital signatures, etc.) for those pseudonyms, without demanding expensive, privacy-endangering "true ID" enforcement. Given the extremely messy legal environment with thousands of jurisdictions criss-crossed by the Internet, a basic principle of Internet commerce should be to minimize the need for legal intervention. Also I'm concerned about the vulnerabity of the IBS organization(s) themselves to corruption, which could sap or destroy an economy centered on such an agency. A good commercial model should be decentralized so that any such corruption can be quickly routed around, much like the Internet is built to route around node failures. With the efficiency of on-line software customers can "ping" banks, billing services, etc. by depositing money in a very fine-grained manner at a wide variety of such service providers, to determine which services are the most trustworthy. Extensive reputation records for these services can be accumulated, searchable on-line Consumer Reports. Thus I hope a wide variety of decentralized means of Internet commerce can be tolerated. Of the possible means, digital cash and/or pseudonyms with transferrable credentials seem the most attractive. They are complicated in raw protocol and software, but could present a simple conceptual interface for most users, and they don't demand that third parties, ie net culture, net user's software, and world politics be changed in in fundamental ways. Some sorts of changes might happen, but the goal of Internet commerce is not to predict them or bring them about or prevent them (we can't do those things any better than anybody else), but to set up Internet commerce without having to rely on major help or change on the part of third parties. Nick Szabo szabo(a)netcom.com

1 0

Re: Macintosh PGP CDEV Idea
by felix＠hu.se 17 Dec '03

17 Dec '03

I have some ideas I've been working on (a modular approach). To be sucessfull, a cryptographic utility for the Mac has to fit nicely into the system. Here's my proposal (divided into five layers): 1 - CryptoModules To do encryption we need cryptographic algorithms. These are written as small modules (code resources) and are put into the Extensions folder. They contain algorithms but no user interaction. It's easy for the user to install and upgrade CryptoModules. It's also easy to write new modules, as you don't need to worry about user interfacing, and can concentrate on the algorithms. 2 - CryptoAccess This module is the interface to the CryptoModules. It provides c/pascal routine interface and scripting abilities (AppleEvents). Contains no user interaction, and is key oriented (it looks up the right algorithm for a given key). 3 - CryptoAPI This module handles the user interaction. Provides the dialogs and menus neccesarry for encrypting/signing data. Accessed by c/pascal routines or AppleEvents. 4 - Applications/Utilities With the CryptoAPI it's easy to write encryption capable programs. Very little code has to be added to existing applications. A nice utility would be encryption of text in TextEdit. 5 - Integration with System 7 Pro Patching the Digital Signature Manager will extend the system in a consistent way. All neat features (like signing in the Finder, etc) will also work with PGP. Unfortunately, I haven't enough spare time to do all this myself. The layer model makes it possible to divide the work that has to be done. ---------------------------------------------------------------------- True Name: Felix Ungman "Gen is god and your God is not"

1 0

Re: ViaCrypt PGP has arrived
by pierre＠shell.portal.com 17 Dec '03

17 Dec '03

> From: jim(a)bilbo.suite.com (Jim Miller) [...] > 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. > Somebody 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 to put in any backdoors. Unfortunately, backdoors have not been the main security problem in commercial system software, bugs and "honest mistakes" have been. Unfortunately too, there has been very little pressure by customers to hold companies accountable for the software they ship. Usually somebody uncovers a bug, uses it for a while, is detected, and that causes (in the best case) the software company to issue a new patch. Some distribute the patches for free, some make you pay big bucks for it. But never is the company really harmed by the fact that it claimed some level of security (or functionality), and was not providing it. If, in the future, ViaCrypt says "ooops, there was a debugging switch left on when we compiled, here is a free patch." would you discard your ViaCrypt PGP, buy the competitor's version (there is none), and sue them? Did they include any disclaimer in the license? Call me cynical, Pierre. pierre(a)shell.portal.com

1 0

Re: PGP BUG/FEATURE: multi-platform keys
by dmandl＠lehman.com 17 Dec '03

17 Dec '03

> As long as I'm at it, here are some more macPGP2.3 bugs, for those who care. Trying to decrypt a message signed by a key I don't have causes a serious crash requiring reboot. Trying to select cancel in a signature dialogue just raises the same dialogue box instead of cancelling. I'm running on a powerbook 145 under system 7.0.1. > > Eternal!Optimist(a)anon.penet.fi (copyright 1993, Eternal Optimist [Ha Ha Ha]) > 0) 0) =:()]-< <na26436(a)anon.penet.fi> It's been a while since I beta-tested MacPGP 2.3, but I think that... The problem with quitting out of the pass phrase prompt was a "feature." When you pressed CANCEL, the interface told the pgp engine that you had typed in a bad pass phrase. I guess this was an easy quick and dirty way to handle it. The problem was, when you typed in a bad pass phrase, you were given two more chances to get it right. Therefore, when you pressed CANCEL, you were also prompted two more times. So, you had to press CANCEL three times to quit from that prompt. This was fixed in 2.3a, a beta version of which I've got. I guess the official 2.3a has been released by now, but I haven't checked. --Dave.

1 0

Sternlight
by Carl Ellison 17 Dec '03

17 Dec '03

I don't know who wanted to start reposting Sternlight posts to this list, but I have a good way in my news reader to avoid mail from him or in reply to him or talking about him -- but lack such facilities in my mail reader. Could any message mentioning Sternlight or reacting to something he said (however indirectly) include his name in the subject line so that I can kill it without reading? Thank you. - Carl

1 0

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

17 Dec '03

ogr(a)wyvern.wyvern.com (Jason Plank) said: > Phil Zimmerman solved this problem by supplying the source code for >his product. You can see for yourself that there are no backdoors. This helps, but is imperfect. How many people will read their particular copy in sufficient detail to ascertain that there aren't any obvious backdoors added by e.g. a sneaky archive site maintainer, or some sneaky cracker who found a way to modify the archived copy? Furthermore, even close reading won't absolutely *guarantee* the lack of backdoors in all cases, even if the reader is an expert on relevant subjects. We'll all continue to use software despite lack of absolute assurances, but it's worth keeping in mind what the situation is. Doug

2 1

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

17 Dec '03

greg(a)ideath.goldenbear.com (Greg Broiles) said: >It's not clear to me how you can trust systems not under your control to >report on themselves or local conditions accurately. As your program gets >more complex, aren't you going to run into an analog of the Turing >machine/halting problem? The idea is to encode the important-to-be-trusted features of the software and the inter-machine protocol handshake together into the equivalent of a Goedel number which acts as a public key during the protocol handshake, so that any change to that core encoding of the functionality would have the side effect that it was no longer able to communicate. >It's an intriguing idea, but it's still very unclear to me how it might >work on software of any real complexity. Yeah...I'm having strong difficulties with doing it in a way that is computationally feasible as well as theoretically sound. Several times I thought I'd found the right approach but then found holes in it. So I lied in implying that I really did have a final algorithm....I *thought* I did, but I was wrong. Doug

1 0

punk-net mailing list
by jdblair＠nextsrv.cas.muohio.EDU 17 Dec '03

17 Dec '03

To those interested in participating in a hardware specific cypherpunks list, (punk-net, net underground, whatever) e-mail me. My sysadmin is cool with the idea of setting the list up here, so if a decent number of people respond over the next week, I'll set it up. So, hardware fiends... time to bring a whiff of burnt flux and overheated resistors to the world of underground cryptography. -john. jdblair(a)nextsrv.cas.muohio.edu

1 0