Yes, I've googled this, no I didn't find an answer.

Some versions of glibc have been extended to support blowfish (algo 2a) in the
crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if
its supported on a given system as crypt() has the very unhelpful behaviour of
SIGSEGV'ing if you give it an invalid encryption algo number.

Muttley@dastardlyhq.com writes:
>Yes, I've googled this, no I didn't find an answer.
>
>Some versions of glibc have been extended to support blowfish (algo 2a) in the
>crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if
>its supported on a given system as crypt() has the very unhelpful behaviour of
>SIGSEGV'ing if you give it an invalid encryption algo number.
>

Have you considered using openssl instead?

On Fri, 28 Oct 2022 15:09:57 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>Yes, I've googled this, no I didn't find an answer.
>>
>>Some versions of glibc have been extended to support blowfish (algo 2a) in
>the
>>crypt via the $2a$ preamble in the salt. Does anyone know of a way to check
>if
>>its supported on a given system as crypt() has the very unhelpful behaviour
>of
>>SIGSEGV'ing if you give it an invalid encryption algo number.
>>
>
>Have you considered using openssl instead?

This has nothing to do with sockets.

Muttley@dastardlyhq.com writes:
>On Fri, 28 Oct 2022 15:09:57 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:
>>>Yes, I've googled this, no I didn't find an answer.
>>>
>>>Some versions of glibc have been extended to support blowfish (algo 2a) in
>>the
>>>crypt via the $2a$ preamble in the salt. Does anyone know of a way to check
>>if
>>>its supported on a given system as crypt() has the very unhelpful behaviour
>>of
>>>SIGSEGV'ing if you give it an invalid encryption algo number.
>>>
>>
>>Have you considered using openssl instead?
>
>This has nothing to do with sockets.
>

Openssl is a generalized cryptographic library that supports pretty much
every standard symmetric and asymmetric crypto algorithm. It does far
more than support transport level security. It's the primary toolkit
(aside from RSA BSAFE) used in cryptographic software of all forms.

On Fri, 28 Oct 2022 15:45:02 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Fri, 28 Oct 2022 15:09:57 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>Muttley@dastardlyhq.com writes:
>>>>Yes, I've googled this, no I didn't find an answer.
>>>>
>>>>Some versions of glibc have been extended to support blowfish (algo 2a) in
>>>the
>>>>crypt via the $2a$ preamble in the salt. Does anyone know of a way to check
>>>if
>>>>its supported on a given system as crypt() has the very unhelpful behaviour
>>>of
>>>>SIGSEGV'ing if you give it an invalid encryption algo number.
>>>>
>>>
>>>Have you considered using openssl instead?
>>
>>This has nothing to do with sockets.
>>
>
>Openssl is a generalized cryptographic library that supports pretty much
>every standard symmetric and asymmetric crypto algorithm. It does far
>more than support transport level security. It's the primary toolkit
>(aside from RSA BSAFE) used in cryptographic software of all forms.

Looks like an absolute PITA to use for that with contect creation and init
calls (why?) whereas crypt() is a single standalone function call that returns
the encrypted data. I'll pass.

Scott Lurndal, dans le message <9hS6L.680938$Ny99.558805@fx16.iad>, a
écrit :
> Have you considered using openssl instead?

Are you sure you understand what crypt() does?

Muttley@dastardlyhq.com writes:
>On Fri, 28 Oct 2022 15:45:02 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:
>>>On Fri, 28 Oct 2022 15:09:57 GMT
>>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>>Muttley@dastardlyhq.com writes:
>>>>>Yes, I've googled this, no I didn't find an answer.
>>>>>
>>>>>Some versions of glibc have been extended to support blowfish (algo 2a) in
>>>>the
>>>>>crypt via the $2a$ preamble in the salt. Does anyone know of a way to check
>>>>if
>>>>>its supported on a given system as crypt() has the very unhelpful behaviour
>>>>of
>>>>>SIGSEGV'ing if you give it an invalid encryption algo number.
>>>>>
>>>>
>>>>Have you considered using openssl instead?
>>>
>>>This has nothing to do with sockets.
>>>
>>
>>Openssl is a generalized cryptographic library that supports pretty much
>>every standard symmetric and asymmetric crypto algorithm. It does far
>>more than support transport level security. It's the primary toolkit
>>(aside from RSA BSAFE) used in cryptographic software of all forms.
>
>Looks like an absolute PITA to use for that with contect creation and init
>calls (why?) whereas crypt() is a single standalone function call that returns
>the encrypted data. I'll pass.
>

