- cypherpunks-legacy - lists.cpunks.org

reputation capital transaction
by SINCLAIR DOUGLAS N 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In anticipation of the upcoming Computers, Freedom and Privacy conference, I'd like to transfer some reputation capital between accounts. Doug Sinclair <diemos(a)io.org> == The Cunning Artificers I ported RC4 to the HP48 calculator. A bignum package capable of RSA and Diffie-Hellman is coming soon. Doug's key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAy93adEAAAEEAPHAXq0g2lFnn1kE4trrPWCjhiCzxNkjake4W4mspvOCGjd0 MUREgYJm3DVcTn5Ue0FdhSHOVoMoS+jdRV8W6wB/hGUUqyqleKkNSv1/yOAPCzHn Iq74GCRniy0WdO5zlDi56LxH5ruteWl6soPt1n3EeJKRldux7DouNsrtqO6VAAUR tB1Eb3VnIFNpbmNsYWlyIDxkaWVtb3NAaW8ub3JnPokAlQMFEDFNZAjhTVXsPaAX /QEBzZED/icJDAo1cjVp0eRqpelcAurXFqlkcfbvyg76KDHsxsiKthLyzF9UwErE xDxMyG/4rhojiJUoVaIq3MgJ9ZwtpXwkLS0kqXZySPSLsWMXjpzy36tOZ2XcdVFv kVVUy3I0M2nYfO8vT4vZV53VC8vqAKTjuQCt/vhcDrYTZdX0BLLY =t2MG - -----END PGP PUBLIC KEY BLOCK----- The Cunning Artificers key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzEAEf4AAAEEAMONoLHj5CwKvaM6ch9GOcUjgoVS5sjXa4TzD2ohhtHFYR9l QzNj0vNASBQKE/Mk9Flqg+dtitS7S7B0qZQ+mQmMT73yniun596jt1NCJ5sLBKrM jDvYK3wGbycVX43RBiR3iwJZGq5blfWqNRE7kFdTxgu+bCdtLOFNVew9oBf9AAUR tBZUaGUgQ3VubmluZyBBcnRpZmljZXJz =pf3Y - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMU1k8uFNVew9oBf9AQG/JQP+K0hNzQew5MBOc1TGea+gkvBrTy+O801j 0yb4OrmAfuEQg6TalE7+jKGPoB/y9Ln2eusaZ+JCneBs7oVdvPSlzm/qNOjYXB7m jSxjkp20lzhxU5UBSAWWePbYsvoCe78BFS51OXEZdTuvGnbcKyh8l1DbvEKEML0i rNzbhRCuMDE= =HOSH -----END PGP SIGNATURE-----

1 0

DEC_lan
by John Young 17 Dec '03

17 Dec '03

NYT of 3-18-96 has front page story on Internet copyright issues, featuring copywebbing terrorist Declan. DEC_lan

2 1

DESCRIBE
by Leonardo Machado 17 Dec '03

17 Dec '03

undescribe cypherpunks(a)toad.com cyber(a)ronet.com.br

1 0

16B_uys
by John Young 17 Dec '03

17 Dec '03

3-18-96. TWP: "FBI, CIA Try to Set Turf Rules as Bureau Branches Out." The growing FBI overseas contingent is establishing liaison relationships with foreign police and intelligence groups that already have relationships with CIA personnel. The FBI agents abroad also try to develop their own clandestine informants, sometimes recruiting individuals who work for the CIA or have been fired by it. At a gathering Feb. 3-4 in Davos, Switzerland, FBI Director Freeh met with six presidents, seven prime ministers and three foreign ministers. 16B_uys

1 0

Re: Judge blocks French ISPs from connecting to revisionist sites
by Phillip M. Hallam-Baker 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [Various holocaust revisionist crap deleted] Don't worry, it will very soon become impossible to block access to anything on the Web. I have a long record of opposing the holocaust revisionists. I have never attempted to prevent them putting their views forward. It is better to expose them and their lies. Winston Smith, Faust and co disappeared after we proved that they were the creations of one Dan Gannon. Attempting to cut off access and the conceit that the truth needs to be legislated merely plays into the facists hands. Any attempt to cut of service can be circumvented simply by connecting to a cache. Hensa in the UK (www.hensa.co.uk ?) run a very large one. There are also many caches run by US universities although for obvious reasons it is preferable for the French to go through a European one. And please, no more anonymous posts trying to persuade us that there is anything worth reading at these hate sites. The literary style is familiar enough that nobody should be fooled. Phill - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMU2UhSoZzwIn1bdtAQFuqAGAxBfCOiZ1LKPIXLdE7OAJnabXlv1rxShW bW7DwF16+4rjLdm9ZahdS/X0NAMS1Oum =ySHM -----END PGP SIGNATURE-----

