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

[hakre]

Hi list,

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?

Can you share reason why/why not? What is your mental model of this "simple string" for the SALT?

I'm just puzzled while creating some edge-case checks/tests in my own software development and would like to get some kind of feedback I can lean on a bit. 

I assume yours here might be able to share.

So thanks for letting me know if

-- hakre

[p***@gmail.com]

Perhaps a glibc mailing list should be a better place to ask. Drepper, iirc, was the author of the crypto sha hash.

Best and sorry for the top posting
----Messaggio originale----
Da: hakre
Inviato: 23/07/2013, 18:25
A: crypt-***@lists.openwall.com
Oggetto: [crypt-dev] NUL bytes in Unix crypt SALT string using SHA-256 and SHA-512


Hi list,

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?

Can you share reason why/why not? What is your mental model of this "simple string" for the SALT?

I'm just puzzled while creating some edge-case checks/tests in my own software development and would like to get some kind of feedback I can lean on a bit. 

I assume yours here might be able to share.

So thanks for letting me know if

-- hakre

[hakre]

----- Ursprüngliche Message -----

Perhaps a glibc mailing list should be a better place to ask. Drepper, iirc, was 
the author of the crypto sha hash.

Yes, Ulrich Drepper was the author, this is the document including the specs incl. the code:

http://www.akkadia.org/drepper/SHA-crypt.txt


Sorry for not providing these details in my original request. I'll consider to mail with glibc, it's just my C skills are limited, otherwise I probably would be able to really answer that myself by reading his code.

Thanks.

-- hakre

[Solar Designer]

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.

Post by hakre
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

[hakre]

----- Ursprüngliche Message -----

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.

Post by hakre
I've got a clarification question regarding the (up-to 16 characters

used) SALT string for Unix crypt using SHA-256 and SHA-512.

Post by hakre
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