[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANN] scrypt command-line utility and library
This reply is just to clarify a few things for you. It is not meant to
convince you, nor to argue with you.
Regarding the encoding syntax proposed at
On Wed, Jun 12, 2013 at 08:14:59PM +0200, JK wrote:
> I would start by adding it as optional with a command-line switch. But
> i'm not convinced of it being the optimum default format.
> - Password and salt length size restrictions
What length restrictions? I think there aren't any for these two things
you mentioned - (plaintext) password and salt.
The hash is fixed length at 256 bits, yes, but for password hashing use
(not a universal KDF) that's fine. When scrypt is used as KDF, there's
no need for an encoding like this.
> - Does not use the usual base64 algorithm but a traditional\historical
> one (But it seems only the two special characters differ)
It's a matter of taste, but I actually prefer the traditional crypt()'s
base 64 encoding to be used for new crypt() schemes.
As to how these differ, another detail is that base64 has padding,
whereas crypt()'s base 64 encoding does not.
> - Uses, and seems to redundantly prefix, the cryptic dollar sign for
> field delimiting
In these strings:
only the dollar sign after the "$7" prefix is technically redundant and
could be avoided by us - however, it has become a traditional part of
crypt() hash type identifiers starting with md5crypt's "$1$" in 1994.
The initial dollar sign is needed to make it unambiguous that we're
introducing a new hash type (and what follows is its ID prefix).
The dollar sign between the salt and the hash is needed to allow for any
salt length. In fact, the salt string may even contain the dollar sign,
as long as implementations are careful to search for this one delimiter
dollar sign from the end of string (mine does).