|
Message-ID: <8332b06221cb51a311e3902fb1ecf13d@smtp.hushmail.com> Date: Thu, 4 May 2017 23:56:38 +0200 From: magnum <john.magnum@...hmail.com> To: john-users@...ts.openwall.com Subject: Re: Max characters for password candidates (NTLM) and others On 2017-05-04 23:44, Frank Dittrich wrote: > Am 04.05.2017 um 23:27 schrieb magnum: >> The NT formats have a max length of 27 *characters* (for performance >> reasons). > > The 27 character limit isn't really a hash format limitation, but a > limitation of John's NT format implementation, ist that correct? Correct. Off the top of my head, the actual maximum in Windows is 255 characters. > So, it would be possible to drop that limit (or change the limit from > currently 27 characters to, say, 54 characters). Sure. We could support any length but it'd be slower. Actually, for a non-SIMD build (eg. non-Intel using OpenSSL) I think our limit is 125 bytes (which is the hard deck no-matter-what, set by legacy core code) and that'd be just 41 characters worst case (that is, every one of them take three bytes to represent in UTF-8). > But trying password candidates that are longer than 27 characters would > reduce the cracking speed to about half the speed of the current > implementation. Actually we could implement some kind of branching and support 27/54/81/108/125 bytes, no problem. And we could re-write John's core and support more than 125 bytes. But with fast hashes like NT the branching would be a significant regression. It would hurt real-world cracking: No-one has a password of 27 characters, let alone longer. > Does hashcat also have a 27 character limit for NT format? Sure. In our world of Merkel-Damgård geeks, it's a perfectly even number. In non-unicode formats like raw-md4/md5, it's 55. Actually in NT it's 27.5 but that obviously doesn't make sense. magnum
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.