This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
SHA-1
SHA-1

Version management

Difference between version and

At line 1 added 63 lines
!!! Overview
Is a [Secure Hash Algorithm] Block [Cipher] [Cryptographic Hash Function] published in 1995 and defined in [RFC 3174] which generates a 160-bit [Hash].
!! About [{$pagename}] Algorithm
[NSA] developed [{$pagename}]. [{$pagename}] is a part of [Secure Hash Algorithm] series and updated version of the forerunner original and short lived [Secure Hash Algorithm] algorithm.
The [{$pagename}] is similar to the earlier [MD5] algorithm and uses a 512-bit block size with a "264 – 1" message size.
In [{$pagename}], if someone changes the part of a [Hash] value, it will produce a different hash value.
%%warning
recent advancements that may indicate a possibility of weakness in the [SHA-1] variant.
%%
!! [{$pagename}] is [Cryptographically Weak]
There have been recent advancements that may indicate a weakening of the SHA-1 variant, but nevertheless there is no evidence to suggest that the way it is used in most applications are under any danger, nor is there any concern about any of the SHA-2 encodings.
In 2005, Bruce Schneier, a cryptographer proved that [{$pagename}] could be broken 2000 times faster than a brute force attack.
In 2012, on base of Moore's law and Amazon web services, Jesse Walker said, [{$pagename}] collision would cost:
* $2M in 2012
* $700K in 2015
* $173K in 2018
* $43K in 2021.
The CA/Browser Forum and [NIST] found [{$pagename}] vulnerable to collision attack and hence, deemed as an [Cryptographically Weak] algorithm which has led to [SHA-1 Deprecation].
[{$pagename}] standard was [Deprecated] for most cryptographic uses after [2010|Year 2010].
Because of these discoveries there has been a [SHA-1 Deprecation] movement.!! Why
The [Hash] value depends on how the certificate is signed. [Certificate Authority] verifies the hash value at the time of [Certificate] issuance.
The [Hash] value of the browser and the [Hash] value of the server should be matched. When hash values match, the server and the identity of a certificate are verified.
However, [{$pagename}] was not able to make accurate identification of both hash value and suspicious to collision attack.
In this case, the attacker might forge a [Certificate] and falsely verify the server’s identity.
!! How [TLS]/[SSL] uses [{$pagename}][1]
! [data] [integrity]
[TLS 1.0] and [TLS 1.1] used [HMAC-SHA1] for data [integrity] in nearly all [Cipher Suites] (a few old ones used [HMAC-MD5] but they have mostly fallen by the wayside already). 1.2 adds some new [Cipher Suites] that use [HMAC-SHA2] ([SHA256] or [SHA384]) and some new [Cipher Suites] that use [AEAD] which combines [integrity] into the [encryption] (specifically [AES] or some others with [GCM], [AES] with [CCM], and [CHACHA20-POLY1305]; in practice only [AES-GCM] and [ChaCha] are common).
The [HMAC] construction blocks collision attacks like the new one for [{$pagename}]. [Cipher Suites] using [HMAC-SHA1] remain as secure now as they were before, and as secure as [HMAC-SHA2] -- which is, not entirely, because there already were and still are attacks unrelated to the hash. Specifically, all [HMAC] [Cipher Suites] either use [RC4], which is badly weakened and __now prohibited__ from all versions of [TLS], or [CBC]-mode ciphers with [MAC]-then-encrypt, which have been subject to a series of padding-oracle attacks -- and in [TLS 1.0] also a known-IV attack ([BEAST]). The fix to these attacks is to use [AEAD] [Cipher Suites] (with neither [HMAC-SHA1] nor [HMAC-SHA2]), which requires [TLS 1.2].
"SHAttered" makes no difference. You should already have preferred [TLS 1.2] with [AEAD] not [HMAC-SHA1] OR [HMAC-SHA2], and you should still.
! [PRF] and key derivation
[TLS 1.0] and [TLS 1.1] used a combination of double-[HMAC-MD5] and double-[HMAC-SHA1] for the [PRF] used in the handshake for key derivation and Finished;
[TLS 1.2] uses double-[HMAC-SHA2]. As above [HMAC] protects against the collision attack, plus the key derivation and Finished data are substantially uncontrollable by an attacker anyway. No difference.
! [Certificates]
[TLS], including [TLS 1.2], usually (though not quite always) relies on [certificates] and their [Digital Signatures], and collision attack can endanger [Certificate Signatures] in at least some cases.
This was true for [MD5] with the 'rogue' attack a decade ago, and resulted in fairly rapid retirement of [MD5] [certificates]. The community has recognized for years that [SHA-1] [certificates] were similarly at risk: [CAs] have been forbidden to issue [SHA-1]-signed [certificates] since at least [2013|Year 2013], depending which authority you go by, and some (most?) [browsers], some other clients and servers, and many tools (notably [SSLLabs] widely used tester) have been warning more or less noisily and intrusively about [SHA-1]-signed [certificates] since [2014] ([SHA-1 Deprecation]); now, as the shattered website notes, some (many?) will soon start rejecting these [certificates].
If you are still using [SHA-1]-signed [certificates]; __stop__. This applies to all versions of [TLS] and also non-[SSL]/[TLS] uses of [certificates] such as email encryption and code signing.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [TLS (and SSL) used or uses SHA-1 in three ways|http://security.stackexchange.com/a/152238/70391|target='_blank'] - based on information obtained 2017-02-24-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop