[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120324004800.GA5424@openwall.com>
Date: Sat, 24 Mar 2012 04:48:00 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Office passwords; testing of raw crypto keys; rainbow tables (was: Research ideas.)
Rich,
This has little to do with Lukas' request for "research ideas", so I've
changed the Subject.
On Fri, Mar 23, 2012 at 04:55:39PM -0400, Rich Rumble wrote:
> I'm sending this as a possible addition to the GSoC Ideas page
> (http://openwall.info/wiki/ideas).
We already have a "more non-hashes" task. The initial task description
on the ideas page is not meant to include an exhaustive list of
non-hashes that a student would need to implement - that is something a
student may specify in their proposal and timeline, and negotiate with
prospective mentor(s).
> 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.
Yes, sharing with the list works best. Thanks.
> 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.
I am all for including the Office stuff among the "non-hashes" - maybe
this year. However, as it relates to JtR, we'd need to be testing
candidate passwords. We do that for PDF now, even though (old) PDF also
allows for the 40-bit key attack (with other tools).
There's currently no JtR development task to add support for testing of
raw crypto keys that are not passwords directly entered by a human.
Many things will need to change in order to support that reasonably, yet
it'd be beneficial for a small subset of the formats only.
As to rainbow tables, they're of even less relevance to the current
functionality, code, and user interface of JtR.
I don't want us to work on these two tasks under GSoC 2012.
Once again, to be clear, I do want simple support for the various Office
files to be implemented - with testing of candidate passwords like JtR
normally does - possibly under GSoC 2012.
> 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 :)
Right.
> 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.
When you say "18Gig's", you probably refer to some kind of rainbow tables
or the like already - not to actually having "all the keys written to
disc" (which would take 128 GB even if you write only 1 bit per key, and
it would be pointless anyway).
Yes, there exist such rainbow tables (and ElcomSoft's Thunder Tables,
which offer 100% success rate).
> 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 :)
Why don't you upload this to our wiki?
http://openwall.info/wiki/john/sample-non-hashes
Just include a note that these are not actually supported by JtR yet.
> 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
I previously posted this link:
http://www.golubev.com/blog/?p=94
> 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.
These are two distinct attacks, but you're right - neither fits JtR well.
> 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
Actually, it's 1 day average on a quad-core CPU without GPU.
> 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.
I don't see how writing the keys to disk (what keys?) would be of help.
> 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.
Yes, thanks. And please upload to our wiki.
Alexander
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.
