RAR encryption has an unusual reputation: in more than twenty years there has been no practical attack against the cipher, no implementation flaw worth the name, and none of the shortcuts that collapsed certain other archive formats in minutes. Yet until recently, nobody could say how fast a RAR password could actually be attacked. The answer was always “it depends”, technically true but not something one could put in front of a client or plan a recovery job around.

Something was not being explained. This article looks at how RAR encryption evolved from the proprietary cipher of the mid-90s to the AES-256 used today, why attacks on the older RAR4 format had no fixed speed, why attacks on RAR5 do, and what changed in the design that made the difference, correcting a few technical claims about RAR that circulate widely and happen to be wrong along the way. None of this is about breaking the encryption; RAR encryption is not broken. This is entirely about the cost of testing a password.

Where RAR sits on the timeline

Archive encryption has a long, mostly bad history.

PKZIP’s encryption dates to the late 80s and used a proprietary stream cipher, published and broken by academic cryptographers by 1994, meaning the most popular archive format in the world was running known-weak encryption. That cipher, usually called ZipCrypto or legacy ZIP encryption, is still shipped today for compatibility and is still trivially attackable. We covered it separately in [link to the ZIP article], so there’s no need to repeat it here.

Where RAR lands on the same timeline is the relevant point.

RAR appeared in 1993, just as the ZIP cipher was fielded and about to be broken. The early versions, 1.5 and 2.0, used a proprietary in-house cipher, barely documented. This was normal for the era: everybody rolled their own, nobody published, and the results were about what you’d expect.

AES was adopted as a NIST standard in 2001, and that’s where the two formats diverge. ZIP added AES later as an option alongside the broken legacy cipher, which it never removed. RAR moved to AES in version 3.0 and never looked back, and has never carried a weak legacy mode for compatibility.

RAR encryption by version

Before getting into why RAR4 behaved the way it did, here’s what each version actually does.

Why RAR4 attacks had no fixed speed

The RAR4 format, produced by WinRAR 3.0 through 4.x, stores no password verification value. There is no field anywhere in the archive that tells the archiver whether the entered password is correct; WinRAR doesn’t check it at all. The password goes through the key derivation function, whatever comes out becomes the AES key, and the archiver decrypts with that key regardless.

The only way to know if the key was right is to look at the result. RAR4 stores a CRC32 checksum per file. The archiver decrypts, decompresses, computes the CRC32, and compares it to the stored value. Match, correct password; no match, an error and often a pile of garbage in the output folder. That’s why WinRAR 4 could unpack gigabytes of noise before admitting the password was wrong.

For a user this is an annoyance. For a password recovery attack it’s a different order of problem, since the same sequence repeats for every candidate in the queue.

The cost of a single password candidate

Testing one password against a RAR4 archive has two very different parts.

The first is key derivation: a custom construction built around SHA-1. The password, in UTF-16LE, and an 8-byte salt run through 2^18 rounds (262,144) of SHA-1 with a counter, producing both the AES-128 key and the IV. This cost is fixed, archive-independent, and GPU-friendly.

The second part is everything else: decrypt, decompress, compute the CRC32, compare. This cost scales with the data, and there’s no upper bound on how much data there is.

That’s the mechanism behind two decades of “it depends.” Attack speed on a RAR4 archive isn’t a property of the format; it’s a property of the specific file.

Three cases, not two

“RAR4 is slow” oversimplifies it. What matters is how much work the format demands after the KDF finishes.

With the -hp switch (headers and file names encrypted along with data), almost none. The archive carries a small block of encrypted header data with a known structure: decrypt it, check whether the result looks like a valid header, move to the next candidate. The amount of data involved is a few dozen bytes and doesn’t change with archive size, so the cost per candidate is essentially just the KDF, and the whole operation stays on the GPU.

Counterintuitively, encrypting file names, the stronger privacy option and the one we’d recommend for sensitive data, produces the RAR4 archive that’s fastest to attack. Hiding the names removes the only thing that was making the attacker pay by the megabyte.

With the -p switch (only file data encrypted, names visible), there’s no header to check, so the file data itself is the only oracle. Here it splits again by compression method:

