- cypherpunks-legacy - lists.cpunks.org

Coming Soon: Commercial version of PGP!
by Philip Zimmermann 25 Aug '93

25 Aug '93

Coming Soon: Commercial Version of PGP! Philip Zimmermann has signed an agreement with ViaCrypt, a division of Lemcom Systems, Inc, to sell a commercial version of PGP. ViaCrypt is a company in Phoenix Arizona that already has an RSA license from Public Key Partners to sell products that use the RSA algorithm. The freeware version of PGP will still be available, and will be maintained as well as the commercial version. Most corporations were not willing to use PGP because it was not licensed by PKP or RSA Data Security. With this commercial version of PGP, it will be possible for PGP to enter commercial environments for the first time, and compete with other products such as PEM. This is expected to enhance PGP's viability as a de facto standard in the long run. ViaCrypt PGP will be available in the USA and Canada, for an introductory price of $100 for a single user, with quantity discounts available. For details, call ViaCrypt at (602) 944-0773, or contact Philip Zimmermann at prz(a)acm.org.

2 1

Digital Coin Claim
by hnash＠mason1.gmu.edu 25 Aug '93

25 Aug '93

The first certificate attached to this message is a claim to ownership of the first digital gold coin. Some anonymous person is claiming ownership of this coin simply because no one else has claimed it. This original owner has signed a deed granting ownership of the coin to himself. The second attached certificate is a transfer of ownership of the same digital coin. The first owner has granted ownership of the coin to some other anonymous person (who could be the original owner himself). If someone tries to offer you coin #1 in exchange for some good or service, make sure his signature matches the public key in the latest deed of ownership of coin #1. (The first public key is now worthless, by convention.) -----BEGIN PGP SIGNED MESSAGE----- <>-<>-<> Deed of Ownership <>-<>-<> The following digital coin is hereby granted to the owner of the following alias by the signer of this deed. coin #1 - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQA/Aix7OzAAAAEBgNeA+IZOQOmczjSUMiWaMTnkZLDYCA1XGzxjnXTiYA1/LVpN SkUywA+kGfe9cCuaQQARAQABtAlhbm9ueW1vdXM= =YrPq - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.3 iQBFAgUBLHtQdYuK85NmoAdhAQHevwF+OOZEZHUjDADYBaM5EQvDbfCTTEskX2kr aA46cE2GaZBPV5JdyjR+dnNwRXHfug0M =z9OC -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- <>-<>-<> Deed of Ownership <>-<>-<> The following digital coin is hereby granted to the owner of the following alias by the signer of this deed. coin #1 - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQA/Aix7SWsAAAEBgLanVXE9dTkrDCAWOt1Dw3bhLSIGMVweD1zifEpiDIWRZzXO Sl22i4YVPmeLvfdL3QARAQABtAVhbm9uMg== =5fkK - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.3 iQBFAgUBLHtQo4uK85NmoAdhAQEF9QF/aB6iX/bwXn6HEerJrOzES0VTpxsybC9L L++CIvjbDLBXmgPzXClGuGKg5t+urJ8J =Jabu -----END PGP SIGNATURE-----

1 0

link
by Kevin Reynolds 25 Aug '93

25 Aug '93

Is anyone currently porting link to msdos? I have the ability, but it may take me a while to do so, so if anyone is already doing it, I'd rather not overdo it. The file is available from soda.berkeley.edu in /pub/cypherpunks. Check it out. kev

1 0

Re: Bank misbehavior (was: Re: No digital coins?)
by plmoses＠unix.cc.emory.edu 25 Aug '93

25 Aug '93

Maybe someone has said this, but another key way to foster privacy is to START A BANK that values this. I recal some references to Swiss banking, anonymous accounts, etc, before. So wouldnt it be a good idea to find some bankers out there who wanted to create a niche market for themselves, and sell them on the crypto-protocols? First suggestion: try Miami.... - paul

1 0

