EMZETT.SHA Types
In short: Overview of the various variants of the “Secure Hash Algorithm” family, which differ in output length and internal construction.
In more detail: SHA-1 (160 bits) has been considered broken since 2017 and should no longer be used. The SHA-2 family (SHA-256, SHA-224, SHA-384, SHA-512) is currently the de-facto standard. SHA-3 is based on a completely different internal construction principle (Keccak/sponge function instead of Merkle-Damgård) and serves as a safeguard in case weaknesses are found in SHA-2 in the future. Which variant to choose depends on the use case: for most purposes, SHA-256 is enough.
In Depth
The three SHA generations at a glance, with their respective security status:
SHA-1 (1995) - 160 bit - BROKEN, no longer use
SHA-2 (2001) - 224-512 bit - current standard (SHA-256, SHA-384, SHA-512, ...)
SHA-3 (2015) - 224-512 bit - backup standard, different internal construction (Keccak)
Why a third generation at all, if SHA-2 is still considered secure? The NSA/NIST wanted to prepare for the possibility that a fundamental attack on the Merkle-Damgård construction, which both SHA-1 and SHA-2 are built on, might be found in the future (it was exactly this construction that ultimately made SHA-1 attackable) — SHA-3 uses a completely different mathematical principle with the “sponge” construction, so that an attack on SHA-2 wouldn’t automatically also affect SHA-3. SHA-3 is therefore a deliberate diversification, not a direct successor meant to replace SHA-2.
In practice you almost exclusively encounter SHA-2 variants (especially SHA-256): TLS certificates, Git commits, package manager signatures and most password-hashing libraries build on it. SHA-3 is so far less actively used, but is, for example, the basis of some newer standards. As a rule of thumb for choosing: SHA-256 for most purposes, SHA-512 when performance on 64-bit systems matters more than a slightly smaller output, SHA-3 only when a standard explicitly requires it.
The case of SHA-1 as a warning
The decline of SHA-1 illustrates how cryptographic algorithms can become insecure over time without anything changing about the algorithm itself — only the available computing power and the mathematical attack techniques keep advancing. Theoretical work as early as 2005 already showed weaknesses in SHA-1 that allowed a collision search faster than the originally intended security level; the first actual collision, however, was only practically demonstrated in 2017 with “SHAttered”. More than ten years passed between the first theoretical warning and the widespread deactivation of SHA-1 in browsers and certificate authorities — an example of how sluggishly large, distributed systems (millions of web servers, millions of installed browsers) adapt to a necessary cryptographic switch, even when the need has long been known.
How a migration works in practice
Switching from a hash algorithm that has become insecure to a new one is rarely trivial, because it has to account for backward compatibility: Git, for example, has experimentally supported SHA-256 as an alternative to the traditional SHA-1 for commit hashes for a few versions, but has to make sure existing repositories and their entire history keep working. Certificate authorities had to observe transition periods during which both SHA-1- and SHA-256-signed certificates were supported in parallel, before SHA-1 certificates were finally marked as completely insecure and rejected by browsers.
How to choose the right variant for your own project
For your own project, the choice can be reduced to a short decision chain: SHA-1 is categorically no longer an option, no matter how minor the apparent use case seems. For general integrity checking, certificates and most signature schemes, SHA-256 is the pragmatic standard, supported by virtually every library and system. For passwords, a plain SHA algorithm shouldn’t be used directly at all, but rather a dedicated, deliberately slow method like bcrypt or Argon2. SHA-3 or SHA-512 are usually only chosen when a specific standard or platform (e.g. certain blockchain protocols) explicitly requires them — otherwise switching brings no practical additional benefit over the established SHA-256.