• Stored, no compression. Decrypt only, nothing to decompress, so it stays on GPU end to end. Cost: the KDF plus decryption of the payload.
• Compressed. Decrypt, then decompress before there’s anything to checksum. Cost: KDF plus decryption plus decompression, and decompression is CPU-bound. Somewhere in the pipeline the RAR decompressor has to run, and that happens on the CPU, not the GPU.

So three cost structures: the KDF alone, the KDF plus the payload, and the KDF plus the payload plus a CPU-bound decompression pass. Only the first can be quoted as a number without asking anything about the archive.

The last case is also the most common one: a user who types a password into the WinRAR dialog and doesn’t tick “Encrypt file names” produces exactly this kind of archive, with default compression, and this is what most RAR4 archives in the wild turn out to be. It took the industry a remarkably long time to handle this case at all. Support for attacking encrypted headers appeared early and everywhere, while the compressed-data case is awkward enough that public tooling such as hashcat only caught up with it around 2020, more than fifteen years after the format shipped. Not an oversight; a genuinely hard case, and the difficulty is the whole point.

The archive is the hash

One detail illustrates this better than any benchmark. Attacking a RAR4 -p compressed archive requires the archive data itself, since that’s what gets decrypted and decompressed. So when a password recovery tool extracts a “hash” from such an archive, the file data goes into it. The result isn’t a hash in any normal sense; it’s the archive itself, wearing a thin hexadecimal coat.

These “hashes” are measured in megabytes rather than bytes, and tools that accept them have to impose a length limit somewhere, and users hit those limits regularly. In one published report, a 4.79 MB archive produced a hash string of 1,944,374 characters, roughly 2 MB of text, well past what the tool was prepared to load.

A format whose “password hash” scales with payload size can’t be benchmarked in any meaningful way. That’s why “how long will this RAR4 take” was never answerable with a number.

Why would anyone design it this way?

Leaving out a password verification value is a curious choice: it costs a few bytes, and every other archive format of the era eventually acquired one. Two explanations are plausible, and there’s no way to confirm which is correct.

It may simply be a product of its time: RAR 3.0’s 2001 header structure was inherited from the RAR 1.5 redesign of the mid-90s, when archives were measured in megabytes, decrypting a few to check a CRC32 wasn’t unreasonable, and the password check came free as a side effect of an integrity feature that already existed.

Or it may have been deliberate. A verification value is a gift to an attacker: it turns a password check from “process the entire file” into “run the KDF, compare 8 bytes.” A format without one charges the attacker the full price of the archive per guess, achieving on 2001 hardware what no amount of KDF tuning could. If this was the intent, it worked remarkably well.

Either way, the format still leaks a yes/no answer for every password; it just charges the whole file for the privilege. That’s not a security property in the strict sense, since the oracle is still there, but it functions as a tax. Whether Eugene Roshal intended it, or it fell out of a design meant for integrity checking, is a question only he can answer, and as far as we know, he never has.

RAR5 and the stored verification value

WinRAR 5.0 introduced a new archive format in April 2013. RAR5 isn’t a revision of RAR4; it’s a different format sharing the file extension, distinguished by its signature bytes, with differences running throughout: AES-256 in CBC mode instead of AES-128, PBKDF2-HMAC-SHA256 instead of the custom SHA-1 construction, BLAKE2sp instead of CRC32 for file checksums, dictionaries up to 1 GB instead of 4 MB.

For our purposes, one change matters: RAR5 stores a password verification value in the header.

What RARLAB actually did

The mechanism is documented by RARLAB directly.

The password and a 16-byte salt run through PBKDF2-HMAC-SHA256. The iteration count isn’t fixed: it’s stored in the header as a base-2 logarithm, and WinRAR 5.0’s default is 2^15, or 32,768 iterations. The 50,000 figure that circulates online is simply wrong. The KDF produces three things: the AES-256 key, a hash key used for the tweaked checksums, and a 12-byte password check value that lands in the header next to the salt and IV.

On password entry, WinRAR runs the KDF, compares the check value against the one stored in the header, and rejects a mismatch immediately: no decryption, no decompression, no CRC. RARLAB’s stated goal: catch wrong passwords before extraction starts, and stop littering the output folder with garbage.

