crypt-dev - Re: NUL bytes in Unix crypt SALT string using SHA-256 and SHA-512

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1374692192.67453.YahooMailNeo@web133006.mail.ir2.yahoo.com>
Date: Wed, 24 Jul 2013 19:56:32 +0100 (BST)
From: hakre <hanskrentel@...oo.de>
To: "crypt-dev@...ts.openwall.com" <crypt-dev@...ts.openwall.com>,
  Solar Designer <solar@...nwall.com>
Subject: Re: NUL bytes in Unix crypt SALT string using SHA-256 and SHA-512




----- Ursprüngliche Message -----
> Von: Solar Designer <solar@...nwall.com>
> An: crypt-dev@...ts.openwall.com; hakre <hanskrentel@...oo.de>
> CC: 
> Gesendet: 1:15 Mittwoch, 24.Juli 2013
> Betreff: Re: [crypt-dev] 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.

Thanks for the nice reminder. Moving forward is good :D

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

That makes perfect sense, thanks a lot for the feedback.

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

Thanks again even this was off-topic.

Have a good time

hakre

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.