BCP 86, RFC 3766 on Determining Strengths For Public Keys Used For Exchanging Symmetric Keys

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A new Request for Comments is now available in online RFC libraries.


        BCP 86
        RFC 3766

        Title:      Determining Strengths For Public Keys Used
                    For Exchanging Symmetric Keys
        Author(s):  H. Orman, P. Hoffman
        Status:     Best Current Practice
        Date:       April 2004
        Mailbox:    hilarie@purplestreak.com, paul.hoffman@vpnc.org
        Pages:      23
        Characters: 55939
        SeeAlso:    BCP 86

        I-D Tag:    draft-orman-public-key-lengths-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3766.txt


Implementors of systems that use public key cryptography to exchange
symmetric keys need to make the public keys resistant to some
predetermined level of attack.  That level of attack resistance is the
strength of the system, and the symmetric keys that are exchanged must
be at least as strong as the system strength requirements.  The three
quantities, system strength, symmetric key strength, and public key
strength, must be consistently matched for any network protocol usage.

While it is fairly easy to express the system strength requirements in
terms of a symmetric key length and to choose a cipher that has a key
length equal to or exceeding that requirement, it is harder to choose
a public key that has a cryptographic strength meeting a symmetric key
strength requirement.  This document explains how to determine the
length of an asymmetric key as a function of a symmetric key strength
requirement.  Some rules of thumb for estimating equivalent resistance
to large-scale attacks on various algorithms are given.  The document 
also addresses how changing the sizes of the underlying large integers
(moduli, group sizes, exponents, and so on) changes the time to use
the algorithms for key exchange.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
<ftp://ftp.isi.edu/in-notes/rfc3766.txt>

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux