RFC 3766: Determining Strengths For Public Keys Used For Exchanging Symmetric Keys
In plain English — editorial summary, not part of the RFC
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.
Document record
- Document ID
- RFC3766
- Published
- April 2004
- Authors
- H. Orman; P. Hoffman
- Status
- BEST CURRENT PRACTICE
- Stream
- IETF
- Area
- —
- Pages
- 23
- Also known as
- BCP86
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 3759RObust Header Compression (ROHC): Terminology and Channel Mapping ExamplesCurrent
April 2004
- RFC 3776Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home AgentsUpdated
June 2004
- RFC 3788Security Considerations for Signaling Transport (SIGTRAN) ProtocolsCurrent
June 2004
- RFC 3723Securing Block Storage Protocols over IPUpdated
April 2004
- RFC 3713A Description of the Camellia Encryption AlgorithmCurrent
April 2004
- RFC 3833Threat Analysis of the Domain Name System (DNS)Current
August 2004
- RFC 3658Delegation Signer (DS) Resource Record (RR)Obsoleted
December 2003
- RFC 3657Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)Current
January 2004
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?