How Unrar Handles RAR4 vs RAR5 Encryption

When processing encrypted archives, the unrar utility applies two distinct decryption pipelines depending on whether the archive is formatted under the legacy RAR4 specification or the modern RAR5 format. This article examines how unrar detects the format version, switches between AES-128 and AES-256 cryptographic algorithms, processes key derivation functions, and validates user passwords during extraction.

Archive Detection and Header Parsing

Before initiating decryption, unrar inspects the initial byte signature (magic bytes) of the target file to determine the archive version:

  • RAR4: Uses the standard 7-byte marker 52 61 72 21 1A 07 00.
  • RAR5: Uses an updated 8-byte marker 52 61 72 21 1A 07 01 00.

This detection dictates which cryptographic routines the engine initializes. If header encryption is enabled (created via WinRAR's -hp switch), standard archive markers are obscured or preceded by encryption headers, prompting unrar to immediately request the user password before reading file metadata.

Symmetric Cipher Implementation

The underlying symmetric encryption differs substantially between the two formats:

  • RAR4 (AES-128): unrar decrypts payload data and file headers using the Advanced Encryption Standard (AES) with a 128-bit key in Cipher Block Chaining (CBC) mode. The initialization vector (IV) and keystream setup rely on legacy block-padding conventions.
  • RAR5 (AES-256): unrar upgrades the cipher to AES-256 in CBC mode. The 256-bit key length significantly increases brute-force complexity compared to RAR4.

Key Derivation Functions (KDF)

The most significant security divergence handled by unrar lies in how user-supplied plaintext passwords are transformed into cryptographic keys.

RAR4 Legacy Derivation

RAR4 uses a custom, lightweight key derivation mechanism:

  • The user's password string is concatenated with an 8-byte (64-bit) random salt stored in the archive header.
  • The combined input is repeatedly hashed using SHA-1 over a fixed, relatively low iteration count (typically around 262,144 rounds of raw SHA-1 hashing).
  • While effective when introduced, this approach lacks modern memory-hardness and allows high-throughput cracking on modern GPUs.

RAR5 Modern Derivation

RAR5 transitions to industry-standard key stretching:

  • It increases the salt size to 16 bytes (128 bits) to eliminate the risk of rainbow-table collisions across archives.
  • It uses standard PBKDF2 (Password-Based Key Derivation Function 2) built on HMAC-SHA-256.
  • The iteration count is drastically increased, scaling dynamically or defaulting to thousands of rounds of computationally heavy HMAC evaluations. This forces unrar to consume more CPU time per key generation, effectively mitigating automated dictionary attacks.

Password Verification

The mechanism unrar uses to check if an entered password is correct differs between formats:

  • RAR4 Verification: The legacy format does not include a dedicated password checksum for encrypted file data. To check if a password is correct, unrar must decrypt the file block and verify the uncompressed data against an internal cyclic redundancy check (CRC32). A wrong password results in a corrupted CRC checksum error at the end of extraction.
  • RAR5 Verification: Modern RAR5 headers include a cryptographically secure password verification hash (derived via PBKDF2). This allows unrar to instantly confirm password validity before attempting any decompression, eliminating false extraction runs and reducing overhead.

Backward Compatibility within unrar

To maintain seamless backward compatibility, the official unrar source code retains both cryptographic code paths. When an extraction job starts, unrar allocates the necessary buffer structures for the specific format. If a RAR4 archive is detected, modern optimizations like hardware-accelerated AES-NI still apply to the AES-128 decryption routine, but the software relies on the legacy hashing structures strictly for compatibility with older archives.