SHA-384 Hash Generator

Understanding SHA-384 hashing

SHA-384 (Secure Hash Algorithm 384-bit) is a member of the SHA-2 (Secure Hash Algorithm 2) family, standardized by the National Institute of Standards and Technology (NIST) in FIPS PUB 180-4. It is built upon the same underlying structure as SHA-512 but uses different initial hash values (IVs) and produces a truncated 384-bit (48-byte) output digest. This truncation provides a distinct security profile: while SHA-384 operates at the same internal word size (64-bit words) and uses the same 1024-bit block size as SHA-512, its output is 128 bits shorter, which offers natural resistance against certain length-extension attack scenarios that can theoretically affect plain SHA-512.

The SHA-384 algorithm processes input data in 1024-bit (128-byte) blocks through a compression function that performs 80 rounds of computation. Each round applies bitwise logical operations, modular addition, and carefully designed shift and rotate operations to achieve strong avalanche effect, where a single-bit change in the input produces a completely different output with approximately 50% of the output bits flipping. This property is fundamental to cryptographic hash functions and ensures that hash digests cannot be used to reconstruct or infer original input data.

According to the NIST FIPS 180-4 specification, SHA-384 uses eight 64-bit working variables and a message schedule of 80 64-bit words, making it computationally intensive and resistant to known cryptanalytic attacks. The algorithm belongs to the Merkle-Damgård construction family, which builds a collision-resistant compression function into a full-domain hash by iterating over fixed-size blocks with a padding scheme that includes the original message length.

SHA-384 algorithm structure

The internal structure of SHA-384 follows the SHA-512 design with carefully chosen initial values. The algorithm consists of three main stages: message preprocessing, message schedule computation, and the compression function. Below is a detailed breakdown of how SHA-384 operates at the bit level, based on the technical description provided by RFC 6234 (US Secure Hash Algorithms) published by the Internet Engineering Task Force (IETF).

1. Message padding: The input message is padded with a '1' bit, followed by '0' bits, and finally a 128-bit representation of the original message length to make the total length a multiple of 1024 bits.
2. Message schedule (W_t): Each 1024-bit block is expanded into an 80-entry message schedule of 64-bit words using recursive XOR, rotation, and shift operations defined in the SHA-512 specification.
3. Compression function: The eight 64-bit working variables (A through H) are initialized with the SHA-384-specific IVs, then iterated through 80 rounds of logical functions (Ch, Maj, Σ0, Σ1) and modular additions.
4. Output truncation: After processing all blocks, the final 512-bit state is truncated to 384 bits by discarding the last two 64-bit words (G and H), producing the 48-byte digest.

SHA-384 vs SHA-256 vs SHA-512: a technical comparison

Understanding the differences between SHA-2 variants helps developers choose the appropriate algorithm for their specific use case. The table below provides a side-by-side comparison of SHA-384 against SHA-256 and SHA-512, based on the official NIST FIPS 180-4 standard document.

As the table illustrates, SHA-384 shares the same word size, block size, and round count as SHA-512, making it nearly as efficient on 64-bit processors. However, its truncated output provides a unique advantage: the 384-bit digest length naturally limits the information available from the internal state, which reduces the practical risk of length-extension attacks compared to full-length SHA-512. This makes SHA-384 an attractive choice for protocols that require a balance between security margin and output compactness.

HMAC-SHA384

HMAC (Hash-based Message Authentication Code) combines a cryptographic hash function with a secret key to provide both data integrity and authenticity. RFC 2104 (HMAC: Keyed-Hashing for Message Authentication), published by the IETF, defines the standard HMAC construction that applies two rounds of hashing with the secret key to prevent length-extension attacks and provide provable security bounds.

• HMAC-SHA384 processes the secret key by XOR-ing it with two fixed constants (ipad and opad), then applies two nested SHA-384 operations: SHA384((K' ⊕ opad) || SHA384((K' ⊕ ipad) || message)).
• The double-hashing structure ensures that even if the underlying hash function has weaknesses, the HMAC construction provides additional security through key separation.
• HMAC-SHA384 is widely used in TLS 1.2 cipher suites, JSON Web Tokens (JWT), API authentication schemes, and financial messaging standards such as ISO 8583.
• Any change in the HMAC key will produce a completely different output, making it suitable for verifying both the integrity and the origin of a message when the key is kept secret.
• For production systems, HMAC keys should be generated using a cryptographically secure random number generator and should have at least 256 bits of entropy, as recommended by NIST SP 800-107 (Recommendation for Applications Using Approved Hash Algorithms).

Security considerations

SHA-384 remains a strong general-purpose cryptographic hash for integrity-focused tasks, but safe use still depends on context and correct implementation. The following table summarizes the current security status of SHA-384 against various attack vectors, based on analysis from NIST’s Cryptographic Hash Function Project and ongoing cryptanalytic research.

Key takeaways from the security analysis:

