10

I see a hashed passphrase like the following in /etc/shadow. I don't quite understand its format.

$y$j9T$F5Jx5fExrKuPp53xLKQ..1$X3DX6M94c7o.9agCG9G317fhZg9SqC.5i5rd.RhAtQ7

It is made of four parts as shown below. According to crypt(5), y means yescrypt.

https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en.html

- y
- j9T
- F5Jx5fExrKuPp53xLKQ..1
- X3DX6M94c7o.9agCG9G317fhZg9SqC.5i5rd.RhAtQ7

What is the meaning of the last three parts?

user15502206
  • 209
  • 1
  • 2
  • 3
  • 1
    Hard to believe that many distributions have switched to yescript as the default hashing algorithm, and none of them describe the `param` part, or why `j9T` is used there and why and what it means. – Stéphane Chazelas Jun 27 '22 at 15:03
  • 1
    [Here](https://unix.stackexchange.com/a/724514/451115) is an answer I provided to another, similar, question on the topic. It takes a deep dive of the `yescrypt` format and includes each of the fields. – NULLx Nov 12 '22 at 17:31

1 Answers1

13

The answer to "What is the meaning of the parts of the crypt(3) function":

  • id
  • param
  • salt
  • hash

As explained more in detail here.

Regarding the new yescrypt "passphrase hashing scheme", the meaning of the second field can be understood by reading this, and if you want even more information, you can also read the yescrypt v2 specification.

I did some more research, and it seems that the hashing is happening in the function yescrypt_r. You can see the different parameters definitions in the code.
In the case the id is 7, N is set to 2^x where x is the number in the first digit of param, and then r and p are both parsed using the function decode64_uint32_fixed from the rest of the param field.
In all other cases (i.e. only when id is y, since the function checks the value of id and returns if it isn't 7 or y), the source conditionally sets various different parameters, with a block of code written in such a way that I feel trying to understand it would go against the wishes of the original author. So I leave it as an exercise for the reader.

In that same file, The function yescrypt that follows it exposes a simpler interface, similar to the one of crypt(3).

7heo.tk
  • 231
  • 1
  • 5
  • 1
    So as far as I understand it, the password is hashed not encrypted. – not2savvy Mar 29 '21 at 07:00
  • I don't see which sentence in crypt(3) explains the four parts. Could you showed me the exact sentence that you refer to? Also, the filippo.io blog is not well written. I don't know what r N P refer to in my example. – user15502206 Mar 29 '21 at 14:07
  • @not2savvy indeed, AFAIR, the name `crypt` comes from the word "cryptography", in its broad sense, and was not meant to imply there was any reversible encryption happening. – 7heo.tk Mar 29 '21 at 16:52
  • 1
    @user15502206 the sentence that explains the four parts isn't in the man, but in the Wikipedia link. man pages are written by people who are perfectly familiar about a topic for people who are perfectly familiar about that topic; so for learning, I'd rank their value lower than the actual source code. The exact sentence is: "The format is defined as: `$[$=(,=)*][$[$]] `". The filippo.io blog only details the logical scrypt parameters, not how the `yescrypt` ones are implemented in `crypt(3)`. So, it is useful, but not directly. – 7heo.tk Mar 29 '21 at 17:02
  • 1
    @not2savvy, yep, you don't encrypt passwords, since it's not necessary to turn them back to plain text, so you _don't_ want that to be easily done. See e.g. https://security.stackexchange.com/q/211/118457 – ilkkachu Mar 29 '21 at 18:39
  • 2
    That obfuscated encoding of the parameters almost feels like a good reason not to use that hash... – ilkkachu Mar 29 '21 at 18:39
  • 2
    @not2savvy The very first version of `crypt()` actually did encrypt a fixed string with your password, hence this name which does not reflect today's processing. – xhienne Mar 29 '21 at 18:49
  • 1
    Hi, do you know what j9T means? Are there other available options in this field? Detailed materials of yescrypt lacks... – Steven Yang Jan 24 '22 at 12:17
  • *"I feel trying to understand it would go against the wishes of the original author"*. Do you mean the algorithm and configuration parameters are intentionally *obfuscated*? – Stéphane Chazelas Jun 27 '22 at 14:56