Handbook of Local Area Networks, 1998 Edition:LAN Security Click Here! Search the site:   ITLibrary ITKnowledge EXPERT SEARCH Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info Previous Table of Contents Next How Hard Is It to Break the Code? There are two possible approaches to defeating the RSA algorithm. The first is the brute-force approach: trying all possible private keys. Thus the larger the number of bits in e and d, the more secure the algorithm. However, because the calculations involved, both in key generation and in encryption/decryption, are complex. The larger the size of the key, the slower the system will run. Most discussions of the cryptanalysis of RSA have focused on the task of factoring p into its two prime factors. Until recently, this was considered infeasible for numbers in the range of 100 decimal digits, which is about 300 or more bits. To demonstrate the strength of RSA, its three developers issued a challenge to decrypt a message that was encrypted using a 129-decimal-digit number as their public modulus. The authors predicted that it would take 40 quadrillion years with current technology to crack the code. Recently, the code was cracked by a worldwide team cooperating over the Internet and using more than 1,600 computers after only eight months of work. This result does not invalidate the use of RSA; it simply means that larger key sizes must be used. Currently, a 1,024-bit key size (about 300 decimal digits), is considered strong enough for virtually all applications. HOW PGP WORKS Digital Signature It may seem that RSA is all that is needed for a secure E-mail facility. Everyone who wants to use PGP can create a matching pair of keys (PGP will do the necessary calculation) and then distribute the public key. To send a message, it must first be encrypted with the private key to guarantee its authenticity. Next, the result of step one must be encrypted with the recipient’s public key to guarantee that no one else can read the message. This scheme is technically valid but impractical. The problem is that RSA, and all other public-key schemes, are very slow. To double-encrypt messages of arbitrary length is far too time-consuming. Users could experience delays of minutes or even hours waiting for their PCs to do the number-crunching. Instead, PGP exploits the strengths of conventional and public-key encryption. When a message is sent, it goes through two security-related stages of processing: digital signature and encryption. The digital signature is one of the most clever innovations to come out of the work on public-key encryption. To use digital signature, users take the message that they want to send and map it into a fixed-length code of 128 bits. The algorithm for doing this is called MD5 (message digest version 5). The 128-bit message digest is unique for this message. It would be virtually impossible for someone to alter this message or substitute another message and still come up with the same digest. PGP then encrypts the digest using RSA and the sender’s private key. The result is the digital signature, which is attached to the message. Anyone who gets this message can re-compute the message digest and then decrypt the signature using RSA and the sender’s public key. If the message digest in the signature matches the message digest that was calculated, then the signature is valid. Because this operation only involves encrypting and decrypting a 128-bit block, it takes little time. For the encryption stage, PGP randomly generates a 128-bit secret key and uses IDEA to encrypt the message plus the attached signature. The recipient can discover the secret key by using RSA. PGP takes the secret key as input to RSA, using the receiver’s public key, and produces an encrypted secret key that is attached to the message. On the receiving end, PGP uses the receiver’s private key to recover the secret key and then uses the secret key and IDEA to recover the plaintext message plus signature. Getting Public Keys Public-key encryption techniques make use of two keys for each user: a private key that is known only to one user, and a corresponding public key that is made known to all users. With these two keys, it is possible to create digital signatures that guarantee the authenticity of a message and to support the encryption of a message in such a way that only the intended recipient can read it. There is, however, a common misconception that each user simply keeps his or her private key private and publishes the corresponding public key. Unfortunately, this is not a simple solution. An impostor can generate a public- and private-key pair and disseminate the public key as if it were someone else’s. For example, suppose that user A wishes to send a secure message to user B. Meanwhile, user C has generated a public- and private-key pair, attached user B’s name and an E-mail address that user C can access, and published this key widely. User A has picked this key up, uses the key to prepare her message for user B, and uses the attached E-mail address to send the message. Result: user C receives and can decrypt the message; user B either never receives the message or could not read it without holding the required private key. One way around this problem is to insist on the secure exchange of public keys. For example, if user B and user A know each other personally and live near each other, they could physically exchange keys on diskettes. But for PGP to be useful as a general-purpose E-mail security utility, it must be possible for people in widely distributed sites to exchange keys with others that they have never met and may not even know. Previous Table of Contents Next Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.