Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 30 Mar 2023 01:57:58 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Looking for input

Hello Nate,

As others have already pointed out, you indeed have an impossible task
there.  Your only (slim) chance is finding some grave vulnerability in
KeePassXC password generation, including possibly in its underlying
software such as Botan's RNGs as used in:

https://github.com/keepassxreboot/keepassxc/blob/develop/src/crypto/Random.cpp

or even in the operating system libraries or e.g. VM hypervisor if you
ran KeePassXC in a VM.  (Sometimes VMs are relatively deprived from good
randomness sources and may, at least theoretically, replay random number
sequences when restored from a snapshot.)

This would be a tricky research project, and it'd be expected to fail -
or you can look at it as a security audit of KeePassXC password
generation, which is valuable regardless of outcome, but would require
expertise and time.

I'd also like to correct a couple of points about JtR capabilities, for
everyone reading this:

On Tue, Mar 14, 2023 at 09:03:36PM +0000, Nate Widmyer wrote:
> I know standard JTR builds use 24 chars as compiled limit, so this means a custom build

Only JtR's incremental mode has such compile-time limit, and for that
mode this limit is way higher than what's reasonable anyway.  So there's
no point in making a custom build with it increased.

Other modes, such as wordlist (optionally with rules) and mask, can
handle your desired candidate password lengths just fine.  If your
password were human-chosen rather than generated, wordlist+rules would
even have a chance of cracking it.  For a generated password, you could
specify masks matching the target character set and lengths, but you'd
only search a negligible fraction of the total password space before
you'd have to give up, so your chances of success would be negligible.

> I believe JTR only deals in ASCII anyway.

No, it can also handle 8-bit extended ASCII, with or without awareness
of a specific 8-bit character set, and UTF-8.  Notably for NT hashes, it
can convert from a specified input character encoding (or UTF-8) to NT
hashes' internal use of UCS-2.  So it can crack NT hash passwords with
multi-byte characters that are not representable as single-byte.

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.