[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Jul 2013 03:15:21 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com, hakre <hanskrentel@...oo.de>
Subject: Re: NUL bytes in Unix crypt SALT string using SHA-256 and SHA-512
Hi hakre,
I'm afraid your question is mostly off-topic for this mailing list.
On this mailing list, we're not very interested in fine details of the
existing password hashing methods - rather, we're interested in moving
forward. So the only relevant aspect close to your question is: "should
future password hashing methods allow arbitrary salts, or would C
strings be OK?" This new question has been sort of answered in the PHC
call for submissions - https://password-hashing.net/call.html - "A salt
of 16 bytes", "const void *salt, size_t saltlen" - thus, NULs may be
embedded in the salt. However, if/when a crypt(3) interface is created
on top of a PHC submission, it will have the "no embedded NULs"
restriction for its salt strings (at the crypt(3) interface level at
least) due to how crypt(3) is defined.
As to your actual off-topic question, see below:
On Tue, Jul 23, 2013 at 05:25:14PM +0100, hakre wrote:
> I've got a clarification question regarding the (up-to 16 characters used) SALT string for Unix crypt using SHA-256 and SHA-512.
>
> Is it acceptable by the definition of the algorithm to provide 16 NUL bytes? In the meaning that those 16 chars are used as SALT?
The reference implementation uses C strings, so if it is considered part
of the definition then you technically can't have embedded NULs.
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.
