From: Alejandro Colomar <alx+linux-man@kernel.org>
To: Alejandro Colomar <alx@kernel.org>
Cc: 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: Tue, 10 Nov 2026 01:01:19 +0100 [thread overview]
Message-ID: <avJeq6_q5rpqoGlW@devuan> (raw)
In-Reply-To: <313da4c4e217a58e49e981f62d16bd15c97352bf.1794268615.git.alx@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 9107 bytes --]
> 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
+ (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>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-11-10 0:01 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 [this message]
2026-11-11 15:05 ` Serge E. Hallyn
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=avJeq6_q5rpqoGlW@devuan \
--to=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