openssl will opportunistically use cryptographic hardware on the
host, when available. A big deal for production software. For toy
software, crypt() may be easy to use, but not necessarily efficient.

Yes, it has a complex API.

Nicolas George <nicolas$george@salle-s.org> writes:
>Scott Lurndal, dans le message <9hS6L.680938$Ny99.558805@fx16.iad>, a
> �crit�:
>> Have you considered using openssl instead?
>
>Are you sure you understand what crypt() does?

Are you sure you understand what opensll does?

Hint, it supports all forms of symmetric and asymmetric
cryptographic algorithms for stand-alone software as
well as supporting transport layer security.

scott@slp53.sl.home (Scott Lurndal) writes:
>Nicolas George <nicolas$george@salle-s.org> writes:
>>Scott Lurndal, dans le message <9hS6L.680938$Ny99.558805@fx16.iad>, a
>> �crit�:
>>> Have you considered using openssl instead?
>>
>>Are you sure you understand what crypt() does?
>
>Are you sure you understand what opensll does?
>
>Hint, it supports all forms of symmetric and asymmetric
>cryptographic algorithms for stand-alone software as
>well as supporting transport layer security.

FWIW, I spent four years at Verisign doing crypto
software and my CPOE designs and sells high-end cryptographic processors.

On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:

> On Fri, 28 Oct 2022 15:45:02 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:
>>>On Fri, 28 Oct 2022 15:09:57 GMT
>>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>>Muttley@dastardlyhq.com writes:
>>>>>Yes, I've googled this, no I didn't find an answer.
>>>>>
>>>>>Some versions of glibc have been extended to support blowfish (algo 2a) in
>>>>the
>>>>>crypt via the $2a$ preamble in the salt. Does anyone know of a way to check
>>>>if
>>>>>its supported on a given system as crypt() has the very unhelpful behaviour
>>>>of
>>>>>SIGSEGV'ing if you give it an invalid encryption algo number.
>>>>>
>>>>
>>>>Have you considered using openssl instead?
>>>
>>>This has nothing to do with sockets.
>>>
>>
>>Openssl is a generalized cryptographic library that supports pretty much
>>every standard symmetric and asymmetric crypto algorithm. It does far
>>more than support transport level security. It's the primary toolkit
>>(aside from RSA BSAFE) used in cryptographic software of all forms.
>
> Looks like an absolute PITA to use for that with contect creation and init
> calls (why?) whereas crypt() is a single standalone function call that returns
> the encrypted data. I'll pass.

Actually, crypt(3) doesn't return encrypted data; that would imply that there
is a way to decrypt the results of crypt(3), which there is not.

crypt(3) returns a suitably-composed encryption "signature" of the original
data. Specifically, it uses the original data, along with a "salt" value, as
an encryption key. It applies this key to encrypt a constant value (usually
a field of binary zeros) using the chosen encryption algorithm. What you get
back is nothing more than an anonymous data blob, encrypted using your
original data as a part of the encryption key. To decrypt the resulting data
would be useless; you'd get back that blob of zeros. To recover the data
given to crypt(3), you must /recover or recreate the encryption key/,
which is a much harder task.

While Openssl can generate message digests, that process would be much
more involved than a simple call to crypt(3).

--
Lew Pitcher
"In Skills, We Trust"

Scott Lurndal, dans le message <M4T6L.348053$elEa.147813@fx09.iad>, a
écrit :
>>Hint, it supports all forms of symmetric and asymmetric
>>cryptographic algorithms for stand-alone software as
>>well as supporting transport layer security.

So now I am sure you do not understand what crypt does().

On 2022-10-28, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> Yes, I've googled this, no I didn't find an answer.
>
> Some versions of glibc have been extended to support blowfish (algo 2a) in the
> crypt via the $2a$ preamble in the salt. Does anyone know of a way to check if
> its supported on a given system as crypt() has the very unhelpful behaviour of
> SIGSEGV'ing if you give it an invalid encryption algo number.

I have experience in this area, having integrated crypt into the TXR
Lisp language, and worked around the embarrassing segfault issue.