• SHA-384 offers strong collision resistance (192-bit security) for practical real-world use, which is significantly higher than SHA-256’s 128-bit collision resistance.
• Because SHA-384 follows a Merkle-Damgård style design, plain (unkeyed) usage inherits theoretical length-extension concerns, although the truncation to 384 bits provides a natural mitigation by discarding 128 bits of the internal state.
• HMAC-SHA384 completely eliminates length-extension concerns for authenticated message verification, as the HMAC construction uses two nested hash operations with the secret key.
• SHA-384 is too fast for password hashing. Use Argon2, bcrypt, scrypt, or PBKDF2 instead, as recommended by NIST SP 800-63B (Digital Identity Guidelines).
• For long-term designs, follow the applicable protocol or compliance guidance. SHA-3 supplements SHA-2 and can be considered for new designs, but it is not a required replacement for SHA-2.

Applications of SHA-384

SHA-384 is deployed across a wide range of security-critical applications and industry standards. Its unique position between SHA-256 and SHA-512 makes it particularly suitable for scenarios where a 384-bit digest provides the optimal balance of security, performance, and output size.

• TLS and SSL certificates: SHA-384 is used in certificate signature algorithms, particularly for ECDSA (Elliptic Curve Digital Signature Algorithm) with P-384 curves, where the hash function strength should match the curve security level.
• Software distribution and package management: Release systems often publish cryptographic checksums or integrity metadata for downloaded artifacts. The exact algorithm depends on the ecosystem and package format.
• Distributed systems: Systems that require a SHA-2 digest with a 384-bit output may choose SHA-384 for identifiers, message digests, or verification metadata when their protocol specifies it.
• Digital signatures: SHA-384 is paired with RSA and ECDSA in high-assurance signature schemes, as specified in NIST FIPS 186-5 (Digital Signature Standard).
• File integrity monitoring (FIM): File monitoring workflows can use SHA-384 as one of several possible checksum algorithms for baseline comparison and change detection.
• HMAC-based API authentication: REST APIs and cloud services can use HMAC-SHA384 to sign requests and verify message authenticity without exposing the secret key.

SHA-384 digest comparison table

The following table shows abbreviated SHA-384 digests for common input values, demonstrating how the algorithm produces deterministic, fixed-length output that varies dramatically with even the smallest input change. You can verify the full values using the SHA-384 generator above.

Notice how changing a single character (lowercase “w” to uppercase “W” in the first two rows) produces a completely different SHA-384 digest. This is the avalanche effect in action. The HMAC-SHA384 column further demonstrates how adding a secret key transforms the output entirely, even when the input remains the same.

History of SHA-384

SHA-384 belongs to the SHA-2 family, which NIST standardized in 2001 as part of FIPS PUB 180-2. It was introduced alongside SHA-512 to provide a truncated alternative that would offer a higher security margin than SHA-256 while maintaining compatibility with 64-bit processor architectures. The development of SHA-2 was driven by the need to replace SHA-1, which had begun to show theoretical weaknesses in its collision resistance.

• 2001: NIST publishes FIPS PUB 180-2, which includes SHA-256, SHA-384, and SHA-512 as part of the SHA-2 family.
• 2005–2008: Cryptanalysts demonstrate practical collision attacks on SHA-1 (estimated at 2⁶⁹ operations), accelerating the industry-wide migration to SHA-2 variants including SHA-384.
• 2012: NIST selects Keccak as the SHA-3 winner, but confirms that SHA-2 (including SHA-384) remains secure and approved for federal government use.
• 2015: NIST revises FIPS 180-4, adding SHA-512/224 and SHA-512/256 while reaffirming SHA-384’s status as a valid SHA-2 variant.
• 2020–present: SHA-384 continues to be widely deployed in TLS certificates, code signing, blockchain systems, and compliance-driven security frameworks such as FIPS 140-3 and FedRAMP.

Limitations and cautions

• Client-side processing: Everything runs in the browser using JavaScript. For production-critical hashing, always verify results with a native or server-side implementation.
• Not for passwords: SHA-384 is too fast for safe password storage. Use Argon2id, bcrypt (cost factor ≥ 10), scrypt, or PBKDF2 (with at least 600,000 iterations) as recommended by OWASP Password Storage Cheat Sheet.
• Not a complete security design: Correct protocol design, key management, secure random number generation, and implementation quality all matter. A hash function alone does not provide confidentiality, authentication, or non-repudiation.
• Encoding sensitivity: Wrong input encoding will produce parsing errors or unexpected output. Always verify that the encoding selection matches the actual source data format.
• Browser dependency: The page assumes a modern browser with JavaScript and the CryptoJS library enabled. Legacy browsers may not support all features.

Final tips

1. Start with UTF-8 input and HEX output for the easiest testing flow. This combination is compatible with the widest range of tools and libraries.
2. Use HMAC only when you intentionally want keyed hashing behavior. Adding an HMAC key when you only need a plain digest adds unnecessary complexity.
3. Validate important digests against another trusted implementation such as OpenSSL (openssl dgst -sha384), Python (hashlib.sha384()), or the command-line sha384sum utility.
4. Use SHA-384 for integrity and compatibility checks when a general-purpose SHA-2 digest is appropriate and a 384-bit output is preferred over 256-bit or 512-bit alternatives.
5. For new cryptographic designs, consider SHA-3 (Keccak) as a modern alternative that uses a fundamentally different sponge construction and is not susceptible to length-extension attacks even in plain hash mode.

Results generated by this tool are for educational and testing purposes only. Actual outputs may vary based on input accuracy, encoding choices, and whether HMAC mode is enabled. Always cross-reference critical hash values against independently verified sources before relying on them in production systems.