[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 11 Nov 2012 00:56:37 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Noob: trying to recover own gpg/pgp passphrase with limited set of characters
On Fri, Nov 09, 2012 at 12:08:40AM +0100, sngh wrote:
> I kinda think I remember my pass-phrase being like either a
> combination of a few words and year numbers and a single exclamation
> mark as "special" character. Until now, running for a few days, I am
> out of luck.
Yes, you're most likely out of luck. It doesn't sound like you remember
enough of the passphrase and/or are able to put enough resources into
getting it cracked.
> I was trying to extract the unique distinct ascii characters from the
> few words that I am thinking about that my pass-phrase could be made
> of, so I found that I needed to feed a colon : and the words (=passes
> as clear-text) into the john.pot file each on a line. I added the
> years (four character num only) as well that I think about.
> (found out about it here:
> http://www.openwall.com/lists/john-users/2012/03/12/2 )
You can do this, but clearly the resulting search space is too large
given the passphrase length and the speeds you can expect to get.
> Additionally maybe my pass-phrase is rather the kind of the first
> letters of the words contained in a sentence, such as "this is my
> great gpg pass-phrase 200x!" = timggp200x! or similar.
This is likely crackable, but how likely is it that you have actually
used this method?
You can try putting just the first letters of the words into your fake
john.pot that you use to generate the .chr file, then append "200x!" to
the passwords being tested with an external filter().
> secring.gpg:$gpg$*17*42*1024*.............
>
> I am wondering does that say how many characters my password might
> have, or anything helpful at all?
It does not say anything about your passphrase.
> Questions would be, can I further optimize the outcome of this
> endeavor,
Yes, but you're most likely out of luck even with further optimizations.
> or should I just dump the gpg private keyring altogether? :(
This is up to you.
> Also, currently I am running this on a cpu (multi-core though), but
> its only outputting like 8 to 9k checks a second or so on a single
> john instance. Maybe I could have access to a gpu gfx card or even a
> few to speed things up, but I havent messed with opencl(? I think the
> gpg/pgp john coding stuff runs as an opencl engine) on Linux (AMDATI
> gfx card) as of yet, I could have easier ways to have gfx cards for
> opencl on Windows, wonder if I can compile john for opencl/gpu for the
> Windows platform?
JtR currently supports OpenCL on Linux and Mac OS X only.
> Also, what does the 32/64 (bits of the platform? key properties or
> calculation method of john?) at the john output during start mean?
This is a convention we use to show bits used / bits total. Some
algorithms are such that they don't use the full machine word width.
> Also what about this default 8characters max that a password can have,
This applies to incremental mode only. You can avoid this limitation by
setting CHARSET_LENGTH to a higher value in params.h, recompiling, and
generating new .chr files - but there's hardly a reason for you to do
that since you're most likely out of luck cracking a longer passphrase
with incremental mode alone at these speeds.
Other cracking modes do not have the limitation. Also, you may combine
e.g. incremental mode trying strings of lengths up to 8 with an external
filter() adding another 5 characters to that (for a total of up to 13).
> I suppose my password for example made up of two familiar words in my
> friends and family realm, would add up to much more than just 8chars,
> the pass might me rather 12chars or so.
It is very inefficient to have John reconstruct the known words from
individual characters anyway. You need to have it use the words as-is -
that is, you need wordlist mode for this.
> Even if I did that word
> letters sentence thingy and the one special character additionally, I
> suppose I am beyond eight characters as password length.
Yes, but it is similarly inefficient to have this reconstructed from the
individual characters (testing many impossible combinations as well).
> If I would go for the opencl/gpu stuff, whats an easy way to split up
> the password ranges for a few concurrent runs of this task on multiple
> machines with gpu, that could cut the time-frame in half or by four or
> so depending to what I might have available.
You need to specify the target keyspace more specifically and decide on
the cracking modes to use first. As it is, cutting it by a factor of 2
or 4 makes very little difference.
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.
