Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 30 Jun 2020 09:26:00 -0400
From: Rich Rumble <>
Subject: Re: decryption without original password

On Tue, Jun 30, 2020 at 4:15 AM magnum <> wrote:

> On 2020-06-23 23:23, Solar Designer wrote:
> > On Mon, Jun 22, 2020 at 02:50:45PM +0200, Johny Krekan wrote:
> >> I have tryed Advanced office password breaker. It is product from
> >> Elcomsoft which can break 40-bit encryption
> >> which is used in Word/Excel versions 97/2000. It decrypts document
> >> without recovering the actual password. It
> >> recovers the key which is generated from the password.
> >> 1. Is doing something like this possible with John on old office
> documents?
> >
> > No.  JtR currently only supports passwords, not binary keys.
> We don't attack the key directly, but we're still getting the "benefit"
> of the crippled 40-bit encryption in that we'll hit usable password
> collisions at about the same rate anyway (once in about 2**40).
> Also, we actually have (at least the GPU version) some quirky means for
> exploiting the 40-bit key once we know it, but I never found it very
> interesting since the format is so weak anyway:
> The format can read a "hash" with an attached known 40-bit key,
> formatted as hashcat does it (Atom calls it MITM key):
> $oldoffice$0*55045061647456688860411218030058*e7e24d163fbd743992d4b8892bf3f2f7*493410dbc832557d3fe1870ace8397e2:91b2e062b9
> The trailing 91b2e062b9 is the 40-bit key. If given, the format will use
> it for speedup, but we're not getting hashcat speeds (I think). Until we
> know they key, I see ~438 Mp/s on a 2080ti using mask mode. Once we hit
> the key, finding more usable passwords (given you used the
> --keep-guessing option) runs about 3x faster at ~1.3 Gp/s.
> We never store the RC4 key in the potfile though, it just ends up in the
> log file. If you want to use it for future sessions, find it (grep log
> for MITM) and attach it to the original non-hash.
> magnum
Just to add to what Solar and Magnum have said already; I have a lot of
experience with ElcomSoft tools, and others that use similar methods.
Elcomsoft called them ThunderTables (They simply added some additional keys
that rainbow-tables would miss), and Ophcrack called them Rainbow-Tables.
RT's find 99% and ThunderTables found the other 1% :)
Both PDF and Office 97-2003 had the RC4 40-Bit key issue (there is a
reason, see below). And to answer your question (3), there are other
passwords where collisions occur and the password that was used is not the
password that is found by the cracker. The CRC32 "password" used in Outlook
PST/OST files was a joke in two ways. CRC32 is a very small keyspace and
thus would be prone to many collisions. For example, if you set the
password '1234' to your pst file, you can also open it with the following
passwords: 'yZdHpA', 'hkNkwC', 'YUWqKD', 'FkbbpH',
NirSoft also has a crc32 PST collision (as well as JtR) finder. Second to
that, the password to open a PST could be IGNORED by a program and the
contents read easily. Outlook obeyed the password to open, but if you
removed it, or ignored it using a different program, you were in :)
The RC4 40-bit key issue allows collisions to take place because the space
is smaller than what is cryptographically strong by modern standards. That
was deliberate btw. At the time any encryption from the US had to have
40-bit keys or less for it to be exported, or it was a "munition"
Now we don't have such restrictions, and you should find less crypto
colliding, and we are deprecating crypto that doesn't secure data any
longer, albeit too slowly.
good reading here too:

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.