- cypherpunks-legacy@lists.ogf.org

Crypto goals
by Marc.Ringuette＠GS80.SP.CS.CMU.EDU 10 Feb '93

10 Feb '93

Y'know, just defining "what we should want" is one of the biggest challenges in moving towards the next generation of crypto. How about making a list of features we want, and/or a list of scenarios we want to be able to handle? Uncontroversial features: message privacy message anonymity message untraceability digital cash digital time stamps More difficult/controversial features: message invisibility [e.g. in low bits of video signal] untraceable access to databases [just anonymous email?] electronic black markets [just electronic cash and anonymous email?] electronic voting m-of-n trust schemes time-delay messages [are they useful?] executable but non-disassemblable code [is it possible?] tagging / un-tagging of copyrighted text [what is possible?] [explanation to follow in another message ] I know how to take a crack at implementing all of these except the last two, but would benefit from better theoretical and practical work on all of them. Most of them are obviously useful, and scenarios come easily to mind. Have I missed anything? -- Marc Ringuette (mnr(a)cs.cmu.edu)

1 0

Re: timed-release crypto
by Karl Barrus 10 Feb '93

10 Feb '93

Tim May writes: >...I could publicly post an encrypted message to this list, or in one >of the "pools," and then scatter the decryption key in several pieces >with several members of this list, paying them $1 each to "hold" their >piece for, say, a month. At the end of the month, they would fulfill >their end of the bargain by forwarding the piece they hold to some >public place or pool and the decryption key would be reconstituted... Cypherpunks, this is an experiment we can try right here right now. We certainly have the anonymous mail facilities, pools, and encryption, as well as a digital bank we could use to "pay" people :-) Splitting a decryption key is fairly easy: we could use the simple XOR method. Say you want to encrypt a message of length m and split the key among n people. Choose n-1 sequences of m random bits (coin flips, cryptographically strong pseudo-random number sequences, etc) and XOR the message with all the random sequences (call the result M'). Then your split secret is the M' and the n-1 sequences. To recover the message, calculate the XOR of M' and the n-1 sequences. Providing for an n-out-of-m scheme takes more work and number theory, but that can be done as well. /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/

1 0

Speaking in Tongues
by deltorto＠aol.com 10 Feb '93

10 Feb '93

>>From: dmandl(a)shearson.com >>Subj: Re: E Pluribus Unum >> >>> From: deltorto(a)aol.com >>> >>> Fellow Cyphers, >>> >>> Eric Hughes contributed: >>> >>I applaud the Clinton administration for making itself available via >>> >>email. I do not think it advisable, however, to send a single >>> >>cypherpunks letter. Rather I urge all interested parties to compose >>> >>their own letters [etc., etc., etc., etc.] >> >>I think I've held my tongue long enough. Hmmmm. Perhaps not. :-D ddt PS: I can't afford six months, but I like (the symbolism of) the idea. There are much more effective ways of pulling their plug, no?

1 0

E Pluribus Unum
by John.Nieder＠f33.n125.z1.FIDONET.ORG 10 Feb '93

10 Feb '93

* Reply to msg originally in Cypherpunks BK> From: deltorto(a)aol.com BK> I believe that sending a BK> powerful concise letter _together_ makes it more likely that it will BK> be read, and even more likely that it will be responded to. Otherwise, BK> we're just a bunch of nutty "individuals." Well, while I am personally of the opinion that this undertaking is of neglible value for the sweat expended anyway, I would suggest that the eventual note (if any) not presume to represent anyone but the individual signatories. BK> On the other hand I am repenting my suggestion that we _might_ include BK> anything political in our missive. Good. The surreal laundry-list of crackpot causes in CPSR's written agenda has gained them my absolute opposition & has probably turned off others as well. It would be a mistake for Cypherpunks to drag in outside issues. BK> I don't think it should be "cutesy" Of course not. There's no quicker way to the bit bucket, assuming this entire e-mail flap isn't a bad joke in the first place. >>Stress privacy, and technological defenses thereto. BK> I agree. Me three. BK> Especially the technological expertise side, as this is what BK> differentiates us from the mass of other people crying about privacy. A good point! Nothing impresses bureaucrats like "experts" [cough!]. >>5) Offer to help. Offer to make timely review of proposed policies. >>If they accept your aid, keep your promises. BK> This is my favorite suggestion. Imagine if they gave us all jobs at BK> the NSA. Heh-heh-heh. You wouldn't like it. BK> Now, I have a general question: what is the current status of the BK> White House email capability as far as everyone can tell? Has anyone BK> had a response yet, by email or snailmail? Is there a possibility that BK> this IS a hoax and that we should just send paper mail instead? Check my previous message. JN ... Source: "Another Burned-Out Spook for Peace," S.F., CA --- Blue Wave/Opus v2.12 [NR] -- John Nieder - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!33!John.Nieder INTERNET - John.Nieder(a)f33.n125.z1.FIDONET.ORG

1 0

The role of pools
by Miron Cuperman 10 Feb '93

10 Feb '93

A pool is used for *replying* to anon mail. The problem is that it's hard to build a system that allows replies to anon email and still maintains absolute security. One way is to broadcast the reply. A pool does just that - it's basically a mailing list. It could be a newsgroup. Since any of the subscribers to the pool could be the intended recipient of any particular message, it would be very hard to use the pool to trace the anonymous recipient. -- Miron Cuperman <miron(a)extropia.wimsey.com> | NeXTmail/Mime ok <miron(a)cs.sfu.ca> | Public key avail AMIX: MCuperman | cyberspacecomputingcryptoimmortalitynetworkslaissezfaire

1 0

["Joyce K. Reynolds": RFC1422 on Certificate-Based Key Management]
by fen＠genmagic.genmagic.com 10 Feb '93

10 Feb '93

Date: Tue, 09 Feb 93 20:46:59 -0500 From: James M Galvin <galvin(a)TIS.COM> Sender: pem-dev-relay(a)TIS.COM -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,SdwD9j3bEJftgUxTr4Oxa2StKH4giFOjvS5ey4B578J pEMgQYtXDXhzX4eNKmV23FducCqWXBaOHL2zvK7jK5A== - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info(a)tis.com". - ------- Forwarded Message Message-ID: <199302092258.AA00113(a)zephyr.isi.edu> Sender: ietf-announce-request(a)IETF.CNRI.Reston.VA.US From: "Joyce K. Reynolds" <jkrey(a)isi.edu> To: IETF-Announce:;@IETF.CNRI.Reston.VA.US cc: jkrey(a)isi.edu Date: Tue, 09 Feb 93 14:56:39 PST Subject: RFC1422 on Certificate-Based Key Management - - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1422: Title: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management Author: S. Kent Mailbox: kent(a)BBN.COM Pages: 32 Characters: 86,085 Obsoletes: RFC 1114 This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. This memo is the outgrowth of a series of meetings of the Privacy and Security Research Group of the Internet Research Task Force (IRTF) and the Privacy-Enhanced Electronic Mail Working Group of the Internet Engineering Task Force (IETF). The author would like to thank the members of the PSRG and the PEM WG for their comments and contributions at the meetings which led to the preparation of this document. The author also would like to thank contributors to the PEM-DEV mailing list ("pem-dev(a)tis.com") who have provided valuable input which is reflected in this memo. This is now a Proposed Standard Protocol. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST(a)NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info(a)ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info(a)ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC(a)NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR(a)ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server(a)nisc.sri.com" Content-Type: text/plain SEND rfc1422.txt - - --OtherAccess Content-Type: Message/External-body; name="rfc1422.txt"; site="nic.ddn.mil"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain - - --OtherAccess-- - - --NextPart-- - ------- End of Forwarded Message -----END PRIVACY-ENHANCED MESSAGE-----

1 0

["Joyce K. Reynolds": RFC1424 on Key Certification and Related Services]
by fen＠genmagic.genmagic.com 10 Feb '93

10 Feb '93

Date: Tue, 09 Feb 93 20:47:53 -0500 From: James M Galvin <galvin(a)TIS.COM> Sender: pem-dev-relay(a)TIS.COM -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,ev2s1woCBNlMsuccJpIUAAEuV9gQZZs5hbHG3fCPYxb hxSChOjQSJRO3cIf6/GyzyJYhRt7jZDc9VH+YLuPMeg== - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info(a)tis.com". - ------- Forwarded Message Message-ID: <199302092258.AA00165(a)zephyr.isi.edu> Sender: ietf-announce-request(a)IETF.CNRI.Reston.VA.US From: "Joyce K. Reynolds" <jkrey(a)isi.edu> To: IETF-Announce:;@IETF.CNRI.Reston.VA.US cc: jkrey(a)isi.edu Date: Tue, 09 Feb 93 14:56:52 PST Subject: RFC1424 on Key Certification and Related Services - - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1424: Title: Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services Author: B. Kaliski Mailbox: burt(a)rsa.com Pages: 9 Characters: 17,537 Updates/Obsoletes: none This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM): key certification, certificate- revocation list (CRL) storage, and CRL retrieval. This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. This document is the product of many discussions at RSA Data Security, at Trusted Information Systems, and on the <pem-dev(a)tis.com> mailing list. This document is the product of the Privacy-Enhanced Electronic Mail Working Group. This is now a Proposed Standard Protocol. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST(a)NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info(a)ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info(a)ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC(a)NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR(a)ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server(a)nisc.sri.com" Content-Type: text/plain SEND rfc1424.txt - - --OtherAccess Content-Type: Message/External-body; name="rfc1424.txt"; site="nic.ddn.mil"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain - - --OtherAccess-- - - --NextPart-- - ------- End of Forwarded Message -----END PRIVACY-ENHANCED MESSAGE-----

1 0

["Joyce K. Reynolds": RFC1423 on PEM: Algorithms, Modes and Identifiers]
by fen＠genmagic.genmagic.com 10 Feb '93

10 Feb '93

Date: Tue, 09 Feb 93 20:47:29 -0500 From: James M Galvin <galvin(a)TIS.COM> Sender: pem-dev-relay(a)TIS.COM -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,SZBZEw1TKP4Mj68wVUb3t1uGaXKAhRfRScqDkULDMuG WRwco4HpFmpJxuBUzPLhysLhi0Rn6D9yG+YxFnZE4bA== - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info(a)tis.com". - ------- Forwarded Message Message-ID: <199302092258.AA00118(a)zephyr.isi.edu> Sender: ietf-announce-request(a)IETF.CNRI.Reston.VA.US From: "Joyce K. Reynolds" <jkrey(a)isi.edu> To: IETF-Announce:;@IETF.CNRI.Reston.VA.US cc: jkrey(a)isi.edu Date: Tue, 09 Feb 93 14:56:45 PST Subject: RFC1423 on PEM: Algorithms, Modes and Identifiers - - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1423: Title: Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers Author: D. Balenson Mailbox: balenson(a)tis.com Pages: 14 Characters: 33,277 Obsoletes: RFC 1115 This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. This document is the outgrowth of a series of meetings of the Privacy and Security Research Group (PSRG) of the Internet Research Task Force (IRTF) and the PEM Working Group of the Internet Engineering Task Force (IETF). This is now a Proposed Standard Protocol. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST(a)NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info(a)ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info(a)ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC(a)NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR(a)ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server(a)nisc.sri.com" Content-Type: text/plain SEND rfc1423.txt - - --OtherAccess Content-Type: Message/External-body; name="rfc1423.txt"; site="nic.ddn.mil"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain - - --OtherAccess-- - - --NextPart-- - ------- End of Forwarded Message -----END PRIVACY-ENHANCED MESSAGE-----

1 0

["Joyce K. Reynolds": RFC1421 on Privacy Enhancement for Electronic Mail]
by fen＠genmagic.genmagic.com 10 Feb '93

10 Feb '93

Date: Tue, 09 Feb 93 20:46:25 -0500 From: James M Galvin <galvin(a)TIS.COM> Sender: pem-dev-relay(a)TIS.COM -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,UYBpHzD3lP5l8Wi2DzdTRPWoag3lQ7NrqmF0U+cfykK VCKx5jxPRR9CaWaddI5QobfpA4hsIVA12ZpsPzmyo9g== - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info(a)tis.com". - ------- Forwarded Message Message-ID: <199302092257.AA29999(a)zephyr.isi.edu> Sender: ietf-announce-request(a)IETF.CNRI.Reston.VA.US From: "Joyce K. Reynolds" <jkrey(a)isi.edu> To: IETF-Announce:;@IETF.CNRI.Reston.VA.US cc: jkrey(a)isi.edu Date: Tue, 09 Feb 93 14:56:08 PST Subject: RFC1421 on Privacy Enhancement for Electronic Mail - - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1421: Title: Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures Author: J. Linn Mailbox: 104-8456(a)mcimail.com Pages: 42 Characters: 103,894 Obsoletes: RFC 1113 This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. This document is the outgrowth of a series of meetings of the Privacy and Security Research Group (PSRG) of the Internet Research Task Force (IRTF) and the PEM Working Group of the Internet Engineering Task Force (IETF). The author would like to thank the members of the PSRG and the IETF PEM WG, as well as all participants in discussions on the "pem-dev(a)tis.com" mailing list, for their contributions to this document. This is now a Proposed Standard Protocol. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST(a)NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info(a)ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info(a)ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC(a)NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR(a)ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server(a)nisc.sri.com" Content-Type: text/plain SEND rfc1421.txt - - --OtherAccess Content-Type: Message/External-body; name="rfc1421.txt"; site="nic.ddn.mil"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain - - --OtherAccess-- - - --NextPart-- - ------- End of Forwarded Message -----END PRIVACY-ENHANCED MESSAGE-----

1 0

Re: CELP speech compression code at cygnus.com:/pub/celp.speech.tar.Z
by wcs＠anchor.ho.att.com 10 Feb '93

10 Feb '93

Forwarded for Bill Stewart, who I assume wanted it posted. Eric ----------------------------------------------------------------------------- John, Perry, and others have been commenting on the use of CELP voice compression and crypto with V.32 or better modems to give end-to-end encrypted speech. Perry says: > Fast enough software compression of voice would mean any PC > with a DSP card and a V.32 modem could become an unbreakable scrambler. > The chief problem is that the DSP needed to do decent compression is > very crunchy, and encryption also tends to be crunchy, so there aren't > typically enough cycles on your average PC. Of course, were someone to > commercially market a board that did all this in hardware... (Please excuse any shameless references to my employer's fine hardware products :-); I do science fiction, er, um, systems engineering, not hardware... and it's been a while since our chip people were in my building.) It may not all be packaged on a single board, but it shouldn't be real tough. PC and Mac Boards with AT&T DSP32C chips were out several years ago, which provided something like 25 MFLOPS, which was more than enough to do voice compression and have leftover guts for crypto (or use your 386; DES at 9600 baud shouldn't cause much heartburn.) I assume that by now there are reasonably-priced floating-point DSP boards from several different vendors out, and AT&T makes modem chipsets and supporting A/D and fixed-point DSP integer-crunchers. If CELP can be done in integers, I'd guess you could chain together a couple DSPs and put together a board for ~$100-150 parts-cost. Also, how much can you do with the various SoundBlaster-related boards? Bill

1 0