December 2003 - cypherpunks-legacy

Well we tried.
by bart＠netcom.com 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Did Ames Disclose Clipper to Russians?
by Dave Banisar 17 Dec '03

17 Dec '03

Interesting yes? In article <2m7tpf$84(a)delphinium.cig.mot.com> Walter F. Lundby, lundby(a)rtsg.mot.com writes: > Hot off the presses: > > 3-14-94 Network World > Page 2, fourth article under "Briefs" > > Clipper compromisde? "Security Insider Report," a monthly > newsletter published in Seminole, Fla., has reported that > government officals are seeking to determine whether former > CIA employee and alleged traitor Aldrich Ames may have sold > informantion to the Russians about the government's secret > key-escrow technology userd in Clipper Chip chipsets and > Capstone Tessera cards. The secret key-escrow technology, > dubbed Skipjack, can be used to encrypt voice and data.

2 1

CFP `94 BOF Session?
by Duncan Frissell 17 Dec '03

17 Dec '03

I'll be in Chicago next week at CFP '94 and I wondered if anyone was planning an official or unofficial Cypherpunks gathering. I'd do a BOF session request but I'm there as a journalist. Anyone else interested? DCF --- WinQwk 2.0b#1165

1 0

No Subject
by matt＠staff.cs.su.oz.au 17 Dec '03

17 Dec '03

Does anyone have a list of anonymous remailers somewhere? matt

1 0

Re: Anonymous remailers
by Anonymous 17 Dec '03

17 Dec '03

> Does anyone have a list of anonymous remailers somewhere? > > matt ---------- Forwarded Message ---------- From: mg5n+remailers(a)andrew.cmu.edu (Automated reply from mail software) Subject: Info on anonymous remailers This info on internet anonymous remailers is maintained by Matthew Ghio <Ghio(a)andrew.cmu.edu> Last Updated: Mar 14 1994 The newest version of this document can be obtained by sending mail to: mg5n+remailers(a)andrew.cmu.edu Automated software will email you a copy. Notice: There have been many changes lately to various remailers. I try to keep this info as up to date as possible, but I may have missed something. If there are any errors, please let me know. The standard cypherpunks anonymous remailers are: hfinney(a)shell.portal.com catalyst(a)netcom.com nowhere(a)bsu-cs.bsu.edu remailer(a)chaos.bsu.edu hh(a)soda.berkeley.edu ebrandt(a)jarthur.claremont.edu remailer(a)merde.dis.org remailer(a)rebma.mn.org rperkins(a)nyx.cs.du.edu rperkins(a)nyx10.cs.du.edu hal(a)alumni.caltech.edu All of these allow you to send anonymous mail by adding the header Request-Remailing-To: and sending to one of the above addresses. Most (but not all) of these remailers also accept Anon-To: in place of Request-Remailing-To. If you can not add the required headers, place two colons (::) on the very first line of your message, then on the next line type Request-Remailing-To: and the address you want to send anonymously to. Skip a line, and then begin your message. Note that by using this method it is possible to send a message consecutively thru more than one remailer. remail(a)extropia.wimsey.com requires that you public-key encrypt your messages with PGP. This added security prevents a hacker or nosey sysadmin at your site from reading your outgoing mail or finding out where it's going. This remailer is not directly connected to the internet, so messages will be delayed about an hour. Some of the other remailers support PGP as well. For remailers which support both encryption and plaintext messages, identify encrypted messages by adding a header which reads: Encrypted: PGP Encryption keys can be found below. The bsu remailers require that you place the Subject: header in the body of the message, after the two colons and the Request-Remailing-To: line. These remailers also allow you to insert a Reply-To: line right after the Subject, so that you can have responses sent to you via an anonymous forwarding address. The other remailers require that you place two number signs (##) on a line, and then add the special headers, such as Reply-To: To get an anonymous forwarding address, send mail to mg5n+getid(a)andrew.cmu.edu There is a pseudonym-based anonymous remailer at anon.penet.fi. For information on this remailer, send mail to: help(a)anon.penet.fi There is another anonymous contact service at chop.ucsd.edu. It's not as full-featured as anon.penet.fi, but is considerably faster since it is not burdened by such a heavy load. For information on this remailer, send mail to: acs-info(a)chop.ucsd.edu Anonymous postings to usenet can be made by sending anonymous mail to one of the following mail-to-usenet gateways: group-name(a)cs.utexas.edu group.name.usenet(a)decwrl.dec.com group.name(a)news.demon.co.uk group.name(a)news.cs.indiana.edu The following lists the response times of the remailers listed above. Although measured accurately, these times are only an estimation of what you can expect. Actual response times will vary somewhat, depending on current network usage and other factors. Ping messages sent: Tue, 8 Mar 1994 00:00:00 EST (-0500) Replies received: nobody(a)shell.portal.com 00:01:57 catalyst-remailer(a)netcom.com 00:02:16 rperkins-remailer(a)nyx10.cs.du.edu 00:02:30 nowhere(a)bsu-cs.bsu.edu 00:02:39 remailer-admin(a)chaos.bsu.edu 00:02:43 rperkins-remailer(a)nyx.cs.du.edu 00:02:48 nobody(a)soda.berkeley.edu 00:02:51 nobody(a)jarthur.cs.hmc.edu 00:06:32 remailer(a)dis.org 00:35:34 remailer(a)rebma.rebma.mn.org 03:12:37 The following are PGP public keys of the remailers which support encryption: <remailer(a)dis.org> 512-bit key, Key ID 64E8A7, created 1993/03/05 Also known as: Anonymous Remailer <remailer(a)utter.dis.org> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQBNAiuX3kAAAAECAMd6YkS3ylajgNSzX+wYLrpW03D+99OFvePQLlR5N+R5iZBr y4FbAMeDj+eCeEAqiEyNjUxHN5tGlqx1g6tk6KcABRG0JFJlbWFpbGluZyBTZXJ2 aWNlIDxyZW1haWxlckBkaXMub3JnPokAVQIFECwomeN8p7i9YJH3xQEBDhEB/A7+ RLEw2bGJeBdBy0yXn5mIenda/tHHs9NGXJZR5BvOsU9EwVY+9s86E33R2/tgqAjY UYc5MiWS0r1+H9Zw+FeJAJUCBRArmsesg4Ds6kta1jMBAW4zA/4waabkcIHN93Jy /9OMXhRDqrRf2kickmeUWOGHF0KALLo37kAqfDvMNDtFs1u3WbdaBWdTSiLR8qIM 6TQNq0IEhAeny07AVweLlIpJc7lVN7biHqVIPknxJTAI/xscybuMUin3yALzFpWR 54uFMbd45iuKWBJ2/IGdUYcd39H0FbQsIEFub255bW91cyBSZW1haWxlciA8cmVt YWlsZXJAdXR0ZXIuZGlzLm9yZz6JAJUCBRArmsmdg4Ds6kta1jMBAbdwA/9m2GYJ 978xxchux7nnl4HAo3N+A2Nx+n40kQftWNiyJwivrG8kYwDI24QYaUpr2l6+2HDd xedEOFsX6DiHbDQK5J7dGYOigASmZHPs39lEdJ3AHvrTVYVYjOxBMQ2W6p+Q5rbn qxfmVlqRMzPRosPJ1gpbfcTzIpqznwSTl7tztQ== =v3Hk -----END PGP PUBLIC KEY BLOCK----- <remail(a)extropia.wimsey.com> 1024-bit key, Key ID B5A32F, created 1992/12/13 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAisrAP0AAAEEAJr3OwIfOIOoh9JndwwqFg+VyWFTAyM8S0B7wyGKI+A9sMAB mbSOIU52EszvLdZk8NH8mrOD9m3EZlt9gXOjln881RMilAunnzdXaJ6ffBKqPL+l yiefCbCo6wScVNfMSV6Di/2HMoFzVqukwRjTx8lqKt6hgy0uedtwcCemtaMvAAUR tCVSZW1haWxlciA8cmVtYWlsQGV4dHJvcGlhLndpbXNleS5jb20+iQCVAgUQK2SV p4OA7OpLWtYzAQG8eQP9F9ye/F/rXhJLNR5W/HV5k+f6E0zWSgtmTTWUYyydfJw+ lKDEDH6v+OFOFE3+fuTIL5l0zsNMSMdF5u7thSSWiwcFgaBFQF9NWmeL/uByOTSY tsB6DQSbw656SBH7c7V7jvUsPit/DubwBXZi9sOlULau3kQqXeeQxPhNE+bpMy6J AJUCBRArKwSLk3G+8Dfo40MBAXYAA/4hCVDFD0zG47pYPMg+y7NPE5LktWt2Hcwt Z4CRuT5A3eWGtG8Sd5QuHzbE4S9mD3CFn79bxZi0UDhryD8dsCG4eHiCpAcZqSvR JSkpgamdRaUQHNmMxv5goxHhRem6wXrKxZQNn5/S0NtQOrS6QKhFlGrzDIh/2ad1 J9qpyzJ/IYkARQIFECsrA9RLrSJixHgP9wEBNcEBewWpzywKk/SBDwocXebJmsT6 zug/ae78U/cu9kTX620Xcj1zqOdx9Y9Ppwem9YShaQ== =I7QE -----END PGP PUBLIC KEY BLOCK----- jarthur remailer <ebrandt(a)jarthur.claremont.edu> 512-bit key, Key ID 7D154B, created 1993/04/04 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQBNAiu+hVUAAAECAMVjEfl2IMNgSOJ+/fx1V6EbH50ofa6K4r1PBKMmkcHQextP ghwC4lXIgaAWUlLJ9x61+qf4jB5fpNUZLrF9FUsABRG0NWphcnRodXIgcmVtYWls ZXIgIGMvbyA8ZWJyYW5kdEBqYXJ0aHVyLmNsYXJlbW9udC5lZHU+iQCVAgUQK8M/ BIOA7OpLWtYzAQGJRAP9GIVi0qoQW4bjU9sikIPG4zIEbQ9O3rU1vd2uCrrnGQMM tdE9NoOx4umoVZKYTpCc96TlFQetb2UVd9JhaayXO7+nwNNHYgApkRJboolq9UzU wCRBA8k1EMAkdzCjzYglpZIQJz2yNP50Izu7g2LMbC1pHQX3CHVL7YlQrKGNLz4= =ItNk -----END PGP PUBLIC KEY BLOCK----- Anonymous Remailer <hfinney(a)shell.portal.com> 510-bit key, Key ID 5620D5, created 1992/11/15 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQBNAisGf+IAAAEB/ieS6th8hI1QBjGpmctVvsIxZBtmpykVXc3psh0XVfH4sECS ugouk2zm/PJtt59A2E5SO3xjpDjeKlkQ745WINUABRG0LFJlbWFpbGluZyBTZXJ2 aWNlIDxoZmlubmV5QHNoZWxsLnBvcnRhbC5jb20+iQCVAgUQK3Azm4OA7OpLWtYz AQHzawQAwZPaJUR9iNwyKMDm4bRSao0uu381pq6rR3nw0RI+DSLKTXPqDaT3xBmL dVv1PVguLcoao/TRLkAheV7CIxodEiI9lAC2o6lqSXCP+vm3jYmulSgUlKafXYbj LAbZpsKRAUjCpyx0wlYmoHhkA+NZDzMcWp6/1/rM/V1i4Jbt2+GJAJUCBRArBpKv qBMDr1ghTDcBASTlBACfTqODpVub15MK5A4i6eiqU8MDQGW0P0wUovPkNjscH22l 0AfRteXEUM+nB+Xwk16RG/GdrG8r9PbWzSCx6nBYb7Fj0nPnRPtS/u69THNTF2gU 2BD0j2vZF81lEHOYy6Ixao2b6Hxmab2mRta2eTg7CV6XP3eRFDPisVqgooAWgw== =arSc -----END PGP PUBLIC KEY BLOCK----- The operation of this system of remailers is a group effort which relies on the contributions of many generous people. Please do not abuse the remailers. If you have problems with a remailer, most of the remailer operators can be contacted by sending mail to the remailer's address without a remailing request header. Otherwise, follow the instructions that come in the messages from the remailer. Do not send complaints to postmaster at the site. Most of the remailers are run by people who are not the site administrators. Sending to postmaster or the site admins will most likely just make them annoyed at you, and won't get your problem resolved. If you can run an anonymous remailer, please volunteer to do so. Software is availiable from anonymous-FTP at soda.berkeley.edu in the directory /pub/cypherpunks/remailer Other remailer program code is availiable at vangogh.vis.colostate.edu in the directory /pub/nate/remailer-GUI/cpremailer.tar.Z The software can usually be run on personal accounts; Root or sysadmin access is not required in most cases. There are two usenet forums for discussion of anonymous remailer systems, alt.privacy.anon-server and alt.anonymous

1 0

Fwd: *AVAILABLE: HIGHLY EFFICIENT ELECTRONIC CASH SYSTEMS*
by Matthew J Ghio 17 Dec '03

17 Dec '03

---------- Forwarded message begins here ---------- Received: via nntpserv with nntp; Thu, 17 Mar 1994 17:00:49 -0500 (EST) Newsgroups: alt.2600,alt.cyberpunk.tech,talk.politics.crypto Path: andrew.cmu.edu!bb3.andrew.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!magn us.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.reston.ans.net!EU.net!s un4nl!cwi.nl!brands From: brands(a)cwi.nl (Stefan Brands) Subject: *AVAILABLE: HIGHLY EFFICIENT ELECTRONIC CASH SYSTEMS* Message-ID: <CMttnF.Btu(a)cwi.nl> Sender: news(a)cwi.nl (The Daily Dross) Nntp-Posting-Host: aasgier.cwi.nl Organization: CWI, Amsterdam Date: Thu, 17 Mar 1994 20:45:15 GMT Lines: 188 Xref: bb3.andrew.cmu.edu alt.2600:2751 alt.cyberpunk.tech:2971 talk.politics.crypto:3810 Subject: ------- seeking interested parties for implementing, and sharing the rights to, my technologies for privacy-protected electronic transfer of certified information. **** I am a PhD student at the Cryptography Department at the Center for Mathematics and Computer Science (CWI) in Amsterdam. In the past two years, I have developed a compact set of new techniques that enable the construction of highly efficient and secure electronic systems for off-line transfer of certified information, such that privacy is fully guaranteed. The resulting systems offers a great many advantages over any other privacy-protected systems you will find. In particular, using a subset of these techniques I have contructed off-line electronic cash systems in which the privacy of the account holders is fully guaranteed. An independent authority in the field of cryptology has recently confirmed that these systems seem to be the most practical such systems to date. I am posting this letter because I am very interested in pursuing the implementation of my systems *jointly*, in a fair business relationship, with a company capable of and interested in standardizing these systems. My technologies / ystenms are ideally suitable for smart cards, hand held computers, interactive TV, etcetera. All the rights to the technology have been transferred to me by CWI, and so part of such a cooperation would be *joint ownership of all rights*. The reason for posting this letter in a news group is that I see *no* other way to get in touch with interested parties. Before I go deeper into this, I would like to give you some more information about my technologies, and explain their many features. If you are not interested, but think you can help me by suggesting names etc.\, I would appreciate your suggestions. Privacy-protected transfer of electronic information. ----------------------------------------------------- Much work has been done to construct privacy-protected off-line cash systems previously, notably by David Chaum (formerly affiliated with CWI). This early work has resulted in two key concepts that can be used to attain the same level of security against double-spending as can trivially be attained in off-line cash systems with full traceability of payments. However, the many practical *realizations* of these concepts that have been proposed are far from satisfactory with respect to efficiency, provability of security (relative to certain well-known problems that are widely believed to be intractable), and extensibility in functionality. The new techniques I developed for my PhD thesis overcome *all* of these problems. They enable the construction of privacy-protected off-line cash systems that are almost as efficient as off-line cash systems that do *not* offer privacy. Succesful attacks against such a system provably imply that one can break a certain well-known signature scheme that is widely believed to be secure (such as the Schnorr scheme, the Guillou/Quisquater scheme, the schemes presented by Okamoto at CRYPTO 92, the Fiat/Shamir scheme etc.). The techniques in fact allow the construction of a highly efficient off-line cash system whose security (and that of all the extensions in functionality!) is based on the security of any one signature scheme of the so-called Fiat/Shamir type. Among the extensions in functionality are: prior restraint of double-spending, electronic cheques, protection against framing, currency exchange, anonymous accounts, and multi-spendable coins. All these extensions can be realized very easily without any need for additional data stuctures or basic algorithms (that is, *no* ad hoc constructions). In particular, prior restraint of double-spending can be achieved by using a tamper-resistant computing device that is capable of merely performing a signature scheme of the Fiat/Shamir type (of one's own choice), such as the Schnorr signature scheme. A highly preliminary report about a small subset of these techniques, based on the Discrete Logarithm problem, has been published by me about a year ago as a technical report at CWI. (A PostScript version of this report can be retrieved by ftp from ftp.cwi.nl, as pub/brands/CS-R9323.ps.). In August 1993 I presented these preliminary results at the CRYPTO 1993 conference in Santa Barbara. The final version of this abstract can also be retrieved by ftp from ftp.cwi.nl, as pub/brands/crypto93.ps. It's succesful acceptance can be measured by the fact that the results in the report are currently being used as the basis for a cash system by the European CAFE project, a project with 13 European partners from industry and science. I understand that some other implementations based on my report are under way as well. New developments. ----------------- In the mean time, however, I have significantly improved and *greatly* extended the techniques described in the preliminary report. Furthermore, I came up with a fully RSA-based variant that offers various advantages over the Discrete Log based variant. Contrary to the description in the preliminary report, the improved techniques allow the construction of withdrawal protocols for which it can rigorously be proven that the aforementioned attack to the withdrawal protocol is as hard as breaking a well-known signature scheme, and the efficiency of the system increases by a factor of two (a factor not to be neglected, especially not in case such a system is implemented using smart card technology!). As an interesting side note, the improved techniques do *not* use the blind signature technique as developed and patented by David Chaum. The full set of techniques can be used to construct highly efficient privacy-protected off-line mechanisms for transferring certified information, the security of which again can be *proven* assuming only the security of a certain well-known signature scheme of the Fiat/Shamir type of one's own choice. The off-line cash systems are in fact just one very particular instance of the general applicability of the complete set of techniques; it is a system in which credentials that may be shown only once can be transferred between any ``organizations'' while privacy is guaranteed. As an example of the usefulness of the new techniques, highly efficient and secure off-line cash systems can be constructed in which payments are made under pseudonym: in order to pay with a coin, an accountholder need do no more than send 35 bytes to an ``organization'' at which he has a pseudonym. For those who want to know in detail about the *many* features of the new techniques, as well as the performance of several preferred embodiments of systems that can be contructed from them, I have prepared a document that can be retrieve by ftp from ftp.cwi.nl, again in the directory pub/brands. There is a PostScript version called features.ps, as well as a plain text version called features.plain. Why am I posting this letter? ----------------------------- As I already mentioned at the start of this letter, I am very interested in pursuing the implementation of my systems *jointly*, in a fair business relationship, with a company capable of and interested in standardizing these systems. I am in the process of finishing my PhD thesis, which deals exclusively with these technologies. If you have read the detailed description of the features in my ``features'' document, then I have no doubt that you will agree with me that these systems offer a *great* many advantages over any other privacy-protected system for off-line transfer of digital information. In general, if you want to implement electronic systems for secure transfer of certified information, whether it be cash or other types of credentials, such that privacy can be guaranteed, then you will find out that this is *the* way to go. I am *not* involved with any project or company whatsoever. In particular, I want like to point out that I am *not* involved in the CAFE project, and I also do *not* have business relations with the company (DigiCash) of David Chaum, although I greatly respect his innovative work on privacy-protected transfer of electronic information. In fact, *all* rights on my technologies have been transferred to me by my employee, CWI. Due to the fact that my research was done independently of any project or company, it is extremely hard for me to get in touch with the appropriate persons at companies that are really interested in this technology *and* that have the capability of implementing it. Since projects and companies that I am not part of obviously do not provide me with such information, I see no better way to bring my technologies under the attention than by publishing this letter on the news net. If you are interested in my technologies, and want to pursue implementation together with me in the *near* future, I invite you to contact me. We can then discuss things further. Part of such a cooperation would be that *sharing* with me the rights to my technologies. My fax number is (31) 30 - 546 468 This is also my telephone number; however, I would prefer if you send fax or e-mail. My e-mail address at CWI is brands(a)cwi.nl. In case you are interested in having my work reviewed beforehand by some cryptography authority, to make sure I am not talking nonsense, I am happy to send to you a detailed description of my work. I guarantee you that he or she will *not* be able to break it, and will confirm the many statements I make about the benefits of my technologies. In addition, or alternatively, depending on the circumstances, I am happy to come over and explain my technologies in person with you. Alternatively, if you or your company is not interested in my technologies, but you think you can help me with pointers to persons at companies that might be interested in this technology, I would very much appreciate any such suggestions.

1 0

New block mode of operation
by peace＠BIX.com 17 Dec '03

17 Dec '03

Fellow cryptorians: The following is a draft of a paper that describes a mode of operation that I personally feel is useful for bulk data encryption for PEM, RIPEM, EDI, PGP and any other secure email application. In particular, submode CC1 is proposed for these applications. I would welcome any suggestions that would help in evaluating this method in those venues. peace at acm.org - - - - - - - - - - - - - - - - - - - - - - Cipher-Chain-Cipher Mode of Operation for Improving the Security of Block Ciphers by Thomas C. Jones 1 ABSTRACT As a way to extend the usefulness of encryption with the DES and prevent several of the more common attacks on the DES, a new mode of operation is defined that can be used with any block cipher, including DES. This mode of operation performs a cipher operation both before and after a chaining operation and so could be called cipher-chain-cipher (CCC) mode of operation. It is characterized by never performing any operation with the plaintext data except immediately after one cipher operation and immediately prior to another, so that cipher operations separate the plaintext and ciphertext in both directions. Thus the common known-text attack and chosen-text attack are avoided and, for some implementations, only two DES operations are required per plaintext block. 2 BACKGROUND Existing block encryption algorithms, such as the Data Encryption Standard (FIPS 46) have reached the end of their useful life. It was expected when the DES was first issued in 1976 that it would be used for 5 to 10 years. It is a tribute the care with which this algorithm was constructed, that it is only now yielding to practical cryptanalysis. In particular, the 56 bit key used with the DES can be determined by brute force attack using specially designed hardware operating in parallel. In practical applications of the DES, there are a wide range of ways to combine the input plaintext with the DES algorithm to produce an output ciphertext. In order to promote interoperability and good cryptographic practice the NIST issued "Modes of Operation of the DES" as FIPS 81. The most popular of the modes of operation for bulk plaintext data to be encrypted is Cipher Block Chaining (CBC). Several candidate algorithms have been offered as a replacement for the DES, but the large installed base of DES hardware and industry expertise in applying the DES have worked against the adoption of any of these candidates. Experience has shown that untested cryptographic algorithms are likely to have unanticipated security weaknesses. This also works against the adoption of new algorithms. When the bankers were looking for a stronger algorithm than the DES for protection of cryptographic keying material, they chose to leave the underlying DES algorithm in place, but apply the algorithm three separate times to the input plaintext to yield a "super-encrypted" output ciphertext. This has been considered to be a special mode of operation known as EDE (for encrypt-decrypt- encrypt) with 2 independent 56 bit keys. The reason that three were chosen, rather than two, relates to a particular cryptanalytic attack called "meet in the middle" where the cryptanalyst starts exhaustive first stage encryption of plaintext simultaneously with exhaustive second stage decryption of ciphertext and comparing the resulting values. While the computer storage required for this attack is impractical today, the theoretical existence of the attack discourages double DES modes of operation. It is well known that the redundancy of common data streams, such as the English language, results in ciphertext that can be decrypted to only one plaintext that is realistically English. The amount of ciphertext that is needed to have some assurance that only a single plaintext interpretation is known as the "unicity distance". For DES and English the unicity distance is slightly longer that one 8 byte block. This means that if the language was known to be English, only two blocks of ciphertext would be required to have a high degree of confidence that any decryption that yielded English text would be the only decryption that would do so. Even more to the point, if a computer could quickly assess the likelihood that a decryption of a single ciphertext block looked like English, only a single additional decryption would be required to verify that. This would make an attack, that tested every one of the possible keys, likely to succeed. The only thing that has prevented such a "brute force" attack has been the time and effort to perform such an attack. That sort of brute force attack is now within the grasp of well- financed commercial enterprises, not to mention secret governmental agencies. Several cryptanalytic attacks have been mounted on the DES to find some simpler way than brute force to recover the key given the output ciphertext and some other information. Most of these attacks rely on access to a large amount of plaintext and the corresponding ciphertext, this is called a "known plaintext attack". Existing modes of operation do not significantly reduce the threat of a known plaintext attack. Several methods are already known to reduce the threat of this attack, principle among them is restricting the use of each DES key to a single document or interchange. That is the method recommended here. If the cryptanalyst has access to the cryptographic engine with the key loaded, then two other attacks are possible. The "chosen plaintext attack" relies on the analysis of the underlying structure of the block algorithm by feeding it special combinations of bits that test particular functional characteristics of that structure. "Differential cryptanalysis" is an attack that relies on changing single bits in the plaintext and checking the effect on the ciphertext. While it seems unlikely that a user would allow any active DES key to be used in this way, resistance to these attacks is considered appropriate in academic circles. More traditional cryptanalysis relied strictly on redundancy that could be exploited with access to only the ciphertext itself. So far no method of attack on ciphertext has proven to be quicker than the brute force method mentioned above. It is up to the user to employ proven good algorithms in a cryptographically sound way with secure physical protection of the keying material. It is claimed that the cipher-chain-cipher modes of operation offer a sound way to extend the life of DES for encrypting bulk data such as that found in electronic mail systems. 3 SUMMARY The CCC mode of operation provides a way for input plaintext to be combined with DES block encryption and chaining from one stage to another to add an apparently random input component to each stage. The essentials of the method is its separation of the input and the output data at each stage by interposing a cipher operation between them. This requires a cipher operation on the output ciphertext before it is combined with the input plaintext, as well as a cipher operation on the result of the combining operation. Thus the cryptanalyst is not aware of either data stream that is to be combined with the input plaintext, nor of the output of the combining of the plaintext with the apparently random data that is combined with the plaintext. One reason for combining some apparently random value with the input plaintext is to provide a means for whitening the input data; that is, for masking any repeating pattern in the input plaintext so that the output ciphertext would also fail to contain any repeating pattern. It might be possible for some cryptanalyst to obtain some meaning from the existence of the repeating pattlue to the receiver. One good method is to place all the above values into a single packet that is encrypted with the receiver's public key component. The resulting encrypted packet can then be transmi at least as good a security level as is available from this mode of operation with the cryptographic algorithms used for bulk data encryption. The interchange is thus broken into two parts: the first involving the selection and secure transmittal of the keying material which is then used in the second part to encrypt the bulk data according to the modes of operation described in detail below. Once the keying material has been generated, the bulk data is broken into blocks as required by the block cryptographic algorithm and processed as specified. The first step is to optionally cipher the input plaintext using the first key. The second step is to chain together this result with apparently random data feed from the prior step. The final step is to cipher the result of the chaining operation and then to transmit the cipher block created. The word cipher is used here to mean either encryption or decryption, since the exact mode that the block cryptographic algorithm is used at each stage is not material to the modes of operation described. 4 DESCRIPTION Other modes of operation, which may have been established by the Federal Government for other reasons, have not been able to deter certain types of cryptanalytic attack. The weakness found in these other modes is shown, together with the advantages of this new mode of operation. Plain1 Plain2 | | v v IV ----------->X +----------->X +------> | | | | +----+ | +----+ | Key -------->| En |-+--------->| En |-+------> +----+ | +----+ | |----+ |----+ v v Cipher1 Cipher2 Where: X = bit-by-bit exclusive-or operation En = DES 8 byte block encryption De = DES 8 byte block decryption Op = Selection of an input plus encryption Plainx = One of the 8 byte input blocks of plaintext Cipherx = One of the 8 byte output blocks of ciphertext Key = 56 bit DES single length key IV = 64 bit Initial Value for chaining operation This shows the Cipher Block Chaining mode of operation of the DES. It is very effective at hiding any pattern in the input plaintext, but does little to deter a cryptanalyst, since if the input plaintext, and output ciphertext are known, then the input and output to the cipher operation are known as well. The fxample of CCC will show how to defeat this sort of attack by separating the chaining operation from the feedback of the ciphertext. Plain1 Plain2 | | IV --------+ | +----+ | +----+ v | | v | | v +----+ | | +----+ | | Key2 --->| En |--+----+->| En |--+----+-> +----+ | | +----+ | | | v | | v | +---> X | +---> X | | | | | v | v | +----+ | +----+ | Key3 --------->| De |-+------->| De |-+------> +----+ | +----+ | |----+ |----+ v v Cipher1 Cipher2 The CCC-Encrypt operation consists of DES block encryption of the ciphertext output from the last stage, an exclusive-or (bit by bit addition) with the next plaintext input, and a final DES block decryption to form the next ciphertext output block. The initial value (IV) serves as a apparently random input to the first stage, while the output of each stage serves as a apparently random input to each stage after the first. The above diagram show the first two full stages of encryption. Cipher1 Cipher2 | | +-----+----+ +----+---- v | v +----+ | +----+ Key2 -------->| En |-------+->| En |-------> +----+ | +----+ IV --------+ | | | | | | | v | v | +----+ | +----+ | Key1 --->| En |-+------->| En |-+---------> +----+ | +----+ | | v | v +--> X +--> X | | v v Plain1 Plain2 The CCC-Decrypt operation consists of DES block encryption of the ciphertext output from the last stage, a DES block encryption of the cipher text input to the current stage, and an exclusive-or with the output of both DES block encryptions. One attack on this mode is differential cryptanalysis, since, although the exact value of input to the final cipher stage is not known, a cryptanalyst that had access to the cryptographic engine with the key loaded could process plaintext that differed by only a single bit which would result in only a single bit change in the input to the final cipher stage. The cryptanalysis would then be performed on the ciphertext output. The CCC-encrypt operation can be generalized as shown in the following diagrams. Plain1 Plain2 | | v v +----+ +----+ Key1 ->| En |------->| En |-----> +----+ +----+ | | Key2 ----+------+------+------+---> | v | v v +----+ v +----+ IV ----->X -->| Op |-->X -->| Op |-> | +----+ | +----+ v ^ v ^ +----+ | +----+ | Key3 ->| De |---+--->| De |---+---> +----+ | +----+ | |------+ |------+ v v Cipher1 Cipher2 The generalized CCC-encrypt operation consists of an initial DES encrypt operation on the plain text using the first key, followed by a chaining operation and then a DES decrypt operation on the result of the chaining operation using the third key. Several operations are possible with the chaining operation which uses the second key. In all cases the input to the exclusive-or operation is the result of a variable operation shown above as Op and the output from the first cipher operation. The variable operation in the middle can have one of two sources, and may use the second key shown in the diagram. Cipher1 Cipher2 | | +------+ +-------+ v | v | +----+ | +----+ | Key3 ->| En |---+--->| En |----+----> +----+ | +----+ | |--+ | |--+ | | | v | | v v | +----+ | | +----+ IV ----->X +->| Op |->X +->| Op |-> | +----+ | +----+ | ^ | ^ Key2 ----+-------+-----+-------+-----> v v +----+ +----+ Key1 ->| De |------->| De |---------> +----+ +----+ | | v v Plain1 Plain2 The generalized CCC-decrypt operation just reverses these operations, except for the chaining operation, which stays the same in the encrypt and decrypt operations. Several submodes are available from this generalized mode of operation depending on the nature of the operator used between chaining operations. Below are listed four submodes that may have particular interest. Mode CC0 - This mode does not use Key1, so the first cipher operation is the identity. The chaining operation is defined to be the DES on the feedback from the final cipher operation. This is exactly the first example shown above. Its advantage is that it uses only two keys and two DES operations per input block. The disadvantages are discussed above. Mode CC1 - This modeof the exclusive-or operation. This means that the exclusive-or product is just the accumulation of all the first stage ciphers with the initialization vector. This mode also only uses two independent key values and two DES operation per input block. A further advantage is that the interior chaining operation only uses data that is not available to the cryptanalyst in either the known-text or the chosen-text attack. Mode CC2 - This mode is identical to mode CC1 except that the chaining operation is the DES performed on the result of the prior exclusive-or. This mode requires three DES operation per input block, but gains by confusion of the diffusion entry added in between each data cipher operation. Mode CC3 - This mode is identical to mode CC2 except that the source of the data for the DES operation prior to chaining is not the prior chaining operation, but feedback from the output stage of the final cipher operation. This too requires three DES operations per input block. 5 EXAMPLE It will be assumed that the block ciphers of interest all result in the same amount of output ciphertext as input plaintext with the possible addition of a fixed length initial value and a variable length padding to create some optimal length. In the DES this optimal data length is any stream that is an exact multiple of 8 bytes. Variants of this method could be used with other block lengths or with byte oriented modes of operation. While this new mode of operation is expected to find its greatest use with bulk encryption using data blocks equal in length to the block length inherent in the underlying block encryption algorithm, any length block of data could be utilized with any block length encryption algorithm. This section shows how bulk data can be segmented into 64 byte blocks and encrypted using the 64 byte block DES algorithm. For added security, the secret keying material and the DES operations are shown to be contained inside the security perimeter of a cryptographic module which is mounted inside of a personal computer using a common operating system. It would be equally useful to move some, or all, of the cryptographic operations to code operating under the personal computer's operation system. It is critical to the security of the overall system that the secret keying material, consisting of the two DES keys and the initial value (IV), be known only to the originating and receiving party to the interchange. One way to do this, and to prevent the accumulation of information for a cryptanalytic attack on the secret keying material, is to create a new packet of keying material for each interchange using some suitably random generator within the security perimeter and encrypt the entire packet of keying material using this, or some other encryption method such as the RSA public key encryption method. Using DES as the underlying secret key encryption algorithm may necessitate other measures when generating the keying material, such as weak key elimination and key parity generation. In any case there are two or three DES keys with parity are 64 bits in length. The initial value is the size of the block which is also 64 bits. At least one byte will be used to determine the exact mode of operation. Since the first key is optional, the block of secret data can be constructed as 200 to 264 bits in the following form: +------+----+------+------+----------------+ | mode | IV | Key3 | Key2 | Key1(optional) | +------+----+------+------+----------------+ This data is just a valuable as the plaintext of the message to be protected, since an attacker is assumed to have access to the ciphertext, so this data will recover the plaintext. It should be noted that it is not any more valuable than the plaintext since it will be used only once to protect one message or interchange. Therefore, if the plaintext data is contained on a personal computer, the enciphering operation can also be performed on the same personal computer. On the other hand, the private components of the public key will be used to decode essentially all the secured messages that are received over its life, and so its value is the sum of all such message. Thus the private components must be protected to a commensurate level with this value. Additional means for protection should include a security perimeter containing these components together with the operations that are possible with them. The security perimeter must be able to physically show when an attack on the components was made. Several devices now have such a security perimeter including: NIST 140-1 cryptographic modules, smart cards with cryptographic co- processors and PCMCIA cards. Once suitable keying material is obtained, the originator of the message may take appropriate means to reduce the redundancy of the plaintext by compressing it. Compression, if successful, always makes the task of the cryptanalyst more difficult by reducing the redundancy in the plaintext, and making any trial decryption more likely to yield a possibly good text plaintext example. - - - - - - - - - - - - - - - - - - - - - - This paper represents ideas that may be subject to patent applications by the author or by others. To the author's knowledge, the mode of operation described in this paper was invented by the author. To the extent that any of these ideas do belong to the author, he grants anybody the right to use his ideas in code compiled by the user for personal, non-commercial use. No warrenty of any sort is implied by this grant. This paper is copyright (c) 1994 by Thomas C. Jones and may be reproduced only with this notice intact.

2 1

Re: The Agency Whose Name May Not Be Spoken
by stevenJ 17 Dec '03

17 Dec '03

Mats Bergstrom muttered something about... :: ::Yeah, I wonder what Jason Bourne is up to these days. If you can track ::him you would probably get close to where the real action is. :: Ok, I'll admit my neophyteness. Who is Jason Bourne? e x t r a p o l a t e steve j. white _____________________________________________________________________________ Gort, klatu barada nicto. aragorn(a)alpha1.csd.uwm.edu

1 0

DTI Hearing on NPR
by Duncan Frissell 17 Dec '03

17 Dec '03

This morning's 6:00am EST (repeated at 8:00am) hourly teaser listing of news items on National Commie Radio included the following: "In Washington today...a Senate Judiciary subcommittee holds hearings on encoding digital communications so that police agencies can still intercept calls." Newsreader was Alex Chadwick DCF -- "The Piano dies in the end." Spoiler for "The Piano" --- WinQwk 2.0b#1165

1 0

Denning Presentation and Q&A at George Mason University
by cfrye＠ciis.mitre.org 17 Dec '03

17 Dec '03

On March 8, Dr. Dorothy Denning was a guest speaker for LRNG 572 - Taming the Electronic Frontier, a course at George Mason University. The professor, Dr. Brad Cox, is a veteran software developer who has turned his attention to developing models for electronic commerce and "student-centered education". The latter is my own term for his concept of students, through a demand-based process, having much more control over and interaction with the university education process. Brad has expressed strong opinions on several issues regarding personal privacy and the Clipper/Digital Telephony proposals; I don't presume to speak for him, but I should note that our homework includes installing PGP 2.2 or 2.3a on our personal machines, generating key pairs, distributing our public keys, and broadcasting an essay encrypted with everyone else's public keys. The lecture was broadcast on the George Mason University channel, 48 on Media General Cable Systems in Fairfax County, VA, and other channels around the DC Metro Area. Tapes are available in the GMU Library and, I believe, may be copied and distributed freely. If any of you would like a copy of the session, I'll look into what has to happen to get it done. I do not have a VCR at home and am not referring to the tape as I write this summary, so there may be some inaccuracies. Further, as I was not taking careful notes, my own comments and questions are most prominent in this summary. In my note to the class, I'll ask them to contribute their own views of the proceedings. I am forwarding this note to Brad, Dr. Denning, and the class to ensure all parties have the opportunity to correct any misrepresentations or omissions. ***The Presentation*** Dr. Denning was clearly nervous -- she indicated that she had never worked with the combination of television, overhead projector and computer-cueing system in the video classroom. Also, I surmise that Brad had warned her that she wouldn't be facing the most sympathetic audience in the world. Each student had written an essay about Clipper and emailed it to Brad, cc'ing the rest of the class. Most of the class didn't think Clipper/Digital Telephony was a hot idea, but there were several supporters. After a brief intro describing Clipper as a "voluntary" standard, she quickly described the key initialization and two-party decryption processes. This part of the lecture was notation-laden and somewhat hard for me to follow, and I've read most of Schneier's _Applied Cryptography_! The folks around me seemed to be lost in the particulars of how the various keys were generated and interacted (especially the session key). However, I believe the basic points got through clearly enough - the class is mostly professionals and is sophisticated enough to pick up anything that's explained well. After Denning indicated that NIST and Treasury were to be the two escrow agents, I asked about VP Gore's 9 February remarks on the potential problems of both agents being in the Executive Branch etc. She glossed over the issue by replying that the process was still being examined and that she didn't see a problem with the two agents residing in the same branch of government. The theme that "the key escrow system prevents abuse" resonated throughout her presentation. A few minutes later, I asked Dr. Denning whether she her earlier published (on Usenet, anyway) statements to the effect that if Clipper were made mandatory she would probably withdraw her support for the standard. She did not dispute the basis of the question but did not answer it per se, either. Her final response (paraphrased) was that she could not foresee all possible outcomes and did not want to commit herself to a position without observable results. After further questions, Denning described the Digital Telephony proposal, stressing that the idea was to maintain the current level of wiretap capabilities despite technological advances. She was very careful to delineate the goals for Clipper and Digital Telephony as follows: o Clipper is designed to provide US citizens strong cryptography that won't threaten US national security; o Clipper is *not* designed to catch crooks; o Digital Telephony is designed to maintain the current level of wiretap capabilities and gives law enforcement officials no new abilities. The first statement is hard to dispute on its face, despite the invocation of that vague concept called "national security". As many others, including Tim May, have said, the government is fighting an imaginary enemy which is, by virtue of it being imaginary, capable of anything. If cellular phones, baby monitors (!) and regular telephones used Clipper-like technology, many citizen-to-citizen privacy worries would be solved since ham radio and scanner operators would be unable to monitor these transmissions. However, the idea that the standard is voluntary, an idea she defended even when pressed that everyone in the government (except the judiciary) answers to the same guy raises a question as to how voluntary the standard is. The second statement goes against much of the rhetoric Clipper supporters have used to link the proposal to the War on Drugs and the general fear of crime. It's interesting to note that, even while she was disavowing Clipper's link to catching crooks, she read anecdotes from the back cover of a book entitled something like _The World's Dumbest Criminals_ and opined that, if someone is dumb enough to call hotel security and report $1000 of cocaine missing from his room, they just might be dumb enough to use Clipper. After all, they talk in the clear now! I think this argument has gotten short shrift on Cypherpunks and does deserve more attention. If the price of ClipperPhones comes down enough so that they're affordable _and_ there's no market competitor of note, why wouldn't drug dealers use the equipment? After all, even assuming the full search warrent process is bypassed, the government needs to know what's happening before they tap the line. The solution, of course, is to market alternative crypto-boxes that can fit between the phone unit and the wall socket. Price competition against high volume manufacturers will be a serious obstacle to successfully circumventing the escrowed technologies. The difference in the rhetorical significance of crime-fighting when Clipper is presented to technical and non-technical audiences is interesting. The final theme, that Digital Telephony adds no new law enforcement capabilities, was not something anyone in the class seemed to have the knowledge to dispute on technical grounds. When I raised the issue of phone calls being directed to central law enforcement sites instead of requiring agents to move to a remote location, Dr. Denning indicated that wiretaps are done by directing calls to a central location now. While J.P. Barlow challenged related issues in the America On Line debate, I have not seen a refutation of this particular point. Can anyone elaborate? ***Personal Notes and Editorials*** o None of us brought up the government ability to request and examine phone usage information without a warrant or pointed out that law enforcement agencies currently do this more than 100,000 times per year. [I wasn't aware of the number until Barlow cited it on AOL.] o I would hope that the ability of government to accumulate behavioral dossiers on private citizens through the information mosaic and link analysis tools is something that would appear in _Time_ right beside the Clipper and Digital Telephony expository articles in the future. If Digital Telephony makes this ability stronger, there is a greater danger of the fishing expeditions and data matching exercises the 1974 Privacy Act is designed to prevent. o In my opinion Dr. Denning sincerely believes these proposals will make a positive difference; however, the sincerity of the advocate does not give credence to the position advocated. -- Best regards, Curtis D. Frye - Job Search Underway!!! cfrye(a)ciis.mitre.org or cfrye(a)mason1.gmu.edu "MITRE's in the past, now. Time to move on!"

2 1