Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F13C3B9.3050509@hushmail.com>
Date: Mon, 16 Jan 2012 07:29:13 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Dragonfly BSD SHA2

On 01/16/2012 02:35 AM, magnum wrote:
> I started implementing these, but there's a hideous bug in both
> crypt-sha256 and crypt-sha512 that makes it less straight-forward:
> 
> 	static const char *magic = "$3$";
> 	...
> 	SHA256_Update(&ctx, magic, sizeof(magic));
> 
> I only noticed because it led my format to fail. It should obviously be
> strlen(magic). I presume this means hashes are not guaranteed to be
> portable between systems, maybe not even between versions of the lib.

And definitely not portable between 32-bit and 64-bit systems, of
course. It seems this code has been in use (and with sha-256 as default)
since April 26, 2011.

> I suppose I would need to create test hashes on a real system and then
> brute force what magic was really used (lol!) or insert debug code that
> does not interfere with this truly magic string :)

For now, I implemented formats for the 32-bit "versions" of the bugs.
This should mean a pointer size of 4: No unknown characters in the magic
but we are hashing the final null.

There was another silly bug in the crypt-sha512 code that I had to
mimic: The base64 step does not actually include the last 16 bits of output.

First versions of formats soon posted to GitHub. I haven't verified the
test hashes with a real system but they were verified with the original
libcrypt code.

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.