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.