2 1

MLM and Web of Trust
by Black Unicorn 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On Tue, 7 May 1996, Hal wrote: > I have a few thoughts relating to the "web of trust" versus > hierarchical key certificate systems. This description is pretty > elementary and is intended more for people who have not been familiar > with the issues before. First some background. [Excellent background deleted] [Trust is not transitive.] > The [trust is not transitive] situation reminds me of a maxim of > multi-level marketing (MLM) companies like Amway. These businesses > typically sell a product, but they use a pyramid scheme for distribution > where people not only sell the product, but try to recruit others to > sell for them. [...] > To achieve success, though, the saying goes like this: You not only > have to sell; you not only have to teach your people to sell; but you > have to teach your people to teach people to sell. [...] > The analogy to transitivity of trust is this. If you want to have > transitive trust, you have to be sure the other person knows how to > securely sign keys. But you also have to make sure he knows how to > make sure that the next person knows how to securely sign keys. And > further you have to make sure he knows how to make sure the next guy > knows how to make sure, and so on. [PGP avoids transitive trust because of this problem and others] Ok, so if the problem is with transitive trust and not the technical issue of security of signatures, why not a hybrid of the vertical and web models? PGP's primary problem in my view is that signatures are not flexible enough, or they are too flexible. A signauture can mean anything. When I sign a document signed by Bob, does that mean that I am vouching for Bob as the author of this document, or that I agree with the document, or that I certify that the document (regardless of my belief in its points) merely passed by my desk on this date? Similarly, when I sign a key. Am I of the opinion that the "real name" associated with this person is the only person in possession of the key, of the opinion that this person is indeed (insert real name here) or am I siging off on the e-mail address? It seems to me that two things need to happen to improve the web of trust. First, signatures have to be application specific. Sure you can put the words "This signature means that I believe XYZPDQ etc." at the bottom of that which you are signing, but this method both lacks any kind of standardization and further requires some sophisticated logical thinking and a lot of planing by the average user. I'd much rather see signature applications integrated in the software in a simple way. PGP currently asks: READ CAREFULLY: Based on your own direct first-hand knowledge, are you absolutely certain that you are prepared to solemnly certify that the above public key actually belongs to the user specified by the above user ID (y/N)? Why should PGP not also ask: READ CAREFULLY: Based on your own direct first-hand knowledge, are you absolutely certain that you are prepared to solemnly certify that the above document is accurate in all respects (y/N)? or READ CAREFULLY: Based on your own direct first-hand knowledge, are you absolutely certain that you are prepared to solemnly certify that the above user is a careful and competent individual with the skill and means to secure his secret key (y/N)? or READ CAREFULLY: Based on your own direct first-hand knowledge, are you absolutely certain that you are prepared to solemnly certify documents signed by the above key are from the internet address associated with it (y/N)? or READ CAREFULLY: Based on your own direct first-hand knowledge, are you absolutely certain that you are prepared to solemnly certify that the above financial transaction corresponds to your exact wishes (y/N)? or READ CAREFULLY: Based on your own direct first-hand knowledge, are you absolutely certain that you are prepared to solemnly certify that the above user is not only a trusted introducer, but is fit in your estimation to gague the security and signing skills of other users and vouch for their fitness as trusted introducers (y/N)? It seems to me that integrating these issues, having a developer think them out ahead of time for the user would be a valuable thing. This solves, to some degree, Mr Finney's "AOL" problem. (Wherein he expresses concern over the differing skills of internet users and the ways these difference complicate the web of trust). Part of having an effective web of trust is defining exactly what a certification means. I don't think the web of trust fails because it is non-vertical, but because it fails to define what certificates mean. It _imposes_ (or at least suggests) horizontal decision or treatment of a certificate when it may be prudent for novice or moderately skilled users to treat them vertically. Yet to simply switch to a vertical scheme will frustrate expert users who wish to maintain the flexibility of a horizontal one for whatever reason. (They don't trust institutions, prefer to have more stringent or otherwise non-standard certification policies, etc.) Using certification that allows either (but perhaps defaults to vertical) can easily be envisaged. Software could be configued to trust only a institutional certifier to designate trusted introducers as a default, (Perhaps an online security mutiple test would be a good way for such an institution to make the determination?) and yet users who wanted other schemes could select the more expert options and designate their own introducers and introducer introducers. READ CAREFULLY: Do you trust the above user to (enter all that apply): A) Introduce other keys for the purposes of secure communications and document certification with those keys? B) Vouch for the security consciousness of other users? C) Vouch for the fitness of other users to certify introducers for your web of trust? D) Vouch for the financial fitness of other users? (etc.) Really it's no more than an extension of the "trust bit" that is already in PGP signatures to other areas. In addition I think it's important to extend this kind of flexibility to all manner of signing activites. I revoked a key some time ago because it was getting old and because 2048 bit keys were made available. That revocation certificate could mean anything. It could mean I KNOW it was compromised, it could mean I suspected it was, it could mean I found my secring.pgp file on a multiuser system where I did not myself put it, it could mean I left a disk with my secring.pgp on it in a library, or it could mean the key expired. How are you to know unless I write up a complicated statement and sign it and take pains to publish it all over creation? Why doesn't PGP simply ask: Are you: A) Certain this key is compromised? B) Of the view that it is probably compromised? C) Worried it might be compromised? D) Revoking this key because it is expired? E) Issuing a general/non-specific revocation? Again, standardized, easy for the user to understand, easy to distribute, and very clarifying. Someone could easily write a module which defined and updated these differing trust issues for PGP and users could pick the codes they prefered. (A trust model flash rom?) fincer - Certification with respect to financial integrity ident1 - Certification with respect to true name identity ident2 - Certification with respect to accuracy of e-mail account secrt2 - Certification with respect to the users ability to keep a secret. etc. Don't force clever and sophisticated users to bow to a vertical system when they don't have/want to. > Hal Finney - --- My preferred and soon to be permanent e-mail address:unicorn@schloss.li "In fact, had Bancroft not existed, potestas scientiae in usu est Franklin might have had to invent him." in nihilum nil posse reverti 00B9289C28DC0E55 E16D5378B81E1C96 - Finger for Current Key Information Opp. Counsel: For all your expert testimony needs: jimbell(a)pacifier.com -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMY/SZmqgui0rHO4JAQFkfwP/XqGH79Z0HX0fF8FvtrxAZB5JbnaMi3K4 gwt1zlQD8ni3n8+6fD887u6vyqxwty8AuQ4BwdxfPfFNecfgcZ8BHv8F1aMopV1x 4clVrHknaKo1BR83MEiEpN74yFebj0fsTlLxijLDbUA5z33Spmcn5Eek21nv4yXR W1ZWUd5uSIk= =vpLU -----END PGP SIGNATURE-----