Re: Attacks on remailers
by remail＠tamsun.tamu.edu 25 Aug '93

25 Aug '93

Hal Finney writes a nice "To Do" list for the cypherpunks remailers by enumerating and describing possible attacks. Let's priortize these items. First we should do those items that are easy to implement, and those items needed to prevent any remaining cheap 'n easy attacks. We can leave expensive attacks for future projects. > Response: Encrypt the messages. Use "nesting", so that all that is > visible as each message leaves a remailer is the destination of the > next remailer. This should be made smoother. The learning curve needed to get to this stage : install PGP & get it working, learn how to use remailers, install remailer nesting script, debug all of the above, because something in there is bound to break at this stage : quite a lot of work! Just improving things up to here with clearer documentation, and better scripts and GUIs, would greatly increase the number of remailer users and traffic. > Response: Run the remailer on a machine which does not keep mail logs, > or on a machine to which you can deny the attackers access. The former is much to be preferred! The first link in the remailer chain, especially, needs to be trusted not to maintain logs. The trustworthy remailer operator goes to great lengths to minimize the temptation to look at messages. >[Attack 3: timing & ordering of messages in & out] >[Attack 4: look at subject line, message size, etc.] >[other attacks involving intercepting mail stream] Batching and random delays only work well if there is large message traffic through the remailer. What in specific detail is needed to gain access to the mail stream to make these attacks? If no mail logs are kept, and the remailer denies access to a spool file, by hiding it or putting random garbage in it or denying access to its host computer, an attack looks to me like it requires a sophisticated wiretap. Avoiding expensive attacks is low priority at this point. >[Message pools] have the problem that they expose everyone > in some group to all of the messages intended for every group member, > hence the number of messages will scale as the square of the number of > group members. First let's make the problem happen. Then we can solve it! Here's another item: faster links! The delay between when I post this and when it arrives on "cypherpunks" can be half a day. What about that idea of using direct sockets instead of SMTP between remailers? That could kill two birds with one stone: delivery speed and cheap attacks against the intermediate links via logging or spool files.

2 1

Blinding messages (newbie questions)
by nobody＠shell.portal.com 25 Aug '93

25 Aug '93

>[Karl Barrus describes blinding] Excellent post! Can you tolerate a few newbie questions? > Conceptually, when you blind a message, nobody else can read it. So "blinding" is a synonym for encryption with your own public key, aka multiplication by a very-hard-to-factor number? > under the right circumstances if another > party digitally signs a blinded message, the unblinded message will > contain a valid digital signature. In other words if Alice encrypts and Bob signs, Da(Db(Ea(M))) = Db(M)? Under what conditions? Does RSA (in PGP) satisfy those conditions? > If someone asks > you to digitally sign a random stream of symbols, remember that what you > sign may be unblinded to reveal a contract, etc. For what applications would Bob want to sign an encrypted contract instead of a plaintext?

1 0

Re: No digital coins (was: Chaum on the wrong foot?)
by nobody＠shell.portal.com 25 Aug '93

25 Aug '93

