[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220107210644.GA21199@openwall.com>
Date: Fri, 7 Jan 2022 22:06:44 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Support for truncated pbkdf2-hmac-sha1 hashes?
Hi,
On Fri, Jan 07, 2022 at 12:03:19AM -0800, Lokkju Brennr wrote:
> I'm working on adding support for cracking the keys used in Chrome's Sync
> system, Nigori, when a custom sync password is set. It can be converted to
> a standard pbkdf2-hmac-sha1 format (with a static salt, even), except that
> Nigori only uses a 16 byte hash length.
>
> pbkdf2-hmac-sha1 seems to support variable salt lengths, but expects a 20
> byte hash length, even though PBKDF2HMAC regularly supports custom hash
> lengths.
>
> Other than adding a new format, or modifying the current format, is there
> any easy way to handle truncated hashes like this?
I'm not aware of an easier way.
You can extend the current format to support hashes with arbitrary lower
PBKDF2 output length (but perhaps no lower than 4 bytes or so, as you'd
run into certain difficulties otherwise). If you do that, it will then
be logical to extend other PBKDF2 formats to also support that.
If you choose to add a new format, that doesn't have to be a separate
source file duplicating all the functions. Instead, you can add a new
format struct to the existing source file and list most of the same
functions in there, overriding just some. We have such multi-format
source files already.
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.
