[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<CH2PR04MB688753AB20BC272A4912DB528FBF9@CH2PR04MB6887.namprd04.prod.outlook.com>
Date: Wed, 15 Mar 2023 00:39:05 +0000
From: Nate Widmyer <touring_fan@....com>
To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com>
Subject: Re: Looking for input
Hello Lukas,
I think I understand what you mean -- to find if there are vulnerabilities to the password generator, ways in which it may be predictable.
I see in the code now that there are modes to use, like exclude lookalike characters.
I'll look into the code more to see if I can find more, and how my use of the app might have configured the generator.
Thanks,
Nate
________________________________
From: Lukas Odzioba <lukas.odzioba@...il.com>
Sent: Tuesday, March 14, 2023 7:52 PM
To: john-users@...ts.openwall.com <john-users@...ts.openwall.com>
Subject: Re: [john-users] Looking for input
Hi Nate,
I am affraid that the main obstacle for recovering password is simply the
search space. a-zA-Z0-9 gives us 62 posibilities for each position, 62 to
the power of 20 assuming no other heuristics to limit the search space is
huge number and it is close to imposible to recover it. Length limit of the
JtR in this format is not the main problem to solve here. What could
potentially help os would be broken password generator used to create the
password, but it is just another way of saying that you need to limit the
search space to even have a chance.
Thanks,
Lukas
wt., 14 mar 2023, 23:44 użytkownik Nate Widmyer <touring_fan@....com>
napisał:
> Hello,
>
> I'm trying to recover a password to three 7-zip archives that I made,
> which I created all in the same way, using 7zip with SHA-256 encryption.
> I got JTR running to the point where JTR starts and begins processing, but
> it's going to take forever to try everything, but since I encrypted it, I
> know what the parameters that were used to generate the passwords to narrow
> down the search size.
>
> * password was definitely between 20 - 30 characters. I know standard JTR
> builds use 24 chars as compiled limit, so this means a custom build, which
> I may be able to manage after creating a development environment, which
> takes time. I'd probably like to split the password input into 4 runs (in
> decreasing order of probability of use): 22-25 chars, 20 and 21 chars, 26
> chars, 27-30 chars.
> * password was generated via KeePassXC password generation, with A-Z, a-z,
> 0-9 and specials character classes, but no extended ASCII. I believe JTR
> only deals in ASCII anyway. That means no dictionary attacks needed, just
> lots of random chars.
>
> I figure I need:
> 1. a build of JTR that can support 30 chars. I know getting it to run on a
> GPU is preferable.
> 2. maybe do it in AWS and get it off of my machine. I saw announcements
> about JTR AMI, but that build may be limited to 24 chars.
> 3. some way to provide possible passwords (on the fly?) for JTR, starting
> from this source:
>
> https://github.com/keepassxreboot/keepassxc/blob/2.7.1/src/core/PasswordGenerator.h
>
> https://github.com/keepassxreboot/keepassxc/blob/2.7.1/src/core/PasswordGenerator.cpp
>
> but probably needs to express the # of total possibilities, etc...
>
>
> What else am I missing that's going to turn this into more of an
> impossible task?
>
> I tried to look for other people trying to do the same sort of thing, but
> nothing seemed obvious and I'm pretty new to this.
>
> Thanks,
> Nate
>
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.