If your goal is only privacy of personal information not economic privacy you would do better to support Clipper-like systems (such as DigiCash with an IRS-Tax Backdoor). Supporting untracable perfectly secure cash will make taxation and state economic planning hard if not impossible. It is contradictory for a liberal to support DigiCash, Strong Cryptography, etc because effective collective coercion requires personal information. All you have to do is take perfect anonymity to its natural conclusion and you see where it leads. (and it ain't socialism)

1 0

16th NCSC meeting Sep 20-23 1993 announcement
by L. Detweiler 25 Aug '93

25 Aug '93

>From Risks 14.86 Aug 24 1993 This is a Spook Central meeting, so the topics given are interesting `signal intelligence' on what's on the NSA^D^D^DNIST's mind at the moment. Also, it suggests what companies have active consulting & production arrangements with NSA (MITRE, Motorola, etc.). What's on their mind: hierarchical security systems (antithetical to the subversive PGP `web of trust'), distributed/network security, CLIPPER, `publishing work', (read: restrictions on cryptographic topics in journals?), `security requirements for cryptographic modules' (read: restrictions on cryptographic device export?) `International harmonization' by a Frenchman (hehe, sounds a lot like `Ministry of Truth'), a probable codeword for International Cryptographic Restriction. Acronyms: TPEP, TTAP -- sound big, what are they? Some kind of U.S. government `evaluation paradigms'. Again, probably for crypto-device export. Interesting presentations by spook outsiders & wannabes: virus attacks, `Security & Auditability of Electronic Voting Systems', `Privacy Impact of technology in 90's', `Electronic Crime Prevention & Investigation' Hopefully, some patriotic cypherpunk can sneak in and smuggle out a report! ------------------------------ Date: Thu, 19 Aug 93 12:32 EDT From: Reiner(a)DOCKMASTER.NCSC.MIL Subject: NCSC 16 Announcement for RISKS 16TH NATIONAL COMPUTER SECURITY CONFERENCE Dates: 20-23 September 1993 Location: Baltimore Convention Center Baltimore, Maryland Registration fee: $275 The National Computer Security Center and the National Institute of Standards and Technology will present the 16th National Computer Security Conference from 20-23 September at the Baltimore Convention Center. This year's three and one-half day program features tracks in : Research & Development; System Implementation; Management & Administration; Criteria & Evaluation; Tutorials & Other Presentations. aA summary of the technical program follows. To obtain more information about the technical program send a message to NCS_Conference at DOCKMASTER.NCSC.MIL or call the NCSC on 410-859-4371. To obtain a registration form, call the Conference Registrar at 301-975-2775 or send a message to NCS_Conference at DOCKMASTER.NCSC.MIL TECHNICAL PROGRAM SUMMARY: R&D TRACK PANELS - Strategies for Integrating Evaluated Products Chair: J. Williams, MITRE - Multilevel Information System Security Initiative Chair: G. Secrest, NSA - Trusted Applications Chair: J. Cugini, NIST - Best of the New Security Paradigms Workshop II Chair: H. Hosmer, Data Security Inc. - Enterprise Security Solutions Chair: P. Lambert, Motorola PAPER SESSIONS - Honesty Mechanisms Chair: E. Boebert, SCTC - Database Research Chair: M. Schaefer, CTA - Access Control Chair: P. Neumann, SRI SYSTEM IMPLEMENTATION TRACK Panels: - Perspectives on MLS System Solution Acquisition Chair: J. Sachs, ARCA - Network Management -- The Harder Problem Chair: R. Henning, Harris Corp. - Application of INFOSEC Products on WANs Chair: J. Capell, Lockheed - Security for the Securities Industry Chair: S. Meglathery, NYSE Paper Sessions: - Access Control Topics Chair: D. Balenson, TIS - Network Risks & Responses Chair: B. Burnham, NSA - Software Engineering Chair: V. Gibson, Grumman - System Engineering with OTS Products Chair: M. Tinto, NSA - Network Implementation Chair: F. Mayer, Aerospace Corp MANAGEMENT & ADMINISTRATION TRACK PANELS - Virus Attacks & Counterattacks: Real World Experiences Chair: J. Litchko, TIS - Terror at the World Trade Center Chair: S. Meglathery, NYSE - Contingency Planning in the 90s Chair: I. Gilbert-Perry, NIST - On a Better Understanding of Risk Management Techniques Chair: S. Katzke, NIST - Security Awareness, Training & Professionalization Chair: D. Gilbert, NIST - Accreditor's Perspective - How Much is Enough? Chair: J. Litchko, TIS - Security & Auditability of Electronic Voting Systems Chair: R. Mercuri, U. of Penn. - Protection of Intellectual Property Chair: G. Lang, Harrison Ave. Corp. - The Privacy Impact pof technology in the 90s Chair: W. Madsen, CSC - Electronic Crime Prevention & Investigation Chair: R. Lau, NSA PAPER SESSION - Managing & Promoting INFOSEC Programs Chair: D. Parker, SRI TUTORIALS & PRESENTATIONS TRACK Tutorials: - Threats & Security Overview A. Liddle, IRMC - Trusted Systems Concepts C. Abzug, IRMC - Trusted Networks R. Bauer, E. Schultz, ARCA - Trusted Databases G. Smith, W. Wilson, ARCA - Trusted Integration & System Certification J. Sachs, ARCA Panel Presentations: - CLIPPER Chip Chair: L. McNulty, NIST - Getting Your Work Published Chair: J. Holleran, NSA - INFOSEC Standards: The DISA Process Chair: W. Smith, DISA - Security Requirements for Cryptographic Modules; Chair: L. Carnahan, NIST CRITERIA & EVALUATION TRACK Presentations: - Introduction to the Federal Criteria G. Troy, NIST; D. Campbell, NSA - Federal Criteria: Protection Profile Development J. Cugini, NIST; M. DelVilbiss, NSA - Federal Criteria: Registration of Protection Profiles D. Ferraiool, NIST; L. Ambuel, NSA Panels - Federal Criteria: Protection Profiles for the 90s Chair: R. Dobry, NSA - Federal Criteria: Vetting & Registration of Protection Profiles Chair: L Ambuel, NSA - Evaluation Paradigms: Update on TPEP and TTAP Chair: S Nardone, NSA - European National Evaluation Schemes Chair: E. Flahavin, NIST - The European Evaluation Process Chair: P. Toth, NIST - International Harmonization I Chair: Y. Klein, SCSSI, France - Goals & Progress Toward the Common Criteria Chair: G. Troy, NIST - Federal Criteria User Forum Chair: C. Wichers NSA Plenary: "Information System Security Strategies for the Future" Chair: Stephen Walker Panel: James P. Anderson Dr. Willis Ware Dr. Roger Schell ------------------------------ End of RISKS-FORUM Digest 14.86 ************************