They knew what they were giving up. The documentation states plainly that the hash function was chosen to be intentionally slow, specifically to reduce the chances of a successful brute force attack; this wasn’t added without thinking through the consequences.

A second, related change: when file names aren’t encrypted, RAR5 checksums are modified using a password-dependent algorithm. Without this, an unencrypted checksum next to an encrypted file would let a third party confirm the file’s contents, without ever knowing the password, just by checksumming a candidate and comparing. RARLAB closed that hole in the same release it opened the other one.

The irony

Side by side, the two formats produce a counterintuitive result.

RAR4’s KDF is heavier: 262,144 rounds of SHA-1 versus 32,768 iterations of PBKDF2-HMAC-SHA256 at RAR5’s default. On paper, the older format should be harder to attack.

In practice it’s the opposite, and we’ve confirmed it in our own testing: when we implemented RAR5 support, the attack we built turned out significantly faster on the new format than on the old one. The reason is data volume: RAR5 charges a fixed price per candidate and hands you the answer. RAR4 charges that same fixed price, then charges again for every byte of the archive.

So a change made entirely for the convenience of legitimate users, so that WinRAR would stop unpacking gigabytes of noise before admitting the password was wrong, is the change that made the format measurable, and by extension, faster to attack. This is worth stating plainly because it’s easy to read it as a mistake, and it wasn’t one.

Why the calculus changed

Why would the same developers who left the check value out in 2001 add it twelve years later? Most likely, the tools available and the threat had both changed.

In 2001 the KDF was the only brake available. AES was new, hardware acceleration for it didn’t exist on consumer machines, and PBKDF2 had only just been published as an RFC. Making the KDF expensive was the only lever to pull, and 2^18 rounds of SHA-1 was genuinely expensive on the hardware of the day; a Pentium III had nothing else to fall back on.

By 2013, both sides of the equation had shifted. AES-NI had been in Intel processors since 2010, making decryption nearly free, so RAR4’s incidental protection from processing the whole archive was worth far less than it used to be. Meanwhile PBKDF2 with a configurable iteration count had become the standard answer, and, crucially, the iteration count could be stored in the archive and raised later. That last part matters more than it looks: a format with a fixed KDF cost ages badly, while a format that writes its iteration count into the header can be tuned upward as GPUs get faster, without breaking any archive created earlier.

Seen this way, RAR5 isn’t a weakening. It’s a trade: give up the accidental protection that came from forcing the attacker through the whole file, and replace it with a deliberate, adjustable brake that stays adjustable for years. Whether the trade was worth it depends on your archives, but it’s the same direction every other format in this space has taken.

The upshot: RAR5 attacks finally have a number attached to them, one that stays the same regardless of whether the archive holds a text file or a disk image.

What this means in practice

The practical situation with RAR hasn’t changed in twenty years: there’s no way in other than the password.

There’s no cryptographic attack against AES-128 or AES-256, no published implementation flaw in the RAR key derivation, and no equivalent of the known-plaintext trick that works against legacy ZIP, because RAR never carried a weak legacy mode for compatibility. Whatever you do with a RAR archive, you’re doing a password search, and the only questions worth asking are how much each candidate costs and how many candidates you have to try.

The cost per candidate depends on the format, and it’s worth knowing which of the four cases you’re looking at before making any promises about timing to a client or to yourself.

• RAR5. Fixed cost, always. The KDF runs, the check value is compared, done. The cost doesn’t depend on archive size, compression, or contents. This is the case where a number can be quoted.
• RAR4 with encrypted headers. Fixed cost, and low. A small header block is decrypted and verified. The fastest RAR case there is.
• RAR4, data only, stored. Fixed cost, moderate. No decompression is needed, so the whole thing stays on the GPU.
• RAR4, data only, compressed. Variable cost, and the variable is the size of the archive. The case behind two decades of “it depends,” and also the most common one.

One thing that’s easy to miss: the RAR5 iteration count isn’t a constant. It’s written into the archive header, and while the default corresponds to 32,768 iterations, WinRAR allows it to be raised. Read the count out of the header before estimating anything. An archive created by a careful user with a raised count will be slower than your estimate by exactly the factor you failed to account for.

