|
Message-ID: <20230329235758.GA24897@openwall.com> 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.