This is the TXR Lisp interactive listener of TXR 283.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
Remove TXR any time for a complete refund of your disk space.
1> (crypt "foo" "abc")
"abQ9KY.KfrYrc"
2> (crypt "foo" "$1$abc")
"$1$abc$/ThTVu/5nq9QB8iGNy5rp/"
3> (crypt "foo" "$2$abc")
** crypt failed: 22/"Invalid argument"
** during evaluation at expr-3:1 of form (crypt "foo" "$2$abc")
3> (crypt "foo" "$2a$abc")
** crypt failed: 22/"Invalid argument"
** during evaluation at expr-3:1 of form (crypt "foo" "$2a$abc")
3> (crypt "foo" "$5$abc")
"$5$abc$SNQ2QQBO1ax39EAHKvvnCoQB2LZIm1UiTfvRzzx0ud8"
4> (crypt "foo" "$7$abc")
** crypt failed: 22/"Invalid argument"
** during evaluation at expr-4:1 of form (crypt "foo" "$7$abc")

Why doesn't it segfault for $7$?

Because my wrapper function lexically analyzes the salt
to validate for good cases that don't crash, and only those
go through to crypt. For the cases that would crash if
crypt were called, it simulates the EINVAL error.

See the crypt_wrap function and its validate_salt helper
in this source file:

http://www.kylheku.com/cgit/txr/tree/sysif.c

validate_salt processes a wchar_t * string because that's
what the project uses everywhere for strings. It goes
to UTF-8 before handing it to crypt. This is 2-Clause BSD
licensed code so you have a lot of freedom with it,
like converting to char *.

If you happen use the code/approach and find cases that sneak through
and cause crypt to crash, please drop me a note.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
> Nicolas George <nicolas$george@salle-s.org> writes:
>>Scott Lurndal, dans le message <9hS6L.680938$Ny99.558805@fx16.iad>, a
>> écrit :
>>> Have you considered using openssl instead?
>>
>>Are you sure you understand what crypt() does?
>
> Are you sure you understand what opensll does?
>
> Hint, it supports all forms of symmetric and asymmetric
> cryptographic algorithms for stand-alone software as
> well as supporting transport layer security.

It's an extra dependency to add to a program, whereas
crypt is in any POSIX glibc (and we can probe it at run-time
for glibc extensions).

if a program just wants to detect whether the glibc "$2a"
is available, and maybe doesn't even care if the answer is
no, then it's rather a big detour to bring in openssl
and muck around with its Blowfish API.

I'm looking at the "openssl passwd" man page for the password
hashing command on a system here. It doesn't have Blowfish
either, only -1, -5, -6, -apr1 and -aixmd5. The first
three are like $1$, $5$ and $6$ in glibc crypt.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
> openssl will opportunistically use cryptographic hardware on the
> host, when available. A big deal for production software. For toy
> software, crypt() may be easy to use, but not necessarily efficient.

Nobody needs crypt to be fast, other than password crackers.

Crypt is only required during password authentication. Maybe if you have
a single box with ten million users, each of whom is doing nothing
but logging in and out once a second, you might benefit from
hardware-accelerated crypt.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
>> openssl will opportunistically use cryptographic hardware on the
>> host, when available. A big deal for production software. For toy
>> software, crypt() may be easy to use, but not necessarily efficient.
>
>Nobody needs crypt to be fast, other than password crackers.
>
>Crypt is only required during password authentication. Maybe if you have
>a single box with ten million users, each of whom is doing nothing
>but logging in and out once a second, you might benefit from
>hardware-accelerated crypt.

Who still uses crypt for password authentication[*]? Most use
message digests or secure hashes. The OP wanted to override the
algorithm with blowfish anyway, using openssl's BF_set_key() and BF_ecb_encrypt()
is relatively straightforward. Typical linux systems use MD5 hashes.

[*] the man page recommends against using crypt for cryptography
projects generally, except for backwards compatability with
legacy password authentication using DES.

On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> openssl will opportunistically use cryptographic hardware on the
>>> host, when available. A big deal for production software. For toy
>>> software, crypt() may be easy to use, but not necessarily efficient.
>>
>>Nobody needs crypt to be fast, other than password crackers.
>>
>>Crypt is only required during password authentication. Maybe if you have
>>a single box with ten million users, each of whom is doing nothing
>>but logging in and out once a second, you might benefit from
>>hardware-accelerated crypt.
>
> Who still uses crypt for password authentication[*]? Most use

Probably, nobody; but they use the crypt API function.

For instance, in an Ubuntu system here, I have this in /etc/shadow:

root:$6$[...edited out...]:18246:0:99999:7:::

$6$ indicates SHA-512. This is the same as what openssl passwd will
generate with the -6 argument.

Your login program and whatnot check that with crypt().

> algorithm with blowfish anyway, using openssl's BF_set_key() and BF_ecb_encrypt()
> is relatively straightforward. Typical linux systems use MD5 hashes.

Not so much any more, I think.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Fri, 28 Oct 2022 16:01:31 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Fri, 28 Oct 2022 15:45:02 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>Muttley@dastardlyhq.com writes:
>>>>On Fri, 28 Oct 2022 15:09:57 GMT
>>>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>>>Muttley@dastardlyhq.com writes:
>>>>>>Yes, I've googled this, no I didn't find an answer.
>>>>>>
>>>>>>Some versions of glibc have been extended to support blowfish (algo 2a) in
>
>>>>>the
>>>>>>crypt via the $2a$ preamble in the salt. Does anyone know of a way to
>check
>>>>>if
>>>>>>its supported on a given system as crypt() has the very unhelpful
>behaviour
>>>>>of
>>>>>>SIGSEGV'ing if you give it an invalid encryption algo number.
>>>>>>
>>>>>
>>>>>Have you considered using openssl instead?
>>>>
>>>>This has nothing to do with sockets.
>>>>
>>>
>>>Openssl is a generalized cryptographic library that supports pretty much
>>>every standard symmetric and asymmetric crypto algorithm. It does far
>>>more than support transport level security. It's the primary toolkit
>>>(aside from RSA BSAFE) used in cryptographic software of all forms.
>>
>>Looks like an absolute PITA to use for that with contect creation and init
>>calls (why?) whereas crypt() is a single standalone function call that
>returns
>>the encrypted data. I'll pass.
>>
>
>openssl will opportunistically use cryptographic hardware on the
>host, when available. A big deal for production software. For toy

Is it? Depends how often you'll be calling it. For user password checks I
doubt you'll be doing it more than a few times a minute at most.

>software, crypt() may be easy to use, but not necessarily efficient.

So /bin/login is toy software?

>Yes, it has a complex API.

Which is a problem with a lot of modern frameworks.

On Fri, 28 Oct 2022 16:17:17 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:
>> Looks like an absolute PITA to use for that with contect creation and init
>> calls (why?) whereas crypt() is a single standalone function call that
>returns
>> the encrypted data. I'll pass.
>
>Actually, crypt(3) doesn't return encrypted data; that would imply that there
>is a way to decrypt the results of crypt(3), which there is not.

That depends on how you personally define encryption. Others have different
ideas.

https://man7.org/linux/man-pages/man3/crypt.3.html

"crypt() is the password encryption function."

On Fri, 28 Oct 2022 18:15:21 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2022-10-28, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> Yes, I've googled this, no I didn't find an answer.
>>
>> Some versions of glibc have been extended to support blowfish (algo 2a) in
>the
>> crypt via the $2a$ preamble in the salt. Does anyone know of a way to check
>if
>> its supported on a given system as crypt() has the very unhelpful behaviour
>of
>> SIGSEGV'ing if you give it an invalid encryption algo number.
>
>I have experience in this area, having integrated crypt into the TXR
>Lisp language, and worked around the embarrassing segfault issue.
>
>Why doesn't it segfault for $7$?
>
>Because my wrapper function lexically analyzes the salt
>to validate for good cases that don't crash, and only those
>go through to crypt. For the cases that would crash if
>crypt were called, it simulates the EINVAL error.
>See the crypt_wrap function and its validate_salt helper
>in this source file:
>
>http://www.kylheku.com/cgit/txr/tree/sysif.c

That doesn't help to determine if a given system would support a given
encryption function because your code simply has hard coded validation.

My problem is that some versions of glibc support $2a$ and some don't and I
can't find any way of determining on the fly which they are short of calling
crypt() and seeing if it crashes which obviously is not very useful on a
running system as I don't want to be catching SIGSEGV just for this case.

On Fri, 28 Oct 2022 18:27:33 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>Scott Lurndal, dans le message <9hS6L.680938$Ny99.558805@fx16.iad>, a
>>> écrit :
>>>> Have you considered using openssl instead?
>>>
>>>Are you sure you understand what crypt() does?
>>
>> Are you sure you understand what opensll does?
>>
>> Hint, it supports all forms of symmetric and asymmetric
>> cryptographic algorithms for stand-alone software as
>> well as supporting transport layer security.
>
>It's an extra dependency to add to a program, whereas
>crypt is in any POSIX glibc (and we can probe it at run-time
>for glibc extensions).

How do we probe it without it crashing? Thats what I'm trying to find out.
Even a macro I can put in an #ifdef would work.

On Fri, 28 Oct 2022 22:13:24 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>On 2022-10-28, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> openssl will opportunistically use cryptographic hardware on the
>>> host, when available. A big deal for production software. For toy
>>> software, crypt() may be easy to use, but not necessarily efficient.
>>
>>Nobody needs crypt to be fast, other than password crackers.
>>
>>Crypt is only required during password authentication. Maybe if you have
>>a single box with ten million users, each of whom is doing nothing
>>but logging in and out once a second, you might benefit from
>>hardware-accelerated crypt.
>
>Who still uses crypt for password authentication[*]? Most use
>message digests or secure hashes. The OP wanted to override the
>algorithm with blowfish anyway, using openssl's BF_set_key() and
>BF_ecb_encrypt()

Why does OpenSSL require so many stages to do such a simple task?

ie: Here is the key, salt and encryption type, now give me the encrypted
data. That can be a single function call.

Muttley@dastardlyhq.com, dans le message <tjin0r$9rb$1@gioia.aioe.org>,
a écrit :
> How do we probe it without it crashing?

Fork to insulate the crash and probe.

On 29 Oct 2022 09:21:50 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>Muttley@dastardlyhq.com, dans le message <tjin0r$9rb$1@gioia.aioe.org>,
> a �crit�:
>> How do we probe it without it crashing?
>
>Fork to insulate the crash and probe.

Yes, that would work but its a lot of effort. Surely glibc must have some
way of informing you whether it supports it?

On Sat, 29 Oct 2022 07:58:13 +0000, Muttley wrote:

> On Fri, 28 Oct 2022 16:17:17 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:
>>> Looks like an absolute PITA to use for that with contect creation and init
>>> calls (why?) whereas crypt() is a single standalone function call that
>>returns
>>> the encrypted data. I'll pass.
>>
>>Actually, crypt(3) doesn't return encrypted data; that would imply that there
>>is a way to decrypt the results of crypt(3), which there is not.
>
> That depends on how you personally define encryption. Others have different
> ideas.
>
> https://man7.org/linux/man-pages/man3/crypt.3.html
>
> "crypt() is the password encryption function."

Despite what the crypt(3) manpage's summary implies, the
manpage does detail the operation that crypt(3) performs:
"By taking the lowest 7 bits of each of the first eight characters
of the key, a 56-bit key is obtained. This 56-bit key is used to
encrypt repeatedly a constant string (usually a string consisting
of all zeros). The returned value points to the encrypted
password, a series of 13 printable ASCII characters (the first
two characters represent the salt itself). The return value
points to static data whose content is overwritten by each call."

So, as you can see, crypt(3) does /not/ encrypt the password, it
encrypts a "constant string" using a key derived from the password
and the salt. Decrypting the results of crypt(3), if at all
successful, will return only that "constant string" that was
encrypted.

--
Lew Pitcher
"In Skills, We Trust"

On 10/29/2022 3:58 AM, Muttley@dastardlyhq.com wrote:
> On Fri, 28 Oct 2022 16:17:17 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Fri, 28 Oct 2022 15:52:07 +0000, Muttley wrote:
>>> Looks like an absolute PITA to use for that with contect creation and init
>>> calls (why?) whereas crypt() is a single standalone function call that
>> returns
>>> the encrypted data. I'll pass.
>>
>> Actually, crypt(3) doesn't return encrypted data; that would imply that there
>> is a way to decrypt the results of crypt(3), which there is not.
>
> That depends on how you personally define encryption. Others have different
> ideas.
>
> https://man7.org/linux/man-pages/man3/crypt.3.html
>
> "crypt() is the password encryption function."
>

crypt() , at least in one place, is deprecated.

There is a substitution library which may be deployed.
You could check a Ubuntu Synaptic package manager or
do "apt search crypt" and see what packages are available/installed.

https://launchpad.net/ubuntu/+source/libxcrypt/1:4.4.28-2

"libxcrypt is a modern library for one-way hashing of passwords.
It supports

DES
MD5
NTHASH
SUNMD5
SHA-2-256
SHA-2-512
bcrypt-based password hashes

It provides the traditional Unix 'crypt' and 'crypt_r' interfaces,
as well as a set of extended interfaces like 'crypt_gensalt'.
"

The SHA512 might bring you closer in line with current practice.

If I look at /etc/shadow in Ubuntu in WSL2 in Windows 11, I see

paul:$6$Igyn9e...

and the $6 suggests SHA512 is being used.

Paul