As for where RAR sits relative to other formats, we published a comparison table in Building a Password Recovery Queue, using WinZip AES-256 as the reference point with a value of 1. RAR5 comes out at roughly 10 times slower than the reference, which makes it one of the slowest commonly encountered formats. For comparison, NTLM hashes on the same hardware run about 45,000 times faster than the reference. If your queue mixes RAR5 archives with anything else, the RAR5 jobs belong at the bottom of it.

[Note for Oleg: this section would be stronger with current lab numbers for the three RAR cases on whatever GPU you want to use as the reference. I have deliberately not invented any figures.]

What about the WinRAR vulnerabilities?

Search for “WinRAR vulnerability” and you’ll find plenty, none of which will help you open an encrypted archive. It’s worth listing them briefly, if only to make clear why they fall outside the scope of this article.

• CVE-2018-20250. A path traversal bug in unacev2.dll, the library WinRAR used to handle ACE archives, unmaintained since 2005, with source code RARLAB no longer had. The fix was to drop ACE support entirely in WinRAR 5.70.
• CVE-2023-38831. File extension spoofing, exploited in the wild since April 2023 against traders on specialist forums before anyone noticed.
• CVE-2025-8088. Path traversal, patched in July 2025, added to the CISA Known Exploited Vulnerabilities catalog, and, according to Google’s Threat Intelligence Group, still being exploited widely as of June 2026.
• CVE-2026-14191. A heap overflow in the RAR5 recovery volume parser, fixed in WinRAR 7.23 at the beginning of July 2026.

The pattern is consistent. Every one of these lives in the code that parses and unpacks archives, and not one of them touches the encryption. They’re also, in a sense, the opposite of our subject: they’re bugs that let a malicious archive attack the user, whereas this article is about a user attacking an archive. Knowing about CVE-2025-8088 will not recover a password.

The last one is a useful illustration. CVE-2026-14191 is a RAR5 bug, in RAR5-specific code, discovered thirteen years after the format shipped, and it still has nothing to do with the cipher. The attack surface of an archiver is the parser. It always has been.

Shameless plug

RAR5 is one of the slowest formats we support, and the reasons are the ones covered above: a fixed but expensive cost per candidate, with no shortcut available and nothing to optimize except raw throughput. That’s precisely the situation GPU acceleration and distributed attacks exist for. Elcomsoft Distributed Password Recovery builds high-performance clusters out of the hardware you already have, offers zero-overhead scalability, and supports GPU acceleration on the whole queue rather than on selected formats. For RAR, this is not a convenience; on a single CPU the numbers simply do not work.

Advanced Archive Password Recovery recovers passwords to encrypted ZIP, 7Zip and RAR archives, covering both the RAR4 and RAR5 formats as well as the older ZIP, ARJ and ACE formats and self-extracting archives. Where a format has a known weakness, the tool targets the weakness rather than the password; where it doesn’t, as with RAR, it offers dictionary, mask and brute force attacks.

Conclusion

RAR encryption has aged well. From version 3.0 onward the format has used AES with an iterated key derivation function, it has never offered a weak mode for backward compatibility, and there is no published attack against it. Whatever else can be said about WinRAR, the encryption is not where it is weak.

What changed between RAR4 and RAR5 was not the strength of the protection but the shape of it. RAR4 stores no password verification value, so the only way to test a password is to decrypt the data, decompress it, and compare a CRC32, a cost that depends on the archive, which is why the speed of a RAR4 attack was never a property of the format and could not be stated as a number. RAR5 stores a verification value in the header, which lets WinRAR reject a wrong password immediately, and which also gives an attacker a fixed price per candidate. RARLAB compensated with a deliberately slow PBKDF2 and an iteration count that can be raised as hardware improves. The result is a format that is slow to attack, but honestly and measurably slow.

For anyone estimating work on a real job: read the header first, find out which of the four cases you’re dealing with, and only then quote a number. If it turns out to be RAR4 with compressed data and no header encryption, the honest answer is still “it depends”, and it always will be.

More information

• • Breaking RAR5 and 7Zip Passwords
  • Building a Password Recovery Queue
  • Password Recovery and Data Decryption: Getting Around and About
  • A Word About Dictionaries
  • What is Password Recovery and How It Is Different from Password Cracking
  • How Long Does It Take to Crack Your Password?
  • [ZIP article, link when published]