RFC 3871           Operational Security Requirements      September 2004

      use non open cryptographic algorithms.  They should be allowed to

      evaluate the trade offs and make an informed choice between open

      and non open cryptography.  See [Schneier] for further discussion.

   Examples.

      The following are some algorithms that satisfy the requirement at

      the time of writing: AES [FIPS.197], and 3DES [ANSI.X9 52.1998]

      for applications requiring symmetric encryption; RSA [RFC3447] and

      Diffie Hellman [PKCS.3.1993], [RFC2631] for applications requiring

      key exchange; HMAC [RFC2401] with SHA 1 [RFC3174] for applications

      requiring message verification.

   Warnings.

      This list is not exhaustive.  Other strong, well reviewed

      algorithms may meet the requirement.  The dynamic nature of the

      field means that what is good enough today may not be in the

      future.

      Open review is necessary but not sufficient.  The strength of the

      algorithm and key length must also be considered.  For example,

      56 bit DES meets the open review requirement, but is today

      considered too weak and is therefore not recommended.

2.2.2.  Use Strong Cryptography

   Requirement.

      If cryptography is used to meet the secure management channel

      requirements, then the key lengths and algorithms SHOULD be

      "strong".

   Justification.

      Short keys and weak algorithms threaten the confidentiality and

      integrity of communications.

   Examples.

      The following algorithms satisfy the requirement at the time of

      writing: AES [FIPS.197], and 3DES [ANSI.X9 52.1998] for

      applications requiring symmetric encryption; RSA [RFC3447] and

      Diffie Hellman [PKCS.3.1993], [RFC2631] for applications requiring

      key exchange; HMAC [RFC2401] with SHA 1 [RFC3174] for applications

      requiring message verification.

Jones                        Informational                     [Page 13]