Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 7 Jan 2022 14:53:51 -0800
From: Lokkju Brennr <>
Subject: Re: Support for truncated pbkdf2-hmac-sha1 hashes?

Thanks! extending the current format turned out to be pretty effective, and
I've opened an issue for integrating the minimal necessary changes


~ Loki

On Fri, Jan 7, 2022 at 1:07 PM Solar Designer <> wrote:

> 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.