1 0

Re: Escrowing signing vs. encryption keys
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"JMKELSEY(a)delphi.com" 7-MAY-1996 01:22:19.14 >this is seen by the Feds to balance out the downside that, if I have >the ability to do secure signatures with certificates, I can always >use Diffie-Hellman to establish a secure session with someone else. This apparant opinion on their part is made more understandable with the headaches involved in using Diffie-Hellman, as I understand it (multiple back-and-forth transfers, et al). -Allen

1 0

No Subject
by Anonymous 17 Dec '03

17 Dec '03

At 07:01 AM 9/23/98 -0500, Bruce Schneier wrote: > >Sorry. I am under NDA. Be sure to drink plenty of fluids and get plenty of rest afterwards; that stuff wears you out ;-)

1 0

No Subject
by Black Unicorn 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On Tue, 7 May 1996, E. ALLEN SMITH wrote: > From: IN%"unicorn(a)schloss.li" "Black Unicorn" 29-APR-1996 02:21:48.23 > > >On Sun, 28 Apr 1996, E. ALLEN SMITH wrote: > > >> Given discussions as to attorneys holding passphrases, et al, perhaps > >> a tutorial from the lawyers on the list (yourself and others, since > >> disagreements among J.D.'s have been known to happen) on what attorney-client > >> confidentiality does cover? > > >Proposed FRE 503 probably has the best codification of the prevailing > >common law on the subject. I reproduce it in part below. Typos are mine. > > Thank you. Sure. > >The identity of the client and the existance of the attorney client > >relationship are not confidential. There are some exceptions. > > What are the exceptions? When a client wishes to make anonymous restitution. Baird v. Koerner, 279 F.2d 623 (9th Cir. 1960) (Wherein attorney was retained to organize anonymous payment of delinquent taxes and IRS demmanded identification of clients by attorney). The so called "missing link" exception, where where disclosure of the identity of client, in conjunction with already available information, would have the effective result of disclosing a privileged communication or violating the privilege against self incrimination. In re Grand Jury Proceedings, 517 F.2d 666 (5th Cir. 1975); C.f., U.S. v Pape, 144 F.2d 778 (2nd Cir. 1944) (Holding that client's identity was not so protected, but which may or may not still be good law); See Generally, Cleary et al, McCormick on Evidence (3rd edition 1984). > >Stolen property may be held by an attorney for a reasonable time for > >inspection purposes, but must be returned to the rightful owner or the > >attorney will be a receiver of stolen goods and participating in an > >ongoing crime. Privilege will thus not apply. In re Ryder, 263 F.Supp. > >360 (E.D.Va 1967). (Some courts will permit the attorney to refuse to > >disclose the source from which he obtained the property, however). > >Consider this in the context of trade secrets. > > A good point... although if it hasn't been proven whether something is > stolen (e.g., an encrypted piece of data sent to the attorney), I would hope > that privilege would still obtain. Of course, there would be the question > (also important for First Amendment issues) of whether information that the > recipient can't understand is communication. Generally speaking, if the attorney believes or should reasonably know that the item was stolen, privilege will not apply. > >All states have laws against destroying or concealing evidence. The > >attorney who advises his client to destroy evidence is a co-consiprator. > >Privilege does not apply. Clark v. State, 261 S.W.2d 339 (Crim. App Tex. > >1953). (Interesting to wonder if advising a client to encrypt evidence is > >'concealing' it). > > A good question. Of course, again there's the point of what if the > attorney has investigated the matter and decided that no crime is being > committed, but that the material should be destroyed because it could be > embarrasing, lead to other problems (e.g., civil lawsuits), etcetera. If a > court later decides that the attorney was wrong, would privilege still obtain, > and would the attorney be a co-conspirator? I would hope the answers would be > yes and no. First question, I can think of few attornies who would actually advise a client to destroy something that might even one day possibly be evidence. Well, let me rephrase that. I can think of few attornies who would actually advise a client to destroy something that might even one day possibly be evidence if they thought they might be caught. Second question, If the court thinks it was a crime and evidence was destroyed it doesn't much matter what the attorney thought at the time. I'll have to check, but this is probably a "reasonably forseeable" question. On Confidentiality: See Generally, Fred Zacharias, Rethinking Confidentiality, 74 Iowa L. Rev. 351 (1989); Fred Zacharias, Rethinking Confidentiality II, 75 Iowa L. Rev. 601 (1990); Geoffrey Hazard, A Historical Perspective on the Attorney Client Privilege, 66 Calif. L. Rev. 1061 (1978); Developments in the Law: Privileged Communications, 98 Harv. L. Rev. 1450 (1985). -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMY//fmqgui0rHO4JAQGDXQQAvSuhnF5SAHTfGd/EhDH2DMNKd8IquqED FGvD0QrEU+3jzNlNKouqnG0SSsP6ILDpUnwDr6ZvGSrc147Kvf37fP6EIMeqGG6A 7wFfrDrr7Lo/96VXnY6Sd9mI5evxDoUDPr6PS+1rbW2le5s8q0mI6C+cFXM5TDEo jY4mQqePufc= =syxB -----END PGP SIGNATURE----- --- My preferred and soon to be permanent e-mail address:unicorn@schloss.li "In fact, had Bancroft not existed, potestas scientiae in usu est Franklin might have had to invent him." in nihilum nil posse reverti 00B9289C28DC0E55 E16D5378B81E1C96 - Finger for Current Key Information Opp. Counsel: For all your expert testimony needs: jimbell(a)pacifier.com

1 0

Re: ecash payee anonymity, cpunk archives
by jim bell 17 Dec '03

17 Dec '03

At 05:36 PM 5/7/96 -0500, Alex Strasheim wrote: >A while back someone posted a note saying that an ecash protocol >garaunteeing payee as well as payer anonymity had been devised. I think that was about a week before Colby disappear, wasn't it? B^) Jim Bell jimbell(a)pacifier.com

1 0