[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANWtx03AhiZQoQiymZVcWLZtRoiqCKTn66DyhKvNU-0w4_UvRw@mail.gmail.com>
Date: Fri, 23 Mar 2012 16:55:39 -0400
From: Rich Rumble <richrumble@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Research ideas.
On Thu, Mar 22, 2012 at 8:03 PM, RB <aoz.syn@...il.com> wrote:
> On Thu, Mar 22, 2012 at 17:33, Lukas Odzioba <lukas.odzioba@...il.com> wrote:
>> I've asked on the University, they accepted this idea. This summer I
>> would like to focus on performance for existing formats and adding 2-3
>> new formats (suggestions are welcomed).
>
> Blowfish ($2) on a GPU. It's not terribly common but is agonizingly
> slow compared to pretty much all the rest of the algorithms, saving
> perhaps RAR. :) Although my W3565 (soon to change) benches around 2k
> c/s with 4 OMP threads, against a single hash I'm seeing at most 100
> c/s. This makes even simple dictionary runs a practice in patience.
>
> Beyond that, more container formats are always welcome, it's been nice
> to see JtR adding the various pieces of functionality we used to have
> to go elsewhere for - zip, pdf, etc. Perhaps Truecrypt or some of the
> password lockers like KeePass or Password Safe. 7-zip as well, I'd
> love to see them all here one day.
I'm sending this as a possible addition to the GSoC Ideas page
(http://openwall.info/wiki/ideas). I've also shared most of this info
with Dhiru Kholia, but I thought it would be better to share with the
list at large. I think JtR could help a lot with Office (be it
Open/Star/Libre Office or MS Office) password recovery, and this may
be another place where GPU coding may be of benefit. MS office
versions 97, 98, 2000, XP, and 2003 defaulted to RC4 40-bit
encryption. The 40-bit encryption offers some resistance to brute
force, but is severely lacking in the possible encryption keys. (2 ^
40 = 1,099,511,627,776) Finding the Encryption key is potentially the
fastest way to recover, even MS thinks so :)
http://blogs.msdn.com/b/david_leblanc/archive/2010/04/16/don-t-use-office-rc4-encryption-really-just-don-t-do-it.aspx
http://blogs.msdn.com/b/david_leblanc/archive/2008/07/03/office-crypto-follies.aspx
It's speculated that all the keys written to disc would occupy around
18Gig's. I'm sure it's entirely possible to optimize that like rainbow
tables do and OphCrack/Decryptum/ElcomSoft/Passware have done so
already.
This may also apply to older PDF versions as all these same
RainbowTable providers purport to have similar tables for older PDF
files. Elcomsoft seems to have both Word and PDF in one "ThunderTable"
http://blog.crackpassword.com/2009/05/thunder-tables/ at around 4Gig's
in size. I believe the affected versions of PDF are quite old however
(up to pdf ver 1.3 or acrobat 2 - 4)
I've found these resources, and have known of the flaws for some time
(like using "VelvetSweatshop" as the password zeros out the encryption
because it is the key in 97-2003)
http://msdn.microsoft.com/en-us/library/cc313071%28v=office.12%29.aspx
(MS-OFFCRYPTO)
http://offcrypto.codeplex.com/releases/view/22783#DownloadId=57606 (C#
ehh what can you do)
http://www.microsoft.com/openspecifications/en/us/programs/osp/ooxml/default.aspx
(Specifications)
http://www.microsoft.com/openspecifications/en/us/programs/osp/office-file-formats/default.aspx
(Specifications)
http://www.lyquidity.com/devblog/?p=35
http://www.lyquidity.com/devblog/?p=85
http://www.password-crackers.com/blog/?p=16
http://www.password-crackers.com/blog/?p=34
I am also placing a tarball of various document's I've made using
various old and new office, and 3rd party office
(OpenOffice/LibreOffice etc) that are password protected. The file
names have the Cipher they were encrypted with and the password that
they were encrypted with. Something to note is that MS Office
truncates the 97-2000 40-bit RC4 encrypted passwords to 15 characters.
See the Readme files about the naming convention used in my tarball.
I've tested each of these files against the various free tools and two
I have paid for and have been able to recover using dictionaries and
or key exhaustion.
MS Office does offer more options of encryption, and I've also made
and tested these files also. These files that don't have "97-2000" in
the name must be brute-forced however, at least that is what everyone
else is doing :)
As far as more modern (default) encryption, 128-Bit AES is used on
Office 2007 and 2010.On a related note I believe the ODF spec uses
Blowfish/PBKDF2
http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part3.html#__RefHeading__752815_826425813
http://ringlord.com/dl/Decrypting%20ODF%20Files.pdf
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/bioctl/pbkdf2.c?rev=HEAD&content-type=text%2Fplain
(PBKDF2 in C)
The MS-OFFCRYPTO I linked to above should have all the resources
details about Microsoft office crypto.OpenSSL seems to have RC4
available, I also understand there is a lot of C source code examples
for RC4.
At the very least I hope this is good information, I realize too that
the "encryption key exhaustion" method, in essence could be considered
a rainbow table of the 1 trillion possible keys and is something JtR
has not had or intended to work with previously. JtR typically doesn't
have such an "opportunity" to take such "shortcuts" afaik... However
other crackers seem to claim using GPU and 4 clients can recover the
key in less than a day:
http://www.password-crackers.com/crack/guaexcel.html Perhaps JtR could
give the option of writing the keys to disk as some point in the
future if anyone even want's to look into this method/task at all.
Example Doc's:
http://sc.openoffice.org/testdocs/filetype/ms_excel_xml_encrypted_aes128.xlsx
(Password)
http://xinn.org/test__data/Office_Secrets.tar.gz
I hope that is enough info for someone to do something interesting
with Office products.
-rich
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.
