Wiley applied cryptography protocols algorthms and source code in c 2nd edition oct 1995 ISBN 0471128457

Previous Table of Contents Next Preface There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files This book is about the latter If I take a letter, lock it in a safe, hide the safe somewhere in New York, then tell you to read the letter, that’s not security That’s obscurity On the other hand, if I take a letter and lock it in a safe, and then give you the safe along with the design specifications of the safe and a hundred identical safes with their combinations so that you and the world’s best safecrackers can study the locking mechanism—and you still can’t open the safe and read the letter—that’s security For many years, this sort of cryptography was the exclusive domain of the military The United States’ National Security Agency (NSA), and its counterparts in the former Soviet Union, England, France, Israel, and elsewhere, have spent billions of dollars in the very serious game of securing their own communications while trying to break everyone else’s Private individuals, with far less expertise and budget, have been powerless to protect their own privacy against these governments During the last 20 years, public academic research in cryptography has exploded While classical cryptography has been long used by ordinary citizens, computer cryptography was the exclusive domain of the world’s militaries since World War II Today, state–of–the–art computer cryptography is practiced outside the secured walls of the military agencies The layperson can now employ security practices that can protect against the most powerful of adversaries—security that may protect against military agencies for years to come Do average people really need this kind of security? Yes They may be planning a political campaign, discussing taxes, or having an illicit affair They may be designing a new product, discussing a marketing strategy, or planning a hostile business takeover Or they may be living in a country that does not respect the rights of privacy of its citizens They may be doing something that they feel shouldn’t be illegal, but is For whatever reason, the data and communications are personal, private, and no one else’s business This book is being published in a tumultuous time In 1994, the Clinton administration approved the Escrowed Encryption Standard (including the Clipper chip and Fortezza card) and signed the Digital Telephony bill into law Both of these initiatives try to ensure the government’s ability to conduct electronic surveillance Some dangerously Orwellian assumptions are at work here: that the government has the right to listen to private communications, and that there is something wrong with a private citizen trying to keep a secret from the government Law enforcement has always been able to conduct court–authorized surveillance if possible, but this is the first time that the people have been forced to take active measures to make themselves available for surveillance These initiatives are not simply government proposals in some obscure area; they are preemptive and unilateral attempts to usurp powers that previously belonged to the people Clipper and Digital Telephony do not protect privacy; they force individuals to unconditionally trust that the government will respect their privacy The same law enforcement authorities who illegally tapped Martin Luther King Jr.’s phones can easily tap a phone protected with Clipper In the recent past, local police authorities have either been charged criminally or sued civilly in numerous jurisdictions—Maryland, Connecticut, Vermont, Georgia, Missouri, and Nevada—for conducting illegal wiretaps It’s a poor idea to deploy a technology that could some day facilitate a police state The lesson here is that it is insufficient to protect ourselves with laws; we need to protect ourselves with mathematics Encryption is too important to be left solely to governments This book gives you the tools you need to protect your own privacy; cryptography products may be declared illegal, but the information will never be How to Read This Book I wrote Applied Cryptography to be both a lively introduction to the field of cryptography and a comprehensive reference I have tried to keep the text readable without sacrificing accuracy This book is not intended to be a mathematical text Although I have not deliberately given any false information, I do play fast and loose with theory For those interested in formalism, there are copious references to the academic literature Chapter 1 introduces cryptography, defines many terms, and briefly discusses precomputer cryptography Chapters 2 through 6 (Part I) describe cryptographic protocols: what people can do with cryptography The protocols range from the simple (sending encrypted messages from one person to another) to the complex (flipping a coin over the telephone) to the esoteric (secure and anonymous digital money exchange) Some of these protocols are obvious; others are almost amazing Cryptography can solve a lot of problems that most people never realized it could Chapters 7 through 10 (Part II) discuss cryptographic techniques All four chapters in this section are important for even the most basic uses of cryptography Chapters 7 and 8 are about keys: how long a key should be in order to be secure, how to generate keys, how to store keys, how to dispose of keys, and so on Key management is the hardest part of cryptography and often the Achilles’ heel of an otherwise secure system Chapter 9 discusses different ways of using cryptographic algorithms, and Chapter 10 gives the odds and ends of algorithms: how to choose, implement, and use algorithms Chapters 11 through 23 (Part III) list algorithms Chapter 11 provides the mathematical background This chapter is only required if you are interested in public–key algorithms If you just want to implement DES (or something similar), you can skip ahead Chapter 12 discusses DES: the algorithm, its history, its security, and some variants Chapters 13, 14, and 15 discuss other block algorithms; if you want something more secure than DES, skip to the section on IDEA and triple–DES If you want to read about a bunch of algorithms, some of which may be more secure than DES, read the whole chapter Chapters 16 and 17 discuss stream algorithms Chapter 18 focuses on one–way hash functions; MD5 and SHA are the most common, although I discuss many more Chapter 19 discusses public–key encryption algorithms, Chapter 20 discusses public–key digital signature algorithms, Chapter 21 discusses public–key identification algorithms, and Chapter 22 discusses public– key key exchange algorithms The important algorithms are RSA, DSA, Fiat– Shamir, and Diffie–Hellman, respectively Chapter 23 has more esoteric public– key algorithms and protocols; the math in this chapter is quite complicated, so wear your seat belt Chapters 24 and 25 (Part IV) turn to the real world of cryptography Chapter 24 discusses some of the current implementations of these algorithms and protocols, while Chapter 25 touches on some of the political issues surrounding cryptography These chapters are by no means intended to be comprehensive Also included are source code listings for 10 algorithms discussed in Part III I was unable to include all the code I wanted to due to space limitations, and cryptographic source code cannot otherwise be exported (Amazingly enough, the State Department allowed export of the first edition of this book with source code, but denied export for a computer disk with the exact same source code on it Go figure.) An associated source code disk set includes much more source code than I could fit in this book; it is probably the largest collection of cryptographic source code outside a military institution I can only send source code disks to U.S and Canadian citizens living in the U.S and Canada, but hopefully that will change someday If you are interested in implementing or playing with the cryptographic algorithms in this book, get the disk See the last page of the book for details One criticism of this book is that its encyclopedic nature takes away from its readability This is true, but I wanted to provide a single reference for those who might come across an algorithm in the academic literature or in a product For those who are more interested in a tutorial, I apologize A lot is being done in the field; this is the first time so much of it has been gathered between two covers Even so, space considerations forced me to leave many things out I covered topics that I felt were important, practical, or interesting If I couldn’t cover a topic in depth, I gave references to articles and papers that did I have done my best to hunt down and eradicate all errors in this book, but many have assured me that it is an impossible task Certainly, the second edition has far fewer errors than the first An errata listing is available from me and will be periodically posted to the Usenet newsgroup sci.crypt If any reader finds an error, please let me know I’ll send the first person to find each error in the book a free copy of the source code disk Previous Table of Contents Next Previous Table of Contents Next About the Author BRUCE SCHNEIER is president of Counterpane Systems, an Oak Park, Illinois consulting firm specializing in cryptography and computer security Bruce is also the author of E–Mail Security (John Wiley & Sons, 1995) and Protect Your Macintosh (Peachpit Press, 1994); and has written dozens of articles on cryptography for major magazines He is a contributing editor to Dr Dobb’s Journal, where he edits the “Algorithms Alley” column, and a contributing editor to Computer and Communications Security Reviews Bruce serves on the board of directors of the International Association for Cryptologic Research, is a member of the Advisory Board for the Electronic Privacy Information Center, and is on the program committee for the New Security Paradigms Workshop In addition, he finds time to give frequent lectures on cryptography, computer security, and privacy Acknowledgments The list of people who had a hand in this book may seem unending, but all are worthy of mention I would like to thank Don Alvarez, Ross Anderson, Dave Balenson, Karl Barrus, Steve Bellovin, Dan Bernstein, Eli Biham, Joan Boyar, Karen Cooper, Whit Diffie, Joan Feigenbaum, Phil Karn, Neal Koblitz, Xuejia Lai, Tom Leranth, Mike Markowitz, Ralph Merkle, Bill Patton, Peter Pearson, Charles Pfleeger, Ken Pizzini, Bart Preneel, Mark Riordan, Joachim Schurman, and Marc Schwartz for reading and editing all or parts of the first edition; Marc Vauclair for translating the first edition into French; Abe Abraham, Ross Anderson, Dave Banisar, Steve Bellovin, Eli Biham, Matt Bishop, Matt Blaze, Gary Carter, Jan Camenisch, Claude CrŽpeau, Joan Daemen, Jorge Davila, Ed Dawson, Whit Diffie, Carl Ellison, Joan Feigenbaum, Niels Ferguson, Matt Franklin, Rosario Gennaro, Dieter Gollmann, Mark Goresky, Richard Graveman, Stuart Haber, Jingman He, Bob Hogue, Kenneth Iversen, Markus Jakobsson, Burt Kaliski, Phil Karn, John Kelsey, John Kennedy, Lars Knudsen, Paul Kocher, John Ladwig, Xuejia Lai, Arjen Lenstra, Paul Leyland, Mike Markowitz, Jim Massey, Bruce McNair, William Hugh Murray, Roger Needham, Clif Neuman, Kaisa Nyberg, Luke O’Connor, Peter Pearson, RenŽ Peralta, Bart Preneel, Yisrael Radai, Matt Robshaw, Michael Roe, Phil Rogaway, Avi Rubin, Paul Rubin, Selwyn Russell, Kazue Sako, Mahmoud Salmasizadeh, Markus Stadler, Dmitry Titov, Jimmy Upton, Marc Vauclair, Serge Vaudenay, Gideon Yuval, Glen Zorn, and several anonymous government employees for reading and editing all or parts of the second edition; Lawrie Brown, Leisa Condie, Joan Daemen, Peter Gutmann, Alan Insley, Chris Johnston, John Kelsey, Xuejia Lai, Bill Leininger, Mike Markowitz, Richard Outerbridge, Peter Pearson, Ken Pizzini, Colin Plumb, RSA Data Security, Inc., Michael Roe, Michael Wood, and Phil Zimmermann for providing source code; Paul MacNerland for creating the figures for the first edition; Karen Cooper for copyediting the second edition; Beth Friedman for proofreading the second edition; Carol Kennedy for indexing the second edition; the readers of sci.crypt and the Cypherpunks mailing list for commenting on ideas, answering questions, and finding errors in the first edition; Randy Seuss for providing Internet access; Jeff Duntemann and Jon Erickson for helping me get started; assorted random Insleys for the impetus, encouragement, support, conversations, friendship, and dinners; and AT&T; Bell Labs for firing me and making this all possible All these people helped to create a far better book than I could have created alone Bruce Schneier Oak Park, Ill schneier@counterpane.com Previous Table of Contents Next Applied Cryptography, Second Edition: Protocols, Algorthms, and Source Code in C (Publisher: John Wiley & Sons, Inc.) Author(s): Bruce Schneier ISBN: 0471128457 Publication Date: 01/01/96 Foreword by Whitfield Diffie Preface About the Author Chapter 1—Foundations 1.1 Terminology 1.2 Steganography 1.3 Substitution Ciphers and Transposition Ciphers 1.4 Simple XOR 1.5 One-Time Pads 1.6 Computer Algorithms 1.7 Large Numbers Part I—Cryptographic Protocols Chapter 2—Protocol Building Blocks 2.1 Introduction to Protocols 2.2 Communications Using Symmetric Cryptography 2.3 One-Way Functions 2.4 One-Way Hash Functions 2.5 Communications Using Public-Key Cryptography 2.6 Digital Signatures 2.7 Digital Signatures with Encryption 2.8 Random and Pseudo-Random-Sequence Generation Chapter 3—Basic Protocols 3.1 Key Exchange 3.2 Authentication 3.3 Authentication and Key Exchange 3.4 Formal Analysis of Authentication and Key-Exchange Protocols 3.5 Multiple-Key Public-Key Cryptography 3.6 Secret Splitting 3.7 Secret Sharing 3.8 Cryptographic Protection of Databases Chapter 4—Intermediate Protocols 4.1 Timestamping Services 4.2 Subliminal Channel 4.3 Undeniable Digital Signatures 4.4 Designated Confirmer Signatures 4.5 Proxy Signatures 4.6 Group Signatures 4.7 Fail-Stop Digital Signatures 4.8 Computing with Encrypted Data 4.9 Bit Commitment 4.10 Fair Coin Flips 4.11 Mental Poker 4.12 One-Way Accumulators 4.13 All-or-Nothing Disclosure of Secrets 4.14 Key Escrow Chapter 5—Advanced Protocols 5.1 Zero-Knowledge Proofs 5.2 Zero-Knowledge Proofs of Identity 5.3 Blind Signatures 5.4 Identity-Based Public-Key Cryptography 5.5 Oblivious Transfer 5.6 Oblivious Signatures 5.7 Simultaneous Contract Signing 5.8 Digital Certified Mail 5.9 Simultaneous Exchange of Secrets Chapter 6—Esoteric Protocols 6.1 Secure Elections 6.2 Secure Multiparty Computation 6.3 Anonymous Message Broadcast 6.4 Digital Cash Part II—Cryptographic Techniques Chapter 7—Key Length 7.1 Symmetric Key Length 7.2 Public-Key Key Length 7.3 Comparing Symmetric and Public-Key Key Length 7.4 Birthday Attacks against One-Way Hash Functions 7.5 How Long Should a Key Be? 7.6 Caveat Emptor Chapter 8—Key Management 8.1 Generating Keys 8.2 Nonlinear Keyspaces 8.3 Transferring Keys 8.4 Verifying Keys 8.5 Using Keys 8.6 Updating Keys 8.7 Storing Keys 8.8 Backup Keys 8.9 Compromised Keys 8.10 Lifetime of Keys 8.11 Destroying Keys 8.12 Public-Key Key Management Chapter 9—Algorithm Types and Modes 9.1 Electronic Codebook Mode 9.2 Block Replay 9.3 Cipher Block Chaining Mode 9.4 Stream Ciphers 9.5 Self-Synchronizing Stream Ciphers 9.6 Cipher-Feedback Mode 9.7 Synchronous Stream Ciphers 9.8 Output-Feedback Mode 9.9 Counter Mode 9.10 Other Block-Cipher Modes 9.11 Choosing a Cipher Mode 9.12 Interleaving 9.13 Block Ciphers versus Stream Ciphers Chapter 10—Using Algorithms 10.1 Choosing an Algorithm 10.2 Public-Key Cryptography versus Symmetric Cryptography Tatebayashi-Matsuzaki-Newman This key distribution protocol is suitable for networks [1521] Alice wants to generate a session key with Bob using Trent, the KDC All parties know Trent’s public key, n Trent knows the two large primes that n factors to, and hence can easily take cube roots modulo n A lot of the details are left out of the following protocol, but you get the idea (1) Alice chooses a random number, rA, and sends Trent rA3 mod n (2) Trent tells Bob that someone wants to exchange a key with him (3) Bob chooses a random number, rB, and sends Trent rB3 mod n (4) Trent uses his private key to recover rA and rB He sends Alice rA⊕ rB (5) Alice calculates (rA⊕ rB) ⊕ rA = rB She uses this rB to communicate securely with Bob This protocol looks good, but it has a horrible flaw Carol can listen in on step (3) and use that information, with the help of an unsuspecting Trent and another malicious user (Dave), to recover rB [1472] (1) Carol chooses a random number, rC, and sends Trent rB3rC3 mod n (2) Trent tells Dave that someone wants to exchange a key with him (3) Dave chooses a random number, rD, and sends Trent rD3 mod n (4) Trent uses his private key to recover rC and rD He sends Carol (rBrC) mod n⊕ rD (5) Dave sends rD to Carol (6) Carol uses rC and rD to recover rB She uses rB to eavesdrop on Alice and Bob This is not good Previous Table of Contents Next Previous Table of Contents Next Like the previous protocol, a group of signers use a shared public large prime, p, and a primitive element, g Alice has a unique private key, x, and a public key, gx mod p To sign a message, Alice computes z =mx mod p To verify a signature: (1) Bob chooses two random numbers, a and b, both less than p, and sends Alice: c = magb mod p (2) Alice chooses a random number, q, less than p, and computes and sends to Bob: s1 = cgq mod p, s2 = (cgq)x mod p (3) Bob sends Alice a and b, so that Alice can confirm that Bob did not cheat in step (1) (4) Alice sends Bob q, so that Bob can use mx and reconstruct s1 and s2 If then the signature is valid s1 ≡ cgq (mod p) s2 ≡ (gx)b +qza (mod p) Alice can also disavow a signature, z, for a message, m See [329] for details Additional protocols for undeniable signatures can be found in [584,344] Lein Harn and Shoubao Yang proposed a group undeniable signature scheme [700] Convertible Undeniable Signatures An algorithm for a convertible undeniable signature, which can be verified, disavowed, and also converted to a conventional digital signature is given in [213] It’s based on the ElGamal digital signature algorithm Like ElGamal, first choose two primes, p and q, such that q divides p -1 Now you have to create a number, g, less than q First choose a random number, h, between 2 and p -1 Calculate g = h( p-1)/q mod p If g equals the 1, choose another random h If it doesn’t, stick with the g you have The private keys are two different random numbers, x and z, both less than q The public keys are p, q, g, y, and u, where y = gx mod p u = gz mod p To compute the convertible undeniable signature of message m (which is actually the hash of a message), first choose a random number, t, between 1 and q -1 Then compute T = gt mod p and m' = Ttzm mod q Now, compute the standard ElGamal signature on m' Choose a random number, R, such that R is less than and relatively prime to p -1 Then compute r =gR mod p, and use the extended Euclidean algorithm to compute s, such that m' ≡ rx + Rs (mod q) The signature is the ElGamal signature (r, s), and T Here’s how Alice verifies her signature to Bob: (1) Bob generates two random numbers, a and b He computes c = TTmagb mod p and sends that to Alice (2) Alice generates a random number, k, and computes h1 = cgk mod p, and h2 = h1 z mod p, and sends both of those numbers to Bob (3) Bob sends Alice a and b (4) Alice verifies that c = TTmagb mod p She sends k to Bob (5) Bob verifies that h1 = TTmagb+k mod p, and that h2 = yrarsaub+k mod p Alice can convert all of her undeniable signatures to normal signatures by publishing z Now, anyone can verify her signature without her help Undeniable signature schemes can be combined with secret-sharing schemes to create distributed convertible undeniable signatures [1235] Someone can sign a message, then distribute the ability to confirm that the signature is valid He might, for example, require three out of five people to participate in the protocol in order to convince Bob that the signature is valid Improvements on this notion deleted the requirement for a trusted dealer [700,1369] 23.5 Designated Confirmer Signatures Here’s how Alice can sign a message and Bob can verify it, such that Carol can verify Alice’s signature at some later time to Dave (see Section 4.4) [333] First, a large prime, p, and a primitive element, g, are made public and used by a group of users The product of two primes, n, is also public Carol has a private key, z, and a public key is h =gx mod p In this protocol Alice can sign m such that Bob is convinced that the signature is valid,but cannot convince a third party (1) Alice chooses a random x and computes a = gx mod p b = hx mod p She computes the hash of m, H(m), and the hash of a and b concatenated, H(a,b) She then computes j = (H(m) ⊕ H(a, b))1/3 mod n and sends a, b, and j to Bob (2) Bob chooses two random numbers, s and t, both less than p, and sends Alice c = gsht mod p (3) Alice chooses a random q less than p, and sends Bob d = gq mod p e = (cd)x mod p (4) Bob sends Alice s and t (5) Alice confirms that gsht ≡ c (mod p) Then she sends Bob q (6) Bob confirms d ≡ gq (mod p) e/aq ≡ asbt (mod p) H(m) ⊕ H(a, b) ≡ j1/3 mod n If they all check out, he accepts the signature as genuine Bob cannot use a transcript of this proof to convince Dave that the signature is genuine, but Dave can conduct a protocol with Alice’s designated confirmer, Carol Here’s how Carol convinces Dave that a and bconstitute a valid signature (1) Dave chooses a random u and v, both less than p, and sends Carol k = guav mod p (2) Carol chooses a random w, less than p, and sends Dave l = gw mod p y = (kl)z mod p (3) Dave sends Carol u and v (4) Carol confirms that guav ≡ k (mod p) Then she sends Dave w (5) Dave confirms that gw ≡ l (mod p) y/hw ≡ hubv (mod p) If they both check out, he accepts the signature as genuine In another protocol Carol can convert the designated-confirmer protocol into a conventional digital signature See [333] for details Previous Table of Contents Next Previous Table of Contents Next 24.6 KryptoKnight KryptoKnight (Kryptonite—get it?) is an authentication and key distribution system designed by IBM It is a secret-key protocol and uses either DES in CBC mode (see Section 9.3) or a modified version of MD5 (see Section 18.5) KryptoKnight supports four security services: — User authentication (called single sign-on) — Two-party authentication — Key distribution — Authentication of data origin and content From a user’s perspective, KryptoKnight is similar to Kerberos Some differences are: — KryptoKnight uses a hash function for authentication and encrypting tickets — KryptoKnight does not rely on synchronized clocks; it uses nonces for challenges (see Section 3.3) — If Alice wishes to communicate with Bob, KryptoKnight has the option of allowing Alice to send a message to Bob and then for Bob to initiate the key exchange protocol KryptoKnight has tickets and authenticators, just like Kerberos It has TGSs, but KryptoKnight calls them authentication servers KryptoKnight’s designers spent considerable effort minimizing the number of messages, lengths of messages, and amount of encryption For further information on KryptoKnight, read [1110, 173, 174, 175] 24.7 SESAME SESAME stands for Secure European System for Applications in a Multivendor Environment It’s a European Community security project, 50 percent funded by RACE (see Section 25.7), whose primary objective is producing technology for user authentication with distributed access control Think of it as kind of a European version of Kerberos It’s a two-part project: Stage one is a basic prototype of the architecture, and stage two is a set of commercial projects The three companies with the greatest hand in development are ICL in the United Kingdom, Siemens in Germany, and Bull in France SESAME is an authentication and key-exchange system [361, 1248, 797, 1043] It uses the Needham-Schroeder protocol, with public-key cryptography to communicate between different security domains The system is seriously flawed in several respects Instead of using a real encryption algorithm, they use XOR with a 64-bit key size Even worse, they use XOR in CBC mode, which leaves half the plaintext unencrypted In their defense, they planned on using DES until the French government complained; they validated the code with DES but then removed it, and expect people to add it back I am unimpressed nonetheless Authentication in SESAME is a function on the first block of a message, not on the entire message This has the effect of authenticating “Dear Sir” and not the body of a letter Key generation consists of two calls to the UNIX rand function, which isn’t very random SESAME uses crc32 and MD5 as one-way hash functions And of course, SESAME is vulnerable to Kerberos-like passwordguessing 24.8 IBM Common Cryptographic Architecture The Common Cryptographic Architecture (CCA) was designed and developed by IBM to provide cryptographic primitives for confidentiality, integrity, key management, and personal identification number (PIN) processing [751, 784, 1025, 1026, 940,752] Keys are managed by control vectors (CVs) (see Section 8.5) Every key has a CV XORed with it and is never separated from the vector unless inside secure hardware The CV is a data structure providing an intuitive understanding of the privileges associated with a particular key The individual bits of the CV are defined to have specific meanings for using and handling each key managed by CCA The CV is carried with the encrypted key in data structures called key tokens Internal key tokens are used locally and contain keys encrypted under the local master key (MK) External key tokens are used to export and import encrypted keys between systems Keys in external key tokens are encrypted under key-encrypting keys (KEK) The KEKs are managed in internal key tokens Keys are separated according to their permitted uses Key length is also specified and enforced using bits in the CV Single length keys are 56 bits and are used for such functions as privacy and message authentication Double length keys are 112 bits and are used for key management, PIN functions, and other special uses Keys can be required to be DOUBLE-ONLY in which both the left and right halves of the key must be different, DOUBLE in which the halves are permitted to be equal by chance, SINGLE-REPLICATED in which the left and right halves are equal, or SINGLE which contains only 56 bits The CCA functions specify hardware enforcement of certain key types to be used for some operations The CV is checked in a secure hardware processor: It must conform to the permitted CCA rules for each CCA function If the CV successfully passes the test requirements, a variant of the KEK or MK is obtained by the XOR of the KEK or MK with the CV, and the plaintext target key is recovered for use internally with the CCA function When new keys are generated, the CV specifies the uses of the generated key Those combinations of key types that could be used in attacking the system are not generated or imported into a CCAcompliant system CCA uses a combination of public-key cryptography and secret-key cryptography for key distribution The KDC shares a secret master key with each user and encrypts session keys using that master key Master keys are distributed using public-key cryptography The system’s designers chose this hybrid approach for two reasons The first is performance Public-key cryptography is computationally intensive; if session keys are distributed using public-key cryptography, the system might bog down The second is backwards compatibility; this system can be overlaid on existing secret-key schemes with minimal disruption CCA systems are designed to be interoperable For systems that are non-CCA compliant, a Control Vector Translate (CVXLT) function permits keys to be passed between the two implementations Initialization of the CVXLT function requires dual control Two individuals must set up the required translation tables independently Such dual control provides a high degree of assurance concerning the integrity and pedigree of any keys introduced into the system A key of type DATA is provided for compatibility with other systems A DATA key is stored with a CV that identifies the key as a DATA key DATA keys can have broad uses and as such must be regarded with suspicion and used with care DATA keys may not be used for any key management functions The Commercial Data Masking Facility (CDMF) provides an exportable version of CCA It has a special feature that reduces DES keys to an effective 40 bits for export (see Section 15.5) [785] 24.9 ISO Authentication Framework Public-key cryptography has been recommended for use with the ISO authentication framework, also known as the X.509 protocols [304] This framework provides for authentication across networks Although no particular algorithms are specified for either security or authentication, the specification recommends RSA There are provisions, however, for multiple algorithms and hash functions X.509 was initially issued in 1988 After public review and comment, it was revised in 1993 to correct some security problems [1100, 750] Figure 24.2 An X.509 certificate Previous Table of Contents Next Previous Table of Contents Next 25.7 RACE Integrity Primitives Evaluation (RIPE) The Research and Development in Advanced Communication Technologies in Europe (RACE) program was launched by the European Community to support pre-competitive and pre-normative work in communications standards and technologies to support Integrated Broadband Communication (IBC) As part of that effort, RACE established the RACE Integrity Primitives Evaluation (RIPE) to put together a portfolio of techniques to meet the anticipated security requirements of IBC Six leading European cryptography research groups made up the RIPE consortium: Center for Mathematics and Computer Science, Amsterdam; Siemens AG; Philips Crypto BV; Royal PTT Nederland NV, PTT Research; Katholieke Universiteit Leuven; and Aarhus Universitet After calls for algorithms in 1989 and 1991 [1564], 32 submissions from around the world, and a 350 man-month evaluation project, the consortium published RIPE Integrity Primitives [1305,1332] The report included an introduction and some basic integrity concepts, and these primitives: MDC-4 (see Section 18.11), RIPE-MD (see Section 18.8), RIPE-MAC (see Section 18.14), IBC-HASH, SKID (see Section 3.2), RSA, COMSET (see Section 16.1), and RSA key generation 25.8 Conditional Access for Europe (CAFE) Conditional Access for Europe (CAFE) is a project in the European Community’s ESPRIT program [204,205] Work began in December 1992 and is scheduled to be finished by the end of 1995 The consortium involved consists of groups for social and market studies (Cardware, Institut für Sozialforschung), software and hardware manufacturers (DigiCash, Gemplus, Ingenico, Siemens), and cryptographers (CWI Amsterdam, PTT Research Netherlands, SPET, Sintef Delab Trondheim, Universities of Århus, Hildesheim and Leuven) The goal is to develop systems for conditional access, particularly digital payment systems Payment systems must give legal certainty to everybody at all times and require as little trust as possible—this certainty should not depend on the tamper-resistance of any devices The basic device for CAFE is an electronic wallet: a small computer that looks something like a pocket calculator It has a battery, keyboard, screen, and an infrared channel for communicating with other wallets Every user owns and uses his own wallet, which administers his rights and guarantees his security A device with a keyboard and screen has an advantage over a smart card; it can operate independent of a terminal A user can directly enter his password and the amount of the payment The user does not have to give his wallet up to complete a transaction, unlike the current situation with credit cards Additional features are: — Offline transactions The purpose of the system is to replace small cash transactions; an online system would be too cumbersome — Loss tolerance If a user loses his wallet, or if it breaks or is stolen, he can recover his money — Support for different currencies — An open architecture and open system A user should be able to pay for arbitrary services, such as shopping, telephone, and public transport, by a range of service providers The system should be interoperable between any number of electronic money issuers, and between different wallet types and manufacturers — Low cost At this writing there is a software version of the system, and the consortium is hard at work on a hardware prototype 25.9 ISO/IEC 9979 In the mid-80s, the ISO tried to standardize DES, which by then was already a FIPS and an ANSI standard After some political wrangling, the ISO decided not to standardize cryptographic algorithms, but instead to register algorithms Only encryption algorithms can be registered; hash functions and signature schemes cannot Any national body can submit an algorithm for registration Currently only three algorithms have been submitted (see Table 25.4) A submission includes information about applications, parameters, implementations, modes, and test vectors A detailed description is optional; it is possible to submit secret algorithms for registration The fact that an algorithm is registered does not imply anything about its quality, nor is registration an approval of the algorithm by the ISO/IEC Registration merely indicates that a single national body wants to register the algorithm, based on whatever criteria that body uses I am not impressed with this idea Registration obstructs the standardization process Rather than agreeing on a few algorithms, the ISO is allowing any algorithm to be registered With so little control over what is registered, stating that an algorithm is “ISO/IEC 9979 Registered” sounds a whole lot better than it is In any case, the registry is maintained by the National Computer Centre Ltd., Oxford Road, Manchester, M1 7ED, United Kingdom Table 25.4 ISO/IEC 9979 Registered Algorithms Name B-CRYPT IDEA LUC Registration Number 0001 0002 0003 25.10 Professional, Civil Liberties, and Industry Groups Electronic Privacy Information Center (EPIC) EPIC was established in 1994 to focus public attention on emerging privacy issues relating to the National Information Infrastructure, such as the Clipper chip, the Digital Telephony proposal, national identity numbers and systems, medical records privacy, and the sale of consumer data EPIC conducts litigation, sponsors conferences, produces reports, publishes the EPIC Alert, and leads campaigns on privacy issues Anyone interested in joining should contact Electronic Privacy Information Center, 666 Pennsylvania Avenue SE, Suite 301, Washington, D.C 20003; (202) 544-9240; fax: (202) 547-5482; Internet: info@epic.org Previous Table of Contents Next ... Table of Contents Next Applied Cryptography, Second Edition: Protocols, Algorthms, and Source Code in C (Publisher: John Wiley & Sons, Inc.) Author(s): Bruce Schneier ISBN: 0471128457 Publication Date: 01/01/96... code than I could fit in this book; it is probably the largest collection of cryptographic source code outside a military institution I can only send source code disks to U.S and Canadian citizens living in the U.S and Canada, but hopefully that will change someday... code, but denied export for a computer disk with the exact same source code on it Go figure.) An associated source code disk set includes much more source code than I could fit in this book; it is probably the largest collection of