From: "Serge E. Hallyn" <serge@hallyn.com>
To: Alejandro Colomar <alx+linux-man@kernel.org>
Cc: Alejandro Colomar <alx@kernel.org>,
linux-man@vger.kernel.org, libc-alpha@sourceware.org,
Walter Harms <wharms@bfs.de>, Rich Felker <dalias@libc.org>,
~hallyn/shadow@lists.sr.ht, musl@lists.openwall.com
Subject: Re: [PATCH v1] man/man3/crypt.3: These functions accept many algorithms, not only DES
Date: Wed, 11 Nov 2026 09:05:40 -0600 [thread overview]
Message-ID: <avSERDjw/CeqN60U@hallyn.com> (raw)
In-Reply-To: <avJeq6_q5rpqoGlW@devuan>
On Tue, Nov 10, 2026 at 01:01:19AM +0100, Alejandro Colomar wrote:
> > Date: 2026-11-10 00:58:45+0100
> > From: Alejandro Colomar <alx@kernel.org>
> >
> > This page was written as if DES was the only portable algorithm, and
> > glibc was a weird one supporting other algorithms. These days (and
> > since a long time ago), DES has been long deprecated, and crypt(3)
> > supports many algorithms in all systems.
> >
> > Signed-off-by: Alejandro Colomar <alx@kernel.org>
> > ---
> >
> > Hi!
> >
> > The patch for documenting the detail about "*" will come later.
> > This was a cleanup that seemed necessary before doing that.
> > Let me know what you think about it. I'll reply with a copy of the
> > formatted page, so you don't need to apply the patch to review it.
>
> Below is a diff of the formatted page.
>
>
> Cheers,
> Alex
> ---
>
> $ MANWIDTH=64 diffman-git -U99 HEAD
> --- HEAD^:man/man3/crypt.3
> +++ HEAD:man/man3/crypt.3
> @@ -1,183 +1,155 @@
> crypt(3) Library Functions Manual crypt(3)
>
> NAME
> crypt, crypt_r - password hashing
>
> LIBRARY
> Password hashing library (libcrypt, -lcrypt)
>
> SYNOPSIS
> #include <unistd.h>
>
> char *crypt(const char *key, const char *salt);
>
> #include <crypt.h>
>
> char *crypt_r(const char *key, const char *salt,
> struct crypt_data *restrict data);
>
> Feature Test Macro Requirements for glibc (see fea‐
> ture_test_macros(7)):
>
> crypt():
> Since glibc 2.28:
> _DEFAULT_SOURCE
> glibc 2.27 and earlier:
> _XOPEN_SOURCE
>
> crypt_r():
> _GNU_SOURCE
>
> DESCRIPTION
> - crypt() is the password hashing function. It is based on
> - the Data Encryption Standard algorithm with variations in‐
> - tended (among other things) to discourage use of hardware
> - implementations of a key search.
> + crypt() is the password hashing function.
>
> key is a user’s typed password.
>
> - salt is a two‐character string chosen from the set
> - [a-zA-Z0-9./]. This string is used to perturb the algo‐
> - rithm in one of 4096 different ways.
> -
> - 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 hashed password, a series of 13 print‐
> - able ASCII characters (the first two characters represent
> - the salt itself). The return value points to static data
> - whose content is overwritten by each call.
> -
> - Warning: the key space consists of 2**56 equal 7.2e16 pos‐
> - sible values. Exhaustive searches of this key space are
> - possible using massively parallel computers. Software,
> - such as crack(1), is available which will search the por‐
> - tion of this key space that is generally used by humans
> - for passwords. Hence, password selection should, at mini‐
> - mum, avoid common words and names. The use of a passwd(1)
> - program that checks for crackable passwords during the se‐
> - lection process is recommended.
> -
> - The DES algorithm itself has a few quirks which make the
> - use of the crypt() interface a very poor choice for any‐
> - thing other than password authentication. If you are
> - planning on using the crypt() interface for a cryptography
> - project, don’t do it: get a good book on encryption and
> - one of the widely available DES libraries.
> + salt is a string used for determining the hasing algorithm
typo: hashing
> + (possibly including parameters). It is also used to per‐
> + turb the algorithm.
> +
> + The returned value points to the hashed password. The re‐
> + turn value points to static data whose content is over‐
> + written by each call.
>
> crypt_r() is a reentrant version of crypt(). The struc‐
> ture pointed to by data is used to store result data and
> bookkeeping information. Other than allocating it, the
> only thing that the caller should do with this structure
> is to set data->initialized to zero before the first call
> to crypt_r().
>
> RETURN VALUE
> On success, a pointer to the hashed password is returned.
> On error, NULL is returned.
>
> ERRORS
> EINVAL
> salt has the wrong format.
>
> ENOSYS
> The crypt() function was not implemented, probably
> because of U.S.A. export restrictions.
>
> EPERM /proc/sys/crypto/fips_enabled has a nonzero value,
> and an attempt was made to use a weak hashing type,
> such as DES.
>
> ATTRIBUTES
> For an explanation of the terms used in this section, see
> attributes(7).
> ┌─────────────────┬───────────────┬──────────────────────┐
> │ Interface │ Attribute │ Value │
> ├─────────────────┼───────────────┼──────────────────────┤
> │ crypt() │ Thread safety │ MT‐Unsafe race:crypt │
> ├─────────────────┼───────────────┼──────────────────────┤
> │ crypt_r() │ Thread safety │ MT‐Safe │
> └─────────────────┴───────────────┴──────────────────────┘
>
> STANDARDS
> crypt()
> POSIX.1‐2008.
>
> crypt_r()
> GNU.
>
> HISTORY
> crypt()
> POSIX.1‐2001, SVr4, 4.3BSD.
>
> Availability in glibc
> The crypt(), encrypt(3), and setkey(3) functions are part
> of the POSIX.1‐2008 XSI Options Group for Encryption and
> are optional. If the interfaces are not available, then
> the symbolic constant _XOPEN_CRYPT is either not defined,
> or it is defined to -1 and availability can be checked at
> run time with sysconf(3). This may be the case if the
> downstream distribution has switched from glibc crypt to
> libxcrypt. When recompiling applications in such distrib‐
> utions, the programmer must detect if _XOPEN_CRYPT is not
> available and include <crypt.h> for the function proto‐
> types; otherwise libxcrypt is an ABI‐compatible drop‐in
> replacement.
>
> NOTES
> - Features in glibc
> - The glibc version of this function supports additional
> - hashing algorithms.
> -
> + salt
> If salt is a character string starting with the characters
> "$id$" followed by a string optionally terminated by "$",
> then the result has the form:
>
> $id$salt$hashed
>
> id identifies the hashing method used instead of DES and
> this then determines how the rest of the password string
> is interpreted. The following values of id are supported:
> ID Method
> ───────────────────────────────────────────────────
> 1 MD5
> 2a Blowfish (not in mainline glibc; added in
> some Linux distributions)
> 5 SHA‐256 (since glibc 2.7)
> 6 SHA‐512 (since glibc 2.7)
>
> Thus, $5$salt$hashed and $6$salt$hashed contain the pass‐
> word hashed with, respectively, functions based on SHA‐256
> and SHA‐512.
>
> "salt" stands for the up to 16 characters following "$id$"
> in the salt. The "hashed" part of the password string is
> the actual computed password. The size of this string is
> fixed:
> MD5 22 characters
> SHA‐256 43 characters
> SHA‐512 86 characters
>
> The characters in "salt" and "hashed" are drawn from the
> set [a-zA-Z0-9./]. In the MD5 and SHA implementations the
> entire key is significant (instead of only the first 8
> bytes in DES).
>
> Since glibc 2.7, the SHA‐256 and SHA‐512 implementations
> support a user‐supplied number of hashing rounds, default‐
> ing to 5000. If the "$id$"charactersinthesaltare followed
> by "rounds=xxx$", where xxx is an integer, then the result
> has the form
>
> $id$rounds=yyy$salt$hashed
>
> where yyy is the number of hashing rounds actually used.
> The number of rounds actually used is 1000 if xxx is less
> than 1000, 999999999 if xxx is greater than 999999999, and
> is equal to xxx otherwise.
>
> SEE ALSO
> login(1), passwd(1), encrypt(3), getpass(3), passwd(5)
>
> Linux man‐pages (unreleased) (date) crypt(3)
>
>
> --
> <https://www.alejandro-colomar.es>
next prev parent reply other threads:[~2026-11-11 15:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 23:58 [PATCH v1] man/man3/crypt.3: These functions accept many algorithms, not only DES Alejandro Colomar
2026-11-10 0:01 ` Alejandro Colomar
2026-11-11 15:05 ` Serge E. Hallyn [this message]
2026-11-11 18:55 ` Alejandro Colomar
2026-11-11 21:13 ` [musl] " Rich Felker
2026-11-11 21:43 ` Alejandro Colomar
2026-11-12 1:52 ` Vincent Lefevre
2026-11-12 2:53 ` Rich Felker
2026-11-12 3:29 ` Vincent Lefevre
2026-11-12 3:37 ` [musl] " Rich Felker
2026-11-12 10:28 ` Alejandro Colomar
2026-11-12 11:40 ` Vincent Lefevre
2026-11-12 12:08 ` Alejandro Colomar
2026-11-12 13:15 ` Vincent Lefevre
2026-11-12 13:26 ` Alejandro Colomar
2026-11-12 12:08 ` Rich Felker
2026-11-12 12:27 ` Alejandro Colomar
2026-11-12 12:41 ` Szabolcs Nagy
2026-11-12 13:12 ` Alejandro Colomar
2026-11-12 13:27 ` Vincent Lefevre
2026-11-12 13:17 ` Vincent Lefevre
2026-11-12 13:23 ` Alejandro Colomar
2026-11-12 13:45 ` Vincent Lefevre
2026-11-12 13:55 ` Rich Felker
2026-11-12 14:07 ` Alejandro Colomar
2026-11-12 14:43 ` Rich Felker
2026-11-12 14:58 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avSERDjw/CeqN60U@hallyn.com \
--to=serge@hallyn.com \
--cc=alx+linux-man@kernel.org \
--cc=alx@kernel.org \
--cc=dalias@libc.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=musl@lists.openwall.com \
--cc=wharms@bfs.de \
--cc=~hallyn/shadow@lists.sr.ht \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox