RSA Cryptography Today FAQ (2/3)


    Archive-name: cryptography-faq/rsa/part2
    Last-modified: 93/09/20
    Version: 2.0
    Distribution-agent: tmp@netcom.com

    (This document has been brought to you in part by CRAM. See the bottom for more information, including instructions on how to obtain updates.)

    
    			  Answers To
    		 FREQUENTLY ASKED QUESTIONS
    		 About Today's Cryptography
    
    
    
    			  Paul Fahn
    		      RSA Laboratories
    		     100 Marine Parkway
    		   Redwood City, CA  94065
    
    
    
       Copyright (c) 1993 RSA Laboratories, a division of RSA Data Security,
          Inc. All rights reserved.
    
       Version 2.0, draft 2f
       Last update: September 20, 1993
    
    
    
    ------------------------------------------------------------------------
    			 Table of Contents
    
    [ part 2 ]
    
    3 Key Management 
           3.1  What key management issues are involved in public-key 
    	    cryptography? 
           3.2  Who needs a key? 
           3.3  How does one get a key pair? 
           3.4  Should a public key or private key be shared among users? 
           3.5  What are certificates? 
           3.6  How are certificates used? 
           3.7  Who issues certificates and how? 
           3.8  What is a CSU, or, How do certifying authorities store their 
    	    private keys? 
           3.9  Are certifying authorities susceptible to attack? 
           3.10  What if the certifying authority's key is lost or compromised? 
           3.11  What are Certificate Revocation Lists (CRLs)? 
           3.12  What happens when a key expires? 
           3.13  What happens if I lose my private key? 
           3.14  What happens if my private key is compromised? 
           3.15  How should I store my private key? 
           3.16  How do I find someone else's public key? 
           3.17  How can signatures remain valid beyond the expiration dates of 
    	     their keys, or, How do you verify a 20-year-old signature? 
           3.18  What is a digital time-stamping service? 
    
    4 Factoring and Discrete Log 
           4.1  What is a one-way function? 
           4.2  What is the significance of one-way functions for cryptography? 
           4.3  What is the factoring problem? 
           4.4  What is the significance of factoring in cryptography? 
           4.5  Has factoring been getting easier? 
           4.6  What are the best factoring methods in use today? 
           4.7  What are the prospects for theoretical factoring breakthroughs? 
           4.8  What is the RSA Factoring Challenge? 
           4.9  What is the discrete log problem? 
           4.10  Which is easier, factoring or discrete log? 
    
    5 DES 
           5.1  What is DES? 
           5.2  Has DES been broken? 
           5.3  How does one use DES securely? 
           5.4  Can DES be exported from the U.S.? 
           5.5  What are the alternatives to DES? 
           5.6  Is DES a group? 
    
    
    --------------------------------------------------------------------
    
    
    
    3 Key Management
    
    3.1 What key management issues are involved in public-key cryptography?
    
    Secure methods of key management are extremely important. In practice,
    most attacks on public-key systems will probably be aimed at the key 
    management levels, rather than at the cryptographic algorithm itself. 
    The key management issues mentioned here are discussed in detail in 
    later questions.
    
    Users must be able to obtain securely a key pair suited to their efficiency 
    and security needs. There must be a way to look up other people's public 
    keys and to publicize one's own key. Users must have confidence in the 
    legitimacy of others' public keys; otherwise an intruder can either change 
    public keys listed in a directory, or impersonate another user. Certificates 
    are used for this purpose. Certificates must be unforgeable, obtainable in a 
    secure manner, and processed in such a way that an intruder cannot misuse 
    them. The issuance of certificates must proceed in a secure way, impervious 
    to attack. If someone's private key is lost or compromised, others must be 
    made aware of this, so that they will no longer encrypt messages under the 
    invalid public key nor accept messages signed with the invalid private key. 
    Users must be able to store their private keys securely, so that no intruder 
    can find it, yet the keys must be readily accessible for legitimate use. Keys 
    need to be valid only until a specified expiration date. The expiration date 
    must be chosen properly and publicized securely. Some documents need to have 
    verifiable signatures beyond the time when the key used to sign them has 
    expired.
    
    Although most of these key management issues arise in any public-key 
    cryptosystem, for convenience they are discussed here in the context of RSA.
    
    
    3.2 Who needs a key?
    
    Anyone who wishes to sign messages or to receive encrypted messages must
    have a key pair. People may have more than one key. For example, someone
    might have a key affiliated with his or her work and a separate key for
    personal use. Other entities will also have keys, including electronic 
    entities such as modems, workstations, and printers, as well as 
    organizational entities such as a corporate department, a hotel 
    registration desk, or a university registrar's office. 
    
    
    3.3 How does one get a key pair? 
    
    Each user should generate his or her own key pair. It may be tempting within 
    an organization to have a single site that generates keys for all members who 
    request one, but this is a security risk because it involves the transmission 
    of private keys over a network as well as catastrophic consequences if an 
    attacker infiltrates the key-generation site. Each node on a network should be
    capable of local key generation, so that private keys are never transmitted 
    and no external key source need be trusted. Of course, the local key generation
    software must itself be trustworthy. Secret-key authentication systems, such 
    as Kerberos, often do not allow local key generation but instead use a 
    central server to generate keys.
    
    Once generated, a user must register his or her public key with some
    central administration, called a certifying authority. The certifying 
    authority returns to the user a certificate attesting to the veracity of 
    the user's public key along with other information (see Questions 3.5 
    and following). Most users should not obtain more than one certificate for
    the same key, in order to simplify various bookkeeping tasks associated
    with the key.
    
    
    3.4 Should a public key or private key be shared among users?
    
    In RSA, each person should have a unique modulus and private exponent, i.e., 
    a unique private key. The public exponent, on the other hand, can be common 
    to a group of users without security being compromised. Some public exponents 
    in common use today are 3 and 2^{16}+1; because these numbers are small, 
    the public-key operations (encryption and signature verification) are fast 
    relative to the private key operations (decryption and signing). If one 
    public exponent becomes a standard, software and hardware can be optimized 
    for that value.
    
    In public-key systems based on discrete logarithms, such as ElGamal,
    Diffie-Hellman, or DSS, it has often been suggested that a group of 
    people should share a modulus. This would make breaking a key more
    attractive to an attacker, however, because one could break every
    key with only slightly more effort than it would take to break a
    single key. To an attacker, therefore, the average cost to break a 
    key is much lower with a common modulus than if every key has a distinct 
    modulus. Thus one should be very cautious about using a common modulus; 
    if a common modulus is chosen, it should be very large. 
    
    
    3.5 What are certificates?
    
    Certificates are digital documents attesting to the binding of a public key 
    to an individual or other entity. They allow verification of the claim that 
    a given public key does in fact belong to a given individual. Certificates 
    help prevent someone from using a phony key to impersonate someone else.
    
    In their simplest form, certificates contain a public key and a name. As
    commonly used, they also contain the expiration date of the key, the name 
    of the certifying authority that issued the certificate, the serial number 
    of the certificate, and perhaps other information. Most importantly, it 
    contains the digital signature of the certificate issuer. The most widely 
    accepted format for certificates is defined by the CCITT X.509 international 
    standard [19]; thus certificates can be read or written by any application 
    complying with X.509. Further refinements are found in the PKCS set of 
    standards (see Question 8.9), and the PEM standard (see Question 8.7). A 
    detailed discussion of certificate format can also be found in Kent [40].
    
    A certificate is issued by a certifying authority (see Question 3.7) 
    and signed with the certifying authority's private key.
    
    
    3.6 How are certificates used?
    
    A certificate is displayed in order to generate confidence in the 
    legitimacy of a public key. Someone verifying a signature can also 
    verify the signer's certificate, to insure that no forgery or false 
    representation has occurred. These steps can be performed with greater 
    or lesser rigor depending on the context. 
    
    The most secure use of authentication involves enclosing one or more 
    certificates with every signed message. The receiver of the message
    would verify the certificate using the certifying authority's public
    key and, now confident of the public key of the sender, verify the message's 
    signature. There may be two or more certificates enclosed with the message, 
    forming a hierarchical chain, wherein one certificate testifies to the 
    authenticity of the previous certificate. At the end of a certificate 
    hierarchy is a top-level certifying authority, which is trusted without a 
    certificate from any other certifying authority. The public key of the 
    top-level certifying authority must be independently known, for example by 
    being widely published.
    
    The more familiar the sender is to the receiver of the message, the less 
    need there is to enclose, and to verify, certificates. If Alice sends 
    messages to Bob every day, Alice can enclose a certificate chain on the 
    first day, which Bob verifies. Bob thereafter stores Alice's public key 
    and no more certificates or certificate verifications are necessary. A sender 
    whose company is known to the receiver may need to enclose only one 
    certificate (issued by the company), whereas a sender whose company is 
    unknown to the receiver may need to enclose two certificates. A good rule of 
    thumb is to enclose just enough of a certificate chain so that the issuer of 
    the highest level certificate in the chain is well-known to the receiver.
    
    According to the PKCS standards for public-key cryptography (see Question
    8.9), every signature points to a certificate that validates the public 
    key of the signer. Specifically, each signature contains the name of the 
    issuer of the certificate and the serial number of the certificate. Thus 
    even if no certificates are enclosed with a message, a verifier can still 
    use the certificate chain to check the status of the public key.
    
    
    3.7 Who issues certificates and how?
    
    Certificates are issued by a certifying authority (CA), which can be any 
    trusted central administration willing to vouch for the identities of those 
    to whom it issues certificates. A company may issue certificates to its 
    employees, a university to its students, a town to its citizens. In 
    order to prevent forged certificates, the CA's public key must be trustworthy: 
    a CA must either publicize its public key or provide a certificate from a 
    higher-level CA attesting to the validity of its public key. The latter
    solution gives rise to hierarchies of CAs.
    
    Certificate issuance proceeds as follows. Alice generates her own key 
    pair and sends the public key to an appropriate CA with some proof of her 
    identification. The CA checks the identification and takes any other steps
    necessary to assure itself that the request really did come from Alice, and 
    then sends her a certificate attesting to the binding between Alice and her 
    public key, along with a hierarchy of certificates verifying the CA's public 
    key. Alice can present this certificate chain whenever desired in order to 
    demonstrate the legitimacy of her public key. 
    
    Since the CA must check for proper identification, organizations will find 
    it convenient to act as a CA for its own members and employees. There will 
    also be CAs that issue certificates to unaffiliated individuals.
    
    Different CAs may issue certificates with varying levels of identification 
    requirements. One CA may insist on seeing a driver's license, another may 
    want the certificate request form to be notarized, yet another may want 
    fingerprints of anyone requesting a certificate. Each CA should publish 
    its own identification requirements and standards, so that verifiers 
    can attach the appropriate level of confidence in the certified name-key 
    bindings.
    
    An example of a certificate-issuing protocol is Apple Computer's Open 
    Collaborative Environment (OCE). Apple OCE users can generate a key 
    pair and then request and receive a certificate for the public key; the
    certificate request must be notarized.
    
    
    3.8 What is a CSU, or, How do certifying authorities store their private keys?
    
    It is extremely important that private keys of certifying authorities are 
    stored securely, because compromise would enable undetectable forgeries. 
    One way to achieve the desired security is to store the key in a tamperproof
    box; such a box is called a Certificate Signing Unit, or CSU. The CSU would, 
    preferably, destroy its contents if ever opened, and be shielded against 
    attacks using electromagnetic radiation. Not even employees of the certifying 
    authority should have access to the private key itself, but only the ability 
    to use the private key in the process of issuing certificates. 
    
    There are many possible designs for CSUs; here is a description of one design
    found in some current implementations. The CSU is activated by a set of data 
    keys, which are physical keys capable of storing digital information. The 
    data keys use secret-sharing technology such that several people must all 
    use their data keys to activate the CSU. This prevents one disgruntled CA 
    employee from producing phony certificates. 
    
    Note that if the CSU is destroyed, say in a fire, no security is compromised.
    Certificates signed by the CSU are still valid, as long as the verifier uses 
    the correct public key. Some CSUs will be manufactured so that a lost private 
    key can be restored into a new CSU. See Question 3.10 for discussion of 
    lost CA private keys.
    
    Bolt, Beranek, and Newman (BBN) currently sells a CSU, and RSA Data Security
    sells a full-fledged certificate issuing system built around the BBN CSU.
    
    
    3.9 Are certifying authorities susceptible to attack?
    
    One can think of many attacks aimed at the certifying authority, which must
    be prepared against them.
    
    Consider the following attack. Suppose Bob wishes to impersonate Alice. 
    If Bob can convincingly sign messages as Alice, he can send a message to 
    Alice's bank saying ``I wish to withdraw $10,000 from my account. Please 
    send me the money.'' To carry out this attack, Bob generates a key pair and 
    sends the public key to a certifying authority saying ``I'm Alice. Here is 
    my public key. Please send me a certificate.'' If the CA is fooled and sends 
    him such a certificate, he can then fool the bank, and his attack will 
    succeed. In order to prevent such an attack the CA must verify that a 
    certificate request did indeed come from its purported author, i.e., it must 
    require sufficient evidence that it is actually Alice who is requesting the 
    certificate. The CA may, for example, require Alice to appear in person and 
    show a birth certificate. Some CAs may require very little identification, 
    but the bank should not honor messages authenticated with such low-assurance 
    certificates. Every CA must publicly state its identification requirements 
    and policies; others can then attach an appropriate level of confidence to 
    the certificates.
    
    An attacker who discovers the private key of a certifying authority could 
    then forge certificates. For this reason, a certifying authority must take 
    extreme precautions to prevent illegitimate access to its private key. The 
    private key should be kept in a high-security box, known as a Certificate 
    Signing Unit, or CSU (see Question 3.8).
    
    The certifying authority's public key might be the target of an extensive 
    factoring attack. For this reason, CAs should use very long keys, preferably 
    1000 bits or longer, and should also change keys regularly. Top-level 
    certifying authorities are exceptions: it may not be practical for them to 
    change keys frequently because the key may be written into software used 
    by a large number of verifiers.
    
    In another attack, Alice bribes Bob, who works for the certifying authority, 
    to issue to her a certificate in the name of Fred. Now Alice can send 
    messages signed in Fred's name and anyone receiving such a message will 
    believe it authentic because a full and verifiable certificate chain will 
    accompany the message. This attack can be hindered by requiring the 
    cooperation of two (or more) employees to generate a certificate; the 
    attacker now has to bribe two employees rather than one. For example, in 
    some of today's CSUs, three employees must each insert a data key containing 
    secret information in order to authorize the CSU to generate certificates. 
    Unfortunately, there may be other ways to generate a forged certificate by 
    bribing only one employee. If each certificate request is checked by only 
    one employee, that one employee can be bribed and slip a false request into 
    a stack of real certificate requests. Note that a corrupt employee cannot 
    reveal the certifying authority's private key, as long as it is properly 
    stored.
    
    Another attack involves forging old documents. Alice tries to factor the 
    modulus of the certifying authority. It takes her 15 years, but she finally 
    succeeds, and she now has the old private key of the certifying authority. 
    The key has long since expired, but she can forge a certificate dated 15 
    years ago attesting to a phony public key of some other person, say Bob; she 
    can now forge a document with a signature of Bob dated 15 year ago, perhaps
    a will leaving everything to Alice. The underlying issue raised by this 
    attack is how to authenticate a signed document dated many years ago; this 
    issue is discussed in Question 3.17.
    
    Note that these attacks on certifying authorities do not threaten the 
    privacy of messages between users, as might result from an attack on a 
    secret-key distribution center.
    
    
    3.10 What if the certifying authority's key is lost or compromised? 
    
    If the certifying authority's key is lost or destroyed but not compromised, 
    certificates signed with the old key are still valid, as long as the verifier
    knows to use the old public key to verify the certificate. 
    
    In some CSU designs, encrypted backup copies of the CA's private key are
    kept. A CA which loses its key can then restore it by loading the encrypted 
    backup into the CSU, which can decrypt it using some unique information 
    stored inside the CSU; the encrypted backup can only be decrypted using the 
    CSU. If the CSU itself is destroyed, the manufacturer may be able to supply 
    another with the same internal information, thus allowing recovery of the key. 
    
    A compromised CA key is a much more dangerous situation. An attacker who 
    discovers a certifying authority's private key can issue phony certificates 
    in the name of the certifying authority, which would enable undetectable 
    forgeries; for this reason, all precautions must be taken to prevent 
    compromise, including those outlined in Questions 3.8 and 3.9. If a 
    compromise does occur, the CA must immediately cease issuing certificates
    under its old key and change to a new key. If it is suspected that some phony 
    certificates were issued, all certificates should be recalled, and then 
    reissued with a new CA key. These measures could be relaxed somewhat if 
    certificates were registered with a digital time-stamping service (see 
    Question 3.18). Note that compromise of a CA key does not invalidate users'
    keys, but only the certificates that authenticate them. Compromise of a 
    top-level CA's key should be considered catastrophic, since the key may 
    be built into applications that verify certificates.
    
    
    3.11 What are Certificate Revocation Lists (CRLs)?
    
    A Certificate Revocation List (CRL) is a list of public keys that have been 
    revoked before their scheduled expiration date. There are several reasons why 
    a key might need to be revoked and placed on a CRL. A key might have been 
    compromised. A key might be used professionally by an individual for 
    a company; for example, the official name associated with a key might be 
    ``Alice Avery, Vice President, Argo Corp.'' If Alice were fired, her company 
    would not want her to be able to sign messages with that key and therefore 
    the company would place the key on the CRL. 
    
    When verifying a signature, one can check the relevant CRL to make sure
    the signer's key has not been revoked. Whether it is worth the time to 
    perform this check depends on the importance of the signed document. 
    
    CRLs are maintained by certifying authorities (CAs) and provide information 
    about revoked keys originally certified by the CA. CRLs only list current 
    keys, since expired keys should not be accepted in any case; when a revoked 
    key is past its original expiration date it is removed from the CRL. Although 
    CRLs are maintained in a distributed manner, there may be central 
    repositories for CRLs, that is, sites on networks containing the latest CRLs 
    from many organizations. An institution like a bank might want an in-house 
    CRL repository to make CRL searches feasible on every transaction.
    
    
    3.12 What happens when a key expires?
    
    In order to guard against a long-term factoring attack, every key must 
    have an expiration date after which it is no longer valid. The time to 
    expiration must therefore be much shorter than the expected factoring time, 
    or equivalently, the key length must be long enough to make the chances of 
    factoring before expiration extremely small. The validity period for a key 
    pair may also depend on the circumstances in which the key will be used, 
    although there will also be a standard period. The validity period, together
    with the value of the key and the estimated strength of an expected attacker, 
    then determines the appropriate key size.
    
    The expiration date of a key accompanies the public key in a certificate
    or a directory listing. The signature verification program should check 
    for expiration and should not accept a message signed with an expired key. 
    This means that when one's own key expires, everything signed with it will
    no longer be considered valid. Of course, there will be cases where it is 
    important that a signed document be considered valid for a much longer period 
    of time; Question 3.17 discusses ways to achieve this.
    
    After expiration, the user chooses a new key, which should be longer than 
    the old key, perhaps by several digits, to reflect both the performance 
    increase of computer hardware and any recent improvements in factoring 
    algorithms. Recommended key length schedules will likely be published. A user 
    may recertify a key that has expired, if it is sufficiently long and has not 
    been compromised. The certifying authority would then issue a new certificate 
    for the same key, and all new signatures would point to the new certificate 
    instead of the old. However, the fact that computer hardware continues to 
    improve argues for replacing expired keys with new, longer keys every few 
    years. Key replacement enables one to take advantage of the hardware 
    improvements to increase the security of the cryptosystem. Faster hardware 
    has the effect of increasing security, perhaps vastly, but only if key 
    lengths are increased regularly (see Question 4.5).
    
    
    3.13 What happens if I lose my private key?
    
    If your private key is lost or destroyed, but not compromised, you can no 
    longer sign or decrypt messages, but anything previously signed with the 
    lost key is still valid. This can happen, for example, if you forget the 
    password used to access your key, or if the disk on which the key is stored 
    is damaged. You need to choose a new key right away, to minimize the number 
    of messages people send you encrypted under your old key, messages which you 
    can no longer read. 
    
    
    3.14 What happens if my private key is compromised?
    
    If your private key is compromised, that is, if you suspect an attacker may 
    have obtained your private key, then you must assume that some enemy can
    read encrypted messages sent to you and forge your name on documents. The 
    seriousness of these consequences underscores the importance of protecting 
    your private key with extremely strong mechanisms (see Question 3.15).
    
    You must immediately notify your certifying authority and have your old key 
    placed on a Certificate Revocation List (see Question 3.11); this will 
    inform people that the key has been revoked. Then choose a new key and obtain
    the proper certificates for it. You may wish to use the new key to re-sign 
    documents that you had signed with the compromised key; documents that had 
    been time-stamped as well as signed might still be valid. You should also 
    change the way you store your private key, to prevent compromise of the new 
    key.
    
    
    3.15 How should I store my private key?
    
    Private keys must be stored securely, since forgery and loss of privacy 
    could result from compromise. The private key should never be stored 
    anywhere in plaintext form. The simplest storage mechanism is to encrypt 
    the private key under a password and store the result on a disk. Of course, 
    the password itself must be maintained with high security, not written down 
    and not easily guessed. Storing the encrypted key on a disk that is not 
    accessible through a computer network, such as a floppy disk or a local 
    hard disk, will make some attacks more difficult. Ultimately, private keys 
    may be stored on portable hardware, such as a smart card. Furthermore, a 
    challenge-response protocol will be more secure than simple password access. 
    Users with extremely high security needs, such as certifying authorities, 
    should use special hardware devices to protect their keys (see Question 
    3.8).
    
    
    3.16 How do I find someone else's public key?
    
    Suppose you want to find Bob's public key. There are several possible ways.
    You could call him up and ask him to send you his public key via e-mail; you 
    could request it via e-mail as well. Certifying authorities may provide
    directory services; if Bob works for company Z, look in the directory kept 
    by Z's certifying authority. Directories must be secure against unauthorized 
    tampering, so that users can be confident that a public key listed in the 
    directory actually belongs to the person listed. Otherwise, you might send 
    private encrypted information to the wrong person.
    
    Eventually, full-fledged directories will arise, serving as online white or 
    yellow pages. If they are compliant with CCITT X.509 standards [19], the 
    directories will contain certificates as well as public keys; the presence 
    of certificates will lower the directories' security needs.
    
    
    3.17 How can signatures remain valid beyond the expiration dates of their
        keys, or, How do you verify a 20-year-old signature?
    
    Normally, a key expires after, say, two years and a document signed with an 
    expired key should not be accepted. However, there are many cases where 
    it is necessary for signed documents to be regarded as legally valid 
    for much longer than two years; long-term leases and contracts are examples. 
    How should these cases be handled? Many solutions have been suggested but 
    it is unclear which will prove the best. Here are some possibilities.
    
    One can have special long-term keys as well as the normal two-year keys. 
    Long-term keys should have much longer modulus lengths and be stored 
    more securely than two-year keys. If a long-term key expires in 50 
    years, any document signed with it would remain valid within that time. 
    A problem with this method is that any compromised key must remain on the 
    relevant CRL until expiration (see Question 3.11); if 50-year keys are 
    routinely placed on CRLs, the CRLs could grow in size to unmanageable 
    proportions. This idea can be modified as follows. Register the long-term 
    key by the normal procedure, i.e., for two years. At expiration time, if 
    it has not been compromised, the key can be recertified, that is, issued 
    a new certificate by the certifying authority, so that the key will be 
    valid for another two years. Now a compromised key only needs to be kept 
    on a CRL for at most two years, not fifty. 
    
    One problem with the previous method is that someone might try to 
    invalidate a long-term contract by refusing to renew his key. This 
    problem can be circumvented by registering the contract with a digital 
    time-stamping service (see Question 3.18) at the time it is originally 
    signed. If all parties to the contract keep a copy of the time-stamp, 
    then each can prove that the contract was signed with valid keys. In 
    fact, the time-stamp can prove the validity of a contract even if one 
    signer's key gets compromised at some point after the contract was 
    signed. This time-stamping solution can work with all signed digital 
    documents, not just multi-party contracts.
    
    
    3.18 What is a digital time-stamping service?
    
    A digital time-stamping service (DTS) issues time-stamps which associate 
    a date and time with a digital document in a cryptographically strong way. 
    The digital time-stamp can be used at a later date to prove that an 
    electronic document existed at the time stated on its time-stamp. For 
    example, a physicist who has a brilliant idea can write about it with
    a word processor and have the document time-stamped. The time-stamp and
    document together can later prove that the scientist deserves the Nobel 
    Prize, even though an arch rival may have been the first to publish.
    
    Here's one way such a system could work. Suppose Alice signs a document 
    and wants it time-stamped. She computes a message digest of the document 
    using a secure hash function (see Question 8.2) and then sends the 
    message digest (but not the document itself) to the DTS, which sends her in 
    return a digital time-stamp consisting of the message digest, the date and 
    time it was received at the DTS, and the signature of the DTS. Since the 
    message digest does not reveal any information about the content of the 
    document, the DTS cannot eavesdrop on the documents it time-stamps. Later, 
    Alice can present the document and time-stamp together to prove when the
    document was written. A verifier computes the message digest of the document, 
    makes sure it matches the digest in the time-stamp, and then verifies the 
    signature of the DTS on the time-stamp.
    
    To be reliable, the time-stamps must not be forgeable. Consider the
    requirements for a DTS of the type just described. First, the DTS itself 
    must have a long key if we want the time-stamps to be reliable for, say,
    several decades. Second, the private key of the DTS must be stored with 
    utmost security, as in a tamperproof box. Third, the date and time must 
    come from a clock, also inside the tamperproof box, which cannot be reset 
    and which will keep accurate time for years or perhaps for decades. Fourth, 
    it must be infeasible to create time-stamps without using the apparatus 
    in the tamperproof box.
    
    A cryptographically strong DTS using only software [4] has been 
    implemented by Bellcore; it avoids many of the requirements just 
    described, such as tamperproof hardware. The Bellcore DTS essentially 
    combines hash values of documents into data structures called binary 
    trees, whose ``root'' values are periodically published in the newspaper. 
    A time-stamp consists of a set of hash values which allow a verifier 
    to recompute the root of the tree. Since the hash functions are one-way 
    (see Question 8.2), the set of validating hash values cannot be forged.
    The time associated with the document by the time-stamp is the date of 
    publication.
    
    The use of a DTS would appear to be extremely important, if not essential, 
    for maintaining the validity of documents over many years (see Question 
    3.17). Suppose a landlord and tenant sign a twenty-year lease. The public 
    keys used to sign the lease will expire after, say, two years; solutions 
    such as recertifying the keys or resigning every two years with new keys 
    require the cooperation of both parties several years after the original 
    signing. If one party becomes dissatisfied with the lease, he or she may 
    refuse to cooperate. The solution is to register the lease with the DTS 
    at the time of the original signing; both parties would then receive a 
    copy of the time-stamp, which can be used years later to enforce the 
    integrity of the original lease.
    
    In the future, it is likely that a DTS will be used for everything
    from long-term corporate contracts to personal diaries and letters.
    Today, if an historian discovers some lost letters of Mark Twain, their
    authenticity is checked by physical means. But a similar find 100 years
    from now may consist of an author's computer files; digital time-stamps 
    may be the only way to authenticate the find.
    
    4 Factoring and Discrete Log
    
    4.1 What is a one-way function?
    
    A one-way function is a mathematical function that is significantly
    easier to perform in one direction (the forward direction) than in the 
    opposite direction (the inverse direction). One might, for example, 
    compute the function in minutes but only be able to compute the inverse 
    in months or years. A trap-door one-way function is a one-way function
    where the inverse direction is easy if you know a certain piece of
    information (the trap door), but difficult otherwise.
    
    
    4.2 What is the significance of one-way functions for cryptography?
    
    Public-key cryptosystems are based on (presumed) trap-door one-way 
    functions. The public key gives information about the particular instance 
    of the function; the private key gives information about the trap door. 
    Whoever knows the trap door can perform the function easily in both
    directions, but anyone lacking the trap door can perform the function only 
    in the forward direction. The forward direction is used for encryption and 
    signature verification; the inverse direction is used for decryption and 
    signature generation.
    
    In almost all public-key systems, the size of the key corresponds to the 
    size of the inputs to the one-way function; the larger the key, the greater
    the difference between the efforts necessary to compute the function in the 
    forward and inverse directions (for someone lacking the trap door). For a 
    digital signature to be secure for years, for example, it is necessary to 
    use a trap-door one-way function with inputs large enough that someone 
    without the trap door would need many years to compute the inverse function.
    
    All practical public-key cryptosystems are based on functions that are 
    believed to be one-way, but have not been proven to be so. This means that 
    it is theoretically possible that an algorithm will be discovered that can 
    compute the inverse function easily without a trap door; this development 
    would render any cryptosystem based on that one-way function insecure and 
    useless. 
    
    
    4.3 What is the factoring problem?
    
    Factoring is the act of splitting an integer into a set of smaller integers
    (factors) which, when multiplied together, form the original integer. 
    For example, the factors of 15 are 3 and 5; the factoring problem is 
    to find 3 and 5 when given 15. Prime factorization requires splitting an 
    integer into factors that are prime numbers; every integer has a unique 
    prime factorization. Multiplying two prime integers together is easy, but 
    as far as we know, factoring the product is much more difficult. 
    
    4.4 What is the significance of factoring in cryptography?
    
    Factoring is the underlying, presumably hard problem upon which several 
    public-key cryptosystems are based, including RSA. Factoring an RSA
    modulus (see Question 2.1) would allow an attacker to figure out 
    the private key; thus, anyone who can factor the modulus can decrypt 
    messages and forge signatures. The security of RSA therefore depends on 
    the factoring problem being difficult. Unfortunately, it has not been 
    proven that factoring must be difficult, and there remains a possibility 
    that a quick and easy factoring method might be discovered (see Question 
    4.7), although factoring researchers consider this possibility remote.
    
    Factoring large numbers takes more time than factoring smaller numbers.
    This is why the size of the modulus in RSA determines how secure an 
    actual use of RSA is; the larger the modulus, the longer it would take
    an attacker to factor, and thus the more resistant to attack the RSA
    implementation is.
    
    
    4.5 Has factoring been getting easier?
    
    Factoring has become easier over the last fifteen years for two reasons:
    computer hardware has become more powerful, and better factoring algorithms 
    have been developed. 
    
    Hardware improvement will continue inexorably, but it is important to 
    realize that hardware improvements make RSA more secure, not less.
    This is because a hardware improvement that allows an attacker to factor
    a number two digits longer than before will at the same time allow 
    a legitimate RSA user to use a key dozens of digits longer than before; 
    a user can choose a new key a dozen digits longer than the old one without
    any performance slowdown, yet a factoring attack will become much more
    difficult. Thus although the hardware improvement does help the attacker, 
    it helps the legitimate user much more. This general rule may fail in the 
    sense that factoring may take place using fast machines of the future, 
    attacking RSA keys of the past; in this scenario, only the attacker gets 
    the advantage of the hardware improvement. This consideration argues for 
    using a larger key size today than one might otherwise consider warranted. 
    It also argues for replacing one's RSA key with a longer key every few 
    years, in order to take advantage of the extra security offered by hardware 
    improvements. This point holds for other public-key systems as well.
    
    Better factoring algorithms have been more help to the RSA attacker than have 
    hardware improvements. As the RSA system, and cryptography in general, have 
    attracted much attention, so has the factoring problem, and many researchers 
    have found new factoring methods or improved upon others. This has made 
    factoring easier, for numbers of any size and irrespective of the speed of 
    the hardware. However, factoring is still a very difficult problem.
    
    Overall, any recent decrease in security due to algorithm improvement can 
    be offset by increasing the key size. In fact, between general computer 
    hardware improvements and special-purpose RSA hardware improvements, 
    increases in key size (maintaining a constant speed of RSA operations) have 
    kept pace or exceeded increases in algorithm efficiency, resulting in no net 
    loss of security. As long as hardware continues to improve at a faster rate 
    than that at which the complexity of factoring algorithms decreases, the 
    security of RSA will increase, assuming RSA users regularly increase their 
    key size by appropriate amounts. The open question is how much faster 
    factoring algorithms can get; there must be some intrinsic limit to 
    factoring speed, but this limit remains unknown.
    
    
    4.6 What are the best factoring methods in use today?
    
    Factoring is a very active field of research among mathematicians and
    computer scientists; the best factoring algorithms are mentioned below 
    with some references and their big-O asymptotic efficiency. O notation 
    measures how fast an algorithm is; it gives an upper bound on the number 
    of operations (to order of magnitude) in terms of n, the number to be 
    factored, and p, a prime factor of n. For textbook treatment of 
    factoring algorithms, see [41], [42], [47],
    and [11]; for a detailed explanation of 
    big-O notation, see [22].
    
    Factoring algorithms come in two flavors, special purpose and general
    purpose; the efficiency of the former depends on the unknown factors, 
    whereas the efficiency of the latter depends on the number to be factored. 
    Special purpose algorithms are best for factoring numbers with small 
    factors, but the numbers used for the modulus in the RSA system do not 
    have any small factors. Therefore, general purpose factoring algorithms 
    are the more important ones in the context of cryptographic systems and 
    their security. 
    
    Special purpose factoring algorithms include the Pollard rho method [66], 
    with expected running time O(sqrt(p)), and the Pollard p-1 method [67], 
    with running time O(p'), where p' is the largest prime factor of p-1. Both 
    of these take an amount of time that is exponential in the size of p, the 
    prime factor that they find; thus these algorithms are too slow for most 
    factoring jobs. The elliptic curve method (ECM) [50] is superior to these; 
    its asymptotic running time is O(exp (sqrt (2 ln p ln ln p)) ). The ECM is 
    often used in practice to find factors of randomly generated numbers; it is 
    not strong enough to factor a large RSA modulus.
    
    The best general purpose factoring algorithm today is the number field 
    sieve [16], which runs in time approximately O(exp ( 1.9 (ln n)^{1/3} 
    (ln ln n)^{2/3}) ). It has only recently been implemented [15], and is 
    not yet practical enough to perform the most desired factorizations. 
    Instead, the most widely used general purpose algorithm is the multiple 
    polynomial quadratic sieve (mpqs) [77], which has running time 
    O(exp ( sqrt (ln n ln ln n)) ). The mpqs (and some of its variations) 
    is the only general purpose algorithm that has successfully factored 
    numbers greater than 110 digits; a variation known as ppmpqs [49]
    has been particularly popular.
    
    It is expected that within a few years the number field sieve will overtake 
    the mpqs as the most widely used factoring algorithm, as the size of the 
    numbers being factored increases from about 120 digits, which is the current 
    threshold of general numbers which can be factored, to 130 or 140 digits. A 
    ``general number'' is one with no special form that might make it easier to 
    factor; an RSA modulus is a general number. Note that a 512-bit number has 
    about 155 digits. 
    
    Numbers that have a special form can already be factored up to 155 digits 
    or more [48]. The Cunningham Project [14] keeps track of the factorizations 
    of numbers with these special forms and maintains a ``10 Most Wanted'' list 
    of desired factorizations. Also, a good way to survey current factoring 
    capability is to look at recent results of the RSA Factoring Challenge 
    (see Question 4.8).
    
    
    4.7 What are the prospects for theoretical factoring breakthroughs?
    
    Although factoring is strongly believed to be a difficult mathematical
    problem, it has not been proved so. Therefore there remains a possibility 
    that an easy factoring algorithm will be discovered. This development, which 
    could seriously weaken RSA, would be highly surprising and the possibility 
    is considered extremely remote by the researchers most actively engaged in 
    factoring research. 
    
    Another possibility is that someone will prove that factoring is difficult.
    This negative breakthrough is probably more likely than the positive 
    breakthrough discussed above, but would also be unexpected at the current 
    state of theoretical factoring research. This development would guarantee 
    the security of RSA beyond a certain key size.
    
    
    4.8 What is the RSA Factoring Challenge?
    
    RSA Data Security Inc. (RSADSI) administers a factoring contest with 
    quarterly cash prizes. Those who factor numbers listed by RSADSI earn
    points toward the prizes; factoring smaller numbers earns more points than
    factoring larger numbers. Results of the contest may be useful to those who 
    wish to know the state of the art in factoring; the results show the size 
    of numbers factored, which algorithms are used, and how much time was 
    required to factor each number. Send e-mail to challenge-info@rsa.com 
    for information. 
    
    
    4.9 What is the discrete log problem?
    
    The discrete log problem, in its most common formulation, is to find
    the exponent x in the formula y=g^x mod p; in other words, it seeks to 
    answer the question, To what power must g be raised in order to obtain 
    y, modulo the prime number p? There are other, more general, formulations 
    as well.
    
    Like the factoring problem, the discrete log problem is believed to be
    difficult and also to be the hard direction of a one-way function. For 
    this reason, it has been the basis of several public-key cryptosystems,
    including the ElGamal system and DSS (see Questions 2.15 and 6.8). The 
    discrete log problem bears the same relation to these systems as factoring 
    does to RSA: the security of these systems rests on the assumption that 
    discrete logs are difficult to compute.
    
    The discrete log problem has received much attention in recent years; 
    descriptions of some of the most efficient algorithms can be found in 
    [47], [21], and [33]. The best discrete log problems have expected 
    running times similar to that of the best factoring algorithms. Rivest 
    [72] has analyzed the expected time to solve discrete log both in terms 
    of computing power and money.
    
    
    4.10 Which is easier, factoring or discrete log?
    
    The asymptotic running time of the best discrete log algorithm is
    approximately the same as for the best general purpose factoring
    algorithm. Therefore, it requires about as much effort to solve
    the discrete log problem modulo a 512-bit prime as to factor a 
    512-bit RSA modulus.  One paper [45] cites experimental evidence 
    that the discrete log problem is slightly harder than factoring: 
    the authors suggest that the effort necessary to factor a 110-digit 
    integer is the same as the effort to solve discrete logarithms modulo 
    a 100-digit prime. This difference is so slight that it should not 
    be a significant consideration when choosing a cryptosystem.
    
    Historically, it has been the case that an algorithmic advance in either 
    problem, factoring or discrete logs, was then applied to the other. This 
    suggests that the degrees of difficulty of both problems are closely 
    linked, and that any breakthrough, either positive or negative, will affect 
    both problems equally.
    
    
    5 DES
    
    5.1 What is DES?
    
    DES is the Data Encryption Standard, an encryption block cipher defined 
    and endorsed by the U.S. government in 1977 as an official standard;
    the details can be found in the official FIPS publication [59]. It was 
    originally developed at IBM. DES has been extensively studied over the 
    last 15 years and is the most well-known and widely used cryptosystem 
    in the world. 
    
    DES is a secret-key, symmetric cryptosystem: when used for communication,
    both sender and receiver must know the same secret key, which is used both
    to encrypt and decrypt the message. DES can also be used for single-user
    encryption, such as to store files on a hard disk in encrypted form. In
    a multi-user environment, secure key distribution may be difficult; 
    public-key cryptography was invented to solve this problem (see Question 
    1.3). DES operates on 64-bit blocks with a 56-bit key. It was designed to 
    be implemented in hardware, and its operation is relatively fast. It works
    well for bulk encryption, that is, for encrypting a large set of data. 
    
    NIST (see Question 7.1) has recertified DES as an official U.S. government 
    encryption standard every five years; DES was last recertified in 1993, 
    by default. NIST has indicated, however, that it may not recertify DES 
    again.
    
    
    5.2 Has DES been broken?
    
    DES has never been ``broken'', despite the efforts of many researchers 
    over many years. The obvious method of attack is brute-force exhaustive 
    search of the key space; this takes 2^{55} steps on average. Early on 
    it was suggested [28] that a rich and powerful enemy could build a 
    special-purpose computer capable of breaking DES by exhaustive search 
    in a reasonable amount of time. Later, Hellman [36] showed a time-memory 
    trade-off that allows improvement over exhaustive search if memory space 
    is plentiful, after an exhaustive precomputation. These ideas fostered 
    doubts about the security of DES. There were also accusations that the 
    NSA had intentionally weakened DES. Despite these suspicions, no feasible 
    way to break DES faster than exhaustive search was discovered. The cost 
    of a specialized computer to perform exhaustive search has been estimated 
    by Wiener at one million dollars [80]. 
    
    Just recently, however, the first attack on DES that is better than 
    exhaustive search was announced by Eli Biham and Adi Shamir [6,7],
    using a new technique known as differential cryptanalysis. This attack 
    requires encryption of 2^{47} chosen plaintexts, i.e., plaintexts chosen 
    by the attacker. Although a theoretical breakthrough, this attack is 
    not practical under normal circumstances because it requires the attacker 
    to have easy access to the DES device in order to encrypt the chosen 
    plaintexts. Another attack, known as linear cryptanalysis [51], does not 
    require chosen plaintexts.
    
    The consensus is that DES, when used properly, is secure against all but
    the most powerful enemies. In fact, triple encryption DES (see Question 
    5.3) may be secure against anyone at all. Biham and Shamir have stated 
    that they consider DES secure. It is used extensively in a wide variety 
    of cryptographic systems, and in fact, most implementations of public-key 
    cryptography include DES at some level. 
    
    
    5.3 How does one use DES securely?
    
    When using DES, there are several practical considerations that can
    affect the security of the encrypted data. One should change DES keys 
    frequently, in order to prevent attacks that require sustained data 
    analysis. In a communications context, one must also find a secure way 
    of communicating the DES key to both sender and receiver. Use of RSA or 
    some other public-key technique for key management solves both these 
    issues: a different DES key is generated for each session, and secure 
    key management is provided by encrypting the DES key with the receiver's 
    RSA public key. RSA, in this circumstance, can be regarded as a tool for 
    improving the security of DES (or any other secret key cipher).
    
    If one wishes to use DES to encrypt files stored on a hard disk, it is
    not feasible to frequently change the DES keys, as this would entail 
    decrypting and then re-encrypting all files upon each key change. Instead,
    one should have a master DES key with which one encrypts the list of DES
    keys used to encrypt the files; one can then change the master key 
    frequently without much effort.
    
    A powerful technique for improving the security of DES is triple encryption, 
    that is, encrypting each message block under three different DES keys in 
    succession. Triple encryption is thought to be equivalent to doubling the 
    key size of DES, to 112 bits, and should prevent decryption by an enemy 
    capable of single-key exhaustive search [53]. Of course, using 
    triple-encryption takes three times as long as single-encryption DES.
    
    Aside from the issues mentioned above, DES can be used for encryption in 
    several officially defined modes. Some are more secure than others. ECB 
    (electronic codebook) mode simply encrypts each 64-bit block of plaintext 
    one after another under the same 56-bit DES key. In CBC (cipher block 
    chaining) mode, each 64-bit plaintext block is XORed with the previous 
    ciphertext block before being encrypted with the DES key. Thus the encryption 
    of each block depends on previous blocks and the same 64-bit plaintext 
    block can encrypt to different ciphertext depending on its context in the 
    overall message. CBC mode helps protect against certain attacks, although 
    not against exhaustive search or differential cryptanalysis. CFB (cipher 
    feedback) mode allows one to use DES with block lengths less than 64 bits. 
    Detailed descriptions of the various DES modes can be found in [60].
    
    In practice, CBC is the most widely used mode of DES, and is specified in 
    several standards. For additional security, one could use triple encryption 
    with CBC, but since single DES in CBC mode is usually considered secure 
    enough, triple encryption is not often used.
    
    
    5.4 Can DES be exported from the U.S.?
    
    Export of DES, either in hardware or software, is strictly regulated by 
    the U.S. State Department and the NSA (see Question 1.6). The government 
    rarely approves export of DES, despite the fact that DES is widely 
    available overseas; financial institutions and foreign subsidiaries of 
    U.S. companies are exceptions. 
    
    
    5.5 What are the alternatives to DES?
    
    Over the years, various bulk encryption algorithms have been designed as 
    alternatives to DES. One is FEAL (Fast Encryption ALgorithm), a cipher for 
    which attacks have been discovered [6], although new versions have been 
    proposed. Another recently proposed cipher designed by Lai and Massey 
    [44] and known as IDEA seems promising, although it has not yet received 
    sufficient scrutiny to instill full confidence in its security. The U.S. 
    government recently announced a new algorithm called Skipjack (see Question 
    6.5) as part of its Capstone project. Skipjack operates on 64-bit blocks of 
    data, as does DES, but uses 80-bit keys, as opposed to 56-bit keys in DES. 
    However, the details of Skipjack are classified, so Skipjack is only 
    available in hardware from government-authorized manufacturers.
    
    Rivest has developed the ciphers RC2 and RC4 (see Question 8.6), which can 
    be made as secure as necessary because they use variable key sizes. Faster 
    than DES, at least in software, they have the further advantage of special 
    U.S. government status whereby the export approval is simplified and 
    expedited if the key size is limited to 40 bits. 
    
    
    5.6 Is DES a group?
    
    It has been frequently asked whether DES encryption is closed under
    composition; i.e., is encrypting a plaintext under one DES key and
    then encrypting the result under another key always equivalent to a 
    single encryption under a single key? Algebraically, is DES a group?
    If so, then DES might be weaker than would otherwise be the case; see 
    [39] for a more complete discussion. However, the answer is no, DES 
    is not a group [18]; this issue was settled only recently, after many 
    years of speculation and circumstantial evidence. This result seems to 
    imply that techniques such as triple encryption do in fact increase 
    the security of DES.
    
    
           --------------------------------------------
    
    RSA Laboratories is the research and consultation division of RSA Data
    Security, Inc., the company founded by the inventors of the RSA
    public-key cryptosystem. RSA Laboratories reviews, designs and
    implements secure and efficient cryptosystems of all kinds. Its
    clients include government agencies, telecommunications companies,
    computer manufacturers, software developers, cable TV broadcasters,
    interactive video manufacturers, and satellite broadcast companies,
    among others.
    
    For more information about RSA Laboratories, call or write to 
    			RSA Laboratories
    			100 Marine Parkway
    			Redwood City, CA 94065
    			(415) 595-7703
    			(415) 595-4126 (fax)
    
    
    
    PKCS, RSAREF and RSA Laboratories are trademarks of RSA Data
    Security, Inc. All other trademarks belong to their respective 
    companies.
    
    This document is available in ASCII, Postscript, and Latex formats
    via anonymous FTP to rsa.com:/pub/faq.
    
    Please send comments and corrections to faq-editor@rsa.com.
    
    
    
    ===
    DISTRIBUTION: How to obtain this document
    
    This document has been brought to you in part by CRAM, involved in the
    redistribution of valuable information to a wider USENET audience (see
    below). The most recent version of this document can be obtained via
    the author's instructions above. The following directions apply to 
    retrieve the possibly less-current USENET FAQ version.
    
      FTP
      ---
        This FAQ is available from the standard FAQ server rtfm.mit.edu via
        FTP in the directory /pub/usenet/news.answers/cryptography-faq/rsa/
    
      Email
      -----
        Email requests for FAQs go to mail-server@rtfm.mit.edu with commands
        on lines in the message body, e.g. `help' and `index'.
    
      Usenet
      ------
        This FAQ is posted every 21 days to the groups
    
          sci.crypt
          talk.politics.crypto
          alt.security.ripem
          sci.answers
          talk.answers
          alt.answers
          news.answers
    
    _ _, _ ___ _, __,  _, _  _, ___ _  _, _, _ _  _, __,  _, _  _ ___ __,
    | |\ | |_ / \ |_)  |\/| / \  |  | / \ |\ | | (_  |_) / \ |  | |_  | )
    | | \| |  \ / | \  |  | |~|  |  | \ / | \| | , ) |   \ / |/\| |   |~\
    ~ ~  ~ ~   ~  ~  ~ ~  ~ ~ ~  ~  ~  ~  ~  ~ ~  ~  ~    ~  ~  ~ ~~~ ~  ~
    
    ===
    CRAM: The Cyberspatial Reality Advancement Movement
    
    In an effort to bring valuable information to the masses, and as a
    service to motivated information compilers, a member of CRAM can help
    others unfamiliar with Usenet `publish' their documents for
    widespread dissemination via the FAQ structure, and act as a
    `sponsor' knowledgable in the submissions process. This document is
    being distributed under this arrangement.
    
    We have found these compilations tend to appear on various mailing
    lists and are valuable enough to deserve wider distribution. If you
    know of an existing compilation of Internet information that is not
    currently a FAQ, please contact us and we may `sponsor' it. The
    benefits to the author include:
    
    - use of the existing FAQ infrastructure for distribution:
      - automated mail server service
      - FTP archival
      - automated posting
    
    - a far wider audience that can improve the quality, accuracy, and 
      coverage of the document enormously through email feedback
    
    - potential professional inquiries for the use of your document in 
      other settings, such as newsletters, books, etc.
    
    - with us as your sponsor, we will also take care of the 
      technicalities in the proper format of the posted version and 
      updating procedures, leaving you free of the `overhead' to focus on 
      the basic updates alone
    
    The choice of who we `sponsor' is entirely arbitrary. You always have
    the option of handling the submission process yourself.  See the FAQ
    submission guidelines FAQ in news.answers. 
    
    For information, send mail to <tmp@netcom.com>.
    
     \   \   \   \   \   \   \   \   \   |   /   /   /   /   /   /   /   /   /   /
    	  _______       ________          _____        _____  _____
    	 ///   \\\      |||   \\\        /// \\\       |||\\\///|||
    	|||     ~~      |||   ///       |||   |||      ||| \\// |||
    	|||     __      |||~~~\\\       |||~~~|||      |||  ~~  |||
    	 \\\   ///      |||    \\\      |||   |||      |||      |||
    	  ~~~~~~~       ~~~     ~~~     ~~~   ~~~      ~~~      ~~~
     /   /   /   /   /   /   /   /   /   |   \   \   \   \   \   \   \   \   \   \
    
    C y b e r s p a t i a l  R e a l i t y  A d v a n c e m e n t  M o v e m e n t
    
    * CIVILIZING CYBERSPACE: send `info cypherwonks' to majordomo@lists.eunet.fi *
    
    
    Return to Cryptosystems Journal Home Page
    Next Page ("RSA FAQ Part 3 of 3")
    Previous Page ("Crypto FAQ") Copyright © 1996 Cryptosystems Journal.
    Most recent update on 28-SEP-96.

    This page is located at the URL http://ourworld.compuserve.com/homepages/crypto/rsafaq02.htm


    E-Mail to: Tony S. Patti, Editor & Publisher.