1 / 10

Howard Weiss NASA/JPL/SPARTA hsw@sparta +1-443-430-8089 January 2007

Authentication Algorithms Discussions CCSDS Security WG Winter 2007 Colorado Springs, Colorado USA. Howard Weiss NASA/JPL/SPARTA hsw@sparta.com +1-443-430-8089 January 2007. Discussion Topics. Future Standards: Authentication/Integrity Encryption Key Management. Previous Agreements.

harvey
Télécharger la présentation

Howard Weiss NASA/JPL/SPARTA hsw@sparta +1-443-430-8089 January 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Authentication Algorithms DiscussionsCCSDS Security WG Winter 2007 Colorado Springs, Colorado USA Howard Weiss NASA/JPL/SPARTA hsw@sparta.com +1-443-430-8089 January 2007

  2. Discussion Topics • Future Standards: • Authentication/Integrity • Encryption • Key Management

  3. Previous Agreements • In Atlanta (Sept 2005) there was consensus to adopt the following algorithms for authentication/integrity: • For digital signature environments: • Digital Signature Algorithm (DSA) per FIPS PUB 186-2 • For non-digital signature environments: • Keyed Hash Message Authentication Code (HMAC) as per FIPS PUB 198a • Baselines SHA-1 hash algorithm but encourages the use of other hash algorithms such as SHA-256, SHA-384, SHA-512, RIPEMD-160, etc.

  4. Revisiting Hash Algorithms • Should we still be promulgating a “new” CCSDS standard using SHA-1 which appears to be falling by the wayside in the community (see following slides)?

  5. Microsoft Dumps SHA-1

  6. NIST Moving to SHA-256 • From NIST Special Pub 800-57 part 1: • Page 64, footnote 22: SHA-1 has recently been demonstrated to provide less than 80 bits of security for digital signatures; at the publication of this Recommendation, the security strength against collisions is assessed at 69 bits. The use of SHA-1 is not recommended for the generation of digital signatures in new systems; new systems should use one of the larger hash functions. For the present time, SHA-1 is included here to reflect it's widespread use in existing systems, for which the reduced security strength may not be of great concern when only 80-bits of security are required.

  7. NIST Comments on Cryptanalytic Attacks on SHA-1 • In 2005 Prof. Xiaoyun Wang announced a differential attack on the SHA-1 hash function; with her recent improvements, this attack is expected to find a hash collision (two messages with the same hash value) with an estimated work of 263 operations, rather than the ideal 280 operations that should be required for SHA-1 or any good 160-bit hash function. This is a very large computation, and to our knowledge nobody has yet verified Prof. Wong’s method by finding a SHA-1 collision, but 263 operations is plainly within the realm of feasibility for a high resource attacker. NIST accepts that Prof. Wang has indeed found a practical collision attack on SHA-1. • NIST held a workshop to consider the status of hash functions on Oct. 31-Nov. 1, 2005 and has reviewed the implications of Prof. Wang’s attack. The attack primarily affects some digital signature applications, including timestamping and certificate signing operations, where one party prepares a message for the generation of a digital signature by a second party, and third parties then verify the signature. There are many applications of hash functions, and many do not require strong collision resistance; for example, keyed hash applications, such as the Hash-based Message Authentication Code (HMAC) or key derivation applications of hash functions do not seem to be affected. • Several steps are now prudent. The first of these is to transition rapidly to the stronger “SHA-2” family of hash functions (SHA-224, SHA-256, SHA-384 and SHA-512) for digital signature applications. The SHA-2 hash functions are in the same general family of hash functions as SHA-1. They could potentially be attacked with similar techniques, but they are much stronger than SHA-1. Practical SHA-2 attacks are unlikely in the next decade; and might never be found, except through decades of exponential growth of available computing power. The SHA-2 hash functions are well along in the commercial system deployment process and are available in many newer systems and applications, but are not yet available in the majority of deployed systems. The primary constraint on the current use of the SHA-2 hash functions for signatures is interoperability; many relying party systems do not yet implement them, and may not do so for several more years. NIST encourages a rapid adoption of the SHA-2 hash functions for digital signatures, and, in any event, Federal agencies must stop relying on digital signatures that are generated using SHA-1 by the end of 2010.

  8. US Govt “Suite B” Algorithms • Encryption: Advanced Encryption Standard (AES) - FIPS 197(with keys sizes of 128 and 256 bits) • Digital Signature: Elliptic Curve Digital Signature Algorithm - FIPS 186-2(using the curves with 256 and 384-bit prime moduli) • Key Exchange: Elliptic Curve Diffie-Hellman or Elliptic Curve MQVDraft NIST Special Publication 800-56(using the curves with 256 and 384-bit prime moduli) • Hashing: Secure Hash Algorithm - FIPS 180-2(using SHA-256 and SHA-384)

  9. What Shall We Do? • Do we stay with the recommendation of SHA-1? • Do we move to one of the larger SHAs (224, 256, 384, 512)? • Do we move now? • Or do we move later (4 years from now)? • Do we move to another (more obscure) hash algorithm such as RIPEMD-160? • Our HMAC w/SHA-1 did not mandate truncation to 96 bits. • If we move to another algorithm (e.g., SHA-224, 256, 384, or 512) do we mandate truncation or leave it as optional?

  10. Discussions/Conclusions

More Related