1 0

No Subject
by Gomes, Bill M'bio 25 Aug '93

25 Aug '93

Please subscribe me to the cypherpunks mailing list. Thanks.

1 0

Re: Digital Gold
by nobody＠soda.berkeley.edu 25 Aug '93

25 Aug '93

At 4:23 PM 8/24/93 -0400, hnash(a)mason1.gmu.edu wrote: > >I tried to imagine a digital currency which is not backed by >any bank, but just exists by mathematics and convention, like >gold. The result is the following currency system which >could be called digital gold. It involves three conventions, >(1) a convention for valuing coins, (2) a convention for >claiming coins, (3) a convention for transfering coins. > >I believe the resulting currency is unforgeable, >uninflatable, and untraceable. Let me know where I've gone >wrong (gently). I love this scheme, but I have two questions about it. 1) How will disputes be settled? >In order to claim a digital gold coin, the claimer must >publicize a "claim certificate", containing the signed >integer and the public key required to recognize the >signature. The first person to publicize a claim certificate >will be recognized as the owner. Some variant of the keyserver could be the public registry of gold. Can this be done in a reasonable way, where a large part of the transaction cost is not involved in verifying that the buyer really owns her cash? Is there some way to make this more like a web of trust? Can it be blinded in a way that maintains the trust but allows anonymous transactions? 2) Why should anyone value a digital gold coin in the first place? Money has value because of people's expectation (based on experience) that if they take it to a store they can buy stuff with it. Where will digital gold obtain its bootstrap value? Somebody has to start using it. My own feeling about how digicash will develop is that it will be added into an initially non-anonymous digital based debt clearinghouse. With PGP (etc.) we already have the means to create verifiable IOU's, contracts, loans, etc. (Is anyone using them?) If such IOU's were used widely but non-anonymously, it would require only a small innovation to move to anonymity (either through blinding, or use of agents with reputations, or ?). The problem is getting any kind of online action to begin with. (AMiX?)

1 0